CS445 CS645 ECE451 Software Requirements Specification and Analysis

1
CS445 / CS645 / ECE451Software Requirements
Specification and Analysis

• Lecture 09
• UML interaction and state diagrams

2
Readings

• Required
• Larman, 3rd ed.
• Ch. 10, 15, 29
• Optional
• Fowler, UML Distilled, 3rd ed.
• Ch. 4, 10, 12

3
UML today (2005)

• Feature bloat?
• UML 1.4 nine diagram kinds
• UML 2.0 twelve diagram kinds
• Rumbaugh said that there was a lot of personal
  politics in deciding which kinds of diagrams and
  features got in
• There is a definition of the UML standard in
  terms of MOF
• This wasnt true for UML 1.X
• Precise semantics of some parts are not well
  defined
• Thats not a problem for most users
• Parnas has called UML the Undefined Modelling
  Language

Dont worry ...
Be happy
4
UML So far

• We have seen
• use case diagrams
• class diagrams (to describe domain models)
• Class diagrams can also be used to describe
  design / real code!
• use case descriptions (not UML per se)
• The use case diagrams give an informal overview
  of the system-level functionality of the system
  as experienced by the users (primary actors)
• The domain model gives a static view of the the
  domain entities and their inter-relationships

5
UML Next up

• We now examine UML diagrams that can describe the
  dynamic behaviour / properties of the SUD in
  detail.
• UML state diagrams model intra-object dynamic
  behaviour
• i.e., within a single object of a class
• Uses a finite state machine, like the lowest
  level of SDL
• UML interaction diagrams model inter-object
  dynamic behaviour
• i.e., interactions of multiple objects
• Two kinds sequence diagrams and communication
  diagrams
• They have almost the same semantics, but are
  drawn differently
• The name communication diagram is new to UML
  2.0 they were called collaboration diagrams in
  UML 1.X (and MagicDraw 9.0)

6
UML Tool annoyances

• Some of the details of UML interaction diagrams
  have changed between UML 1.X and 2.0
• e.g., how to indicate selection and iteration in
  sequence diagrams via interaction frames
• The 3rd edition (the current one) of both Fowler
  and Larman use the 2.0 standard
• MagicDraw 9.0 (the latest) implements them
  (clumsily), but older versions may not
• From our point of view, you may use either the
  UML 1.X or 2.0 approach
• or even something else, if you clear it with your
  tutor first).
• It doesnt really matter to us, as long as you
  are consistent and clear about the intended
  meaning.

7
UML Interaction and state diagrams

• Like SDL FSMs, UML state diagrams are capable of
  completely specifying the dynamic behaviour of a
  class of objects
• You can generate source code from them with a
  suitable tool
• You can maintain the system by editing the
  diagram (and never touching the code by hand)
• This is the goal of the MDA (model driven
  architecture) movement
• Make the high level description (specifically,
  the UML model or similar) the maintenance
  artifact, not the source code

8
UML Interaction and state diagrams

• Interaction diagrams illustrate rather than
  prescribe / define the interactions of a system
  and the domain entities
• They show one execution instance of a scenario
  in terms of interactions between concerned
  entities
• The do not contain enough info to model all the
  possible interactions
• Youll see why this is true later on
• You can think of them like a method call trace
• Design-time interaction diagrams are method call
  traces

9
Sidebar Model Driven Architecture

• Currently / historically, the MDA approach only
  works reasonably well for embedded and real-time
  systems
• Fairly simple data model / data structures, small
  code base
• State-based / event-driven programming paradigm
• Key problems in these kinds of systems
• Modelling interactions correctly
• Handling concurrency
• Covering all the sub-cases
• Features these systems usually do not have
• Large code bases, hairy data structures,
  semantics distributed throughout the codebase

10
Sidebar Model Driven Architecture

• The goal of the MDA movement is to make this kind
  of automated approach to software development
  practical in other domains, where there is a good
  understanding of the problem domain and vendors
  can build dumb hairy wizards for your problem
• It is the model (as represented in UML) that is
  maintained rather than the source code.
• The source code becomes a derived artifact,
  treated much like we treat object code today
• i.e., we put complete trust in the compiler /
  linker
• The MDA approach is actually built around MOF,
  which is the language used to define UML, rather
  than UML itself.
• Dont understand that? Dont worry. Be happy.

11
Sidebar Model Driven Architecture

• How MDA works
• Some clever vendor builds a system, call it V,
  that includes a UML model of an interesting
  domain, say travel agency. V is also capable of
  generating source code that implements a system
  that conforms to the travel agency UML model.
• The vendor sells an instance of this system to a
  client, who wants to specialize it for their own
  company
• i.e., they want V to generate a system C that
  they can use that is customized for their needs.
• The client fine-tunes the UML model, and presses
  the generate system button to produce C.
• If / when needs change, the client changes the
  UML model appropriately and generates a new
  system.

12
Sidebar Model Driven Architecture

• The M in MDA means that you are developing and
  maintaining the abstract model of your system,
  rather than the source code
• i.e., you are managing the domain model elements
  and their interactions of your particular world
  rather than the source code
• The A in MDA refers to the architecture of the
  development process, not the architecture of the
  system you are developing
• Its a poor choice of terms!

13
Sidebar Model Driven Architecture

• Politics
• MDA is a trademark of OMG (the inter-company
  consortium that owns the UML standard and
  others)
• MDA specifies things you may / many not do
• You have to follow their rules, or you are not
  MDA-compliant
• Other related terms
• Model driven development (generic MDA)
• Software factories (Microsoft)

14
Sequence Diagrams

• A sequence diagram is a form of event trace,
  showing objects (not classes) and their
  interactions over time.
• It depicts a scenario, showing the end-to-end
  behaviour
• It indicates which object has the responsibility
  to respond to events
• They are pretty intuitive!
• Notes
• A top-level view of system interacting with
  environment is called a system sequence diagram
  (SSD) Larman
• Sequence diagrams were inspired by message
  sequence charts (MSCs), a standardized
  engineering notation in wide use
• Pedantic NB In UML 2.0, the participants are
  not necessarily objects and are not supposed to
  be underlined.
• My advice Dont worry be happy.

15
Example sequence diagram
MagicDraw 9.0
16
Sequence Diagrams Notation

• Basic features
• Each column models the behaviour of an object
  within a given scenario
• Ivory true for UML 2.0, but close enough ?
• A vertical line is the lifeline of object
• Time goes downward
• A rectangle on lifeline is activation bar (focus
  of control)
• Its the period during which the object is
  involved in the activity initiated at the top of
  the focus
• In a design diagram, it can represent an active
  method call whose activation record is on the
  stack at that moment.

17
Sequence Diagrams Notation

• Basic features
• A horizontal arrow expresses an event conveyed by
  source object to target object.
• During requirements, these are abstract events
  initiated by the source and responded to by the
  target
• During design, these can represent a method call
  by the source object of a method defined by the
  target objects class
• A dashed arrow can be used to show method
  returns.
• Usually omitted used mostly to show when a value
  is returned by a method call
• A looping arrow expresses recursion or self-call

18
Larman Fig 15.7
Larman Fig 15.8
19
Sequence Diagrams Notation

• Basic features
• A filled arrowhead shows a synchronous message
• The sender blocks until the recipient returns,
  like a normal procedure/method call in a
  sequential program
• A stick arrowhead shows an asynchronous message
• The sender sends the message and then carries on
• Common in concurrent systems

Since UML 1.4
Until UML 1.3 (deprecated)
20
Sequence Diagrams Notation

• UML 1.X advanced features
• A before the message name or a marginal note
  indicates iteration
• Sometimes, square brackets surround the thing to
  iterate over
• for each line item in sales order
• A message may be conditional / guarded
• total gt 1000 getManagerApproval ()
• All participants are objects,
• i.e., instances of a (possibly abstract!) class
• Names of object and class are underlined
• aCaller Caller, Exchange

21
Sequence Diagrams Notation

• UML 2.0 advanced features
• Participants Fowlers term are not necessarily
  objects
• Messages may be sent to a class rather than an
  object
• Like a static method call in Java
• Dont underline the names
• Conditionals, loops, other advanced control
  features are modelled through activation frames.

22
Elaborating sequence diagrams

• As you elaborate the domain model and specify in
  more detail the entities that the system senses
  and controls, the self calls become messages to
  these other entities
• Some of these are transient entities that exist
  (conceptually) only during a system interaction.
  We can show their birth / death on a sequence
  diagram
• Create transient objects
• in response to a create
• Destroy transient objects
• either because it receives a destroy message or
  because it destroys itself.

23
Another example
24
Sequence diagrams

• While sequence diagrams can model if and loop
  behaviours, they arent very natural
• Clutter becomes a problem for interaction
  diagrams if you try to show too much detailed
  behaviour
• These diagrams are much better at showing
  abstract sequences of how goals are satisfied,
  and the responsibilities that the various
  participants have
• State (and other UML) diagrams are much better at
  modelling if and loop
• And code / pseudo-code is even better, esp. if
  the semantics arent a good fit for the
  state-transition paradigm

25
Interaction frames

• Interaction frames
• are new to UML 2.0
• can be used to model several kinds of control
  structures (if, loop, parallelism, etc.)
• For MagicDraw 9.0, use the CombinedFragment
  button
• Basic idea
• A box covers a fragment of a sequence diagram
• The box is labelled at the top left with an
  operator name
• Depending on the operator kind
• The box may be divided into several sections
• Each section may have a guard (boolean expression)

26
Another example Larman Fig 10.2
27
Some interaction frame operators
28
(No Transcript)
29
Another example Larman Fig. 15.19
30
System sequence diagrams (SSDs)

• Scenarios and sequence diagrams can be used at
  almost any level of detail at any stage of
  development.
• They can illustrate uses case behaviour with
  little detail.
• They can show full blown system method traces of
  the implementing code.
• SSD is Larmans term for a sequence diagram at
  the top (aka system) level
• The SUD is one box, and actors involved in the
  scenario are the other participants.
• There are no found events scenarios start by a
  system-level trigger by an actor action.

31
Another example Larman Fig 10.3
32
Communication diagrams

• Roughly speaking, they are sequence diagrams that
  use a different layout.
• Think of them as an object diagram with the info
  from a sequence diagram overlaid on top
• They are a bit less powerful than sequence
  diagrams in what they can represent
• No interaction frames, but they can show
  iteration and selection
• Messages are annotated with sequence numbers to
  show the order of events.
• The numbering can be simply 1, 2, 3, 4, ...
• However, to show decomposition of requests into
  sub-requests and sub-responses, messages can be
  annotated with a nested numbering scheme.

33
An example
34
An example
35
UML state diagrams

• aka state-machine diagrams aka Statecharts
  Harel
• Shows finely-grained behaviour within an object
• Useful for describing the inner behaviour of a
  class that conforms well to the state-transition
  paradigm
• Finitely many discernable inner states methods
  responses highly dependent on internal state
• Many of the classes you have written in previous
  programming courses do not conform well to this
  paradigm
• They may have infinitely many possible abstract
  inner states (defined implicitly by their
  instance variables) but they respond more less
  the same way to method invocations

36
An example Fowler p108
37
UML state diagrams

• are a form of hierarchical finite state
  machine
• It shows the lifecycle of an instance of the
  class
• The objects starts in a given state, and
  transitions to others based on external messages
  received and the values of its internal variables
• It shows the behaviour of an object across
  several use cases.
• We define one Statechart diagram (perhaps of
  several parts) per class
• We dont bother defining state diagrams for the
  classes with simple behaviour.
• Taken together, the Statecharts for all the
  objects of the system describe how the system
  reacts to inputs from its environment

38
States

• A state is the condition of an object at a
  moment in time Larman
• It represents the history of inputs received
• e.g., a parity check
• A state
• partitions class behaviour,
• e.g., not being able to check out a borrowed
  book.
• affects what input the object will react to,
• e.g., ignoring most input in the state OFF.
• Thus, a state is the aggregated value of an
  interesting collection of attributes, not
  necessarily all of them.

39
Events and transitions

• An event is a significant or noteworthy
  occurrence Larman
• (external) a change in the environment
• e.g., off-hook
• (internal) a message from another object
  (operation call)
• (external/internal) change in a condition
• e.g., when (temperature gt 100 degrees)
• (temporal) the occurrence of a specific date/time
  or passage of time
• e.g., after (20 minutes)
• Events make an object change state.
• A transition describes a change in state due to
  the occurrence of an event.
• Suppose an object is in a particular state and an
  event occurs
• If there is no outgoing transition triggered by
  that event, then that event is ignored.

40
Overview of state diagram

• Each of these parts of the transition is
  optional.
• event(args) event / message that triggers the
  transition
• condition (boolean) guard condition the
  transition cannot fire unless the guard condition
  is true
• /action a simple, fast, non-interruptible
  action,
• e.g., variable assignment, send a message to an
  object Object.event(args)

41
State actions and activities

• A state can have actions and activities
  associated with it also.
• State actions and activities can manipulate
  object attributes or other variables.
• Action simple, non-interruptible. It can be
• associated with a transition, or
• performed on state entry or exit.
• Activity interruptible may require much
  computation. It can be
• associated with a state, and
• can be interrupted by a transition.
• In UML 2.0, the terminology is different. As
  defined above
• Actions are known as regular activities
• Activities are known as do-activities

42
An example Fowler p110
43
State actions and activities

• States can be annotated with entry or exit
  actions, internal actions, and activities
• entry / action
• event / action
• a way to describe reactions to events that dont
  cause a state change internal transitions
• exit / action
• do / activity
• If a transition has no event label, it can occur
  once any activity associated with the state is
  complete.

44
Describing behaviour

• Compared to an action on a transition, one could
  also
• as action in state
• as activity in state
• as activity in another, special state

45
Describing behaviour

• Compared to an action on a self-transition, one
  could
• as action internal transition
• as activity in another, special state

46
State actions and activities

• In a transition, the order of effects is
• exit actions of source
• transition actions
• entry actions of destination, and
• state activities
• A self-transition will cause reactivation of exit
  and then entry events.
• If you want a self-transition that does not
  activate these events, you can use an internal
  event, labelled with the event and the associated
  action or activity,
• e.g., req/reply in the middle StateA.

47
Summary
48
Superstates

• A superstate combines states and transitions that
  work together towards a common goal.
• If a transition leaves a superstate, this
  transition applies to all the sub-states and has
  higher priority than the transitions within the
  superstate.
• The substates inherit the transitions of the
  superstate.

49
Another example Larman 29.3
50
Concurrent states

• A concurrent state captures two or more
  behaviours of the object that happen
  concurrently, each with its own control thread.
• If you have many concurrent states, you should
  consider dividing the behaviour between more
  objects.
• Concurrency also helps to unclutter
• Note final states all concurrent components have
  to reach final states before transitions

51
Concurrent state example
52
(No Transcript)
53
Hidden slide

• To see that they are identical, let
• Stacks (InLibrary, NotReserved)
• OnLoan (OutOfLibrary, NotReserved)
• ReserveShelf (InLibrary, Reserved)
• ReserveLoan (OutOfLibrary, Reserved)
• Recall (Recall, Recall)
• and consider each of the possible transitions
• borrow, return, reserve, unreserve
• and see that the equivalences are preserved by
  each transition, with possible conditions.

54
Controller

• Most objects in an information system like a
  library have simple dynamic models.
• Each tends to be a passive object that waits for
  an event, changes a few attributes, and then
  returns to itself.
• The question is from where do these input events
  come?
• Control Object
• complex object that collaborates with many
  objects to achieve a task, e.g., a use case

55
Examples

• An aggregate object (a container) often acts as a
  control object for its components.
• A system object often acts as a control object
  for the system.
• An interface object often interacts with the
  user, and realizes the users requests by
  controlling various other objects.

56
History

• History can be used to return to the last known
  substate upon re-entry from a superstate.
• This is shallow history there is also deep
  history

57
Sending messages to objects

• Problem
• There may be many instances of a given class. How
  can we send a message (invoke an operation) to a
  particular instance?
• One solution
• Use class-scope operations (operations belonging
  to the class aka static operation) to find the
  particular object.
• A transition in the library might have
• p Patron.findPatron (PatronID)
• p.checkfine()

58
Classes and statechart diagrams

• We only need to draw state diagrams for classes
  with interesting behaviour. Common examples
• Controller objects
• User interface screens / web pages
• Business transactions (multi-staged)
• Embedded / control / telecom systems / protocol
  handlers
• According to Larman
• state-independent objects for all events of
  interest, the object always responds the same way
• state-dependent objects react differently to
  events depending on the internal state
• We want to describe state diagrams for the
  state-dependent objects.

59
(No Transcript)
60
Statecharts diagrams Validation

• Avoid inconsistency dont have multiple
  transitions leave the same state under the same
  event.
• Problem What is the next state? Which transition
  is taken? This is a particular problem in
  hierarchical state machines. When transitions at
  different levels are activated by the same event,
  which transition has priority?
• Ensure completeness a reaction is specified for
  every possible input.
• This is an issue particularly when transitions
  are conditional. If there are transitions
  triggered by an event conditioned on some guard,
  what happens if the guard is false? This is most
  important in safety-critical systems.

61
Hidden slide

• Do bicycle computer example

62
GRASP patterns Larman

• What class should do what? Which class has
  certain responsibilities?
• GRASP General Responsibilities Assignment
  Software Patterns
• Information Expert give the responsibility to
  the class that has the information to carry out
  the task.
• Creator the creator of an object should be the
  class that aggregates / contains / has
  initializing data for new object.
• Low Coupling dont want objects to be tightly
  related to each other (not good for reuse)
• High Cohesion the responsibilities of a class
  should be strongly related and focused
• Controller a class for receiving and handling
  system events delegates work

63
Hidden slide

• Do library example

64
Hidden slide
65
Hidden slide
66
Hidden slide
67
Hidden slide
68
Hidden slide
69
Hidden slide
70
CS445 / CS645 / ECE451Software Requirements
Specification and Analysis

• Lecture 09
• UML interaction and state diagrams