# Surgery Sessions (Weeks 6-10)

## Presentation on theme: "Surgery Sessions (Weeks 6-10)"— Presentation transcript:

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.

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

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.

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.

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)

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

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

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)

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

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

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

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

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

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

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

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

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()

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()

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

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

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.

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)

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

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.

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

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.

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”

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

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»

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

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

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()

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)

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

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

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.

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.

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

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!

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

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

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

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

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)

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.

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

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

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.

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.

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

Similar presentations