Analysis BD Ch' 5

1
Analysis (BD Ch. 5)
CS223 Lecture 7 Ananda Amatya Reminder Surgery
Sessions (Weeks 6-10) Mon 2 - 4 pm in C1.01 Fri
9 - 11 am in C1.04
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
• Abbotts Technique
• Behavioural (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.
  

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

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

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.

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 users terms (application domain)

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

9
Example 2BWatch Objects
Button
Year
ChangeDate
Month
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

ltltBoundarygtgt Button
ltltEntitygtgt Year
ltltControlgtgt ChangeDate
ltltEntitygtgt Month
ltltBoundarygtgt LCDDisplay
ltltEntitygtgt 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.

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.

13
Toy Shop Example Flow of Events for BuyAToy Use
Case
Flow of events

• 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.

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 Abbots technique
Grammatical construct
UML Component
Example
Concrete Person, Thing
Object
Monopoly"
noun
class
toy"
Adjective
Attribute
"3 years old"
verb
Operation
enters"
Intransitive verb
Operation (Event)
depends on."
Classifying verb
Inheritance
is a" ,either. or", kind of"
Possessive Verb
Aggregation
"Has a ", consists of"
modal Verb
Constraint
must be", less than"
15
Generation of a class diagram from flow of events
Flow of events
Customer
customer
store
enters
buy

• 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.

toy
daughter
less than 50 Euro
videogame
depends
age
boardgame
type of toy
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

17
Improving Object Models
Customer


Has
Name
CustomerId()
Savings Account
Checking Account
Mortgage Account
Dont 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()
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)

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 gt sequence
  diagram
• Model dynamic behavior of a single object gt
  statechart

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
• ....

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 ( 445pm, 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 gt These are the objects
  participating in the use case

24
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?

25
Sequence Diagram for Get SeatPosition
Seat
Onboard Computer
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
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.

27
Is this a good Sequence Diagram?
Seat
Onboard Computer
Smart Card

• 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
Accept Connection
Accept Connection
Get SeatPosition
500,575,300
28
Example Impact on ARENAs Object Model

• Lets assume, ARENAs 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
30
League
League

Owner
1

Attributes
Attributes
Operations
Operations
Tournament
Attributes
Operations
Player
Match


Attributes
Attributes
Operations
Operations
31
League
League

Owner
1

Attributes
Attributes
Operations
Operations
Tournament
Attributes
Operations
Player
Match


Attributes
Attributes
Operations
Operations
32
Impact on ARENAs 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.

33
Example from the Sequence Diagram
createTournament is a (public) operation owned
by Announce_Tournament_Control
createTournament (name, maxp)
34
League
League

Owner
1

Attributes
Attributes
Operations
Operations
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
Guard condition
entry /action
exit/action
Also internal transition and deferred events

• 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
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

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

38
Example of a StateChart Diagram (Vending Machine)
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.

40
Example of a Nested Statechart Diagram
do dispense item
41
Example of a Nested Statechart Diagram
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
do move arm to column
do dispense item
do push item off shelf
43
Expanding activity dodispense item
Dispense item as an atomic activity
change0
do dispense item
Dispense item as a composite activity
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)

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.

46
Example of Concurrency within an Object
Splitting control
Synchronization
Emitting
Do Dispense
Cash taken
Cash
Ready
Setting
to r
eset
Up
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

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)

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.

50
Summary of Requirements Analysis

• 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.