Introduction to Software Engineering ECSE-321 Unit 5 – Modeling with UML

Introduction to Software Engineering

ECSE-321

Unit 5 – Modeling with UML

Introduction to Software Engineering – ECSE321

Modeling

Describing a system at a high level of abstraction● A model of the system● Used for requirements and specification

Many notations over time● State machines● Entity-relationship diagrams● Dataflow diagrams

Winter 2009, Maheswaran Unit 5 – Modeling in UML /2

Introduction to Software Engineering – ECSE321Winter 2009, Maheswaran Unit 5 – Modeling in UML /3

Why model software?

Software is already an abstraction: why model software?Software is getting larger, not smaller

● Firefox ~ 2 MLOC● Windows XP ~ 40 MLOC (Vista ~ 50 MLOC)● Mac OS X ~ 86 MLOC● Adobe CS ~ 100 MLOC● A single programmer cannot manage this amount of code

in its entirety. Code is often not directly understandable by developers

(who did not participate in the development)We need simpler representations for complex systems


Systems, Models, and Views

A system is an organized set of communicating parts

A model is an abstraction describing a system or a subset of a system

A view depicts selected aspects of a modelA notation is a set of graphical or textual rules

for representing views


What is UML?

UML (Unified Modeling Language) – a notation●A standard for modeling object-oriented software

SpecifyingVisualizingConstructingDocumenting

●Language independent (OO)●Designed by a committee

Reference: “The Unified Modeling Language User Guide”, Addison Wesley, 1999.

• www.uml.org

http://www.uml.org/


What is UML?

Resulted from the convergence of notations from three leading object-oriented methods:

OMT (James Rumbaugh), OOSE (Ivar Jacobson), Booch (Grady Booch), etc.

First edition: 1995, belongs to the Object Management Group (www.omg.org)

Resulting design is huge● Many features● Many loosely unrelated styles under one roof

Could be called “union of all modeling languages”!

http://www.omg.org/


UML Aspects Covered HereFunctional models (functional behavior of the system as

seen by the user)● Use case diagrams

Structural models (static structure of the system: Objects, Attributes, and Associations)

● Class diagrams● Object diagrams

Dynamic models (dynamic behavior between actors and the system and between objects of the system)

● Sequence diagrams● Activity diagrams● State diagrams


Use Case Diagrams

Used during requirements elicitation to represent external behavior

Actors represent roles, that is, a type of user of the system

Use cases represent a sequence of interaction for a type of functionality

The use case model is the set of all use cases. It is a complete description of the functionality of the system and its environment

A solid line represents communications between actors and use cases

Passenger

PurchaseTicket

Communicate


Actors

An actor models an external entity which communicates with the system:

● User● External system● Physical environment

An actor has a unique name and a description

Examples:● Passenger: A person in the train● GPS satellite: Provides the system with GPS

coordinates● External database

Passenger


Use CaseA use case represents a class of

functionality provided by the system as an event flow.

A use case consists of:Unique nameParticipating actorsEntry conditionsNormal Flow of eventsAlternate Flow of EventsExit conditionsSpecial requirements (e.g., quality

requirements)

PurchaseTicket


Use Case Diagram Example

WatchUser WatchRepairPerson

ReadTime

SetTime

ChangeBattery

Actor

Use case

PackageSimpleWatch

Functionality of the system from user’s point of view


Use Case Example

Name: PurchaseTicket

Participating actor: Passenger

Entry condition: Passenger standing in front of

ticket distributor. Passenger has sufficient

money to purchase ticket.

Exit condition: Passenger has ticket.

Event flow:1. Passenger selects the

destination to be traveled.

2. Distributor displays the amount due.

3. Passenger inserts money, of at least the amount due.

4. Distributor returns change.

5. Distributor issues ticket.


Scenarios

An instance of a use case● Concrete (names,

actions)● All names are

specific and underlined

● Flow of events is step by step

Name: purchaseTicketCCDeclined

Participating actor: mike:Passenger

Flow of events:

1. Mike stands in front of ticket machine and selects Toronto as destination

2. Distributor displays amount due

3. Mike inserts credit card

4. Distributor checks credit card validity with company. Credit card is declined.

5. Distributor ask for cash

6. Mike pays cash

7. Ticket is issued to Mike


The <<extend>> Relationship

Passenger

PurchaseTicket

TimeOut

<<extend>>

NoChange

<<extend>>OutOfOrder

<<extend>>

Cancel

<<extend>>


Extend

Models optional behavior in the system● new functionality to the customer● functionality for a future iteration

The direction of the <<extend>> relationship is to the extended use case

Use cases representing exceptional flows can extend more than one use case

If it is removed or not implemented, there is no impact on the system (the related use case does not know about the extension)


Passenger

PurchaseSingleTicket

PurchaseMonthlyPass

<<include>>

CollectMoney

<<include>>

The <<include>> Relationship (re-use)


Include

An <<include>> relationship represents behavior that is factored out of the use case.

An <<include>> represents behavior that is factored out for reuse

The direction of a <<include>> relationship is to the included use case (unlike <<extend>> relationships).


Inheritance RelationshipRefinement of one use

case by another (“kind of” relationship)

A solid line with triangle pointing to the basic use case

Different from <<extend>> which describes a different flow of events

CollectMoneyWithCard

CollectMoneyWithVISA

CollectMoneyWithAMEX

Introduction to Software Engineering – ECSE321

Class Diagrams

Describe classes – in the OO sense

Class diagrams are static – they display what interacts but not what happens when they do interact

Each box is a class● list of fields● list of methods

Winter 2009, Maheswaran Unit 5 – Modeling in UML /19

Train

addStop (stop)startTrain(velocity)stopTrain()openDoors()closeDoors()

lastStopnextStopvelocitydoorsOpen?


Classes

A class represent a concept● Attribute and behavior of a set of objects

Each attribute has a typeEach operation may have a signatureThe class name is the only mandatory information.

zone2pricegetZones()getPrice()

TariffSchedule

Table zone2priceEnumeration getZones()Price getPrice(Zone)

TariffSchedule

Name

Attributes

Operations

Signature

TariffSchedule

Type


Class Diagrams

Class diagrams are used● during requirements analysis to model problem domain

concepts● during system design to model subsystems and interfaces● during object design to model classes.

Different kinds of edges to show relationships between classes

TariffSchedule

* *

TripLegprice: Pricezone: ZoneEnumeration getZones()

Price getPrice(Zone)


Objects (instances)

An object encapsulates state and behaviorAn object has an indistinguishable identity An object represents a phenomenonThe name of an instance is underlined and can contain

the class of the instanceThe attributes are represented with their values

zone2price = {{‘1’, 20},{‘2’, 40},{‘3’, 60}}

tariff_1372:TarifScheduleunderline

d


Actor vs. Instances

What is the difference between an actor and a class and an instance?

Actor: ● An entity outside the system to be modeled, interacting with

the system (“Ticker Purchaser”)Class:

● An abstraction modeling an entity in the problem domain, inside the system to be modeled (“Tariff Database”)

Object: ● A specific instance of a class (“Joe, the traveler”, “The Tariff

Database from Montreal to Quebec City”)


Associations

Associations denote relationships between classes (“know of”)

Typically implemented by pointersThe multiplicity of an association end denotes how many

objects the source object can legitimately referenceUsually bi-directional – both classes “know of” each other

Enumeration getZones()Price getPrice(Zone)

TarifSchedule

*pricezone

TripLeg

*


1-to-1 and 1-to-Many Associations

1-to-1 association

1-to-many association

*

draw()

Polygon

x:Integery:Integer

Point1

Has-capital

name:String

Country

name:String

City11


Many-to-Many and Navigational Associations

many-to-many association

*

draw()

Polygon

x:Integery:Integer

Point*

1-to-many associationwith navigation – direction of usage

*

draw()

Polygon

x:Integery:Integer

Point1


AggregationAn aggregation is a special case of association

denoting a “consists of” hierarchyThe aggregate is the parent class, the

components are the children class

1

Car

Engine Wheels

3..6

VIN11

1

1


Composition

A solid diamond denote composition, a strong form of aggregation where components cannot exist without the aggregate.

3

TicketMachine

ZoneButton

1


Dependency

“I need your services, but I don’t know that you exist” (client-supplier). Dashed line from client to supplier

Other examples?

draw()

Polygon 3DShadingAlgorithm


Generalization

Generalization relationships denote inheritance between classes (“a type of”)

The children classes inherit the attributes and operations of the parent class

Generalization simplifies the model by eliminating redundancy

Button

ZoneButtonCancelButton

Abstract classes

are italicized


A File System Example

FileSystemElement

FileDirectory

*

1

FileSystemElement

FileDirectory

*

*

Standard FS

Non hierarchical FS


From Problem Statement to CodeProblem StatementA stock exchange lists many companies. Each company is identified by a ticker symbol

Class Diagram

Java Code

public class StockExchange { public Vector Companies = new Vector();};public class Company { public string tickerSymbol; public Vector stockExchanges = new Vector();};

*StockExchange

tickerSymbol

Company*lists


Example - ATM

What are the actors?Use cases?Relationship between actors and use

cases




UML Sequence Diagrams

Used during requirements analysis● To refine use case descriptions● to find additional objects

(“participating objects”) Used during system design

● to refine subsystem interfaces Classes are represented by

columns Messages are represented by

arrows Activations are represented by

narrow rectangles Lifelines are represented by

dashed lines (parallel to activations)

selectZone ()

pickupChange()

pickUpTicket()

insertCoins()

PassengerTicketMachine


UML Sequence Diagrams: Nested Messages

The source of an arrow indicates the activation which sent the message

An activation is as long as all nested activationsDashed line denoted return of data flow

selectZone()

PassengerZoneButton TarifSchedule Display

lookupPrice(selection)

displayPrice(price)

price

Dataflowreturn

…to be continued...

Nested Activation


Sequence Diagram Observations

UML sequence diagrams represent behavior in terms of interactions

Complement the class diagrams which represent structure

Help refine use cases Useful to find participating objectsTime consuming to build but worth the investmentOther types of interaction diagrams exist (see UML

guide)


State charts

Represent state machinesMoore (output per state) or Mealy (output

per transition)Nested state charts Focus on the behavior of a single objectUsed for analysis and design


Activity DiagramsAn activity diagram shows flow control within a system

A special case of a state chart diagram in which states are activities (“functions”)

Two types of states: ● Action state:

Cannot be decomposed any furtherHappens “instantaneously” with respect to the level of

abstraction used in the model

● Activity state: Can be decomposed furtherThe activity is modeled by another activity diagram

HandleIncident

DocumentIncident

ArchiveIncident


Activity Diagram: Modeling Decisions

OpenIncident

NotifyPolice Chief

NotifyFire Chief

AllocateResources

[fire & highPriority]

[not fire & highPriority]

[lowPriority]

Branch Handle incident


Activity Diagrams: Modeling Concurrency

Splitting the flow of control into multiple threadsSynchronization of multiple activities

SynchronizationSplitting

ArchiveIncident

OpenIncident

DocumentIncident

AllocateResources

CoordinateResources


Activity Diagrams: Swimlanes

Actions may be grouped into swimlanes to denote the object or subsystem that implements the actions.

In this course we use activity diagrams mostly for development management

ArchiveIncident

Dispatcher

FieldOfficer

OpenIncident

DocumentIncident

AllocateResources

CoordinateResources


Summary

UML provides a wide variety of notations for representing many aspects of software development

● Powerful, but complex language● Can be misused to generate unreadable models● Can be misunderstood when using too many exotic features

We concentrate only on a few notations:● Functional model: use case diagram● Object model: class diagram● Dynamic model: sequence diagrams, state chart and activity

diagrams


Use Case Diagram for Simple Watch

WatchUser WatchRepairPerson

ReadTime

SetTime

ChangeBattery

Actor

Use case

PackageSimpleWatch

Functionality of the system from user’s point of view


Class Diagrams for Simple Watch

Batteryload()

1

2

Timenow()

PushButtonstatepush()release()

1

1

1

1

1

2

blinkIdxblinkSeconds()blinkMinutes()blinkHours()stopBlinking()referesh()

LCDDisplay

SimpleWatch

Class

Association

Multiplicity

AttributesOperation

sThe structure of the system


Interaction Diagrams for Simple WatchObjec

t

MessageActivationThe system behavior as interactions

blinkHours()

blinkMinutes()

incrementMinutes()

refresh()

commitNewTime()

stopBlinking()

pressButton1()

pressButton2()

pressButtons1And2()

pressButton1()

:WatchUser:Time:LCDDisplay:SimpleWatch

time


button1&2Pressed

button1&2Pressed

button1Pressed

button2Pressed

button2Pressed

button2Pressed

button1Pressed

button1&2Pressed IncrementMinutes

IncrementHours

BlinkHours

BlinkSeconds

BlinkMinutes

IncrementSeconds

StopBlinking

Statechart for SimpleWatchStat

eInitial state

Final state

Transition

Event

Documents

Introduction to Software Engineering ECSE-321 Unit 5 – Modeling with UML