System Development Phases and UML

Notes

Dr. Nagy Ramadan

Email: nagyrd@[Link]
What is modeling?

 Modeling consists of building an abstraction of reality.

 Abstractions are simplifications because:
 They ignore irrelevant details and
 They only represent the relevant details.
 What is relevant or irrelevant depends on the purpose of the
model.
 UML (Unified Modeling Language)
 An emerging standard for modeling object-oriented software.
 Application Domain (Requirements Analysis):
 The environment in which the system is operating
 Solution Domain (System Design, Object Design):
 The available technologies to build the system

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2
 Important UML Diagrams
 Use case Diagrams
 Describe the functional behavior of the system as seen by the user.
 Class diagrams
 Describe the static structure of the system: Objects, Attributes,
Associations
 Sequence diagrams
 Describe the dynamic behavior between actors and the system and
between objects of the system
 Statechart diagrams
 Describe the dynamic behavior of an individual object (essentially a
finite state automaton)
 Activity Diagrams
 Model the dynamic behavior of a system, in particular the workflow
(essentially a flowchart)
 Component diagrams
 Model the dynamic behavior of a system, in particular the workflow
(essentially a flowchart)
 Deployment diagrams
 Model the dynamic behavior of a system, in particular the workflow
(essentially a flowchart)
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3
1. Use case diagrams

Package Use case

Watch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

ChangeBattery

Use case diagrams represent the functionality of the system

from user’s point of view
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4
UML Core Conventions

 Rectangles are classes or instances

 Ovals are functions or use cases
 Instances are denoted with an underlined names
 myWatch:SimpleWatch
 Joe:Firefighter
 Types are denoted with non underlined names
 SimpleWatch
 Firefighter
 Diagrams are graphs
 Nodes are entities
 Arcs are relationships between entities

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5
Use Case Diagrams

 Used during requirements

elicitation to represent external
behavior

Actors represent roles, that is, a 

type of user of the system
Passenger  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
PurchaseTicket the system and its environment

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6
Actors

 An actor models an external entity which

communicates with the system:
 User
 External system
 Physical environment
 An actor has a unique name and an optional
Passenger description.
 Examples:
 Passenger: A person in the train
 GPS satellite: Provides the system with GPS
coordinates

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7
 Use Case

A use case represents a class of

functionality provided by the system as
an event flow.

A use case consists of:

PurchaseTicket  Unique name
 Participating actors
 Entry conditions
 Flow of events
 Exit conditions
 Special requirements

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8
Use Case Diagram: Example

Name: Purchase ticket Event flow:

1. Passenger selects the number of
Participating actor: Passenger zones to be traveled.
2. Distributor displays the amount
due.
Entry condition:
3. Passenger inserts money, of at
 Passenger standing in front of
least the amount due.
ticket distributor.
4. Distributor returns change.
 Passenger has sufficient money
to purchase ticket. 5. Distributor issues ticket.

Exit condition:
 Passenger has ticket.
Anything missing?

Exceptional cases!
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9
 The <<extends>> Relationship
 <<extends>> relationships
represent exceptional or seldom
invoked cases.
 The exceptional event flows are
Passenger factored out of the main event flow
for clarity.
 Use cases representing exceptional
flows can extend more than one
PurchaseTicket use case.
 The direction of a <<extends>>
<<extends>> relationship is to the extended use
case
<<extends>>
<<extends>>

OutOfOrder <<extends>> TimeOut

Cancel NoChange
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10
 The <<includes>> Relationship

 <<includes>> relationship
represents behavior that is factored
Passenger out of the use case.
 <<includes>> behavior is
factored out for reuse, not because
PurchaseMultiCard it is an exception.
PurchaseSingleTicket  The direction of a <<includes>>
<<includes>>
relationship is to the using use case
(unlike <<extends>>
<<includes>>
relationships).

CollectMoney
<<extends>> <<extends>>

NoChange Cancel
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11
Use Case Diagrams: Summary

 Use case diagrams represent external behavior

 Use case diagrams are useful as an index into the use cases
 Use case descriptions provide meat of model, not the use case
diagrams.
 All use cases need to be described for the model to be useful.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
 2. Class diagrams
Class diagrams represent the structure of the system

Association
Class

Multiplicity Watch
1 1 1 1
2 1 2 1
PushButton LCDDisplay Battery Time
state blinkIdx load now
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking()
referesh()

Attribute
Operations

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13
Class Diagrams

TarifSchedule
Trip
Enumeration getZones() zone:Zone
Price getPrice(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.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14
Classes
TarifSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)

TarifSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations TarifSchedule

 A class represent 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.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15
Instances
tarif_1974:TarifSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}

 In instance, the attributes are represented with their values.

 The name of an instance is underlined and can contain the class of the
instance.
 What is the difference between an actor , a class and an instance?
 Actor: An entity outside the system to be modeled, interacting with the
system (“Passenger”)
 Class: 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”).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16
 Associations

TarifSchedule TripLeg

Enumeration getZones() Price

Price getPrice(Zone)
* * Zone

 Associations denote relationships between classes.

 The multiplicity of an association end denotes how many objects the source
object can legitimately reference.
 Associations may be:
 1 – to – 1 Associations.
 1 – to – Many Associations.
 Many – to – Many Associations.
 An aggregation is a special case of association denoting a “consists of”
hierarchy.
 The aggregate is the parent class, the components are the children class.
 A solid diamond denotes composition, a strong form of aggregation where
components cannot exist without the aggregate. (Bill of Material)
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17
From Problem Statement To Object Model
Problem Statement: A stock exchange lists many companies. Each
company is uniquely identified by a ticker symbol
Class Diagram:

StockExchange * * Company
Lists
tickerSymbol

From Problem Statement to Code

Java Code
public class StockExchange
{
private Vector m_Company = new Vector();
};
public class Company
{public int m_tickerSymbol;
private Vector m_StockExchange = new Vector();
};
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
Inheritance

Button

CancelButton ZoneButton

 The children classes inherit the attributes and operations of the

parent class.
 Inheritance simplifies the model by eliminating redundancy.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19
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.

DispatcherInterface

Notification IncidentManagement

 A complex system can be decomposed into subsystems, where

each subsystem is modeled as a package

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20
 3. Sequence diagram
Actor Object

:Watch :LCDDisplay :Time

:WatchUser

pressButton1() blinkHours()
pressButton1() blinkMinutes()

Message pressButton2() incrementMinutes()

refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Activation Lifeline

Sequence diagrams represent the behavior as interactions

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21
UML sequence diagrams

 Used during requirements analysis

TicketMachine  To refine use case descriptions
Passenger
 to find additional objects
selectZone() (“participating objects”)
 Used during system design
 to refine subsystem interfaces
insertCoins()  Classes are represented by
columns
 Messages are represented by
arrows
pickupChange()
 Activations are represented by
narrow rectangles
 Lifelines are represented by
pickUpTicket() dashed lines

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22
Nested messages

ZoneButton TarifSchedule Display

Passenger

selectZone()
lookupPrice(selection)

price
displayPrice(price)
Dataflow
…to be continued...

 The source of an arrow indicates the activation which sent the message
 An activation is as long as all nested activations
 Horizontal dashed arrows indicate data flow
 Vertical dashed lines indicate lifelines

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23
 Iteration & condition
…continued from previous slide...

ChangeProcessor CoinIdentifier Display CoinDrop

Passenger

*insertChange(coin) lookupCoin(coin)

price
Iteration displayPrice(owedAmount)

[owedAmount<0] returnChange(-owedAmount)
Condition
…to be continued...

 Iteration is denoted by a * preceding the message name

 Condition is denoted by boolean expression in [ ] before the message
name

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24
 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.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25
Sequence Diagram Summary

 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).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26
 4. Statechart diagrams for objects with interesting
dynamic behavior
Event State
Initial state
[button1&2Pressed] [button2Pressed]
BlinkHours IncrementHrs

[button1Pressed]
Transition
[button1&2Pressed] [button2Pressed]
BlinkMinutes IncrementMin.

[button1Pressed]

[button1&2Pressed] [button2Pressed]
BlinkSeconds IncrementSec.

StopBlinking Final state

Bernd Bruegge & Allen H. Dutoit

Represent behavior as states and transitions
Object-Oriented Software Engineering: Using UML, Patterns, and Java 27
5. Activity Diagrams

 An activity diagram shows flow control within a system

Handle Document Archive

Incident Incident Incident

 An activity diagram is a special case of a state chart diagram in

which states are activities (“functions”)
 Two types of states:
 Action state:
 Cannot be decomposed any further
 Happens “instantaneously” with respect to the level of abstraction
used in the model
 Activity state:
 Can be decomposed further
 The activity is modeled by another activity diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28
 Statechart Diagram vs. Activity Diagram
Statechart Diagram for Incident
(State: Attribute or Collection of Attributes of object of type Incident)
Event causes
State transition

Active Inactive Closed Archived

Incident- Incident- Incident-
Handled Documented Archived

Activity Diagram for Incident

(State: Operation or Collection of Operations)

Handle Document Archive

Incident Incident Incident

Triggerless
Completion of activity Transition
causes state transition
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29
Activity Diagram: Modeling Decisions

[lowPriority]
Open Allocate
Incident Resources
[fire & highPriority]

[not fire & highPriority]

Notify
Fire Chief

Notify
Police Chief

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30
Activity Diagrams: Modeling 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

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31
Activity Diagrams: Swimlanes ‫خطوط السباحة‬

 Actions may be grouped into swimlanes to denote the object or

subsystem that implements the actions.

Allocate Dispatcher
Resources

Open Coordinate Archive

Incident Resources Incident

FieldOfficer
Document
Incident

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32
6. Drawing Hardware/Software Mappings in UML

 System design must model static and dynamic

structures:
 Component Diagrams for static structures
 show the structure at design time or compilation time
 Deployment Diagram for dynamic structures
 show the structure of the run-time system

 Note the lifetime of components

 Some exist only at design time
 Others exist only until compile time
 Some exist at link or runtime

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33
Component Diagram

 Component Diagram
 A graph of components connected by dependency relationships.
 Shows the dependencies among software components.
 source code, linkable libraries, executables
 Dependencies are shown as dashed arrows from the client
component to the supplier component.
 The kinds of dependencies are implementation language specific.
 A component diagram may also be used to show dependencies
on a façade:
 Use dashed arrow the corresponding UML interface.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34
Component Diagram Example

Scheduler reservations

UML Component
UML Interface

Planner update

GUI

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35
Deployment Diagram

 Deployment diagrams are useful for showing a system design

after the following decisions are made
 Subsystem decomposition
 Concurrency
 Hardware/Software Mapping

 A deployment diagram is a graph of nodes connected by

communication associations.
 Nodes are shown as 3-D boxes.
 Nodes may contain component instances.
 Components may contain objects (indicating that the object is part
of the component)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36
Deployment Diagram Example
Compile Time
Dependency

:HostMachine
<<database>>
meetingsDB

:Scheduler

Runtime
Dependency

:PC

:Planner

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37
UML 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

 For now we concentrate on a few notations:

 Functional model: Use case diagram
 Object model: class diagram
 Dynamic model: sequence diagrams, statechart and activity
diagrams

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38