object oriented diagrams
TRANSCRIPT
Object‐Oriented Diagrams
1
Bernd Bruegge, Allen H. Dutoit, Object Oriented Software Engineering using UML, Patterns and Java, 3rd ed., Pearson Education, 2009Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young, Jim Conallen, Kelli A. Houston, Object-Oriented Analysis and Design with Applications, 3rd ed., Addison-Wesley, 2007.
TopicsModelsClass & ObjectUML
Use Case Digrams Class Diagrams Object Diagram
Interaction Diagrams Collaboration diagrams Sequence diagrams
Statechart diagrams / State diagrams Activity diagrams Diagram 0rganizations
2
Model A model is an abstraction of a system
A system that no longer exists An existing system A future system to be built.
3
Use Models to describe Software Systems
Object model: What is the structure of the system? Functional model: What are the functions of the system?
Dynamic model: How does the system react to external events?
System Model: Object model + functional model + dynamic model
4
Technique to deal with Complexity: Decomposition A technique used to master complexity ‐>
(“divide and conquer”)
Two major types of decomposition Functional decomposition Object‐oriented decomposition
5
Functional decomposition The system is decomposed into modules Each module is a major function in the application domain Modules can be decomposed into smaller modules.
Object‐oriented decomposition The system is decomposed into classes (“objects”) Each class is a major entity in the application domain Classes can be decomposed into smaller classes
Which decomposition is the right one?
Decomposition
6
Functional DecompositionTop Level functions
Level 1 functions
Level 2 functions
Machine instructions
System Function
Load R10 Add R1, R10
Read Input Transform ProduceOutput
Transform ProduceOutputRead Input
7
Functional Decomposition The functionality is spread all over the system Maintainer must understand the whole system to make a single change to the system
Consequence: Source code is hard to understand Source code is complex and impossible to maintain User interface is often awkward and non‐intuitive.
8
Changing a Square into a Circle?
Functional Decomposition: Autoshapec
Autoshape
DrawRectangle
DrawOval
DrawCircle
Change Draw
ChangeRectangle
ChangeOval
ChangeCircle
Object-oriented View
9
Class Identification Basic assumptions:
We can find the classes for a new software system:Greenfield Engineering
We can identify the classes in an existing system: Reengineering
We can create a class‐based interface to an existing system: Interface Engineering
Object + Function
10
NoseEye
Ear
ChinMouth
Hair
EllbowNeck
Glove
CoatPocket
Cave
A Face!An Eskimo!
11
Why can we do this? Philosophy, science, experimental evidence
What are the limitations? Depending on the purpose of the system, different objects might be found
CrucialIdentify the purpose of a system
depending on the purpose of the system, different objects can be found
Class Identification
12
Hierarchy A system of organizing things Class and Object
“Chunks” to deal with complexity ‐> to provide relationships between these chunks
"Part‐of" hierarchy "Is‐kind‐of" hierarchy
13
Part‐of Hierarchy (Aggregation)
I/O Devices CPU Memory
Computer
Cache ALU ProgramCounter
14
Is‐Kind‐of Hierarchy (Taxonomy)
Cell
Striate Smooth
Muscle Cell Blood Cell Nerve Cell
Red White Cortical Pyramidal
15
The picture can't be displayed.
The picture can't be displayed.
The picture can't be displayed.
The picture can't be displayed.
MembersName
Watch
Purpose
A device thatmeasures time.
Classes
16
Abstract Data Types & Classes Abstract data type
A type whose implementation is hidden from the rest of the system
Class: An abstraction in the context of object‐oriented languages
A class encapsulates state and behavior Example: Watch Unlike abstract data types, subclasses can be defined in terms of other classes using inheritance Example: CalculatorWatch
17
Abstract Data Types & Classes
Watch
timedate
SetDate(d)
CalculatorWatch
EnterCalcMode()InputNumber(n)
calculatorState
State
Behavior
Inheritance
Subclass
Superclass
18
Models must be falsifiable Karl Popper (“Objective Knowledge):
There is no absolute truth when trying to understand reality One can only build theories, that are “true” until somebody finds a counter example Falsification: The act of disproving a theory or hypothesis
The truth of a theory is never certain. We must use phrases like: “by our best judgment”, “using state‐of‐the‐art knowledge”
In software engineering any model is a theory: We build models and try to find counter examples by:
Requirements validation, user interface testing, review of the design, source code testing, system testing, etc.
Testing: The act of disproving a model. 19
Systems, Models and Views
System: Airplane
Models: Flight simulator, Scale model
Views: Blueprint of the airplane components, Electrical wiring diagram, Fuel system, Sound wave created by airplane
A model is an abstraction describing a system or a subsystem
A view depicts selected aspects of a model A notation is a set of graphical or textual
rules for depicting models and views
20
Systems, Models and Views
(“Napkin” Notation)
AircraftFlightsimulator
Scale ModelBlueprints Electrical
Wiring
Fuel System
Views and models of a complex system usually overlapViews and models of a complex system usually overlap 21
SystemView 1
Model 2View 2
View 3
Model 1
Systems, Models and ViewsSystem View
*Model
*
Depicted byDescribed by
Airplane:System
Scale Model:Model Flight Simulator:Model
Fuel System:View
Electrical Wiring:View
Blueprints: View
(UML Notation)
Class Diagram
Object Diagram
22
What is UML? UML (Unified Modeling Language)
Nonproprietary standard for modeling software systems Convergence of notations used in object‐oriented methods
Object‐modeling technique (OMT ‐ James Rumbaugh and collegues)
Booch Method (Grady Booch) Object‐oriented Software Engineering (OOSE ‐ Ivar Jacobson)
Object Management Group (OMG) the International Organization for Standardization (ISO) as industry standard for modeling software‐intensive systems
Information at the OMG portal http://www.uml.org/
23
24
UML diagrams Class diagrams describe classes and their relationships
Interaction diagrams show the behaviour of systems in terms of how objects interact with each other
State diagrams and activity diagrams show how systems behave internally
Component and deployment diagrams show how the various components of systems are arranged logically and physically
25
UML features It has detailed semantics It has extension mechanisms It has an associated textual language Object Constraint Language (OCL)
The objective of UML is to assist in software development
It is not a methodology
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 objects of the system
Statechart diagrams / State diagrams Describe the dynamic behavior of an individual object
Activity diagrams Describe the dynamic behavior of a system, in particular the workflow.
UML
26
Diagrams Use case diagrams Class diagrams Object diagram
Sequence diagrams Statechart diagrams Activity diagrams Diagram 0rganizations
27
Events and StatesTransitionsActions and Activities
Collaboration
Diagrams UML provides a wide variety of notations for modeling many aspects of software systems Functional model: Use case diagram Object model: Class diagram Dynamic model: Sequence diagrams, Activity diagrams, Statechart diagrams
28
UML Core Conventions All UML Diagrams denote graphs of nodes and edges
Nodes are entities and drawn as rectangles or ovals Rectangles denote classes or instances Ovals denote functions
Names of Classes are not underlined SimpleWatch Firefighter
Names of Instances are underlined myWatch:SimpleWatch Joe:Firefighter
An edge between two nodes denotes a relationship between the corresponding entities
29
Use Case Diagrams
Use case diagrams represent the functionality of the system from user’s point of view
Actor.
Use Case
System boundary
Classifier
30
Packages
WatchUser
Actor
Use casePackageWatch
ReadTime
SetTime
ChangeBattery
WatchRepairPerson
31
Use Case Diagrams An actor represents a role, that is, a type of user of the system
A use case represents a class of functionality provided by the system
Use case model: The set of all use cases that completely describe the functionality of the system.
Passenger
PurchaseTicket
Used during requirements elicitation and analysis to represent external behavior (“visible from the outside of the system”)
32
Actors An actor is a model for an external entity which interacts (communicates) with the system: User External system (Another system) Physical environment (e.g. Weather)
An actor has a unique name and an optional description
Examples: Passenger: A person in the train GPS satellite: An external system that provides the system with GPS coordinates.
Passenger
Name
Optional Description
33
Use Case• A use case represents a class of functionality
provided by the system • Use cases can be described textually, with a
focus on the event flow between actor and system
• The textual use case description consists of 6 parts: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements.
PurchaseTicket
34
The template of use case consists of 6 fields: Name Participating actors Entry conditions Flow of events Exit conditions Special requirements
35
Use Case Diagram: Template
Use Case Diagram: Template
Template might include Pre‐conditions (must be true before use case can take place)
Post‐conditions (must be true after use case can take place)
Purpose of this use case Description
36
Use Case Description Example
Name: Purchase ticketParticipating actor: PassengerEntry condition: Passenger stands in front of ticket distributor Passenger has sufficient money to purchase ticket
Passenger
PurchaseTicket
37
Use Case Description Example
Flow of events:1. Passenger selects the number of zones to be traveled2. Ticket Distributor displays the amount due3. Passenger inserts money, at least the amount due4. Ticket Distributor returns change5. Ticket Distributor issues ticket
Exit condition: Passenger has ticketSpecial requirements: None
38
39
Use Case Diagram: Scenarios A scenario is an instance of a use case describing a concrete set of actions.
A scenario consists of Name Participating actor instances Flow of events
Use case diagrams
40
Customer
BuyTicket
PurchaseReceipt
TicketSellingSystem
System boundaryUse caseActor
Use Case Diagram: Template Use case name: TicketSellingSystem Participant actors:
Invoked by Customer Entry condition:
Customer requests for a “BuyTicket” function. The TicketSellingSystem responds by presenting the destination.
Flow of events The Customer chooses the destination, the TicketSellingSystemcharges the ticket fee.
The TicketSellingSystem display the ticket and receipt to the Customer.
Exit conditions The Customer receives the receipt.
Special requirements The ticket and the receipt must be delivered to the Customer within 30 sec.
41
Use Case Diagram: Scenarios
Scenario Name: TicketSellingSystem
Participating actor instances: Tawee: Customer
Flow of events Tawee chooses the destination, the TicketSellingSystemcharges the ticket fee.
The TicketSellingSystem display the ticket and receipt to Tawee.
42
Uses Cases can be related Extends Relationship
To represent seldom invoked use cases or exceptional functionality
Includes Relationship To represent functional behavior common to more than one use case.
43
The <<extends>>Relationship <<extends>> relationships model
exceptional or seldom invoked cases The exceptional event flows are factored
out of the main event flow for clarity The direction of an <<extends>>
relationship is to the extended use case Use cases representing exceptional flows
can extend more than one use case.
44
Passenger
PurchaseTicket
Time Out
<<extend>>
No Change
<<extend>>
Out ofOrder
<<extend>>
Cancel
<<extend>>
The <<includes>>Relationship
<<includes>> relationship represents common functionality needed in more than one use case
<<includes>> behavior is factored out for reuse, not because it is an exception
The direction of a <<includes>> relationship is to the using use case (unlike the direction of the <<extends>> relationship).
Passenger
PurchaseSingleTicket
PurchaseMultiCard
<<includes>>
CollectMoney
<<includes>>
NoChange
<<extends>>
Cancel
<<extends>>
Cancel
<<extends>>
45
Collaboration Diagram It is the most useful of these for our present purpose. It shows some of the structure that exists between objects that take part in the collaboration.
It can be represented as an object diagram.
46
47
Collaboration diagrams (Communication diagrams) Collaboration diagrams emphasise how the objects collaborate in order to realize an interaction A collaboration diagram is a graph with the objects as thevertices.
Communication links are added between objects Messages are attached to these links.
Shown as arrows labelled with the message name Time ordering is indicated by prefixing the message withsome numbering scheme.
48
Collaboration Diagram
49
Collaboration diagrams (an example and same example with more details)
Class Diagrams
ClassAssociation
Multiplicity
Class diagrams represent the structure of the system
21 1
11
11
2
SimpleWatch
Display Battery TimePushButton
50
Class Diagrams
12
push()release()
1
1
blinkIdxblinkSeconds()blinkMinutes()blinkHours()stopBlinking()referesh()
LCDDisplay BatteryLoad
1
2
1
TimeNow
1
Watch
Operations
statePushButton
Attribute
ClassAssociation
Multiplicity
51
Class Diagrams Class diagrams represent the structure of the system Used
during requirements analysis to model application domain concepts
during system design to model subsystems during object design to specify the detailed behavior and attributes of classes.
Table zone2priceEnumeration getZones()Price getPrice(Zone)
TarifSchedule
* *
Tripzone:ZonePrice: Price
52
Classes
A class represents a concept A class encapsulates state (attributes) and behavior (operations)
Each attribute has a type Each operation has a signature
Table zone2priceEnumeration getZones()Price getPrice(Zone)
TarifSchedule
zone2pricegetZones()getPrice()
TarifSchedule
Name
Attributes
Operations
Signature
TarifSchedule
The class name is the only mandatory information
Type
Instances
An instance represents a phenomenon The attributes are represented with their values The name of an instance is underlined The name can contain only the class name of the instance (anonymous instance)
zone2price = {{‘1’, 0.20},{‘2’, 0.40},{‘3’, 0.60}}
tarif2006:TarifSchedulezone2price = {{‘1’, 0.20},{‘2’, 0.40},{‘3’, 0.60}}
:TarifSchedule
Actor vs Class vs Object Actor
An entity outside the system to be modeled, interacting with the system (“Passenger”)
Class An abstraction modeling an entity in the application or solution domain
The class is part of the system model (“User”, “Ticket distributor”, “Server”)
Object A specific instance of a class (“Joe, the passenger who is purchasing a ticket from the ticket distributor”).
55
Associations
Associations denote relationships between classes The multiplicity of an association end denotes how many objects the instance of a class can legitimately reference.
Aggregation An aggregation is a special case of association denoting a “consists‐of” hierarchy
Slide 15 A solid diamond denotes composition: A strong form of aggregation where the life time of the component instances is controlled by the aggregate. That is, the parts don’t exist on their won (“the whole controls/destroys the parts”)
TicketMachine
ZoneButton3
Inheritance
Inheritance is another special case of an association denoting a “kind‐of” hierarchy
Inheritance simplifies the analysis model by introducing a taxonomy
The children classes inherit the attributes and operations of the parent class.
Button
ZoneButtonCancelButton
58
Class Diagrams
59
TicketSeller
DayTicketSeller NightTicketSeller
BUS
Seat …Wheel Break
1
4..** 1
Building
1
Room*
ClassAssociationMultiplicity
Class Diagrams Class diagrams describe the structure of the system in terms of classes and objects.
60
Customer
ScheduleReceipt
Ticket1
1
1 1..*
1
1..*
1
1..*
Class Diagrams Class diagrams describe the structure of the system in terms of classes and objects.
61
Customer
Receipt
Ticket1
1
1
1..*
1
1..*
Packages Packages help you to organize UML models to increase their readability
We can use the UML package mechanism to organize classes into subsystems
Any complex system can be decomposed into subsystems, where each subsystem is modeled as a package.
Account
CustomerBank
62
63
Interaction Diagrams Interaction diagrams are used to model the dynamic aspects of a software system They help you to visualize how the system runs. An interaction diagram is often built from a use case and a class diagram. The objective is to show how a set of objects accomplish the required interactions with an actor.
Interaction diagrams show how a set of actors and objectscommunicate with each other to perform: The steps of a use case The steps of some other piece of functionality.
The set of steps, taken together, is called an interaction.
64
Instances of classes Shown as boxes with the class and object identifier underlined
Actors Use the stick‐person symbol as in use case diagrams
Messages Shown as arrows from actor to object, or from object to object
To develop a class diagram and a use case modelbefore starting to create an interaction diagram. There are two kinds of interaction diagrams:
Sequence diagrams, Collaboration diagrams
Interaction Diagrams
Sequence Diagram Sequence diagrams describe patterns of communication among a set of interesting objects.
An object interact with another by sending messages. Arguments
may be passed along with the message are bound to the parameters of the executing operation in the receiving object.
The sequence diagrams are used to described the event flow of a use case identify the objects that participate in the use case assign pieces of the use case behavior to object in the form of services.
65
Sequence Diagram Sequence diagrams leads to
refinements in the use case discovery of more objects and more services.
Used during analysis To refine use case descriptions to find additional objects (“participating objects”)
Used during system design to refine subsystem interfaces
66
Sequence Diagrams
Instances are represented by rectangles. Actors by sticky figures
Lifelines are represented by dashed lines
Messages are represented by arrows
Activations are represented by narrow rectangles.
selectZone
pickupChange
pickUpTicket
insertCoins
TicketMachinePassenger
67
68
Sequence diagrams A sequence diagram shows the sequence of messages exchanged by the set of objects performing a certain task The objects are arranged horizontally across the diagram. An actor that initiates the interaction is often shown onthe left.
The vertical dimension represents time. A vertical line, called a lifeline, is attached to each objector actor.
The lifeline becomes a broad box, called an activation boxduring the live activation period.
A message is represented as an arrow between activationboxes of the sender and receiver (A message is labelledand can have an argument list and a return value.)
Lifeline and Execution Specification A lifeline represents an individual participant (or object) in the interaction
A lifeline is shown using a symbol that consists of a rectangle forming its “head” followed by a vertical line (which may be dashed) that represents the lifetime of the participant
An execution specification specifies a behavior or interaction within the lifeline
An execution specification is represented as a thin rectangle on the lifeline.
69
Messages Define a particular communication between lifelines of an interaction
Examples of communication raising a signal invoking an operation creating or destroying an instance
Specify (implicitly) sender and receiver are shown as a line from the sender to the receiver Form of line and arrowhead reflect message properties
70
Message
Sequence diagram
:Time:Watch:WatchUser
Object
Activation
Actor
pressButton1
Lifeline
blinkHours
pressButton2incrementMinutes
:LCDDisplay
pressButton1and2commitNewTime
stopBlinking
refresh
pressButton1blinkMinutes
Sequence diagrams represent the behavior of a system as messages (“interactions”) between different objects. 71
Sequence Diagrams
selectZone
pickupChange
pickUpTicket
insertCoins
TicketMachinePassenger
Focus on Controlflow
TicketMachine
selectZone()insertCoins()pickupChange()pickUpTicket()
Messages ‐> Operations on participating Object
72
73
Sequence diagrams
74
Sequence diagrams – (same example, more details)
Sequence Diagrams
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
Passenger
selectZone
ZoneButton TarifSchedule Display
lookupPrice(selection)
displayPrice(price)
price
Dataflow
Iteration & Condition
Iteration is denoted by a * preceding the message name Condition is denoted by boolean expression in [ ] before the message name
PassengerChangeProcessor
insertChange(coin)
CoinIdentifier Display CoinDrop
displayPrice(owedAmount)
lookupCoin(coin)
price
[owedAmount<0] returnChange(-owedAmount)
Iteration
Condition
*
77
An iteration over objects is indicated by an asteriskpreceding the message name
Sequence diagrams (an example with replicated messages)
*[for all Purchase] getSubtotal
:Item:Bill
getUnitPrice
computeTotal
:Purchase
78
Sequence diagrams (an example with replicated messages)
Creation and 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.
PassengerChangeProcessor
Ticket
createTicket(selection)
free
Creation of Ticket
Destruction of Ticket
80
If an object’s life ends, this is shown with an X at the endof the lifeline
Sequence diagrams – (an example with object deletion)
Message Types Asynchronous Synchronous , Call and Object creation
Reply, Return
Lost Found
81
Sequence Diagram
82
Time
ActorObjectMessageLifelineActivation
:Customer :Ticket :Receipt
RequestTicket
ShowSchedule()
SelectShowTime
PayMoney
SendReceipt()ShowTicket&Receipt()
:Schedule
CheckTicket()ShowPrice()
GetTicket() PrintTicket()
83
Sequence diagrams vs Collaboration diagrams Sequence diagrams
Make explicit the time ordering of the interaction. Use cases make time ordering explicit too So sequence diagrams are a natural choice when you build aninteraction model from a use case.
Make it easy to add details to messages. Collaboration diagrams have less space for this
Collaboration diagrams Can be seen as a projection of the class diagram
Might be preferred when you are deriving an interactiondiagram from a class diagram.
Are also useful for validating class diagrams.
Statechart Diagrams Statechart diagrams are used to represent nontrivial behavior of a subsystem or an object.
While the sequence diagrams focus on the events impacting the behavior of a set of objects, statechart diagrams make explicit which attribute or set of attributes have an impact on the behavior of a single object.
Statechart diagrams are used to identify object attributes and to refine the behavior description of an object.
84
85
State Diagrams A state diagram describes the behaviour of a system,some part of a system, or an individual class. At any given point in time, the system or class is in acertain state. Being in a state means that it is will behave in a specific wayin response to any events that occur.
Some events will cause the system to change state. (statetransition) In the new state, the system will behave in a different wayto events.
A state diagram is a directed graph where the nodes are states and the arcs are transitions.
Events and States What is an event? a noteworthy happening What is a state?
The state of an object is defined by the set of values if something held by the attributes.
At any moment in time, an object exists in a certain manner or condition object state.
86
Events and States Types of events
Signals These are asynchronous messages, where the objects that send them do not expect any response from the receiving object, and nor do they wait around for one.
Calls These are synchronous messages, where the calling object stops what it was doing and waits for control to be returned, along with some results, before it carries on.
87
Events and States Types of events (cont.)
The passage of Time This is like setting a timer, and when it goes off a transition occurs.
A change in state When one object changes its state, it can execute one or more actions. There can be an exit actionfor the state it’s in, an entry action for the state it moves to, and the transition can have another action attached to it
88
Events and States State consists of
Name Entry and exit actions Deferred events Internal transitions
A state transition is the act or experience of changing from one state to another.
Statechart diagram is a map that shows all the permissible states permissible transitions for a class of objects, events that cause these transitions actions and activities that result from them. 89
90
States At any given point in time, the system is in one state. It will remain in this state until an event occurs that causesit to change state.
A state is represented by a rounded rectangle containing thename of the state.
Special states: A black circle represents the start state A circle with a ring around it represents an end state
Transitions A transition represents a change of state in response to anevent. It is considered to occur instantaneously.
The label on each transition is the event that causes thechange of state.
Statechart Diagrams
Transitions A transition consists of
Source state The state the object was in before the transition occurred.
Event trigger The event that causes the object to move from one state to another.
Guard condition A Boolean expression that will prevent the transition if it evaluates to FALSE.
Action An atomic operation that will be executed during the transition.
Target state The state the object ends up in after the transition is done. 91
State Diagrams Classes that needs statechart diagrams
A class that has an interesting, or complex life cycle. An instance that update its attributes in a variety of ways as it goes through its life cycle.
A class that has operational life cycle. Two classes are depending on each other, in that one of them can start the other on its life cycle, or change the order in which it goes from state to state.
An object’s current behavior depends on what happened to its past history.
92
Statechart diagrams
State
Initial state
Final state
Transition
Event
Represents behavior of a single object with interesting dynamic behavior.
button1&2Pressed
button1Pressed
button2Pressed
button2Pressed
button2Pressed
button1Pressed
button1&2Pressed IncrementMinutes
IncrementHours
BlinkHours
BlinkSeconds
BlinkMinutes
IncrementSeconds
StopBlinking
93
Statechart Diagrams
94
1: State_1 2: State_2
3: State_34: State_4
Initialstate
Event_1 Event_2
Event_3
Event_5Event_6Finalstate
Event_4
Statechart Diagrams
95
1: Thai Font 2: Eng FontPressFont button
PressFontButton
press other keyspress other keys
1: Thai Font 2: Eng FontPressFont button
PressFontButton
press other keys press other keys
96
State diagrams – (an example of transitions with time‐outs and conditions)
State Diagrams
97The State Diagram of the Customer class
1: GeneralCustomer
3:ChoseShowTime
requestTicket
ShowTicketPrice
2: waitService
5: ValidCustomer
4: Payment
ShowSchedule
ReceiveTicket andReceipt
98
requestToRegister(aStudent)
/createRegistration
ClosedclassSize >= maximum
cancel
openRegistration
Planned
OpenEnoughStudents
OpenNotEnoughStudents
classSize >= minimum
requestToRegister(aStudent)
/createRegistration
closeRegistration
closeRegistration
cancel
Cancelled
State diagrams – (an example conditional transitions)
99
Activities in state diagrams An activity is something that takes place while the system is in a state. It takes a period of time. The system may take a transition out of the state in response to completion of the activity,
Some other outgoing transition may result in: The interruption of the activity, and An early exit from the state.
100
Actions in state diagrams An action is something that takes place effectively instantaneously When a particular transition is taken, Upon entry into a particular state, or Upon exit from a particular state
An action should consume no noticeable amount of time
Actions and Activities Action is an atomic behavior that associated with a state or a transition, and its considered a part of the life cycle.
Atomicit cannot be split any further without losing or changing the meaning of what it is.
An entry action is an action performed each time the object enters or re‐enters a state, regardless of how it got there.
An exit action is an action that the object performs whenever it transitions out of the state.
101
Actions and Activities Whatever the object is doing while it’s waiting must be something that can be interrupted by the arrival of a suitable event. Define a chain if actions. If the event happened to arrive while one of these actions was underway, it would be made to wait for a gap between actions, and then it can interrupt and cause a transition.
Define an activity.
Activity is an ongoing process (behavior) that continues as long as the object remains in this state, but can be interrupted by a suitable trigger event.
Activity is not atomic.102
Actions and Activities Action and activity may be added to the statechartdiagram.
The name of action or activity will be written inside the state box.
Action and activity can update the attributes, which may be in this object or in other instances of the same class, or in objects from other classes.
Action and activity update other objects by sending a message to the object, this is an operation or method call, or a signal.
103
Actions and Activities When an action or activity needs to request some operation from another object, it originates a message. If the receiving object is in a class that has a statechart diagram, and if the message causes the receiving object to change its state, then the message is said to be a signal. This event will cause the receiving object to fire the exit action for the class it is in.
104
Activity Diagrams An activity diagram is a special case of a statechart diagram
The states are activities (“functions”) The outgoing transitions are triggered by the completion of an action associated with the state action state.
The name of a state condition The name of an action state action Activity diagrams are statechart diagram whose states are action states.
An activity diagram is useful to depict the workflow in a system 105
106
Activity Diagrams An activity diagram is like a state diagram. Except most transitions are caused by internal events,such as the completion of a computation.
An activity diagram Can be used to understand the flow of work that an object or component performs.
Can also be used to visualize the interrelation and interaction between different use cases.
Is most often associated with several classes. One of the strengths of activity diagrams is the representation of concurrent activities.
Activity Diagrams vs. Statechart DiagramsStatechart Diagram for IncidentFocus on the set of attributes of a single abstraction (object, system)
Activity Diagram for Incident (Focus on dataflow in a system)
HandleIncident
DocumentIncident
ArchiveIncident
Triggerlesstransition
Completion of activity causes state transition
Active Inactive Closed ArchivedIncident-Handled
Incident-Documented
Incident-Archived
Event causesstate transition
107
Activity Diagrams (allow to model Decisions)
OpenIncident
NotifyPolice Chief
NotifyFire Chief
AllocateResources
[fire & highPriority]
[not fire & highPriority]
[lowPriority]
Decision
108
Activity Diagram
109
Activities with start/end state and a decision point
Ask for destination
Ask for booking
Be added to queue
Seat not full
Seat full
Get seat number
110
Representing concurrency Concurrency is shown using forks, joins andrendezvous. A fork has one incoming transition and multipleoutgoing transitions. The execution splits into two concurrent threads.
A rendezvous has multiple incoming and multipleoutgoing transitions. Once all the incoming transitions occur all theoutgoing transitions may occur.
111
Representing concurrency A join has multiple incoming transitions and oneoutgoing transition. The outgoing transition will be taken when allincoming transitions have occurred.
The incoming transitions must be triggered in separatethreads.
If one incoming transition occurs, a wait conditionoccurs at the join until the other transitions occur.
Activity Diagrams (Concurrency) Synchronization of multiple activities Splitting the flow of control into multiple threads
OpenIncident
AllocateResources
CoordinateResources
DocumentIncident
ArchiveIncident
SynchronizationSplitting
112
Activity Diagrams
Initial node
Merge node
Final node
Fork node
Join node
113
114
Activity diagrams
Activity Diagram
115
Select showtimeRequest ticket
Buy ticketReceive ticketand receipt
The Activity Diagram of the Customer class
Activity Diagrams: Grouping of Activities Activities may be grouped into swimlanes to denote the object or subsystem that implements the activities.
OpenIncident
AllocateResources
CoordinateResources
DocumentIncident
ArchiveIncident
Dispatcher
FieldOfficer
116
Activity Diagram with swimlanesCustomer Ticker seller Ticker checker
Ask for booking
Assign seat number
Get ticket and
boarding
check ticket and stamp
117
118
Activity diagrams– (an example with swimlanes) Activity diagrams are most often associated with several classes.
The partition of activities among the existing classes can be explicitly shown using swimlanes.
Receive courseregistration request
Student CourseSectionVerify course not full
Check prerequisites
Check special permission
Complete registration
119
Activity diagrams– (an example with swimlanes)
Diagram Organization
120
TicketManagement
Customer TicketSeller
BuyTicket
PurchaseReceipt
CheckTicket TicketChecker
package
120
Diagram Organization
121
SellingSystem PrintingSystem
customer
TicketSeller Receipt
YearReport
121
122