1. Surgery Sessions (Weeks 6-10)
Analysis (BD Ch. 5)
CS223 Lecture 7
Ananda Amatya
Reminder:
Surgery Sessions (Weeks 6-10)
Mon pm in C1.01
Fri am in C1.04
Good Morning Everybody!
Today’s lecture is about Requirements Analysis.
Just to remind you that Surgery sessions are running, and you should take advantage of the help offered by tutors.
This week’s surgery sessions include discussion of last week’s lecture on Requirements by considering Exercises from Chapter 4 of the BD book.
Next week’s surgery session will include discussion of Requirement Analysis by considering Exercises from Chapter 5 of the BD book.
Next week’s lecture will be given by Dr. Arshad Jhumka and will cover the topic of moving from Requirements Analysis to Design.

2. Outline of Analysis Analysis modelling review
Object (Static) modelling
Activities during object modelling
Pieces of Object Model
Class identification
Finding Participating Objects from Use Cases
Object types
Object naming
Abbott’s Technique
Behavioural (Dynamic) modelling
Sequence diagrams
Statechart diagrams
Outline of this lecture is as follows:
Review Analysis modelling issues
Discuss Object (Static) modelling:
Activities in object modelling,
Parts of object models,
Identifying classes in the system,
Objects from use case event flows,
Object Types,
Naming Objects,
Abbott’s technique.
Discuss Behaviour (Dynamic) modelling:
Sequence diagrams,
Statechart diagrams

3. Analysis modelling review
During Requirements Analysis, analysis models are constructed.
Analysis model main stake-holders: End user, Customer, Analyst.
Analysis model diagrams contain only application domain classes.
Analysis model forms the basis for communication between analysts, application domain experts and end users of the system.
Analysis Models are of 2 types:
Object (static) models: deals with class structure (classes, association, inheritance, dependency)
Behaviour (dynamic) models: deals with object interactions (objects, method invocation, messages)
During Design, the analysis models are refined to design models
Design models main stake-holders: class specifiers, class implementers and class users
Design models diagrams contain classes from both application and solution domains.
Design models form the basis for communication between designers and implementers of the system.
During Requirements Analysis, analysis models are constructed
Main stake-holders of analysis models are End Users, Customers, and Systems Analysts
Analysis model diagrams contain ONLY Application (Problem) domain classes
Analysis models form the basis for communications between System Analysts, Application Domain Experts and End Users of the system
TWO types of Analysis models: Object (Static) models, Behaviour (Dynamic) models
Object (Static) models deal with the Class structure of the system, and consist of Classes and Relationships (Associations, Inheritance, Dependency)
Behaviour (Dynamic) models deal with object interactions in the system, and consist of Objects and method invocations (messages, signals, stimuli)
The analysis models are refined to design models during Systems design.
Design models main stake-holders are class specifiers, implementers, and users
Design models diagrams contain classes from BOTH application and solution domains
Design models form the basis for communication between designers and implementers of the system.

4. Activities during Object (Static) Modelling
Main goal: Find the important abstractions
What happens if we find the wrong abstractions?
Iterate and correct the model
Steps during object modelling
1. Find the Classes
2. Find the attributes
3. Find the methods
4. Find the associations
Order of steps
Goal: get the desired abstractions
Order of steps secondary, only a heuristic
Iteration is important
Start with review:
What is a model?
What is an abstraction?
They are used synonymously, and mean that they provide a simplified view of a complex system that we cannot understand by looking at all of its components simultaneously.
Models by their definition abstract away important characteristics of a system by emphasizing the main aspects.
Example: Clay model concentrates on the form of the car, nobody can sit in it.
Prototypes are models.
Iterate and correct the model:
A scientific model is always like a hypothesis.
The important part of a scientific model is that it is falsifiable.
This is an important aspect of prototyping.
They are immediately understandable and can be falsified (that is our theory of how the application should work!).
This is one of the main strengths of prototyping: End user falsifiability.
Redesign (Falsification principle in science: Work with model until it is proven to be false).
Object modelling involves finding classes, their attributes, their methods, and their associations with other classes
The order of steps is secondary, and is only a heuristic.
Important to get the desired abstractions.
Iterate until this is achieved.

5. Pieces of an Object Model
Classes
Associations
Generic associations
Canonical associations --
Part-of Hierarchy (Aggregation)
Kind-of Hierarchy (Generalization)
Attributes
Determining attributes -- application specific
Attributes Vs classes – may need to turn attributes to classes or vice versa
Operations
Determining operations
Generic operations: Get/Set, General world knowledge, design patterns
Domain operations: Dynamic model, Functional model
Pieces of Object model:
Class
Association (Generic, Aggregation, Generalization)
Attributes (application specific, distinction from classes)
Operations (Generic: Get/Set, domain operation)

6. Class Identification Determine system boundary
Find the important entities in the system
Class identification is crucial to object-oriented modelling
Approaches in Requirements Analysis
Application domain experts help to identify abstractions
Noun-verb analysis (Abbott) in flow of events of use cases
Approaches in Design & Implementation
Refine Analysis classes to corresponding Solution classes
Use Design patterns to determine Solution classes
Use Component-based approach to identify Existing Solution classes.
To identify the classes:
Determine system boundary
Determine important entities of the system: Forward Engineering – find classes for a new system, Reverse Engineering – find classes for an existing system
Class identification crucial
Application domain experts help in identifying the main abstractions
Using Abbott’s Noun-Verb Analysis Technique in Use case Event flows
Design & Implementation refine Analysis level classes, and determine solution classes using design patterns and component-based (reuse) approaches

7. Finding Participating Objects in Use Cases
Pick a use case and look at its flow of events
Find terms that need to be clarified to understand event flows
Look for recurring nouns (e.g., Incident),
Find real world entities (e.g., FieldOfficer, Dispatcher)
Find real world procedures (e.g., EmergencyOperationsPlan),
Identify data sources or sinks (e.g., Printer)
Identify interface artifacts (e.g., PoliceStation)
Initially some objects will be missed; will be found later (iteration)
Model the flow of events with a sequence diagram
Always use the user’s terms (application domain)
Finding Participating Objects from Use case flow of events:
Recurring nouns
Real world entities
Real world procedures
Data sources or sinks
Interfaces artefacts
Iterate to find missing objects and to discard objects not belonging to the system
Use Sequence Diagrams for Use Case Event Flows
Always use (application domain) user’s terms

8. Object Types
Entity: persistent information - application-domain/business objects
Boundary: interaction between user and system - interface
Control: control tasks - state dependent
Entity most resilient to change, Boundary least, Control in between.
Object types originated in Smalltalk: Model, View, Controller MVC
Object types:
Entity (application domain objects)
Boundary (interface between user and system)
Control (system control task)
Entity most resilient to system change
Interface least resilient to system change
Control in between
MVC (Smalltalk Model, View, and Control)

9. Example: 2BWatch Objects
Button
Year
ChangeDate
Month
Example: 2BWatch Objects:
Entity objects
Year
Month
Day
Control objects
ChangeDate
Interface (Boundary) objects
Button
LCDDisplay
LCDDisplay
Day
Entity Objects
Control Objects
Interface Objects

10. Naming of Object Types in UML
UML provides several mechanisms to extend the language
Stereotype is one such mechanism to present new modelling elements
<<Boundary>>
Button
<<Entity>>
Year
<<Control>>
ChangeDate
Naming Object Types:
Stereotypes:
<<entity>>,
<<control>>,
<<boundary>>
Extends the language giving special meanings
<<Entity>>
Month
<<Boundary>>
LCDDisplay
<<Entity>>
Day
Entity Objects
Control Objects
Boundary Objects

11. Recommended Naming Convention for Object Types
To distinguish the different object types on a syntactical basis, we recommend suffixes:
Objects ending with the “_Boundary” suffix are boundary objects
Objects ending with the “_Control” suffix are control objects
Entity objects do not have any suffix appended to their name.
Naming convention for Object Types
classes to show their object types:
_Boundary: Button_Boundary, LCDDisplay_Boundary
_Control: ChangeDate_Control
No suffix for Entity classes
Year
ChangeDate_
Control
Button_Boundary
Month
LCDDisplay_Boundary
Day

12. Example: Toy Shop
A customer enters a store with the intention of buying a toy for a child. Help must be available within less than one minute. The store owner gives advice to the customer. The advice takes into account the age of the child and the attributes of the toy. The customer selects a dangerous toy which is unsuitable for the child. The store owner recommends a safer doll.
Example: Toy shop system

13. Toy Shop Example: Flow of Events for BuyAToy Use Case
A customer enters the store to buy a toy.
It has to be a toy that his daughter likes and it must cost less than 50 Euro.
He tries a videogame, which uses a data glove and a head-mounted display. He likes it.
Is this a good use
Case?
An assistant helps him.
The suitability of the game depends on the age of the child; the daughter is only 3 years old.
The assistant recommends another type of toy, namely the boardgame ``Monopoly’’.
Event flow for BuyAToy Use Case of Toy Shop Example:
Isolate constraints from functions
Separate scenarios from use cases
Complete the event sequence
Not quite!
“Monopoly” is probably an
outcome of the scenario
The use case should
terminate with the
customer leaving the store

14. Textual Analysis using Abbot’s technique
Example
Grammatical construct
UML Component
“Monopoly"
Concrete Person, Thing
Object
“toy"
noun
class
"3 years old"
Adjective
Attribute
Abbott‘s Technique of Textual Analysis
Names are objects
Nouns are candidate classes
Adjectives are attributes
Verbs are operations
Intransitive verbs are Events
Classifying verbs are Inheritance relations
Possessive verbs are Aggregation (Composition)
Modal verbs are Constraints
“enters"
verb
Operation
“depends on…."
Intransitive verb
Operation (Event)
“is a" ,“either. or", “kind of…"
Classifying verb
Inheritance
"Has a ", “consists of"
Possessive Verb
Aggregation
“must be", “less than…"
modal Verb
Constraint

15. Generation of a class diagram from flow of events
Customer
Flow of events:
The customer enters the store to buy a toy.
It has to be a toy that his daughter likes and it must cost less than 50 Euro.
He tries a videogame, which uses a data glove and a head-mounted display. He likes it.
An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old.
The assistant recommends another type of toy, namely a boardgame.
The customer buys the game and leaves the store.
customer
enters
store
buy
toy
Store
enter() ?
enter()
daughter
less than 50 Euro
videogame
daughter
Daughter
age
Class diagrams from Use case Event flows:
Classes: Customer, Daughter, Toy, Videogame, Boardgame
Attributes: age, price
Operations: enter(), buy(), like()
Inheritance: Type of Toy
Association: depends, suitability
Constraints: less than
suitable *
Toy
price
buy()
like()
depends
age
toy
toy
buy()
type of toy
boardgame
Videogame
Boardgame

16. Order of activities in Object modelling
Formulate a few scenarios with help from the end user and/or application domain expert.
Extract the use cases from the scenarios, with the help of application domain expert.
Analyse the flow of events, for example with Abbott's textual analysis.
Generate the class diagrams, which includes the following steps:
Class identification (textual analysis, domain experts).
Identification of attributes and operations (sometimes before the classes are found!)
Identification of associations between classes
Identification of multiplicities
Identification of roles
Identification of constraints
Order of activities in Object modelling:
Formulate a few scenarios with help from users and application domain experts
Extract use cases from the scenarios with help from application domain experts
Analyse flow of events of use cases using Abbott’s textual analysis
Generate class diagrams which includes the following steps:
Identification of Classes (textual analysis, domain experts)
Identification of attributes and operations (some time before the classes are found!)
Identification of associations between classes
Identification of multiplicities
Identification of roles
Identification of constraints

17. Improving Object Models
Account
AmountId
Amount
Deposit()
Withdraw()
GetBalance()
Bank
Name
Customer * *
Has
Name
CustomerId()
Improving Object Models:
Names of Classes, attributes and operations
Associations: names, multiplicities, roles
Introduce Generalization (inheritance) hierarchies
Separate inheritance hierarchies if too many (7+-2 rule) classes in the same package
Savings
Account
Checking
Account
Mortgage
Account
Don’t put too many classes into the same package:
7+-2 (or even 5+-2)
Withdraw()
Withdraw()
Withdraw()

18. Put Taxonomies on a separate Diagram
Account
accountID
amount
Deposit()
Withdraw()
getBalance()
Introduce Inheritance separately to simplify class diagrams
Savings
Account
Checking
Account
Mortgage
Account
Withdraw()
Withdraw()
Withdraw()

19. Dynamic (Behaviour) Modelling with UML
Diagrams for dynamic modelling
Interaction diagrams describe the dynamic behaviour between objects
Statecharts describe the dynamic behaviour of a single object
Interaction diagrams:
Sequence diagram:
Dynamic behavior of a set of objects arranged in time sequence.
Good for real-time specifications and complex scenarios
Collaboration diagram (UML2 name: Communication Diagram):
Shows the relationship among objects. Does not show time
StateChart diagram:
A state machine that describes the response of an object of a given class to the receipt of outside stimuli (Events).
Activity diagram: A special type of statechart diagram, where all states are action states (Moore Automaton)
Dynamic (Behaviour) modelling
Diagrams for dynamic modelling
Interaction diagrams describe the dynamic behaviour between objects
Statecharts describe the dynamic behaviour of a single object
Interaction diagrams:
Sequence diagram:
Dynamic behavior of a set of objects arranged in time sequence.
Good for real-time specifications and complex scenarios
Collaboration diagram (UML2 name: Communication Diagram):
Shows the relationship among objects. Does not show time
StateChart diagram:
A state machine that describes the response of an object of a given class to the receipt of outside stimuli (Events).
Often need consider statecharts only for state dependent control classes.
Activity diagram:
A special type of statechart diagram, where all states are action states (Moore Automaton)
Often need consider activity diagrams only when implementing complex algorithms for methods

20. Dynamic Modelling Definition of dynamic model:
A collection of multiple statechart diagrams, one statechart for each class with important dynamic behavior (e.g., state dependent control classes).
Purpose:
Determine classes missing from object models
Detect and supply methods for the object models
How do we do this?
Start with use case or scenario
Model interaction between objects => sequence diagram
Model dynamic behavior of a single object => statechart
Dynamic modelling:
Statechart for each state dependent control class of the object model: dynamic behaviour of such objects
Sequence diagram for scenario or use case: dynamic behaviour of interactions between objects in the sequence diagram
Determines missing classes in object model
Determines class methods in object models

21. Start with Flow of Events from Use Case
Flow of events from “Dial a Number” Use case:
Caller lifts receiver
Dial tone begins
Caller dials
Phone rings
Callee answers phone
Ringing stops
....
A scenario is a sequence of events that occurs during one particular execution of a system.
The scope of a scenario can vary: it may include all events in the system, or it may include only those events generated by certain objects of the system.
A scenario can be the historical record of executing a system or a thought experiment of executing a proposed system.
Each event transmits information from one object to another.
For example, dial tone begins to transmit a signal from the phone line to the caller.

22. What is an Event? Something that happens at a point in time
Relation of events to each other:
Causally related: before and after
Causally unrelated: concurrent
An event sends information from one object to another
Events can be grouped in event classes with a hierarchical structure. ‘Event’ is often used in two ways:
Instance of an event class:
Event class “New ITEM”, Subclass “Figure Change”
Attribute of an event class
Car starts at ( 4:45pm, Monroeville Mall, Parking Lot 23a)
Mouse button down (button#, tablet-location)
Events:
Event: Something that happens at a point in time
Relation of events to each other: Causally related: before and after; Causally unrelated: concurrent
An event sends information from one object to another
Events can be grouped into event classes with a hierarchical structure.
‘Event’ is often used in two ways:
Instance of an event class: Event class “New ITEM”, Subclass “Figure Change”
Attribute of an event class: Car starts at ( 4:45pm, Monroeville Mall, Parking Lot 23a); Mouse button down (button#, tablet-location)

23. Sequence Diagram
From the flow of events in the use case or scenario proceed to the sequence diagram
A sequence diagram is a graphical description of objects participating in a use case or scenario using a DAG (direct acyclic graph) notation
Relation to object identification:
Objects/classes have already been identified during object modelling
Objects are identified as a result of dynamic modelling
Heuristic:
A event always has a sender and a receiver.
The representation of the event is sometimes called a message
Find them for each event => These are the objects participating in the use case
Sequence Diagrams:
From the flow of events in the use case or scenario proceed to the sequence diagram
A sequence diagram is a graphical description of objects participating in a use case or scenario using a DAG (direct acyclic graph) notation
Relation to object identification:
Objects/classes have already been identified during object modelling;
New Objects may be identified as a result of dynamic modelling
Heuristic:
A event always has a sender and a receiver.
The representation of the event is sometimes called a message
Find the objects (sender & receiver) for each event
These are the objects participating in the use case

24. 1. Establish connection between smart card and onboard computer
An Example
Flow of events in a “Get SeatPosition” use case :
1. Establish connection between smart card and onboard computer
2. Establish connection between onboard computer and sensor for seat
3. Get current seat position and store on smart card
Which are the objects?
Example: Flow of event for GetSeatPosition use case:
User inserts smart card
System establishes connection between smart card and onboard computer
System establishes connection between onboard computer and seat sensor
System gets current seat position and stores it on the smart card.

25. Sequence Diagram for “Get SeatPosition”
Onboard Computer
Seat
Smart Card
1. Establish connection between smart card and onboard computer
2. Establish connection between onboard computer and sensor for seat
3. Get current seat position and store on smart card
Establish Connection
Establish Connection
Sequence Diagram for “GetSeatosition” scenario:
SmartCard sends EstablishConnection message to OnboardComputer
OnboardComputer sends EstablishConnection message to Seat
Seat sends AcceptConnection message back to OnboardComputer
OnboardComputer sends AcceptConnection message to SmartCard
SmartCard sends message GetSeatPosition to Seat
Seat returns and stores “500,575,300” (current seatnumber) to SmartCard
Accept Connection
Accept Connection
Get SeatPosition
“500,575,300”
time

26. Heuristics for Sequence Diagrams
Layout:
1st column: Should correspond to the actor who initiated the use case
2nd column: Should be a boundary object
3rd column: Should be the control object that manages the rest of the use case
Creation:
Control objects are created at the initiation of a use case
Boundary objects are created by control objects
Access:
Entity objects are accessed by control and boundary objects,
Entity objects should never call boundary or control objects: This makes it easier to share entity objects across use cases and makes entity objects resilient against technology-induced changes in boundary objects.
Heuristics for Sequence Diagrams:
Layout:
1st column: Should correspond to the actor who initiated the use case
2nd column: Should be a boundary object
3rd column: Should be the control object that manages the rest of the use case
Creation:
Control objects are created at the initiation of a use case
Boundary objects are created by control objects
Access:
Entity objects are accessed by control and boundary objects,
Entity objects should never call boundary or control objects:
This makes it easier to share entity objects across use cases and makes entity objects resilient against technology-induced changes in boundary objects.

27. Is this a good Sequence Diagram?
Smart Card
Onboard Computer
Seat
First column is not the actor
It is not clear where the boundary object is
It is not clear where the control object is
Establish Connection
Establish Connection
Some problems with sequence diagrams:
Layout problem:
The actor is missing.
Who is talking to the Smartcard?
(Create Driver actor who inserts Smart Card into Cardreader)
Creation problem: The control object is not created by the interface object (add dashed lifeline until create() call by interface object)
Access problem: The interface object accesses the control object (replace by dashed line)
Accept Connection
Accept Connection
Get SeatPosition
“500,575,300”

28. Example: Impact on ARENA’s Object Model
Let’s assume, ARENA’s object model contained the objects
League Owner, Arena, League, Tournament, Match and Player
Next examine the Sequence Diagram for CreateTournament Use case.
The Sequence Diagram identified new Classes
Tournament Boundary, Announce_Tournament_Control
ARENA: New classes from Sequence Diagram:
Assume, ARENA’s object model contained the objects: League Owner, Arena, League, Tournament, Match and Player
Next examine the Sequence Diagram for CreateTournament Use case.
The Sequence Diagram identified new Classes: Tournament Boundary, Announce_Tournament_Control

29. An ARENA Sequence Diagram : Create Tournament
League
Owner
:Tournament
Boundary
:Arena
:League
newTournament
(league)
:Announce
Tournament
Control
«new»
Sequence diagram for CreateTournament Use Case:
LeagueOwner sends message newTournament(league) to Tournament_Boundary class which then
creates AnnounceTournament_Control Class which then
sends checkMaxTournament() message to Arena Class
LeagueOwner then sends setName(name) message to Tournament_Boundary class followed by
message setMaxPlayers(maxp) to Tournament_Boundary class and then
sends commit() message to Tournament_Boundary class which then
Sends createTournament(name, maxp) message to AnnounceTournament_Control class which then
sends createTournament(name, maxp) message to League class which finally
creates the Tournament class
checkMax
Tournament()
setName(name)
setMaxPlayers
(maxp)
createTournament
(name, maxp)
commit()
create
Tournament
(name, maxp)
:Tournament
«new»

30. League Owner League 1 * Attributes Attributes Operations Operations
Tournament
The ARENA object diagram needs to contain the classes: Tournament_Boundary and AnnounceTournament_Control, notpresent in the original object diagram.
Attributes
Operations
Player
Match * *
Attributes
Attributes
Operations
Operations

31. Tournament_ Boundary Announce_ Tournament_ Control
League
Owner
League 1 *
Attributes
Attributes
Operations
Operations
Attributes
Operations
Tournament_
Boundary
Tournament
Attributes
Operations
Announce_
Tournament_
Control
More information on these new classes can be deduced from the messages in the use case sequence diagram.
Attributes
Operations
Player
Match * *
Attributes
Attributes
Operations
Operations

32. Impact on ARENA’s Object Model (contd.)
The Sequence Diagram also supplied us with a lot of new events
newTournament(league)
setName(name)
setMaxPlayers(maxp)
Commit()
checkMaxTournaments()
createTournament(name, maxp)
Question: Who owns these events?
Answer: For each object that receives an event there is a public operation in the associated class.
The name of the operation is usually the name of the event.
The messages along with the parameters passed in the sequence diagram give the public operations of these classes.
Thus Tournament_Boundary class has operations: newTournament(league), setName(name), setMaxPlayers(max), commit()
Also, AnnounceTournament_Control class has operation: createTournament(name, maxp)
And Arena class has operation: checkMaxTournaments()

33. Example from the Sequence Diagram
create
Tournament
(name, maxp)
League
Owner
:Tournament
Boundary
newTournament
(league)
:Announce
Control
«new»
setName(name)
setMaxPlayers
(maxp)
commit()
checkMax
Tournament()
:Arena
:League
createTournament is a (public)
operation owned by
Announce_Tournament_Control
createTournament
(name, maxp)

34. Tournament_ Boundary Announce_ Tournament_ Control
League
Owner
League 1 *
Attributes
Attributes
Operations
Operations
Attributes
Operations
Tournament_
Boundary
Tournament
Announce_
Tournament_
Control
Attributes
Operations
Attributes
createTournament
(name, maxp)
Player
Match * *
Attributes
Attributes
Operations
Operations

35. UML Statechart Diagram Notation
Event trigger
With parameters
State1
State2
Event1(attr) [condition]/action
do/Activity
entry /action
Guard
condition
exit/action
Also: internal transition
and deferred events
A state is drawn as a rounded box containing a name.
The state name starts with a capital letter.
A transition is drawn as an arrow from the state which receives the event to the target state.
Event names are written on the transition arrow, optionally followed by one or more attributes within parentheses.
A condition is a Boolean function of object values (e.g., emission is above legal value).
Conditions can be guards on transitions.
A guarded transition fires only when the event occurs and the condition is true.
Conditions are shown as expressions in square brackets following the event name and its parameter list.
An action follows the event name and/or the condition by the slash (/) character.
Events that cause an action without causing a state change are written inside the state box.
Internal action and self-transition are different.
When an internal action occurs, neither the entry action nor the exit action is executed.
When a self-transition occurs, these actions (both entry and exit) are executed.
Events sent to other objects are shown in dashed lines.
Notation based on work by Harel
Added are a few object-oriented modifications
A UML statechart diagram can be mapped into a finite state machine

36. associated with states
Statechart Diagrams
Graph whose nodes are states and whose directed arcs are transitions labeled by event names.
We distinguish between two types of operations in statecharts:
Activity: Operation that takes time to complete
associated with states
Action: Instantaneous operation
associated with events
associated with states (for reducing drawing complexity): Entry, Exit, Internal Action
A statechart diagram relates events and states for one class
An object model with a set of objects has a set of state diagrams
A state diagram relates events and states for one object.
A transition is drawn from one state to another of the same object.
State diagrams would be quite useless if they only describe event patterns.
A behavioral description of an object must specify what the object does in response to events.
This is specified in operations attached to states and transition .
An activity is an operation that takes time to complete.
Activities are always associated with a state.
The notation: do Activity1, within a state box indicates that the activity, Activity1, starts on entry to the state and stops when complete.
Sometimes it is more advantageous to associate an action with a state.
When? - when all the state transitions cause the same action, it is a better notational convenience to list the action only once.
This reduces clutter in the state diagrams.
An action is an instantaneous operation.
This is of course a relative notion.
What we mean by instantaneous is that the duration of the operation is insignificant when compared to the time resolution of the state diagram.
It also means we do not care about the internal structure of this operation.
An action is therefore associated with an event.

37. State An abstraction of the attributes of a class
State is the aggregation of one or more attributes a class
Basically an equivalence class of all those attribute values and links that do not need to be distinguished as far as the control structure of the system is concerned
Example: State of a bank
A bank is either solvent or insolvent
State has duration
An object model describes the possible patterns of objects, attribute values and links that can exist in a system.
A dynamic model describes the possible patterns of states, events and actions that can exist in a system.
Over time, the objects stimulate each other, resulting in a series of changes to their states.
An individual stimulus from one object to another is called an event.
Events can be organized into classes.
Events can be error conditions as well as normal occurrences.
Event as an object : Some events are only signals (OK), others have attributes associated with them (Unix signals: Bus error, Segment violation).
Attributes are shown in parentheses after the class name.
Events are important for UI, Communication and Notification.
Other groups have to worry about events as well, because the interaction between the subsystems should be via the Request Broker.
The response to an event depends on the state of the object receiving it.
It can include a state change or sending of another event to another object and sending a event back to the sender (return result, ok, ...)
The Events and states are duals of one another: An event separates 2 states and a state separates 2 events.

38. Example of a StateChart Diagram (Vending Machine)
coins_in(amount) / set balance
Collect Money
coins_in(amount) / add to balance
Idle
cancel / refund coins
[item empty]
[select(item)]
[change<0]
A good application for nested state diagrams is this example of a vending machine.
Here we see the top level dynamic model of the object vending machine, which certainly has interesting dynamic behavior for the designer.
Question: Is the dynamic model interesting for the end user? If the end user has the choice of one of the 3 models (Object model, dynamic model and functional model), which one would they use?
Answer: The functional model! If I select this particular candy bar, then that is what I want to get.
Notice the activity do : dispense item.
In the case, when we really have to engineer (develop) the dispenser, there is much more to it than just an activity dispense.
Note, by the way, that this particular state does not have a name!
The state in the upper right has a state, namely Collect Money.
This is incomplete if we insist that all states have names, but it is completely natural while we do dynamic modelling.
We do not necessarily immediately come up with good names for everything.
We had encountered a similar problem during object modelling: In some cases, we found the class name first, in others we first find the method or methods or maybe we start with something where we only know the attribute.
There is no predefined roadmap to arrive at good models, be it object, dynamic or functional models.
Creativity cannot be forced into a Procustres bed, or otherwise we will end up with an empty set of boxes!
do: test item and compute change
[change=0]
[change>0]
do: dispense item
do: make change

39. Nested State Diagram
Activities in states are composite items denoting other lower-level state diagrams
A lower-level state diagram corresponds to a sequence of lower-level states and events that are invisible in the higher-level diagram.
Sets of substates in a nested state diagram denoting a superstate are enclosed by a large rounded box, also called contour.
1. Nested state diagrams are useful for two reasons:
2. As a solution to cope with the complexity in your design:
Abstraction: A state is actually more complex and leads to a finite state automaton itself. On the top level we don’t model all the complex states.
Modularization: Each state diagram has up to 7+-2 states.
Hierarchy: We apply the “ Consist of” association!

40. Example of a Nested Statechart Diagram
Idle
Collect Money
coins_in(amount) / add to balance
do: test item and compute change
do: make change
[change>0]
[item empty]
[select(item)]
[change<0]
coins_in(amount) / set balance
cancel / refund coins
[change=0]
A good application for nested state diagrams in this example of a vending machine.
Here we see the top level dynamic model of the object vending machine, which certainly has interesting dynamic behavior for the designer.
Question: Is the dynamic model interesting for the end user? If the end user has the choice of one of the 3 models (Object model, dynamic model and functional model), which one would they use?
Answer: The functional model! If I select this particular candy bar, then that is what I want to get.
Notice the activity do : dispense item.
In the case, when we really have to engineer (develop) the dispenser, there is much more to it than just a activity dispense.
Note, by the way, that this particular state does not have a name!
The state in the upper right has a state, namely Collect Money.
This is incomplete if we insist that all states have names, but it is completely natural while we do dynamic modelling.
We do not necessarily immediately come up with good names for everything.
We had encountered a similar problem during object modelling: In some cases, we found the class name first, in others we first find the method or methods or maybe we start with something where we only know the attribute.
There is no predefined roadmap to arrive at good models, be it object, dynamic or functional models.
Creativity cannot be forced into a Procustres bed, or otherwise we will end up with an empty set of boxes!
Superstate
do: dispense item

41. Example of a Nested Statechart Diagram
[change=0]
A good application for nested state diagrams in this example of a vending machine.
Here we see the top level dynamic model of the object vending machine, which certainly has interesting dynamic behavior for the designer.
Question: Is the dynamic model interesting for the end user? If the end user has the choice of one of the 3 models (Object model, dynamic model and functional model), which one would they use?
Answer: The functional model! If I select this particular candy bar, then that is what I want to get.
Notice the activity do : dispense item.
In the case, when we really have to engineer (develop) the dispenser, there is much more to it than just a activity dispense.
Note, by the way, that this particular state does not have a name!
The state in the upper right has a state, namely Collect Money.
This is incomplete if we insist that all states have names, but it is completely natural while we do dynamic modelling.
We do not necessarily immediately come up with good names for everything.
We had encountered a similar problem during object modelling: In some cases, we found the class name first, in others we first find the method or methods or maybe we start with something where we only know the attribute.
There is no predefined roadmap to arrive at good models, be it object, dynamic or functional models.
Creativity cannot be forced into a Procustres bed, or otherwise we will end up with an empty set of boxes!
Superstate
do: dispense item

42. Example of a Nested Statechart Diagram
‘Dispense item’ as
a composite activity:
‘Dispense item’ as
an atomic activity:
do: move arm
to row
arm ready
A good application for nested state diagrams in this example of a vending machine.
Here we see the top level dynamic model of the object vending machine, which certainly has interesting dynamic behavior for the designer.
Question: Is the dynamic model interesting for the end user? If the end user has the choice of one of the 3 models (Object model, dynamic model and functional model), which one would they use?
Answer: The functional model! If I select this particular candy bar, then that is what I want to get.
Notice the activity do : dispense item.
In the case, when we really have to engineer (develop) the dispenser, there is much more to it than just a activity dispense.
Note, by the way, that this particular state does not have a name!
The state in the upper right has a state, namely Collect Money.
This is incomplete if we insist that all states have names, but it is completely natural while we do dynamic modelling.
We do not necessarily immediately come up with good names for everything.
We had encountered a similar problem during object modelling: In some cases, we found the class name first, in others we first find the method or methods or maybe we start with something where we only know the attribute.
There is no predefined roadmap to arrive at good models, be it object, dynamic or functional models.
Creativity cannot be forced into a Procustres bed, or otherwise we will end up with an empty set of boxes!
do: move arm
to column
arm ready
do: dispense item
do: push item
off shelf

43. Expanding activity “do:dispense item”
‘Dispense item’ as
an atomic activity:
[change=0]
do: dispense item
‘Dispense item’ as
a composite activity:
1. Here is the nested state diagram for do : dispense item.
2. The activity dispense item is now decomposed (remember, decomposition is one of the 3 pillar stones to deal with complexity) into 3 distinct states, namely
1. Move arm to correct row
2. Move arm to correct column
3. Push item from the shelf
3. As a result of this refinement, we actually see two new objects emerging, namely row, column and shelf.
And a new method, namely Push Item().
5.This is another example, of where the dynamic model helps with the identification of objects and methods.
6.Here are two good heuristics for dynamic modelling that I would like you to know as well:
1) Any event in a state diagram is a good candidate for a method of a class.
2) If the class does not yet exist to which this event should be attached as method, its existence should be postulated (and verified by the customer and/or analyst).
do: move arm
to row
do: push item
off shelf
do: move arm
to column
arm
ready
arm
ready

44. Superstates Goal: Avoid spaghetti models
Reduce the number of lines in a state diagram
Transitions from other states to the superstate enter the first substate of the superstate.
Transitions to other states from a superstate are inherited by all the substates (state inheritance)
Superstates
Goal:
Avoid spaghetti models
Reduce the number of lines in a state diagram
Transitions from other states to the superstate enter the first substate of the superstate.
Transitions to other states from a superstate are inherited by all the substates (state inheritance)

45. Modelling Concurrency
Two types of concurrency:
1. System concurrency
State of overall system as the aggregation of state diagrams, one for each object. Each state diagram is executing concurrently with the others.
2. Object concurrency
An object can be partitioned into subsets of states (attributes and links) such that each of them has its own subdiagram.
The state of the object consists of a set of states: one state from each subdiagram.
State diagrams are divided into subdiagrams by dotted lines.
Concurrency is an important aspect of any application for two reasons:
Maintainability: If two classes are really concurrent, that means, they are not related to each other, and they can be designed and developed completely independently from each other.
Improved Performance: Concurrency also means in many cases a possible source for fast response time.
If methods can be executed in parallel, and not in serial fashion, the systems response time will be better.
Concurrency within a state of a single object arises when the object can be partitioned into subsets of attributes, each of which has its own subdiagram.
In this case, the state of the object comprises one state from each subdiagram.
Note that these subdiagrams don’t have to be independent.
The same event can cause state transitions in more than one subdiagram.
Examples of concurrency within an object: dispenser machine, that simultaneously dispenses cash and ejects the card.
Often concurrency within an object is discovered after the object has been identified.
It might be the source for iterating on the object identification and question if there are not two separate objects in the problem that are worth modeling.

46. Example of Concurrency within an Object
Splitting control
Synchronization
Emitting
Do: Dispense
Cash taken
Cash
1. Concurrency might be detected within a single object.
This sometimes means that our overall decomposition of the system or our initial object identification was too coarse grain.
If there is concurrency, the first question an analyst should ask: What two objects are hidden in the currently modeled single objects? In many cases, uncovering these two yet unknown classes will lead to new insights in the application or result in a better taxonomy or object model.
2. In some cases, the object is inherently not further decomposable.
But even in this case, the discussion of concurrency is very important at analysis level, because it will have important ramifications during system design (mappability of the concurrent methods on two different processors due to data parallelism, for example) and implementation (choice of programming language that supports light level threads instead of heavy level processes).
Setting
Ready Up
to r
eset
Ready
Do: Eject
Card
Card taken

47. Statechart Diagram vs Sequence Diagram
Statechart diagrams help to identify:
Changes to an individual object over time
Sequence diagrams help to identify
The temporal relationship between objects over time
Sequence of operations as a response to one or more events
Statechart diagrams help to identify:
Changes to an individual object over time
Sequence diagrams help to identify:
The temporal relationship between objects over time;
Sequence of operations as a response to one or more events

48. Practical Tips for Dynamic Modelling
Construct dynamic models only for classes with significant dynamic behavior
Avoid “analysis paralysis”
Consider only relevant attributes
Use abstraction if necessary
Look at the granularity of the application when deciding on actions and activities
Reduce notational clutter
Try to put actions into state boxes (look for identical actions on events leading to the same state)
A few practical tips.
The most important one:
If you have a couple of hundred objects, that does not necessarily mean that you have a couple of hundred dynamic models.
Only those objects with significant dynamic behavior need to be modeled dynamically.
Also, if two objects have the same dynamic behavior, it is often only necessary to model one of these objects with a dynamic model and then describe with a single sentence that the same dynamic model applies to both objects.
The Power and Headlight classes from our Mini People Mover are a good example.
Only one of them needs to be modeled dynamically, because they both have the same identical dynamic behavior.
Because the states are permutations over different values of attribute settings, it is important to use abstraction if necessary to filter out irrelevant attributes.
That is, if an attribute is not contributing to the dynamic behavior of an object, it does not have be modeled in the dynamic model.
This often helps in reducing the number of states of the state diagram for the object.
What makes up an action and what makes up an activity is relative, as we have already discussed earlier.
If in doubt, it is always better to model something first as an action, unless somebody points out that it has internal structure which is relevant for the application, or it has a duration which is significant with respect to the overall lifetime of the object.
Example: An alarm “Propulsion System Failure” should be modeled as an activity, because the propulsion system will most probably be down for a while after such a failure.

49. Summary of Object (Static) & Behaviour (Dynamic) Modelling
Object modelling: a central activity in Requirements Analysis
Class identification: a major activity of Object modelling
Apply syntactic rules in Event Flows of Use cases
Distinguish between Attributes and Classes
Object Types: Entity, Boundary, Control
Class Associations: Generic, Aggregation or Composition
Generalizations (Inheritance): Improve Object model
Iterate: Remove errors and improve models
Dynamic models from Use cases and Object models.
Sequence and Statechart diagrams identify new classes and operations.
Summary of Object & Behaviour Modelling:
Object modelling: a central activity in Requirements Analysis
Class identification: a major activity of Object modelling
Apply syntactic rules in Event Flows of Use cases
Distinguish between Attributes and Classes
Object Types: Entity, Boundary, Control
Class Associations: Generic, Aggregation or Composition
Generalizations (Inheritance): Improve Object model
Iterate: Remove errors and improve models
Dynamic models from Use cases and Object models.
Sequence and Statechart diagrams identify new classes and operations.

50. Summary of Requirements Analysis
Object model: Class & Object diagrams
Dynamic model: Sequence &Statechart diagrams
Functional model: Use Case diagrams
Differentiate between Class diagrams in
Analysis models: Application domain, users, clients
Design models: Solution domain, design patterns
Implementation models: Code, Components
Now Read Chapter 5 of BD.
Summary of Requirements Analysis
Object model: Class & Object diagrams
Dynamic model: Sequence &Statechart diagrams
Functional model: Use Case diagrams
Differentiate between Class diagrams in
Analysis models: Application domain, users, clients
Design models: Solution domain, design patterns
Implementation models: Code, Components