Handout2 Extra

Software Engineering
Exercise
Modeling with UML:
Sequence and Activity Diagrams
Lilith Al-Jadiri
Lehrstuhl für Angewandte Softwaretechnik
Institut für Informatik
Technische Universität München
aljadiri@in.tum.de
November 7, 2005
Content
27.10.05 Modeling with UML: Use Case and class diagrams
03.11.05 Modeling with UML: Sequence and activity
diagrams
10.11.05 Requirements Elicitation
17.11.05 Analysis
24.11.05 System Design
01.12.05 Dies Academicus
08.12.05 Object Design: Using Design Patterns
15.12.05 Object Design: Object Constraint Language
22.12.05 to 12.01.06 Mapping models to code
19.01.06 to 09.02.06 Miniproject: Asteroids
26.01.06 to 02.02.06 Testing
Software Engineering Exercise 1

Lilith Al-Jadiri November 7, 2005 2
Exercise 1
Consider an ATM system. Identify at least three

different actors that interact with this system?

Exercise 2
Can the system under consideration be

represented as an actor?
Justify your answer.

Exercise 3
What is the difference between a scenario and a

use case?
When do you use each construct?

Exercise 4
Draw a use case diagram for a ticket distributor for a train
system. The system includes two actors: a traveler, who
purchases different types of tickets, and a central
computer system, which maintains a reference database
for the tariff. Use cases should include:
BuyOneWayTicket, BuyWeeklyCard,
BuyMonthlyCard, UpdateTariff. Also include the
following exceptional cases: Time-Out (i.e., traveler took
too long to insert the right amount),
TransactionAborted (i.e., traveler selected the cancel
button without completing the transaction),
DistributorOutOfChange, and
DistributorOutOfPaper.

Exercise 5
Write the flow of events and specify all fields for the
use case UpdateTariff that you drew in Exercise
4.
Do not forget to specify any relationships.

Exercise 5: Use Case Template
Use case name UpdateTariff
Participating Actors ….
Flow of events 1. …
2. ….
3. …
:
:
:
Entry condition …..
Exit condition ….
Quality requirements ….

Exercise 5: Solution
Use case name UpdateTariff
Participating Actors Initiated by CentralComputerSystem
Flow of events 1. The CentralCo m puterSystem activates the “UpdateTariff” function of the
ticket distributors available on the network.
2. The ticket distributor disables the traveler interface and
posts a sign indicating that the ticket distributor is under
maintenance.
3. The ticket distributor waits for the new database from the
CentralCo mputerSystem .
4. After waiting a minute for the ticket distributors to reach a waiting state,
the CentralCo m puterSystem broadcasts the new database.
5. The ticket distributor system receives the new database
of tariff. Upon complete, the ticket distributor sends an
ack nowledgement to the CentralC omputerSystem
6. After ack nowledgment, the ticket distributor enables the
traveler interface and can issue tickets at the new tariff.
7. The CentralCo m puterSystem checks if all ticket distributors have
ack nowledged the new database. If not, the CentralComputerSystem
invokes the CheckNonRespo ndingDistributo rs
use case.
Entry condition The ticket distributor is connected to a network reachable by the
CentralComputerSystem.
Exit condition The ticket distributor can issue tickets under the new tariff, OR
The ticket distributor is disabled and displays a sign denoting that it is
under maintenance.
Quality requirements The ticket distributor stays offline at most 2 minutes and is considered out-
Software Engineeringof-order
Exercise 1
otherwise.
Exercise 6
Draw a class diagram representing a book defined

by the following statement:
“A book is composed of a number of parts, which in

turn are composed of a number of chapters.
Chapters are composed of sections.”
Focus only on classes and relationships.

Exercise 7
Add multiplicity to the class diagram you produced

in Exercise 6.

Exercise 6 & 7: Solution
Book
1
*
Part
1
*
Chapter
1
*
Section

Exercise 8
Draw an object diagram representing the first part

of the oose book (table of contents is on sheet 1).
Make sure that the object diagram you draw is

consistent with the class diagram of Exercise 6.

Exercise 9
Extend the class diagram of Exercise 6 to include

the following attributes:
• book includes a publisher, publication date, and
an ISB
• a part includes a title and a number
• a chapter includes a title, a number, and an
abstract
• a section includes a title and a number

Book Part Chapter Section

publisher:Person title:String title:String title:String
publicationDate:Date number:Integer number:Integer number:Integer
ISBN:Integer[4] abstract:String
1 * 1 * 1 *

Exercise 10
Consider the class diagram of Exercise 9. Note that

the Part, Chapter, and Section classes all include
a title and a number attribute. Add an abstract
class and a generalization relationship to factor
out these two attributes into the abstract class.

NumberedComponent
title:String
number:Integer
Book Part Chapter Section

publisher:Person abstract:String
publicationDate:Date
ISBN:Integer[4]
1 * 1 * 1 *

Exercise 11
Draw a class diagram representing the relationship

between parents and children. Take into account
that a person can have both a parent and a child.
Annotate associations with roles and multiplicities.
Solution
child
Person
*
parent 2

Hand-out 2

Sequence Diagrams
• Used during requirements analysis
– To refine use case descriptions
TicketMachine
Passenger – to find additional objects
(“participating objects”)
selectZone()
• Used during system design
– to refine subsystem interfaces
• Used during Testing
insertCoins() – to specify expected behaviour and
validate output
• Classes are represented by
rectangles
pickupChange()
• Lifelines are represented by
dashed lines
• Messages are represented by
pickUpTicket() arrows
• Activations are represented by
narrow rectangles.
Sequence Diagrams: Dataflow
ZoneButton TarifSchedule Display

Passenger
selectZone()
lookupPrice(selection)
price
displayPrice(price)
Dataflow
…continued on next slide...
• The source of an arrow indicates the activation which sent
the message
• Horizontal dashed arrows indicate data flow, for example
return results from a message

Sequence Diagrams: Iteration & Condition
…continued from previous slide...
ChangeProcessor CoinIdentifier Display CoinDrop

Passenger
*insertChange(coin) lookupCoin(coin)
price
Iteration displayPrice(owedAmount)
[owedAmount<0] returnChange(-owedAmount)
Condition
…continued on next slide...
• Iteration is denoted by a * preceding the message name

• Condition is denoted by boolean expression in [ ] before the
message name
Creation and destruction
…continued from previous slide...
ChangeProcessor
Passenger
Creation
createTicket(selection)
Ticket
print()
free()
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.
Exercise 1
Draw a sequence diagram for the warehouseOnFire

scenario of Figure 1. Include the objects bob, alice,
john, FRIEND, and instances of other classes you
may need. Draw only the first five message
sends.

Exercise 1 contd.


Exercise 2
Draw a sequence diagram for the ReportIncident use

case of Figure 2. Draw only the first five message
sends. Make sure it is consistent with the
sequence diagram of Exercise 1.

Exercise 2 contd.


Activity Diagrams
• An activity diagram is a special case of a state

chart diagram
• The states are activities (“functions”)
• An activity diagram is useful to depict the
workflow in a system
Handle Document Archive

Incident Incident Incident

Activity Diagrams allow to model Decisions
[lowPriority]
Open Allocate
Incident Resources
[fire & highPriority]
[not fire & highPriority]

Notify
Fire Chief
Notify
Police Chief

Activity Diagrams allow to model Concurrency
• Synchronization of multiple activities

• Splitting the flow of control into multiple threads
Allocate
Splitting Resources Synchronization
Open Coordinate Archive

Incident Resources Incident
Document
Incident

Activity Diagrams: Grouping of Activities
• Activities may be grouped into swimlanes to
denote the object or subsystem that implements
the activities.
Allocate Dispatcher
Resources
Open Coordinate Archive

Incident Resources Incident
FieldOfficer
Document
Incident

Exercise 3
Consider the process of ordering a pizza over the

phone. Draw an activity diagram representing
each step of the process, from the moment you
pick up the phone to the point where you start
eating the pizza. Do not represent any
exceptions. Include activities that others need to
perform.


Exercise 4
Add exception handling to the activity diagram you

developed in Exercise 3. Consider at least three
exceptions (e.g. delivery person wrote down
wrong address, deliver person brings wrong
pizza, store out of anchovies).


Classes in a Class Diagram
• Class name only Example
Bank
Class Name Account
• With Details Example
Class Name Bank Account

attributes double balance
methods deposit()
withdraw()

Relationships
• Inheritance (arrow)
– example: between Secretary and Employee
• Composition/Aggregation (diamond)
– example: between Car and Wheel
• Association (line)
– example: between Borrower and Book

Inheritance
Employee
public class Secretary extends Employee {

…
}
Secretary

Composition/Aggregation
4
Car Wheel
w[]
public class Car {

Wheel w[];
...
public Car() {
w = new Wheel[4]; Note: [ ] in diagram
… is sometimes left out
} since w does not need
... to be an array
}

Association
1 3
Borrower Book
currBorr bk[]
public class Borrower { public class Book {

Book bk[]; Borrower currBorr;
… …
public Borrower() { }
bk = new Book[3];
}
}

Notational Details
• Cardinality
– Specifies the number of objects that may participate in
the relationship
• Roles and Navigability
– Specifies relationship name and access
• Aggregation versus Composition
• Dependencies

Cardinality
• Also known as multiplicity
– Exact number (mandatory)
– Range (e.g., 0..5)
– * (many-valued)
• Specifies the number of objects that may be
associated with an object of the other class
• For associations, multiplicity is specified on both
participants

Roles and Navigability
• Role name placed on the side of a participant
• Let A and B be associated classes and let rrr be
the role specified on B’s side
– rrr is the role of B in the relationship
– rrr is a member in class A
– rrr refers to one or more (depending on multiplicity) B
objects
• An arrowhead indicates the ability to access B
participant(s) from A

Uni-directional Navigability
FastFood pc PriceChecker
Counter
getPrice()
public class FastFoodCounter {

PriceChecker pc;
… public class PriceChecker {
public void add( … ) { // no access to counter
… }
double pr = pc.getPrice();
…
}
…
}

Bi-directional Navigability
1 3
Borrower Book
currBorr bk[]
public class Borrower { public class Book {

Book bk[]; Borrower currBorr;
… …
public Borrower() { }
bk = new Book[3];
}
Note: double arrowheads may
}
be omitted (bi-directional
navigability assumed)

Aggregation versus Composition
• Part-of relationships
• Aggregation
– Part may be independent of the whole but the whole
requires the part
– Unfilled diamond
• Composition (“stronger” form of aggregation)
– Part is created and destroyed with the whole
– Filled diamond
• Definitions and distinctions between aggregation
and composition still “under debate”

Association/Aggregation/Composite
• Composition
– E.g., Glider has a component Tail
– Composite object is the whole
– Component is the part
• Composite cannot exist without component
• A component is part of only one composite
– Stronger: composite should create component
– Stronger: if delete composite, component goes away
too, i.e., cascading delete
– Typically a composite has many different kinds of
components

Whole/Part Associations
• Aggregation, weaker than composition
– E.g., City is an aggregate of houses
– Aggregate is the whole
– Constituent is the part
• Aggregate may exist without constituents
• Each object may be part of more than one
aggregate
• Typically, constituents are of same class

Composition/Aggregation Notations
MovieTheater BoxOffice
1 1
whole part
0..*
composition
0..* aggregation
Movie
part

Composition vs. Aggregation
• In real world there are 7 or 8 varieties of
whole/part relationships, but UML has only two
constructs – composition and aggregation
• It can be very difficult, and confusing to choose
one
• UML 2.0 has essentially deprecated aggregation
– So, don’t use it (choose composition or association)
– But you might see it

Dependencies
• Some classes use other classes but are not
related to them in ways previously discussed
• Not relationships in the sense that participants do not become
attributes in another class
• Most common example:
– As local variables in (or arguments to) a method of the
class

Dependency Example
Restaurant uses Parser
processOrders() getOrder()
public class Restaurant {

…
public void processOrders() {
Parser p = new Parser(…);
// call getOrder() in this method
}
…
}

Association/Aggregation/Composition
Window
scrollbar[2]: Slider
title: Header
body: Panel
Window
1 1 1
scroll 2 title 1 body 1

Slider Header Panel

Mandatory Parts
4
Car Wheel
wheels
public class Car

{
private Wheel wheels[4];
// wheel objects are created externally
...
public Car(Wheel w1, Wheel w2, … ) …
// wheels required in constructor
// w1, w2, … will be checked for null values
}


Handout2 Extra

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Handout2 Extra

Загружено:

Авторское право:

Доступные форматы

Software Engineering

Software Engineering Exercise 1

Consider an ATM system. Identify at least three

Software Engineering Exercise 1

Can the system under consideration be

Justify your answer.

Software Engineering Exercise 1

What is the difference between a scenario and a

When do you use each construct?

Software Engineering Exercise 1

Software Engineering Exercise 1

Do not forget to specify any relationships.

Software Engineering Exercise 1

Software Engineering Exercise 1

Draw a class diagram representing a book defined

“A book is composed of a number of parts, which in

Focus only on classes and relationships.

Software Engineering Exercise 1

Add multiplicity to the class diagram you produced

Software Engineering Exercise 1

Software Engineering Exercise 1

Draw an object diagram representing the first part

Make sure that the object diagram you draw is

Software Engineering Exercise 1

Extend the class diagram of Exercise 6 to include

Software Engineering Exercise 1

Book Part Chapter Section

Software Engineering Exercise 1

Consider the class diagram of Exercise 9. Note that

Software Engineering Exercise 1

Book Part Chapter Section

Software Engineering Exercise 1

Draw a class diagram representing the relationship

Software Engineering Exercise 1

Software Engineering Exercise 1

ZoneButton TarifSchedule Display

Software Engineering Exercise 1

ChangeProcessor CoinIdentifier Display CoinDrop

• Iteration is denoted by a * preceding the message name

• Creation is denoted by a message arrow pointing to the object.

Draw a sequence diagram for the warehouseOnFire

Software Engineering Exercise 1

Software Engineering Exercise 1

Software Engineering Exercise 1

Draw a sequence diagram for the ReportIncident use

Software Engineering Exercise 1

Software Engineering Exercise 1

Software Engineering Exercise 1

• An activity diagram is a special case of a state

Handle Document Archive

Software Engineering Exercise 1

[fire & highPriority]

[not fire & highPriority]

Software Engineering Exercise 1

• Synchronization of multiple activities

Open Coordinate Archive

Software Engineering Exercise 1

Open Coordinate Archive

Software Engineering Exercise 1

Consider the process of ordering a pizza over the

Software Engineering Exercise 1

Software Engineering Exercise 1

Add exception handling to the activity diagram you