Download - UML Unified Modeling Language. Credits Wolfgang Pelz uml-diagrams.org Emanuele Debenedetti
History
• Booch: Booch Method• Rumbaugh: OMT (object modeling technique)• Jacobson: OOSE (OO software engineering)
Class diagram
• static view of a system in terms of classes and relationships among the classes– associations– subtypes
• typically done in parallel with interaction diagrams
• a more graphical alternative to CRC cards
Common uses
• Provide a view of services the system should provide to its end user
• Model the vocabulary of a system• Model simple collaborations• Model a logical database schema
Levels of abstraction
• Conceptual model: class name– Associations are conceptual relationships
• Specification model: above + behavior– Associations and responsibilities
• Implementation model: above + state– Probably too low-level for design stage
Steps to create a class diagram
• Identify classes using interaction diagrams and place them in the class diagram
• Get attributes from the conceptual model and the method names from the interaction diagrams
• Add type information and associations based on attribute visibility
• Add navigability arrows and dependencies
Cautions
• Start small• Perspective should match activity
– analysis: conceptual model– software: specification model
• Don’t go to details too early
Classes
• Classes comprise three slots (the forth is optional)– Name– Attributes (state)– Methods (behavior)
Professor
namesurname
create()delete()
Professor
create()delete()
Professor
namesurname
Professor
Classes(Visibility and multiplicity)
• Attribute: visibility name: type [multiplicity] = default {further properties}• Method: visibility name (parameter list): returned type {further properties}• Visibility: + public, - private, # protected, ~ friendly• Parameter: direction name: type = default
name: Stringsurname: Stringage: integer
visualize()selectCourse()
Professor
Professor
+ name: String# surname: String - age: integer = 33
+visualize()- selectCourse()
public
protected
private
Associations
• Describe relations between classes• Associations have roles (given at the end of the
association) which have multiplicities• Associations have navigability
– A sends a message to B– A creates an instance of B– A needs to maintain a connection with B
• Navigability is identified from collaboration diagrams
Roles
• Define the roles played in associations• Useful for
– Self-associations– Multiple associations between the same two classes
work forPerson Company
employee eployer
1..* 0..1
Person
0..1
0..1
husband
wife
is merried toUser Directory
owner
ack. user
container
contained
0..*
0..*
0..*
0..*1
Example
class Persona { private String nome; private String cognome; private Date dataNascita; private static int numPersone; public Persona marito; public Persona moglie;
public boolean siSposa(Persona p) { … }
public boolean compieAnni(Date d) { … }}
Association classes
• Sometimes the association itself might have properties– They cannot be moved to one of the two parts – UML defines association classes (association + class)
Company Person
JobdescriptiondateHiredsalary
* 1..*
employer employee
Aggregations
• They are specialized associations that stress the containment between the two classes
• We have a part-of relationship
Course Curriculum1..* 0..*
Composites
• Composites are heavy aggregations– The contents is subordinated to the container– For example, deleting the container means deleting
the contents as well
SliderPanel Button
Window
scrollbar body close2
1 1
1
1
1
Inheritance (Generalization)
• Makes common properties explicit
• Inheritance is an elegant modeling means, but– It is not mandatory– Maybe we must add
properties– Maybe we must refine/modify
other properties• We can work
– Bottom-up (Generalization)– Top-down (Specialization)
Person
Student Professor
Inheritance and abstract classes
• Abstract classes – Aggregate common
properties– They are inherited by
all subclasses• Inheritance and
abstract classes provide an elegant and synthetic modeling means
Polygon Circle
Shape
Triangle Square
Dependency relationship
• One element (of any kind, including classes, use cases, etc.) has knowledge of another element– If one element changes, the other might have to
change as well– Differs from plain attribute visibility which uses
regular association line and a navigability arrow
Interface
• Interface is a class of abstract/pure virtual functions
• All functions in the interface are public• Interface cannot be used to instantiate objects• There is no data members in an interface class• UML: use <<interface>> to prefix the class
name
Object diagram• Also called instance diagrams• Useful of showing object connections (not interactions)• Can be thought of as collaboration/communication diagram without messages
Use case diagram
• For capturing the functional requirements of a system
• Typical interaction between user and system– captures some user-visible function– achieves a discrete goal for the user
• System interaction is the low-level work that ultimately achieves the user goal
Common uses
• To model the context of a system– System, actors, and their interactions with it
• To model the requirements of a system– What system should do – Independent of how it is done– Point of view outside of system
Caution
• It is easy to get too low-level
A use case is a relatively large end-to-end process description that typically includes many steps or transactions; it is not normally an individual step or activity in a process.
– Larman [1998] Applying UML and Patterns
Steps
• Capture normal case first• For every step, ask:
– “What can go wrong”– “How might this work differently”
• Each variation is plotted as an extension• Common behavior can be encapsulated in
another use case to be used by other cases
Interaction diagrams
• Models that describe how groups of objects interact (collaborate)
• Class and use case diagrams are useful at capturing the structural nature of a system design in a generalized way
• Interaction diagrams capture dynamic behavior applicable to timing or sequencing requirements
Use case and Interaction diagrams
• Scenario - a specific instance of a use case, that is, a particular path through system functionality
• A single use case represents many related yet distinctly different scenarios
• Typically, an interaction diagram captures the behavior of a single scenario
• Two forms of interactive diagrams: sequence and collaboration/communication
Sequence
• Boxes at the top are participants (objects)• Vertical lines are time lines • Horizontal directed lines are messages• Unless specifically noted, only sequence (location
on the time line) is important, not exact times• An activation rectangle in the lifeline indicates a
focus of control (activation) during which an object is performing an action, either directly or through another object
Lifetime of objects
• Creation: arrow with 'new' written above it– Notice that an object
created after the start of the scenario appears lower than the others
• Deletion: an X at bottom of object's lifeline– Java doesn't explicitly
delete objects; they fall out of scope and are garbage-collected
More elements• Messages are function calls in traditional programming and events in event-driven
programming• Messages may carry parameters• A dashed line indicates a return, used to carry a return message or just indicate the
end of a group of sub-actions• Self-call: sending messages to one self (message lines direct back to the same life line)• Found message: messages not originated from any participants.• Synchronous message: messages return only when done, block the flow of execution,
no more messages from the same participant until a synchronous message is done• Asynchronous message: messages returns immediately, do not block the flow of
execution• Guards are conditional expressions in square
Interaction frames
• Notations for loops, conditions and other detail algorithms
• Common operators for Interactive Frames:• alt (alternative), opt (optional), par
(parallel), loop (loop), region (critical region), neg (negative), ref (reference), sd (sequence diagram)
42
Indicating selection and loops• frame: box around part of a sequence diagram to indicate selection or loop
– if -> (opt) [condition]– if/else -> (alt) [condition], separated by horiz. dashed line– loop -> (loop) [condition or items to loop over]
[balance <> 0]opt [balance < 100.00]
[balance >= 100.00]
alt
[balance < 0]loop
linking sequence diagrams
• If one sequence diagram is too large or refers to another diagram, indicate it with either:– An unfinished arrow and comment– A "ref" frame that names the other diagram– When would this occur in our system?
Verify customer credit
refCustomer Info
Approved?
44
(De)centralized system control
• What can we say about the control flow of each of the following systems?– centralized?– distributed?
Collaboration (UML 1.x)Communication (UML 2.x)
• An interaction diagram that utilizes message numbering instead of a time line; emphasizes structural organization of objects that send and receive messages
Which to use?
• Choose sequence diagram when only the sequence of events needs to be shown and collaboration among the objects are priority
• Choose a collaboration/communication diagram when the objects and their links facilitate understanding the interactions
• Collaboration diagrams have relatively fixed notation and numbering scheme
Activity diagrams
• Useful to specify software or hardware system behavior• Based on data flow models – a graphical representation
(with a Directed Graph) of how data move around an information system
FillOrder
ShipOrder
SendInvoice
AcceptPayment
CloseOrder
Make Payment
[orderaccepted]
Invoice
ReceiveOrder
[order reject]
Actions
• The fundamental unit of executable functionality in an activity
• The execution of an action represents some transformations or processes in the modeled system
Pins
• Actions can have inputs and outputs, through the pins• Hold inputs to actions until the action starts, and hold the
outputs of actions before the values move downstream• The name of a pin is not restricted: generally recalls the
type of objects or data that flow through the pin
Output pinsStandalone pin notations:
the output pin and the input pin have the same name and
same type
Input pins
Activities• An activity is the specification of parameterized behaviour as the
coordinated sequencing of subordinate units whose individual elements are actions
• Uses parameters to receive and provide data to the invoker
Parameter name
Parameter name Parameter
nameOutput
parameter
Activity nodes
Activity edgesInput
parameter
An action can invoke an activity to describe its action more finely
Activity nodes• Action nodes: executable activity nodes; the execution of an action
represents some transformations or processes in the modeled system (already seen)
• Control nodes: coordinate flows in an activity diagram between other nodes
• Object nodes: indicate an instance of a particular object, may be available at a particular point in the activity (i.e Pins are object nodes)
Activity edges• Control flow edge - is an edge which starts an activity node after the
completion of the previous one by passing a control token
• Object flow edge - models the flow of values to or from object nodes by passing object or data tokens
• Weight can determine the minimum number of tokens that must traverse the edge at the same time
Decision nodes
• Route the flow to one of the outgoing edges (tokens are not duplicated)
• Guards are specified on the outgoing edges or with the stereotype «decisionInput»
• There is also the predefined guard [else], chosen only if the token is not accepted by all the other edges
• If all the guards fail, the token remains at the source object node until one of the guards accept it
Merge nodes
• Bring together multiple alternate flows• All controls and data arriving at a merge node
are immediately passed to the outgoing edge• There is no synchronization of flows or joining
of tokens
Fork nodes
• Fork nodes split flows into multiple concurrent flows (tokens are duplicated)
• UML 2.0 activity forks model unrestricted parallelism
Join nodes• Join nodes synchronize multiple flows
• Generally, controls or data must be available on every incoming edge in order to be passed to the outgoing edge, but user can specify different conditions under which a join accepts incoming controls and data using a join specification
Final nodes
• Flow final:– destroys the tokens that arrive into it– the activity is terminated when all tokens in the graph are destroyed
• Final node:– the activity is terminated when the first token arrives
Object nodes• Hold data temporarily while they wait to move through the graph• Specify the type of values they can hold (if no type is specified,
they can hold values of any type)• Can also specify the state of the held objects
• There are four kinds of object nodes:
Pins(three differents notations)
Activity Parameter Nodes
Central Buffer Nodes
Data Store Nodes
Activity edges - transformation
• It is possible to apply a transformation of tokens as they move across an object flow edge (each order is passed to the transformation behaviour and replaced with the result)
In this example, the transformation gets the value of the attribute Customer of
the Order object
<<transformation>>
transformation specification
68
Example
Get luggage
ready
[on car]
[on train]
«local precondition»Have a license
Turn on the car
To motorway
tollgate
Exit to Genova tollgate
Go home with the
car
Go to the station with a
friend
Buy the ticket
Obliterate the ticket
Catch the train
When the trainarrives
to Genova
Get off the train
The trainderail
Car crash
The friend goes home
Go home with bus
Go to Heaven/Hell ;
)
Go to Heaven/Hell ;)
Study for 5
minutes
[Genova is a long way]
[else]
Catch the
ticket
Fill up with fuel
[the tank is full]
[else]
Pay the ticket
ActivityPartition• Partitions divide the nodes and edges for identifying actions that
have some characteristics in common• They often correspond to organizational units in a business model• Partitions can be hierarchical and multidimensional• Additional notation is provided: placing the partition name in
parenthesis above the activity name
SendSignalAction
• Creates a signal instance from its inputs, and transmits it to the target object (local or remote)
• A signal is an asynchronous stimulus that triggers a reaction in the receiver in an asynchronous way and without a reply
• Any reply message is ignored
Time triggers and Time events
• A Time trigger is a trigger that specifies when a time event will be generated
• Time events occur at the instant when a specified point in time has transpired
• This time may be relative or absolute– Relative time trigger: is specified with the keyword ‘after’
followed by an expression that evaluates to a time value– Absolute time trigger: is specified as an expression that
evaluates to a time value
Jan, 1, 2000, Noonafter (5 seconds)
AcceptEventAction
• Waits for the occurrence of an event meeting specified conditions
• Two kinds of AcceptEventAction:– Accept event action – accepts signal
• events generated by a SendSignalAction
– Wait time action – accepts time events
Accept event action
Wait time action
The objects stored in Personnel are only retrieved when the join succeeds (only
once a year)
InterruptibleActivityRegion• Is an activity group (sets of nodes and edges) that supports termination of
tokens flowing into it• When a token leaves an interruptible region via interrupting edges, all
tokens and behaviours in the region are terminated• Token transfer is still atomic: a token transition is never partial; it is either
complete or it does not happen at all (also for internal stream)
Interrupting edge
ExpansionRegion
• Nested region of an activity in which each input is a collection of values
• The expansion region is executed once for each element (or position) in the input collection
• On each execution of the region, an output value from the region is inserted into an output collection at the same position as the input elements
State machine diagrams
On FirstFloor
MovingUp
IdleMovingDown
Moving toFirst Floor
up floor
arrive atfloor
up floor
arrive at floor
down floor
time-out
arrive atfirst floor
transition state
An Elevator
State machine diagrams
• A state machine diagram models the behavior of a single object– Specifies the sequence of events that an object
goes through during its lifetime in response to events
Transitions
• A transition may have a trigger, a guard and an effect– Trigger is the cause of the transition, which could be a signal,
an event, a change in some condition, or the passage of time– Guard is a condition which must be true in order for the
trigger to cause the transition– Effect is an action which will be invoked directly on the object
that owns the state machine as a result of the transition• Self-Transitions
State actions
• Effects can be associated with states• Possible triggers
– Any event– Entry: behavior performed upon entry to the state– Do: ongoing behavior, performed as long as the
element is in the state– Exit: behavior performed upon exit from the state
• It is possible to define any number of actions of each type
Entry and exit points
• Entry Points help define alternative initial states
• Exit Points help specify alternative exit points
Pseudo-state and history
• Entering a terminate pseudo-state indicates that the lifeline of the state machine has ended
• A history state is used to remember the previous state of a state machine when it was interrupted