Requirements Analysis

1
Requirements Analysis

• Chapters 5-6
• Object-Oriented Software Engineering
• Using UML, Patterns, and Java, 2nd Edition
• By B. Bruegge and A. Dutoit
• Prentice Hall, 2004.

2
Requirements Analysis

• Formalization of requirements elicited from users
• Analysis models
• Functional model (use cases)
• Analysis object model (class diagrams)
• Dynamic model (statechart and sequence diagrams)

3
Object Models and Dynamic Models

• Object model
• Focuses on individual concepts manipulated by
  system
• Class diagrams represent relationships between
  classes and objects and properties of those
  classes and relationships
• Dynamic model
• Focuses on behavior of the system
• Sequence diagrams represent interactions between
  objects within a single use case
• Statecharts represent behavior within a single
  object

4
Analysis Activities

• Identifying entity objects
• Identifying boundary objects
• Identifying control objects
• Mapping use cases to objects with sequence
  diagrams
• Modeling interactions among objects with CRC
  cards
• Identifying associations
• Identifying aggregates
• Identifying attributes
• Modeling state-dependent behavior of individual
  objects
• Modeling inheritance relationships between
  objects
• Reviewing the analysis model

5
Object Models

• Analysis Object Model
• Classes and objects that describe the application
  domain
• Part of the Requirements Document
• Examples BoardGame, Watch
• Solution Object Model
• Classes and objects that are used to solve the
  problem
• Part of the Design Document
• Examples Tree, Hashtable, Widget
• During Requirements Analysis, we focus on
  building the Analysis Object Model

6
Activities during Object Modeling

• Main goal Find the important abstractions
• What happens if we find the wrong abstractions?
• Iterate and correct the model
• Steps during object modeling
• 1. Class identification
• Based on the fundamental assumption that we can
  find abstractions
• 2. Find the attributes
• 3. Find the methods
• 4. Find the associations between classes
• Order of steps
• Goal get the desired abstractions
• Order of steps secondary, only a heuristic
• Iteration is important

7
Class Identification

• Identify the boundaries of the system
• Identify the important entities in the system
• Class identification is crucial to
  object-oriented modeling
• Basic assumption
• 1. We can find the classes for a new software
  system (Forward Engineering)
• 2. We can identify the classes in an existing
  system (Reverse Engineering)
• Depending on the purpose of the system different
  objects might be found
• How can we identify the purpose of a system?
• Scenarios and use cases

8
Pieces of an Object Model

• Classes
• Associations (Relations)
• Generic associations
• Canonical associations
• Part of- Hierarchy (Aggregation)
• Kind of-Hierarchy (Generalization)
• Attributes
• Detection of attributes
• Application specific
• Attributes in one system can be classes in
  another system
• Turning attributes to classes
• Operations
• Detection of operations
• Generic operations Get/Set, General world
  knowledge, design patterns
• Domain operations Dynamic model, Functional model

9
Object vs Class

• Object (instance) Exactly one thing
• Class describes a group of objects with similar
  properties
• Object diagram A graphic notation for modeling
  objects, classes and their relationships
  ("associations")
• Class diagram Template for describing many
  instances of data. Useful for taxonomies,
  patters, schemata...
• Instance diagram A particular set of objects
  relating to each other. Useful for discussing
  scenarios, test cases and examples

10
Finding Participating Objects in Use Cases

• Pick a use case and look at its flow of events
• Find terms that developers or users need to
  clarify in order to understand the flow of events
• Look for recurring nouns (e.g., Incident),
• Identify real world entities that the system
  needs to keep track of (e.g., FieldOfficer,
  Dispatcher, Resource),
• Identify real world procedures that the system
  needs to keep track of (e.g., EmergencyOperationsP
  lan),
• Identify data sources or sinks (e.g., Printer)
• Identify interface artifacts (e.g.,
  PoliceStation)
• Be prepared that some objects are still missing
  and need to be found
• Model the flow of events with a sequence diagram
• Always use the users terms

11
Mapping parts of speech to object model
components Abbott, 1983

Part of speech
Model component
Example

Proper noun
object
Jim Smith

Improper noun
class
Toy, doll

Doing verb
method
Buy, recommend

being verb
inheritance
is-a (kind-of)

having verb
aggregation
has an

modal verb
constraint
must be

adjective
attribute
3 years old

transitive verb
method
enter

intransitive verb
method (event)
depends on
12
Object Types

• Entity Objects
• Represent the persistent information tracked by
  the system (Application domain objects, Business
  objects)
• Boundary Objects
• Represent the interaction between the user and
  the system
• Control Objects
• Represent the control tasks performed by the
  system
• Having three types of objects leads to models
  that are more resilient to change.
• The interface of a system is more likely to
  change than the control
• The control of the system is more likely to
  change than the application domain

13
Example 2BWatch Objects
Button
Year
ChangeDate
Month
LCDDisplay
Day
Entity Objects
Control Objects
Interface Objects
14
Naming of Object Types in UML

• UML provides several mechanisms to extend the
  language
• UML provides the stereotype mechanism to present
  new modeling elements

ltltBoundarygtgt Button
ltltEntitygtgt Year
ltltControlgtgt ChangeDate
ltltEntititygtgt Month
ltltBoundarygtgt LCDDisplay
ltltEntitygtgt Day
Entity Objects
Control Objects
Boundary Objects
15
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.

Button_Boundary
Year
ChangeDate_ Control
Month
LCDDisplay_Boundary
Day
16
Example Flow of events

• The customer enters a store with the intention of
  buying a toy for his child with the age of n.
• Help must be available within less than one
  minute.
• The store owner gives advice to the customer. The
  advice depends on the age range of the child and
  the attributes of the toy.
• The customer selects a dangerous toy which is
  kind of unsuitable for the child.
• The store owner recommends a more yellow doll.

17
Identifying Entity Objects

• Entity objects
• Persistent information tracked by system
• Heuristics
• Terms that developers or users need to clarify in
  order to understand the use case
• Recurring nouns in the use case
• Real-world entities that the system needs to
  track
• Real-world activities that the system needs to
  track
• Data sources or sinks

18
Identifying Boundary Objects

• Boundary objects
• Interactions between actors and system
• Heuristics
• Identify user interface controls that the user
  needs to initiate the use case
• Identify forms the user needs to enter data into
  the system
• Identify notices and messages the system needs to
  respond to the user
• Identify actor terminals to refer to the user
  interface under consideration
• Do not model the visual aspects of the user
  interface
• Use end users terms

19
Identifying Control Objects

• Control objects
• Realize use cases, encapsulates the behavior of
  the use case
• Usually not persistent, exists in the lifetime of
  the use case
• Helps clarify the entry and exit conditions of
  the use case
• Heuristics
• Identify one control object per use case
• Identify one control object per actor in the use
  case

20
Identifying Associations

• Association
• A relationship between two or more classes
• Properties
• Name describes what the relationship is all
  about
• Role the function of each class in the
  association
• Multiplicity number of possible instances
• Heuristics
• Examine verb phrases
• Name associations and roles precisely
• Use qualifiers to identify namespaces and keys
• Eliminate associations that can be derived from
  other associations
• Worry about multiplicity later
• Minimize the number of associations

21
Qualifiers

• Qualifiers can be used to reduce the multiplicity
  of an association.

22
Identifying Aggregates

• Aggregate
• An association denoting whole-part relationship
• Composition aggregate
• Whole and parts cannot exist without each other
• Denotes is-part-of relationship
• Shared aggregate
• Whole and parts can exist independently
• Denotes belongs-to relationship
• Heuristics
• 1-to-many relationships could potentially be
  whole-part relationships

23
Aggregation

• An aggregation is a special case of association
  denoting a consists of hierarchy.
• The aggregate is the parent class, the components
  are the children class.
• A solid diamond denotes composition, a strong
  form of aggregation where components cannot exist
  without the aggregate. (Bill of Material)

Exhaust system
0..2
1
Muffler
Tailpipe
diameter
diameter
3
24
Identifying Attributes

• Attributes
• Properties of individual objects
• Properties
• Name
• Type
• Heuristics
• Examine possessive phrases
• Represent stored state as an attribute
• Describe each attribute

25
Modeling Inheritance Relationships

• Generalization
• Identification of abstract concepts from
  lower-level ones
• Specialization
• Identification of more specific concepts from a
  high-level one
• Heuristics
• Look for classes that share similarities
• Look for groups of classes that appear to be a
  taxonomy

26
A Strategy for Building Object Models

• Explicitly schedule meetings for object
  identification
• First just find objects
• Then try to differentiate them between entity,
  interface and control objects
• Find associations and their multiplicity
• Unusual multiplicities usually lead to new
  objects or categories
• Identify Inheritance Look for a Taxonomy,
  Categorize
• Identify Aggregation
• Allow time for brainstorming , Iterate, iterate

27
Analysis Activities

• Identifying entity objects
• Identifying boundary objects
• Identifying control objects
• Mapping use cases to objects with sequence
  diagrams
• Modeling interactions among objects with CRC
  cards
• Identifying associations
• Identifying aggregates
• Identifying attributes
• Modeling state-dependent behavior of individual
  objects
• Modeling inheritance relationships between
  objects
• Reviewing the analysis model

28
Dynamic Modeling with UML

• Diagrams for dynamic modeling
• Interaction diagrams describe the dynamic
  behavior between objects
• Statecharts describe the dynamic behavior 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
• Shows the relationship among objects. Does not
  show time
• State Chart 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)

29
Dynamic Modeling

• Definition of dynamic model
• A collection of multiple state chart diagrams,
  one state chart diagram for each class with
  important dynamic behavior.
• Purpose
• Detect and supply methods for the object model
• 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 diagram

30
What is an Event?

• Something that happens at a point in time
• Relation of events to each other
• Causally related Before, 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 Bob calls Janet.
• Event class New call, Subclass Pick up
  receiver
• Attribute of an event class
• Call(Bob, Janet)

31
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 modeling
• Objects are identified as a result of dynamic
  modeling
• 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

32
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
• ....
• Actors caller, callee
• Objects
• Caller phone, callee phone, network
• Phone aggregate of receiver, keypad, ringer,
  line
• Network aggregate of switches, trunks, signaling
  links

33
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.
• Use CRC cards as first step in defining complex
  sequence diagrams

34
CRC Cards

• CRC class, responsibilities, collaborators
• Class name of class
• Responsibilities operations the class is
  responsible for
• Collaborators other classes it is associated
  with
• CRC cards can be used to clarify the scope of a
  class
• Useful during brainstorming sessions
• Take vertical slice through a scenario
• Identify all classes, write each one on a card
• While examining flow of events, fill in the
  responsibilities of each class
• Collaborators are added as dependencies between
  classes are identified.

35
What else can we get out of sequence diagrams?

• Sequence diagrams are derived from the use cases.
  We therefore see the structure of the use cases.
  
• The structure of the sequence diagram helps us to
  determine how decentralized the system is.
• We distinguish two structures for sequence
  diagrams Fork and Stair Diagrams (Ivar Jacobsen)

36
Fork Diagram

• Much of the dynamic behavior is placed in a
  single object, ususally the control object. It
  knows all the other objects and often uses them
  for direct questions and commands.

37
Stair Diagram

• The dynamic behavior is distributed. Each object
  delegates some responsibility to other objects.
  Each object knows only a few of the other objects
  and knows which objects can hel with a specific
  behavior.

38
Fork or Stair?

• Which of these diagram types should be chosen?
• Object-oriented fans claim that the stair
  structure is better
• The more the responsibility is spread out, the
  better
• However, this is not always true. Better
  heuristics
• Decentralized control structure
• The operations have a strong connection
• The operations will always be performed in the
  same order
• Centralized control structure (better support of
  change)
• The operations can change order
• New operations can be inserted as a result of new
  requirements

39
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

40
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 (reduces 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

41
State

• An abstraction of the attributes of a class
• State is the aggregation of several attributes a
  class
• Basically an equivalence class of all those
  attribute values and links that do no 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

42
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
  denote a superstate are enclosed by a large
  rounded box, also called contour.

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

44
Modeling 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.

45
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
46
State Chart Diagram vs Sequence Diagram

• State chart diagrams help to identify
• Changes to an individual object over time
• Sequence diagrams help to identify
• The temporal relationship of between objects over
  time
• Sequence of operations as a response to one ore
  more events

47
Dynamic Modeling of User Interfaces

• Statechart diagrams can be used for the design of
  user interfaces
• Also called Navigation Path
• States Name of screens
• Graphical layout of the screens associated with
  the states helps when presenting the dynamic
  model of a user interface
• Activities/actions are shown as bullets under
  screen name
• Often only the exit action is shown
• State transitions Result of exit action
• Button click
• Menu selection
• Cursor movements
• Good for web-based user interface design

48
Navigation Path Example

• Diagnostics Menu
• User moves cursor to Control Panel or Graph

• Graph
• User selects data group and type of graph

• Control panel
• User selects functionality of sensors

• Selection
• User selects data group
• Field site
• Car
• Sensor group
• Time range
• User selects type of graph
• time line
• histogram
• pie chart

• Define
• User defines a sensor event
• from a list of events

• Disable
• User can disable a sensor event from a list of
  sensor events

• Enable
• User can enable a sensor event from a list of
  sensor events

• List of events
• User selects event(s)

• Visualize
• User views graph
• User can add data groups for being viewed

• List of sensor events
• User selects sensor event(s)

• Link
• User makes a link (doclink)

49
Practical Tips for Dynamic Modeling

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

50
Summary Requirements Analysis

• 1. What are the transformations?
• Create scenarios and use case diagrams
• Talk to client, observe, get historical records,
  do thought experiments

2. What is the structure of the system? Create
class diagrams Identify objects. What are the
associations between them? What is their
multiplicity? What are the attributes of the
objects? What operations are defined on the
objects?
3. What is its behavior? Create sequence
diagrams Identify senders and receivers Show
sequence of events exchanged between objects.
Identify event dependencies and event
concurrency. Create state diagrams Only for the
dynamically interesting objects.
51
Example

• Flow of events from Dial a Number Use case
• Caller lifts receiver
• Dial tone begins
• Caller dials
• Phone rings
• Callee answers phone
• Ringing stops
• ....
• Actors caller, callee
• Objects
• Caller phone, callee phone, network
• Phone aggregate of receiver, keypad, ringer,
  line
• Network aggregate of switches, trunks, signaling
  links

52
Define Use Case What is the system boundary?
Network is part of system
Network is not part of system
(Exceptions are not shown here)
53
Initial Objects
54
Sequence Diagram for Call Origination
55
Updated List of Objects
56
State Chart for originateCallControl Object
57
Modeling Checklist for the Review

• Is the model correct?
• A model is correct if it represents the clients
  view of the the system Everything is the model
  represents an aspect of reality
• Is the model complete?
• Every scenario through the system, including
  exceptions, is described.
• Is the model consistent?
• The model does not have components that
  contradict themselves (for example, deliver
  contradicting results)
• Is the model unambiguous?
• The model describes one system (one reality), not
  many
• Is the model realistic?
• The model can be implemented without problems

58
Diagram Checklist for the Requirements Document

• One problem with modeling
• We describe a system model with many different
  views (class diagram, use cases, sequence
  diagrams, )state charts)
• We need to check the equivalence of these views
  as well
• Syntactical check of the models
• Check for consistent naming of classes,
  attributes, methods in different subsystems
• Identify dangling associations (associations
  pointing to nowhere)
• Identify double- defined classes
• Identify missing classes (mentioned in one model
  but not defined anywhere)
• Check for classes with the same name but
  different meanings

59
Additional slides
60
When is a model dominant?

• Model dominance One model having significantly
  higher importance than the rest
• Object model The system has objects with
  nontrivial state.
• Dynamic model The model has many different types
  of events Input, output, exceptions, errors,
  etc.
• Functional model The model performs complicated
  transformations (e.g. computations consisting of
  many steps).
• Which of these models is dominant in the
  following three cases?
• Compiler
• Database system
• Spreadsheet program

61
Dominance of models

• Compiler
• The functional model most important. (Why?)
• The dynamic model is trivial because there is
  only one type input and only a few outputs.
• Database systems
• The object model most important.
• The functional model is trivial, because the
  purpose of the functions is usually to store,
  organize and retrieve data.
• Spreadsheet program
• The functional model most important.
• The dynamic model is interesting if the program
  allows computations on a cell.
• The object model is trivial, because the
  spreadsheet values are trivial and cannot be
  structured further. The only interesting object
  is the cell.

62
Team Analysis

• A system is a collection of subsystems providing
  services
• Analysis of services is provided by a set of the
  teams who provide the models for their subsystems
• Integration of subsystem models into the full
  system model by the architecture team
• Analysis integration checklist
• Are all the classes mentioned in the data
  dictionary?
• Are the names of the methods consistent with the
  names of actions, activities, events or
  processes?
• Check for assumptions made by each of the
  services
• Missing methods, classes
• Unmatched associations

63
Analysis UML Activity Diagram
64
Object Model Integration in a large Project
All Teams
Model Changes
Team 1
Integrated
System
Model

User Interface
Module 1
Module
Integration
Architecture Team
Module 4
Module 3
Module 2
Module 5
Analysis
Team 5
Team 3
Team 4
Team 2
65
Project Agreement

• The project agreement represents the acceptance
  of (parts of) the analysis model (as documented
  by the requirements analysis document) by the
  client.
• The client and the developers converge on a
  single idea and agree about the functions and
  features that the system will have. In addition,
  they agree on
• a list of prioritized requirements
• a revision process
• a list of criteria that will be used to accept or
  reject the system
• a schedule, and a budget

66
Prioritizing requirements

• High priority (Core requirements)
• Must be addressed during analysis, design, and
  implementation.
• A high-priority feature must be demonstrated
  successfully during client acceptance.
• Medium priority (Optional requirements)
• Must be addressed during analysis and design.
• Usually implemented and demonstrated in the
  second iteration of the system development.
• Low priority (Fancy requirements)
• Must be addressed during analysis (very
  visionary scenarios).
• Illustrates how the system is going to be used in
  the future if not yet available technology
  enablers are available

67
Summary

• In this lecture, we reviewed the construction of
  the dynamic model from use case and object
  models. In particular, we described In
  particular, we described
• Sequence and statechart diagrams for identifying
  new classes and operations.