Modeling Um L

Chapter 3:
A deeper look into UML

Organizational
Requirements
Engineering
Prof. Dr. Armin B. Cremers
Sascha Alda
Overview, last lesson

z
Idea of modeling
Short overview on OO
First Steps through UML
What is it good for?

Use case diagrams
Class diagrams
Sequence diagrams
Activity diagrams
Statechart diagrams
Armin B. Cremers, Sascha Alda
Organizational Requirements Engineering
Overview, this lesson

z
A deeper view into UML
Use Case Diagrams
Class Diagrams
Sequence Diagrams
UML:
First Pass
UML First Pass

z
Use case Diagrams
Class diagrams
Functional
model
Describe the functional behavior of the system as seen by the user
Describe the dynamic behavior between actors and the system and
between objects of the system
Statechart diagrams
Describe the static structure of the system: Objects, Attributes,

Associations
Sequence diagrams
Object
model
Describe the dynamic behavior of an individual object (essentially a

finite state automaton)
Dynamic
model
Activity Diagrams
Model the dynamic behavior of a system, in particular the workflow

(essentially a flowchart)
Relationship between UML and

current OO languages
llta
a
Sm
lk
C++
UML
Jav
concepts without a
counterpart
directly mappable
part
language specific
details
5
UML Core Conventions
UML
Rectangles are classes or instances
Ovals are functions or use cases
Instances are denoted with an underlined names
Types are denoted with non-underlined names
myWatch:SimpleWatch
Joe:Firefighter
SimpleWatch
Firefighter
Diagrams are graphs
Nodes are entities

Arcs are relationships between entities
UML:
Use Cases
Use Case Diagrams: The idea 1

z
Use case diagrams represent the functionality of the

system from users point of view
Used during requirements elicitation to represent
external behavior
Can be used to discuss current and future functionality
with the users
UML:
Use Cases
Use Case Diagrams: The idea 2

z
Passenger
<<initiates>>
<<communicates>>
PurchaseTicket
Actors models an external entity

which communicates with the
system
Use cases represent a
sequence of interaction with the
system and thus a certain
functionality of it
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
Description of dependencies
between system functionalities
and external actors
Use Case Diagrams:

Actors
z
An actor models an external entity which

communicates with the system
User
External system (DB, software, devices)
An actor has a unique name and an

optional description
Examples:
Passenger
UML:
Use Cases
Passenger: A person in the train

GPS satellite: Provides the system with
GPS coordinates
UML:
Use Cases
Use Case Diagrams: Use Case

z
PurchaseTicket
An use case represents a class of

functionality provided by the system as a
sequence of interaction (event flow)
A use case consists of

z Unique name
z Participating actors
z Entry conditions
z Flow of events
z Exit conditions
z Special requirements
Hard to infer from the graphical
representation
10
Use Cases
Textual Representation
Template for a textual use case
Use case name
Participating Actors
Flow of Events
Entry Condition
Exit Condition
Quality Requirements
11
Use Cases
Textual Representation
<<initiates>>
Passenger
PurchaseTicket
Use case name
Purchase ticket
Participating Actors
Initiated by Passenger
Flow of Events
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 returnsInitialized
change.by the system
5. SYSTEM issues ticket.
Initialized by an actor
Entry Condition
Passenger standing in front of ticket distributor.
Exit Condition
Passenger has a correct ticket.
Quality Requirements
The Passengers ticket is issued within 15 seconds.

12
Use Case Diagrams:
UML:
Use Cases
The Generalization/Inheritance Relationship

z
Passenger
Purchase
Ticket
Generalization is used like

between classes
Means specialization (inverted
direction)
Mostly the same use case but
slightly different (enhanced)
functionality
Functionality can be used or
overridden
PurchaseTicket
SpecialFee
13
Use Case Diagrams:

The <<extend>> Relationship
z
Passenger
z
Base Use Case

z
PurchaseTicket
<<extend>>
<<extend>>
UML:
Use Cases
<<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 case
Condition must be specified
when the extending use case
will be inserted
The direction of a <<extend>>
relationship is from the
extending (supplier) use case to
the extended (base) use case
OutOfOrder
Supplier Use Case
Cancel
14
Use Case Diagrams:

The <<include>> Relationship
z
UML:
Use Cases
<<include>> relationship is
used to include behavior that is

factored out of the use case
Passenger
z
PurchaseMultiCard
PurchaseSingleTicket
<<include>>
<<include>>
<<include>> behavior used to
share common behavior

among use cases
The direction of a <<include>>
relationship is from the base
use case to the using (supplier)
use case (unlike <<extend>>
relationships).
CollectMoney
15
Use Case Diagrams:

Overview
z
Example
Example
Elements
Actor
customer
System
Use cases
Annotations
Role of
an actor
Relationships
name
salesperson
place order
comments ...
When placing an order, ...

A
B
<<include>>
<<extend>>
B
B
<<inherit>>
16
Use Cases in a textual way
Describing <<include>> and <<extend>>

Supplier
Use Case
<<include>> relationship
Flow of Events
CollectMoney
3.
PurchaseTicket
Passenger confirms the purchase of a ticket

SYSTEM receives the confirmation and asks for
inserting coins (by using Use Case CollectMany)
Supplier
Use Case
<<extend>> relationship
<<extend>>
Cancel
Base
Use Case
CollectMoney
The Cancel use case extends any use case in which the the
user presses the Cancel button
1.
Passenger presses the Cancel button

2.
Base
Use Case
...
4.
Flow of Events
<<include>>
SYSTEM rolls back the transaction
17
Use Case Diagrams:

How to elicit use cases
z
User Participation
Interviews with users

Discussions
Attending at daily work
z
Goals
Understanding current work and use of software

Describing requirements
z
Classification in SE Process
System Architecture must fit in the use cases

Systems functionality must fit in the use cases, has to compared to elicited
requirements
z
Problem
Actors (Users) are just at the margin

There is no notation which centers the user at its interaction with the system
18
Use Case Diagrams:

Summary
UML:
Use Cases
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 systems functionality with

users
19
From Use Cases To Class Diagrams
Problem: Use Case Model is described

Goal: Class Diagrams have to be modeled
Technique: Extraction by textual analysis
Classes
Verbs Functions
Nouns
Analysis:
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.

Class Passenger
Class Distribution Machine
Method Passenger.chooseZone()
Method
DistributionMachine.displayAmount()
20
UML: Class
Diagrams
Class Diagrams: Idea
TariffSchedule
Enumeration getZones()
Price getPrice(Zone)
Trip
zone:Zone
Price: Price
Class diagrams represent the structure of the system.
Used
during requirements analysis to model problem domain concepts

during system design to model subsystems and interfaces
during object design to model classes
21
UML: Class
Diagrams
Class Diagrams: Classes
TariffSchedule
Table zone2price
Enumeration getZones()
Price getPrice(Zone)
Name
TariffSchedule
zone2price
getZones()
getPrice()
z
z
z
z
z
Attributes
Operations
Signature
TariffSchedule
A class represents a concept

A class encapsulates state (attributes) and behavior (operations)
Each attribute has a type
Each operation has a signature
The class name is the only mandatory information
22
Class Diagrams: Instances
UML: Class
Diagrams
tarif_1974:TariffSchedule
zone2price = {
{1, .20},
{2, .40},
{3, .60}}
z
z
An instance represents a phenomenon

The name of an instance is underlined and can contain the class of the
instance
The attributes are represented with their values
23
UML: Class
Diagrams
Class Diagrams: Actor vs. Instances

z
What is the difference between an actor, a class and an instance?
Actor:
Class:
An entity outside the system to be modeled, interacting with the

system (Passenger)
An abstraction modeling an entity in the problem domain, must be
modeled inside the system (User)
Object:
A specific instance of a class (Joe, the passenger who is purchasing

a ticket from the ticket distributor).
24
UML: Class
Diagrams
Class Diagrams: Associations
Class A
aLabel
z
z
Class B
Associations denote relationships between classes

The 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
25
Class Diagrams:
UML: Class
Diagrams
1-to-1 and 1-to-many Associations

Country
name:String
has-capital
City
name:String
One-to-one association
Polygon
Point
x: Integer
draw()
* = 0,1,2,,n
y: Integer
One-to-many association
26
Class Diagrams:
UML: Class
Diagrams
Many-to-Many Associations
StockExchange
Lists
Company
tickerSymbol
Many-to-many association
27
Class Diagrams:
UML: Class
Diagrams
Problem Statement Object Model

z
Problem Statement: A stock exchange should list many companies.

Each company is uniquely identified by a ticker symbol.
Class Diagram:
StockExchange
Company
Lists
tickerSymbol
28
Class Diagrams:
Problem Statement Object Model
UML: Class
Diagrams
Problem Statement: A stock exchange should list many companies.

Each company is uniquely identified by a ticker symbol.
Class Diagram:
StockExchange
Company
Lists
tickerSymbol
z
Possible Java Code:

public class StockExchange {
private Vector m_Company = new Vector();
}
public class Company {
public int m_tickerSymbol;
private Vector m_StockExchange = new Vector();
}
29
UML: Class
Diagrams
Class Diagrams: Inheritance

Button
CancelButton
ZoneButton
The children classes (subclasses) inherit the attributes and

operations of the parent class (superclasses)
Inheritance simplifies the model by eliminating redundancy
30
Class Diagrams:
UML: Class
Diagrams
Inheritance of Interface
<<interface>>
Moveable
Implementation
Generalization
<<interface>>
Car
ExtdMoveable
Interfaces are classes that define a set of externally accessible

operations without implementations contract for classes
Implementation classes must provide concrete implementation

Otherwise:
Abstract classes
Stereotype: Used for extending UML elements
31
UML: Class
Diagrams
Class Diagrams: Aggregation

z
z
z
z
An aggregation is a special case of association denoting a is-part of

hierarchy
The aggregate (whole) is the parent class, the parts are the children
class
Aggregate and its part can exist independently
Parts can be rebound to other aggregates
Fire Station
Car
usually
0..1
1
Ambulance
FireFighter
brand
power
4
Wheals
inch
1
Engine
power
32
UML: Class
Diagrams
Class Diagrams: Composition

z
z
z
z
A solid diamond denotes composition, a strong form of aggregation

where parts cannot exist without the aggregate
Deletion of the aggregate causes the deletion of its parts
Parts cannot be rebound to other aggregates
Usage is not always obvious Usage should be argued
State
Tree
Human
usually
1
*
Country
inch
or
*
Leaf
inch
Heart
inch
*
Town
power
33
Aggregation vs. Composition

z
Often indicated as the "is-part of"-relationship
Often implies cascading operations:
Often implies existence
a part does not exist without the unit

parts will be deleted or move to another unit if the unit is deleted
Implies exclusivity
operations on the unit will also be executed on the parts

example: Moving a rectangle will also move its edges
a part is contained by exactly one unit
Possible semantic categories

Existence (Deletion) vs. Exclusivity
Four categories
34
Class Diagrams:
The four is-part-of categories
exclusive
not exclusive
(only part of one unit)
(part of several units)
dependent
1..*
(propagation of
deletion operations)
+ explicit specification of
deletion propagation
company
department
0..1
independent
1.*
project
Timeplan
(no propagation of
deletion operations)
car
0..1
tire
project
employees
35
Class Diagrams: Association Classes

z
UML: Class
Diagrams
Attributes and operations can be attached to an association

AllocatedBy
Time
Person
Person
AllocatedBy 1
Room
Room
Time
36
Object Modeling in Practice:

A Banking System
Modeling in
Practice
Account
Bank
Name
Value
AccountID
CustomID
Deposit()
Withdraw()
GetBalance()
Customer
Name
CustomID
1. Find New Objects

2. Iterate on Names, Attributes and
Methods
37
Object Modeling in Practice:

A Banking System
*
Account
Bank
Name
Value
AccountID
Modeling in
Practice
has
Deposit()
Withdraw()
GetBalance()
Customer
Name
CustomID
1. Find New Objects
3. Find Associations between Objects
2. Iterate on Names, Attributes and

Methods
4. Label the Associations

5. Determine the multiplicity of the
associations
38
Practice Object Modeling:

Iterate, Categorize!
*
Bank
Name
Account
Value
AccountID
Modeling in
Practice
has
Name
CustomID
Deposit()
Withdraw()
GetBalance()
CustomerID()
Savings
Account
Mortgage
Account
Checking
Account
Withdraw()
Withdraw()
Withdraw()
Customer
39
UML:
Packages
Packages
z
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
DispatcherInterface
Notification
IncidentManagement
A complex system can be decomposed into subsystems, where

each subsystem is modeled as a package
40
Dynamic
Models
Sequence diagrams
z
Used during requirements analysis
Passenger
To refine use case descriptions

to find additional objects (participating
objects)
TicketMachine
selectZone()
z
insertCoins()
pickupChange()
pickUpTicket()
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)
41
Sequence diagrams:
Nested messages
Passenger
Dynamic
Models
Zone Button
selectZone()
TariffSchedule
Display
lookupPrice(selection)
price
Dataflow
displayPrice(price)
to be continued...
z
z
z
Concrete Sequences visualize one possible interaction

The source of an arrow indicates the activation which sent the message
Stick arrowhead: flat flow of control:
Control is passed to receiver

No further details about communication are provided
z
Horizontal dashed arrows indicate data flow

42
Sequence diagrams:
Iteration & Condition
Dynamic
Models
continued from previous slide...

Passenger
ChangeProcessor
*insertChange(coin)
Iteration
Condition
CoinIdentifier
Display
CoinDrop
lookupCoin(coin)
price
displayPrice(owedAmount)
[owedAmount<0] returnChange(-owedAmount)
to be continued...
z
z
z
Abstract Sequences visualize all possible interactions

Iteration is denoted by a * preceding the message name
Condition is denoted by boolean expression in [ ] before the
message name
43
Sequence diagrams:
Creation and destruction
Passenger
ChangeProcessor
Dynamic
Models
Creation
createTicket(selection)
Ticket
print()
free()
z
z
Destruction
Creation is denoted by a message arrow pointing to the object

Destruction is denoted by an X mark at the end of the destruction
activation
In garbage collection environments, destruction can be used to denote
the end of the useful life of an object
44
Sequence diagrams:
Self-Delegation
aMethod
aMethod
z
z
An operation may invoke itself recursively (self-delegation)

Nesting may occur to an arbitrary depth
45
Sequence diagrams:
Synchronous interaction
Sender
Receiver
Message
Dynamic
Models
Sender
Receiver
Message
(implied Return)
Return
Explicit return
z
Implicit return
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
46
Sequence diagrams:
Dynamic
Models
Concurrency (Asynchronous interaction)

Sender
Receiver
Message
Return x
z
z
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 other
If the receiver returns information to the sender, the information must be
explicit
47
Sequence diagrams:
Summary
Dynamic
Models
UML sequence diagram represent behavior in terms of

interactions
Useful to find missing objects
Time consuming to build but worth the investment
Complement the class diagrams (which represent structure)
Easy understandable Control Flow
Concurrency can be presented
48
What should be done first? Coding or

Modeling?
z
It all depends.
Forward Engineering
Reverse Engineering
Creation of code from a model

Greenfield projects
Creation of a model from code
Interface or reengineering projects
Roundtrip Engineering
Move constantly between forward and reverse engineering

Useful when requirements, technology and schedule are changing
frequently
49
Conclusions: UML Summary

z
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
For now we concentrate on a few notations:
Functional model: Use case diagram

Object model: class diagram
Dynamic model: sequence diagrams
50

Modeling Um L

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modeling Um L

Uploaded by

Copyright:

Available Formats

Chapter 3:

A deeper look into UML

Overview, last lesson

First Steps through UML

What is it good for?

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Overview, this lesson

A deeper view into UML

Use Case Diagrams

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

UML First Pass

Use case Diagrams

Describe the static structure of the system: Objects, Attributes,

Describe the dynamic behavior of an individual object (essentially a

Model the dynamic behavior of a system, in particular the workflow

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Relationship between UML and

UML Core Conventions

Rectangles are classes or instances

Ovals are functions or use cases

Instances are denoted with an underlined names

Types are denoted with non-underlined names

Diagrams are graphs

Nodes are entities

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Use Case Diagrams: The idea 1

Use case diagrams represent the functionality of the

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Use Case Diagrams: The idea 2

Armin B. Cremers, Sascha Alda

Actors models an external entity

Organizational Requirements Engineering

Use Case Diagrams:

An actor models an external entity which

An actor has a unique name and an

Armin B. Cremers, Sascha Alda

Passenger: A person in the train

Organizational Requirements Engineering

Use Case Diagrams: Use Case

An use case represents a class of

A use case consists of

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Organizational Requirements Engineering

Use case name

1. Passenger selects the number of zones to be

Passenger standing in front of ticket distributor.

Passenger has a correct ticket.

Armin B. Cremers, Sascha Alda

The Passengers ticket is issued within 15 seconds.

Use Case Diagrams:

The Generalization/Inheritance Relationship

Generalization is used like

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Use Case Diagrams:

Base Use Case