modeling 2

Prof. Dr. Armin B. CremersSascha Alda

Organizational

Requirements

Engineering

Chapter 3: A deeper look into UML

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 2

Overview, last lesson

Idea of modelingShort overview on OOFirst Steps through UML

What is it good for?Use case diagramsClass diagramsSequence diagramsActivity diagramsStatechart diagrams


Overview, this lesson

A deeper view into UMLUse Case DiagramsClass DiagramsSequence Diagrams


Dynamicmodel

Objectmodel

Functionalmodel

UML First Pass

Use case DiagramsDescribe the functional behavior of the system as seen by the user

Class diagramsDescribe the static structure of the system: Objects, Attributes, Associations

Sequence diagramsDescribe the dynamic behavior between actors and the system and between objects of the system

Statechart diagramsDescribe the dynamic behavior of an individual object (essentially a finite state automaton)

Activity DiagramsModel the dynamic behavior of a system, in particular the workflow (essentially a flowchart)

UML: First Pass


Relationship between UML and current OO languages

Smalltalk

C++

Java

language specificdetails

concepts without a counterpart

directly mappablepart

UML


UML Core Conventions

Rectangles are classes or instancesOvals are functions or use casesInstances are denoted with an underlined names

myWatch:SimpleWatchJoe:Firefighter

Types are denoted with non-underlined namesSimpleWatchFirefighter

Diagrams are graphsNodes are entitiesArcs are relationships between entities

UML


Use Case Diagrams: The idea 1

Use case diagrams represent the functionality of the system from user’s point of view Used during requirements elicitation to represent external behaviorCan be used to discuss current and future functionality with the users

UML:Use Cases


Use Case Diagrams: The idea 2

Actors models an external entity which communicates with the systemUse cases represent a sequence of interaction with the system and thus a certain functionality of itThe use case model is the set of all use cases. It is a complete description of the functionality of the system and its environmentDescription of dependenciesbetween system functionalities and external actors

Passenger

PurchaseTicket

UML:Use Cases

<<initiates>><<communicates>>


Use Case Diagrams:Actors

An actor models an external entity which communicates with the system

UserExternal system (DB, software, devices)

An actor has a unique name and an optional descriptionExamples:

Passenger: A person in the trainGPS satellite: Provides the system with GPS coordinates

Passenger

UML:Use Cases


Use Case Diagrams: Use Case

An use case represents a class of functionality provided by the system as a sequence of interaction (event flow)

A use case consists ofUnique nameParticipating actorsEntry conditionsFlow of eventsExit conditionsSpecial requirements

Hard to infer from the graphical representation

PurchaseTicket

UML:Use Cases


Use CasesTextual RepresentationTemplate for a textual use case

Use case name

Participating Actors

Flow of Events

Entry Condition

Exit Condition

Quality Requirements


Use CasesTextual Representation

Use case nameParticipating ActorsFlow of Events

Entry ConditionExit ConditionQuality Requirements

Purchase ticket

Initiated by Passenger

1. Passenger selects the number of zones to be traveled.

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

4. SYSTEM returns change.5. SYSTEM issues ticket.

Passenger standing in front of ticket distributor.

Passenger has a correct ticket.• The Passenger‘s ticket is issued within 15 seconds.

Initialized by an actor

Initialized by the system

Passenger PurchaseTicket

<<initiates>>


PurchaseTicketSpecialFee

Use Case Diagrams:The Generalization/Inheritance Relationship

Generalization is used like between classes Means specialization (inverted direction)Mostly the same use case but slightly different (enhanced) functionalityFunctionality can be used or overridden

Passenger

PurchaseTicket

UML:Use Cases


Use Case Diagrams:The <<extend>> Relationship

<<extend>> relationship is used to extend a use case by exceptional, optional or seldom invoked cases.Extension points may be defined in the base use caseCondition must be specified when the extending use case will be insertedThe direction of a <<extend>>relationship is from the extending (supplier) use case to the extended (base) use case

Passenger

PurchaseTicket

OutOfOrder

<<extend>>

Cancel

<<extend>>

UML:Use Cases

Supplier Use Case

Base Use Case


Use Case Diagrams:The <<include>> Relationship

<<include>> relationship is used to include behavior that is factored out of the use case<<include>> behavior used to share common behavior among use casesThe direction of a <<include>>relationship is from the base use case to the using (supplier) use case (unlike <<extend>>relationships).

Passenger

PurchaseSingleTicket

PurchaseMultiCard

<<include>>

CollectMoney

<<include>>

UML:Use Cases


ExampleExampleElements

Actor

System

Use cases

Annotations

Relationships

Use Case Diagrams:Overview

place order

When placing an order, ...

name

comments ...

<<extend>> BA

<<include>>A B

<<inherit>>BA

Role ofan actor

salespersoncustomer


Use Cases in a textual wayDescribing <<include>> and <<extend>>

... 3. Passenger confirms the purchase of a ticket

4. SYSTEM receives the confirmation and asks forinserting coins (by using Use Case CollectMany)

<<include>> relationship

<<extend>> relationship

Flow of Events

The Cancel use case extends any use case in which the theuser presses the Cancel button

1. Passenger presses the Cancel button

2. SYSTEM rolls back the transaction

Flow of Events

CollectMoney

<<extend>>

Cancel

PurchaseTicket

<<include>>

CollectMoney

Base Use Case

Supplier Use Case

Supplier Use Case

Base Use Case


Use Case Diagrams: How to elicit use cases

User Participation Interviews with usersDiscussionsAttending at daily work

GoalsUnderstanding current work and use of softwareDescribing requirements

Classification in SE ProcessSystem Architecture must fit in the use cases Systems’ functionality must fit in the use cases, has to compared to elicited requirements

ProblemActors (Users) are just “at the margin”There is no notation which centers the user at its interaction with the system


Use Case Diagrams: Summary

Use Case diagrams represent external behavior (and internal functionality)Use Cases consist of diagrams and textual description (of behavior, actors, entry conditions, etc.)Use Cases are needed to discuss the system’s functionality with users

UML:Use Cases


From Use Cases To Class Diagrams

Problem: Use Case Model is describedGoal: Class Diagrams have to be modeled

Technique: Extraction by textual analysisNouns ClassesVerbs Functions

Example:

1. Passenger selects the number of zones 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.

Analysis:

♦ Class “Passenger”

♦ Class “Distribution Machine”

♦ Method “Passenger.chooseZone()“

♦ Method “DistributionMachine.displayAmount()”

♦ ….


Class Diagrams: Idea

Class diagrams represent the structure of the system.Used

during requirements analysis to model problem domain conceptsduring system design to model subsystems and interfacesduring object design to model classes

Enumeration getZones()Price getPrice(Zone)

TariffSchedule

* *

Tripzone:ZonePrice: Price

UML: ClassDiagrams


Class Diagrams: Classes

A class represents a conceptA class encapsulates state (attributes) and behavior (operations)Each attribute has a typeEach operation has a signatureThe class name is the only mandatory information

zone2pricegetZones()getPrice()

TariffSchedule

Name

Attributes

Operations

Signature

TariffSchedule

UML: ClassDiagrams

Table zone2priceEnumeration getZones()Price getPrice(Zone)

TariffSchedule


Class Diagrams: Instances

An instance 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}}

tarif_1974:TariffSchedule

UML: ClassDiagrams


Class Diagrams: Actor vs. Instances

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

An entity outside the system to be modeled, interacting with thesystem (“Passenger”)

Class: An abstraction modeling an entity in the problem domain, must bemodeled inside the system (“User”)

Object: A specific instance of a class (“Joe, the passenger who is purchasing a ticket from the ticket distributor”).

UML: ClassDiagrams


Class Diagrams: Associations

Associations denote relationships between classesThe multiplicity of an association end denotes how many objects the source object can reference (cardinality)Associations can be labeled to emphasize the purpose of the association

Class A Class B

n m

UML: ClassDiagrams

aLabel


Country

name:String

City

name:String

has-capital

Polygon

draw()

Point

x: Integer

y: Integer

One-to-one association

One-to-many association

*

1

Class Diagrams:1-to-1 and 1-to-many Associations

UML: ClassDiagrams

1

1

* = 0,1,2,…,n


StockExchange Company

tickerSymbol

Lists **

Class Diagrams:Many-to-Many Associations

UML: ClassDiagrams

Many-to-many association


Class Diagrams:Problem Statement Object Model

Problem Statement: A stock exchange should list many companies. Each company is uniquely identified by a ticker symbol.Class Diagram:


tickerSymbol

Lists**

UML: ClassDiagrams


public class StockExchange {private Vector m_Company = new Vector();

}public class Company {

public int m_tickerSymbol;private Vector m_StockExchange = new Vector();

}

Problem Statement: A stock exchange should list many companies. Each company is uniquely identified by a ticker symbol.Class Diagram:

Possible Java Code:

UML: ClassDiagrams


tickerSymbol

Lists**

Class Diagrams:Problem Statement Object Model


Class Diagrams: Inheritance

The children classes (subclasses) inherit the attributes and operations of the parent class (superclasses)Inheritance simplifies the model by eliminating redundancy

Button

ZoneButtonCancelButton

UML: ClassDiagrams


Class Diagrams: Inheritance of Interface

Interfaces are classes that define a set of externally accessible operations without implementations contract for classesImplementation classes must provide concrete implementation

Otherwise: Abstract classesStereotype: Used for extending UML elements

<<interface>>Moveable

UML: ClassDiagrams

Car <<interface>>ExtdMoveable

GeneralizationImplementation


0..1usually

Class Diagrams: AggregationAn aggregation is a special case of association denoting a “is-part of”hierarchyThe aggregate (whole) is the parent class, the parts are the children classAggregate and its part can exist independentlyParts can be rebound to other aggregates

Fire Station

Ambulance

brand

FireFighter

power

1 *

UML: ClassDiagrams

Car

Wheals

inch

Engine

power

4 1


1usually

Class Diagrams: Composition

A solid diamond denotes composition, a strong form of aggregation where parts cannot exist without the aggregateDeletion of the aggregate causes the deletion of its partsParts cannot be rebound to other aggregatesUsage is not always obvious Usage should be argued

UML: ClassDiagrams

State

Country

inch

Town

power

*

*

Tree

Leaf

inch

*

Human

Heart

inch

1

?? or


Aggregation vs. Composition

Often indicated as the "is-part of"-relationshipOften implies cascading operations:

operations on the unit will also be executed on the partsexample: Moving a rectangle will also move its edges

Often implies existencea part does not exist without the unitparts will be deleted or move to another unit if the unit is deleted

Implies exclusivitya part is contained by exactly one unit

Possible semantic categoriesExistence (Deletion) vs. ExclusivityFour categories


Class Diagrams:The four is-part-of categories

dependent

independent

exclusive not exclusive

(propagation of deletion operations)

0..1

0..1car tire4

1

1company department*

(no propagation of deletion operations)

(only part of one unit) (part of several units)

project

*

* employees*

1..*

+ explicit specification of deletion propagation

1.* Time-plan

project *


Class Diagrams: Association Classes

Attributes and operations can be attached to an association

1 *

AllocatedBy

Person Room

Time

UML: ClassDiagrams

1 AllocatedByPerson RoomTime

* 1 1


Object Modeling in Practice:A Banking System

Account

ValueCustomID

Deposit()Withdraw()GetBalance()

1. Find New Objects

Customer

NameBank

Name

2. Iterate on Names, Attributes and Methods

AccountID

CustomID

Modeling inPractice


Object Modeling in Practice: A Banking System

Account

ValueAccountID


1. Find New Objects

Customer

NameCustomID

Bank

Name

2. Iterate on Names, Attributes and Methods

3. Find Associations between Objects

has

4. Label the Associations

*

5. Determine the multiplicity of the associations

Modeling inPractice


Practice Object Modeling: Iterate, Categorize!

Account

ValueAccountID


Customer

NameCustomID

CustomerID()

Bank

Name

has**

Modeling inPractice

CheckingAccount

Withdraw()

MortgageAccount

Withdraw()

SavingsAccount

Withdraw()


Packages

A package is a UML mechanism for organizing elements into groups (usually not an application domain concept)Packages are the basic grouping construct with which you may organize UML models to increase their readability

A complex system can be decomposed into subsystems, where each subsystem is modeled as a package

DispatcherInterface

Notification IncidentManagement

UML: Packages


Sequence diagrams

Used during requirements analysisTo refine use case descriptionsto find additional objects (“participating objects”)

Class roles represent a specific part involved in the collaboration (rectangles)Messages represent information that is exchanged during interactions (labeled solid arrows)Activations to represent the time during which as class is performing an action or when it is active and has focus on control (vertical bars)Lifelines represent the existence of a class over a period of time (dashed lines)

selectZone()

pickupChange()

pickUpTicket()

insertCoins()

Passenger TicketMachine

DynamicModels


Sequence diagrams:Nested messages

Concrete Sequences visualize one possible interactionThe source of an arrow indicates the activation which sent the messageStick arrowhead: flat flow of control:

Control is passed to receiverNo further details about communication are provided

Horizontal dashed arrows indicate data flow

selectZone()

TariffSchedule Display

lookupPrice(selection)

displayPrice(price)

price

Dataflow

…to be continued...

DynamicModels

Zone ButtonPassenger


Sequence diagrams:Iteration & Condition

Abstract Sequences visualize all possible interactionsIteration is denoted by a * preceding the message nameCondition is denoted by boolean expression in [ ] before the message name

Passenger ChangeProcessor

insertChange(coin)

CoinIdentifier Display CoinDrop

displayPrice(owedAmount)

lookupCoin(coin)

price

[owedAmount<0] returnChange(-owedAmount)

Iteration

Condition

…to be continued...

…continued from previous slide...

*

DynamicModels


Sequence diagrams:Creation and destruction

Creation is denoted by a message arrow pointing to the objectDestruction is denoted by an X mark at the end of the destruction activationIn garbage collection environments, destruction can be used to denote the end of the useful life of an object

Passenger ChangeProcessor

Ticket

createTicket(selection)

free()

Creation

Destruction

print()

DynamicModels


Sequence diagrams: Self-Delegation

aMethod

aMethod

An operation may invoke itself recursively (self-delegation)Nesting may occur to an arbitrary depth


Sequence diagrams:Synchronous interaction

Represent a nested control flow via an operation call. The operation call invokes an operations synchronously (filled arrowhead)The sender passes control to the receiver via the message and pauses to wait for the receiver to return control (implicitly or explicitly)Nested sequences complete before their outer sequence resume

DynamicModels

Sender Receiver

Message

Return

Sender Receiver

Message

(implied Return)

Explicit return Implicit return


Sequence diagrams:Concurrency (Asynchronous interaction)

Represent a non-nested flow of control via a message. The message invokes an operation asynchronously (half-filled arrowhead). Both Objects stay active, can communicate with each otherIf the receiver returns information to the sender, the information must be explicit

DynamicModels

Sender Receiver

Message

Return x


Sequence diagrams:Summary

UML sequence diagram represent behavior in terms of interactionsUseful to find missing objectsTime consuming to build but worth the investmentComplement the class diagrams (which represent structure)

Easy understandable Control FlowConcurrency can be presented

DynamicModels


What should be done first? Coding or Modeling?

It all depends….

Forward EngineeringCreation of code from a modelGreenfield projects

Reverse EngineeringCreation of a model from codeInterface or reengineering projects

Roundtrip EngineeringMove constantly between forward and reverse engineeringUseful when requirements, technology and schedule are changing frequently


Conclusions: UML Summary

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

Powerful, but complex languageCan be misused to generate unreadable modelsCan be misunderstood when using too many exotic features

For now we concentrate on a few notations:Functional model: Use case diagramObject model: class diagramDynamic model: sequence diagrams

modeling 2

Documents