Beruflich Dokumente
Kultur Dokumente
2.0
UML Introduction
2/51
What is UML?
Unified Modeling Language
Visual language for specifying, constructing and documenting
Object-oriented
Model / view paradigm
Target language independent
3/51
4/51
Classification of
UML diagram types
5/51
Usage of UML
UML as sketch
Selectivity (abstraction) is the key
No formal semantics are given
UML as blueprint
Completeness is the key
6/51
7/51
8/51
Subject Name
Box Office
Use Case
Survey Sales
Supervisor
Association
Actor
<<include>>
Buy
Tickets
Kiosk
Make Charges
<<include>>
Buy
Subscription
Customer
System Boundary
9/51
Actor
Someone or some thing that must interact with the
system
Users, external systems, devices
Box Office
Survey Sales
Actor
Make Charges
Credit Card
Service
<<include>>
Buy
Tickets
Kiosk
Supervisor
<<include>>
Buy
Subscription
Customer
10/51
An Actor is a Role
An actor defines a single role played by users in their
interactions with the system:
Multiple users can play a single role
A single user may play multiple roles
<<actor>>
Consultant
<<actor>>
John
<<actor>>
Instructor
<<actor>>
Project Manager
<<actor>>
Jane
11/51
Identifying Actors
Useful questions
Who will use the main functionality of the system (primary
actors)?
Who will need support from the system to their daily tasks?
Who will need to maintain, administrate, and keep the system
working (secondary actors)?
Which hardware devices does the system need to handle?
With which other systems does the system need to interact?
Who or what has an interest in the results (the value) that the
system produces?
(From :oopsla.snu.ac.kr/research/UML/ )
12/51
Use Case
Unit of functionality expressed as a transaction among
actors and the subject
Interaction between one or more actors and the system
Use Case
Box Office
Survey Sales
Make Charges
Credit Card
Service
<<include>>
Buy
Tickets
Kiosk
Supervisor
Use Case Name
<<include>>
Buy
Subscription
Customer
13/51
Use Case
Identifying Use Cases
Which functions does the actor require from system?
Does the actor need to read, create, destroy, modify, or store
some kind of information in the system?
Does the actor have to be notified about events in the system
Could the actors daily work be simplified or made more efficient
through new functions in the system
14/51
Extensions :
3a : Customer is regular customer
.1 : System displays current shipping, pricing, and billing information
.2 : Customer may accept or override these defaults, returns to MSS at step 6
6a : System fails to authorize credit purchase
.1 : Customer may reenter credit card information or may cancel
15/51
Subject Symbol
Indicate system boundary
Classifier that realizes behavior defined by a use case
Subject Name
Subject
Box Office
Survey Sales
Make Charges
Credit Card
Service
<<include>>
Buy
Tickets
Kiosk
Supervisor
<<include>>
Buy
Subscription
Customer
System Boundary
16/51
Association
Represent bi-directional communication between the
actor and the system
Drawn between an actor and a use case
Association
Box Office
Survey Sales
Make Charges
Credit Card
Service
<<include>>
Buy
Tickets
Kiosk
Supervisor
<<include>>
Buy
Subscription
Customer
17/51
Dependency Include
Represent relationship from a base to an inclusion use case
Imply a Use Case calls another Use Case
Primarily used to reuse behavior common to several Use Cases
Box Office
Survey Sales
Inclusion
Use Cases
Supervisor
Make Charges
Credit Card
Service
<<include>>
Buy
Tickets
Kiosk
<<include>>
Dependency
Customer
Buy
Subscription
18/51
Dependency Extend
Used when some additional behavior should be added
Models optional or conditional behavior
Show infrequent events
Add sugar
<<extend>>
Buy coffee
Customer
19/51
Class Diagrams
21/51
Class Diagrams
Description of static structure
Showing the types of objects in a system and the relationships
between them
BasketballPlayer
Multiplicity
Class Name
loy
emp
Team
Class
Attributes
- TeamName: String
- NumberofPlayer: Integer
Class
Operations
+ TeamMembers()
-Name: String
-Height: Float
-Weight: Float
+ ballDribble()
+ ballPass()
Association + rebound()
+ shoot()
Generalization
means
there may be
elements.
A blank means
unknown or no
members
Guard
Forward
22/51
Classes
Most important building block of any object-oriented system
Description of a set of objects
Abstraction of the entities
Existing in the problem/solution domain
Team
- TeamName: String
- NumberofPlayer: Integer
+ TeamMembers()
BasketballPlayer
Class Name
- Name: String
- Height: Float
- Weight: Float
+ ballDribble()
+ ballPass()
+ rebound()
+ shoot()
23/51
Operations
Implement of a service requested from any object of the class
Syntax: operationName(param1:type, param2:type, ...) : Result
Team
- TeamName: String
- NumberofPlayer: Integer
+ TeamMembers()
BasketballPlayer
Class
Attributes
Class
Operations
- Name: String
- Height: Float
- Weight: Float
+ ballDribble()
+ ballPass()
+ rebound()
+ shoot()24/51
Multiplicity
Number of instances of one class related to ONE instance of
the other class
Multiplicity
Team
- TeamName: String
- NumberofPlayer: Integer
+ TeamMembers()
Basketball Player
Association
1
employ
-Name: String
-Height: Float
-Weight: Float
+ ballDribble()
Association name + ballPass()
Team employs zero or more + rebound()
+ shoot()
basketball players
25/51
Composition
Strong whole-part relationship between elements
Window contains a scrollbar
Airport
Window
Aggregation
*
Airplane
Composition
*
Transporters
1
Panel
0 ..2
Scrollbar
26/51
Inheritance
Relationship between superclass and subclasses
All attributes and operations of the superclass are part of the subclasses
Transportation
Generalization
Specialization
Automobile
Car
Benz
Truck
BMW
Boat
Sports Car
Motor Boat
Audi
27/51
Yacht
Passive class
Own address space, but not thread of control
Executed under a control thread anchored in an active object
Game
Passive
class
Level : Charstring
NumberOfPlayers : Integer
HighScore : Integer
StartNew ()
GameOver ()
Player
Id : Integer
InitiateGame()
28/51
Active
class
Interfaces
Describe behavior of objects without giving their implementations
Each class implements the operations found in the interface
Coffee Machine
Port symbol
Interface
Definition
<<interface>>
<<interface>>
FromUser
signal Coin(Integer)
signal Tea()
signal Coffee()
ToUser
signal CupofCoffee()
signal CupofWater()
signal ReturnChange()
29/51
Interface
Name
Required interface
Class uses to implement its internal behavior
What the object needs to do
Services that a message from the port may require from external
environment (outgoing)
Provided Interface
Class
SubmitJob
CheckStatus
SetPrintProperties
Required Interface
PrintServer
TransmitData
Interface Name
30/51
Display
keybd
IKeybdListener
video
PC
keybd
IKeybdListener
IDisplay
video
IDisplay
31/51
Another Example
<<interface>>
Timer
Window
getTime()
Realization
Usage
(requires
dependency)
Clock
Timer is a
provided
interface of
Clock
Clock
Timer Timer
Window
getTime()
Window
getTime()
Window has a
dependency on the
Timer interface
32/51
Sequence Diagrams
34/51
Sequence Diagrams
Show sequences of messages (interactions) between
instances in the system
Emphasize time ordering
Sequence Diagram
Name
sd MakeCoffee
:Customer
Reference
Frame
:CoffeeMachine
Lifeline
theMessage(Insert Coins)
ref
InsertCoins
Coffee()
Messages
line
CupofCoffee()
ref
Message
name
ReturnCoins
35/51
Lifelines
Individual participant in the interaction over period time
Subsystem/ object/ class
Actor
sd MakeCoffee
:Customer
:CoffeeMachine
Lifeline
theMessage(Insert Coins)
ref
InsertCoins
Coffee()
CupofCoffee()
ref
ReturnCoins
36/51
Messages
One-way communication between two objects
May have parameters that convey values
sd MakeCoffee
:Customer
:CoffeeMachine
Message
name
theMessage(Insert Coins)
ref
Messages
line
InsertCoins
Coffee()
CupofCoffee()
ref
Asynchronous
message
ReturnCoins
Synchronous
message
37/51
[x!=0]
38/51
Referencing
Reuse already existing sequence diagrams
Avoid unnecessary duplication
sd MakeCoffee
:Customer
:CoffeeMachine
theMessage(Insert Coins)
ref
sd InsertCoins
:Customer
:CoffeeMachine
InsertCoins
Coin()
Reference
Coffee()
CupofCoffee()
OK()
ref
ReturnCoins
39/51
Express the flow from left to right and from top to bottom.
Put active instances to the left/top and passive ones to the
right/bottom.
Draw sequence diagrams for each use-case if you want to
look at the behavior of several objects
(From :oopsla.snu.ac.kr/research/UML/ )
40/51
41/51
Event
turn PC on
Initial
State
Booting
Transition
Working
terminate
Shutting
Down
Guard Condition
keyStrock or
mouseMovement
[is Timeout]/
popUpScreenShot()
Screen
Saving
Action
42/51
Final
State
States
State
Condition or situation during the life of an object
Satisfies some condition, performs some activity or waits for some event
State
turn PC on
Initial
State
Booting
Working
keyStrock or
mouseMovement
terminate
[is Timeout]/
popUpScreenShot()
Screen
Saving
State
43/51
Shutting
Down
Final
State
Action
Output of a signal or an operation call
Event
turn PC on
Event
Working
Booting
keyStrock or
mouseMovement
Event
terminate
Shutting
Down
Guard Condition
[is Timeout]/
popUpScreenShot()
Screen
Saving
Action
44/51
Transition
Change state from one to another triggered by an event
Occur only when guard condition is true
Syntax: event(arguments)[condition]/action
turn PC on
Booting
Transition
Working
keyStrock or
mouseMovement
terminate
[is Timeout]/
popUpScreenShot()
Screen
Saving
45/51
Shutting
Down
Internal Activities
States can react to events without transition
Putting the event, guard, and activity inside the state box
Two special activities
The entry and exit activities
46/51
Activity States
Regular activities
Instantaneous behavior
Cannot be interrupted
Do-activities
Takes finite time
Can be interrupted
47/51
Superstates
Several states share common transitions and internal
activities
Move the shared behavior into a superstate
A behavior can be expressed in a modular/hierarchical way
48/51
Activity Diagram
Supplements the use
case by providing a
graphical
representation of the
flow of interaction
within a specific
scenario
enter password
and user ID
valid passwords/ ID
invalid passwords/ ID
other f unctions
may also be
selected
input tries remain
select surveillance
thumbnail views
no input
tries remain
select specific
camera - thumbnails
prompt for
another view
exit this f unction
These slides are designed to accompany Software Engineering: A Practitioners Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.
49
Swimlane Diagrams
h o m e o wn e r
c a m e ra
i nt e rf a c e
enter password
and user ID
input t ries
remain
select surveillance
no inp ut
tries remain
select specific
camera - thumbnails
generate video
output
view camera output
in labelled window
prompt for
another view
exit t his
f unct io n
see
ano t her
camera
These slides are designed to accompany Software Engineering: A Practitioners Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.
50
Deployment Diagrams
51/51
Deployment Diagrams
Show runtime architecture of devices, execution
environments, and artifacts in architecture
Physical description of system topology
Node
AppServer
<<artifact>>
ShoppingApp.ear
<<artifact>>
ShoppingCart.jar
artifact
<<artifact>>
Order.jar
<<deployment spec>>
ejb-jar.xml
<<TCP/IP>>
52/51
client
Communication Path
Deployment Diagrams
Node
Computational resource upon which artifacts may be deployed
for execution
Communication path
Show connection between nodes
Stereotype can be used for communication protocol or network used
Artifact
Specification of a physical piece of information that is used or
produced by a software development process, or by deployment
and operation of a system.
Examples of artifacts include model files, source files, scripts, and
binary executable files, a table in a database system, a development
deliverable, or a word-processing document, a mail message.
53/51
Summary
Activity diagram
Sequence diagrams
State diagrams
54/51