COS 315

1
COS 315 SOFTWARE ENGINEERING 7. Object-Oriented
Analysis Requirements Analysis from O-O
Perspective - Object Modeling
2
Where are we right now?

• Three ways to deal with complexity
• Abstraction
• Decomposition (Technique Divide and conquer)
• Hierarchy (Technique Layering)
• Two ways to deal with decomposition
• Object-orientation and functional decomposition
• Functional decomposition leads to unmaintainable
  code
• Depending on the purpose of the system,
  different objects can be found
• What is the right way?
• Start with a description of the functionality
  (Use case model). Then proceed by finding objects
  (Object model).
• What activities and models are needed?
• This leads us to the software lifecycle we use in
  this class

3
Object-Oriented Analysis (OOA)

• Creating a model of the system in terms of
  objects, attributes, classes, members, wholes,
  and parts
• - Coad/Yourdon
• Pioneers of Structured Analysis and Design, 1991
• but now converted disciples of OOAD
• Always use domain or user terminology
• Reference
• http//www.sei.cmu.edu/str/descriptions/ooanalysis
  .html

4
OOA Process - in a nutshell!

• Select classes and objects using requirements as
  guideline
• Identify attributes and operations for those
  objects
• Define structures and hierarchies that organize
  classes
• Construct object diagrams
• Refine with high-level sequence diagrams

5
Note Jargon application domain ? problem domain
6
In (requirements) analysis, developers focus on
structuring and formalizing the requirements
elicited from users. Analysis focuses on
producing a model of the system called the
analysis model, which comprises three individual
models - the functional model use cases and
scenarios gtgt developed during requirements
elicitation - the object model class and
object diagrams - the dynamic model statechart
and sequence diagrams
The three models together form the specification
7
(No Transcript)
8
The Analysis Process
Build a prototype
Requirements elicitation
Develop specification
The problem
Review
Create analysis models
9
The functional model is evolved during
requirements elicitation. Refinement of the
functional model allows us to derive the other
two models - the object model - the dynamic
model
10
Four UML Models Use Case diagrams - represent
the functionality of the system from a users
point of view. They define the boundaries of the
system. Class diagrams - represent the structure
of the system in terms of objects, their
attributes and relationships. Sequence diagrams
- represent the systems behaviour in terms of
interactions among a set of objects. They are
used to help identify objects in the application
and implementation domains. Statechart diagrams
- represent the behaviour objects as a sequence
of states object goes through in response to
external events.
11
Activities during Object Modeling Main goal
Find the important abstractions ? objects What
happens if we find the wrong abstractions? -
Iterate (Try again! Refine!) and correct the
model Steps during object modeling 1. Class
identification gtgt Based on the fundamental
assumption that we can find abstractions! 2.
Find the class attributes 3. Find the class
methods 4. Find the associations between
classes Order of steps Goal get the desired
abstractions Order of steps secondary, only a
heuristic! Iteration (aka refinement) is
important
12
From Use Cases to Objects
Refinement
13
Use Cases can be used by more than one object

Le
v
el 1
Top Level Use Case
Level 2 Use Cases
Le
v
el 2
Le
v
el 2
Level 3 Use Cases
Le
v
el 3
Le
v
el 3
Le
v
el 3
Operations
Le
v
el 4
Le
v
el 4
A
B
Participating Objects
14
Class Identification 1. Identify the boundaries
of the system 2. Identify the important entities
(? objects) in the system ? class
identification Class identification is crucial
to object-oriented modeling! Identifying objects
helps us identify the classes ? implement as
C/Java/ functions
15
Class identification Objects are not just found
by taking a picture of a scene or domain. The
application domain has to be analyzed. Depending
on the purpose of the system, different objects
might be found - How can we identify the
purpose of a system? gtgt Via scenarios and use
cases Another important problem Define the
system boundary. - What objects are inside,
what objects are outside?
16
Pieces of an Object Model Classes which have -
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 class data - Operations - Detection of
operations - Generic operations Get/Set
(C/C), general world knowledge, design
patterns - Domain operations dynamic model,
functional model
17
Object Types Distinguish three types of
objects Entity Objects - Represent the
persistent information tracked by the system (aka
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
18
Having three types of objects leads to models
that are more resilient to change. - The
interface of a system changes more likely than
the control - The control of the system changes
more likely than the application domain The
system is partitioned into three separate
categories, thereby making changes in one
category have less of an impact (in terms of
changes) on the other categories.
19
Entity Objects

• Objects that represent a participating object (in
  a use case)
• Real-world things - entities in the problem
  domain
• Heuristics for identifying them
• Terms that must be understood to clarify a use
  case
• Recurring nouns in the use case
• Real-world entities and activities that need to
  be tracked
• Use cases themselves (e.g. ReportEmergency)
• Data producers or consumers

20
E.g. Entity objects from the ReportEmergency use
case Dispatcher EmergencyReport FieldOfficer
Incident
21
Boundary Objects

• Represent the system interface with the actors
• Each use case has at least one boundary object
  (one per actor-use case association. By
  definition!)
• The boundary object collects the information from
  the actor and translates it into an
  interface-neutral form that can be used by the
  entity objects and control objects. Boundary
  objects model the user interface at a coarse
  level.
• Heuristics for identifying them
• Identify forms and windows that users need to
  enter data into the system
• Identify notices and messages that system uses to
  respond to user

22
E.g. Boundary objects from the ReportEmergency
use case AcknowledgementNotice DispatcherStati
on EmergencyReportForm FieldOfficerStation I
ncidentForm
23
Control Objects

• Coordinate boundary and entity objects
• Usually do not reflect a real-world entity
• Heuristics for identifying them
• Identify at least one control object for each use
  case (more if complex)
• Identify one control object per actor in the use
  case
• Life span is extent of a use case or user session
• If hard to define, then reevaluate entry and exit
  conditions for use case

24
It is generally recommended that there should be
a control class for each use case. In a sense,
the control class represents those parts that are
not specific to the behaviour of a particular
entity, but are specific to the use case (e.g.
the scheduling of certain actions). In general
terms, the interaction between the boundary
(interface) class and the entity (business) class
is controlled by the control class. This also
means that no entity class needs to know anything
about any other entity class unless this directly
relevant to its responsibilities. All
messages are routed via the control class.
25
Control classes unite objects to provide some
behaviour. Instances of the control class are
often temporary and usually only last during the
execution of the activity. They are best
identified via sequence diagrams. A typical
example would be a sequence of operations that
generates the result of some computation. E.g.
generating a report of some kind. Entity classes
could supply the information for various parts of
the report to a control class, Report_Generator,
which actually generates the report. If the
contents of the report change in any way in the
future, then only the implementation of
Report_Generator will be affected.
26
E.g. Control objects from the ReportEmergency use
case ReportEmergencyControl ManageEmergencyCon
trol One control object for FieldOfficer and one
for Dispatcher.
27
Example - Digital watch
Entity Objects Control Object Boundary Object
28
Naming of Object Types in UML

• UML provides several mechanisms to extend the
  language
• UML provides a 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
29
Summary - Class Diagram Stereotypes

• Analysis class stereotypes distinguish the roles
  objects can play
• Boundary objects model interaction between the
  system and actors (and other systems)
• Entity objects represent information and
  behaviour in the application domain
• Control objects co-ordinate and control other
  objects

30
Notations for stereotype classes
31
Heuristics for Identifying Initial Analysis
Object Classes

• For each use case, do the following
• Find terms that developers or users need to
  clarify in order to understand the flow of
  events.
• Find recurring nouns in the use cases (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
• Do textual analysis to find additional objects
  (Use Abotts technique - see later!)
• Model the flow of events with a sequence diagram
  to check for
• further objects
• This is just the first step!

32
Example use case
Use case name ReportEmergency Entry condition 1.
The FieldOfficer activates the Report Emergency
function of terminal. Flow of events 2. System
responds by presenting a form to the
officer... 3. The FieldOfficer fills the form
... 4. The Dispatcher reviews the information
submitted by the FieldOfficer ... Exit
condition 5. The FieldOfficer receives the
acknowledgment and the selected response.
33
Use Case Example - ReportEmergency Flow of
Events 1. The FieldOfficer activates the Report
Emergency function of terminal. System responds
by presenting a form to the officer. 2. The
FieldOfficer fills the form, by selecting the
emergency level, type, location, and brief
description of the situation. The FieldOfficer
also describes possible responses to the
emergency situation. Once the form is completed,
the FieldOfficer submits the form, at which
point, the Dispatcher is notified. 3. The
Dispatcher reviews the submitted information and
creates an Incident in the database by invoking
the OpenIncident use case. The Dispatcher selects
a response and acknowledges the emergency
report. 4. The FieldOfficer receives the
acknowledgment and the selected response. Look
for common nouns in Flow of Events of Use Case.
34
Identified initial objects for ReportEmergency
use case Dispatcher EmergencyReport FieldOf
ficer Incident But this is not a complete
description! Refine!!
35
UML Class Notation
Class name compartment
Attributes compartment
Operations compartment
36
UML Instance Notation
Object name compartment
FoodCoClient
companyAddressEvans Farm
companyEmailmail_at_foodco.com
Attribute values
companyFax01589-008636
companyNameFoodCo
companyTelephone01589-008638
Instances do not have operations
37
A basic Class diagram - developed during further
analysis
38
Class Diagram Attributes

• Attributes are
• Part of the essential description of a class
• The common structure of what the class can know
• Each object has its own value for each attribute
  in its class
• Aka data structures

39
Class Diagram Associations

• Associations represent
• The possibility of a logical relationship or
  connection between objects of one class and
  objects of another.
• If two objects can be linked, their classes have
  an association

40
Class Diagram Associations
Association
Association role
Client
StaffMember
companyAddress
staffContact
staffName
companyEmail
liaises with
staffNo
companyFax
staffStartDate
companyName
companyTelephone
Association name
Direction in which name should be read
41
Class Diagram Links
Yellow PartridgeClient
A link is a logical connection between two objects
FoodCoClient
Ivo IvanovStaffMember
Petar StratevStaffMember
Soong Motor CoClient
42
Class Diagram Multiplicity

• Associations have multiplicity.
• Multiplicity is the range of permitted
  cardinalities of an association.
• Represent enterprise (or business) rules
• For example
• Any bank customer may have one or more accounts
• Every account is for one, and only one, customer

43
Class Diagram Multiplicity
Multiplicities
Client
StaffMember
companyAddress
1
0..
companyEmail
staffName
companyFax
staffNo
liaises with
companyName
staffStartDate
companyTelephone

• Exactly one staff member liaises with each
  client
• A staff member may liaise with zero, one or more
  clients

44
Class Diagram Operations

• Operations are
• An essential part of the description of a class
• The common behaviour shared by all objects of the
  class
• Services that objects of a class can provide to
  other objects
• Aka as methods, functions,

45
Class Diagram Operations

• Operations describe what instances of a class can
  do
• Set or reveal attribute values
• Perform calculations
• Send messages to other objects
• Create or destroy links

46
From Requirements to Classes
3
1
2
4
47
From Requirements to Classes

• Start with one use case
• 2. Identify the likely classes involved (the use
  case collaboration)
• 3. Draw a collaboration diagram that fulfils the
  needs of the use case
• 4. Translate this collaboration diagram into a
  class diagram
• Repeat for other use cases

48
1. Start with one use case
49
Add a new advert to a campaign
Client
Campaign
2. Identify the likely classes involved (the use
case collaboration)
50
5 createNewAdvert()
5.1 addNewAdvert()
4 selectCampaign()
4.1 showCampaignAdverts()

4.1.2 getAdvertDetails()
3 selectClient()
3.1 showClientCampaigns()
Advert
AddAdvertUI
AddAdvert
5.1.1 addNewAdvert()
2 startInterface()
Campaign Manager
4.1.1 listAdverts()
3.1.2 getCampaignDetails()
1getClient()
3.1.1 listCampaigns()
5.1.1.1 createAdvert()
Client
Campaign
newAdAdvert

3. Draw a collaboration diagram that fulfils the
needs of the use case. (Do not worry about making
full sense of the diagram for the moment. The
important thing to notice is that it shows some
of the structure that exists between the objects
that take part in the collaboration.)
51
1
0..
1
0..
conducted by
places
4. Translate this collaboration diagram into a
class diagram
52
Reasonability Checks for Candidate Classes

• A number of tests help to check whether a
  candidate class is reasonable
• Is it beyond the scope of the system?
• Does it refer to the system as a whole?
• Does it duplicate another class?
• Is it too vague?

• Is it too tied up with physical inputs and
  outputs?
• Is it really an attribute?
• Is it really an operation?
• Is it really an association?
• If any answer is Yes, consider modelling the
  potential class in some other way (or do not
  model it at all!)

53
Class identification Finding objects is the
central activity in object modeling Approaches
Application domain approach 1. Ask
application domain expert to identify relevant
abstractions ( objects) 2. Learn about
problem domain Observe your client. 3.
Apply general world knowledge and intuition
54
Syntactic approaches 1. Extract
participating objects from flow of events in
use cases - Try to establish a
taxonomy. 2. Use noun-verb analysis on problem
statement, scenario or flow of events, etc.
(Abbots technique) to identify components of
the object model - Nouns are good
candidates for classes - Verbs are good
candidates for operations 3. From Dynamic
model Events Candidates for operations to be
offered by classes Sequence diagrams as
sources for more objects
55
Finding Entity Objects in Use Cases Use
following in conjunction with Abbots method For
each use case, 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. EmergencyOperationsPlan) -
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 (vocabulary, terminology)
56
Textual Analysis using Abbots technique Mapping
parts of speech to object model components Abbot
1983 Need to know and recognize parts of speech
(!!) - noun - verb - adjective
57
Example Part of Speech Model Component Examples
Proper noun Object Elena Common
noun Class FieldOfficer Doing verb
Operation Creates, submits,
selects Being verb Inheritance Is
a kind of, is one of either Having verb
Aggregation Has, consists of,
includes Modal verb Constraints Must
be Adjective Attribute Brief
(description)
58
Guidelines for Classes

• Each object class should
• provide a crisp abstraction of something drawn
  from the vocabulary of the problem domain or
  solution domain.
• embody a small, well-defined set of
  responsibilities and carry them out well.
• provide a clear separation of the abstractions
  specification and implementation.
• be understandable and simple, yet extensible and
  adaptable.

59
Rejecting Classes

• Analysis will come up with many possible classes,
  some of which we will not need.
• Competing priorities
• Simplest set of classes to satisfy current needs
• Set of classes which will easily accommodate
  future needs
• Need to apply criteria to possible classes
• Need to reject redundant classes

60
Rejection criteria

• Redundant classes
• E.g. User and Customer of an ATM
• retain the more descriptive name
• Irrelevant classes
• context dependent
• E.g. Customer complaint is outside the scope of
  the ATM system
• Vague classes
• A class should be specific
• E.g ATM Failure is not clearly defined
• Attributes
• E.g. name, age, weight, address are not
  usually classes

61

• Functions
• a behaviour of a class rather than a class in
  itself
• E.g. in a car system, acceleration is a function
  (method), not a class
• Implementation constructs
• classes which are extraneous to the real world
• E.g. CPU, subroutine, array, linked list etc.

62
Class Diagrams

• Describe the structure of the system
• Help to define system boundaries
• Model the application domain
• Classes and their relationships
• Association
• Generalization
• Aggregation
• Composition
• Describe classes with attributes and operations
• Later models will refine operations into methods

63
Class Diagram Example
64
Identifying Classes from Use Cases - Pick out
nouns
E.g.
Use Case - Verify ATM Customer Actor Action 1.
Customer inserts Card into ATM 3. Customer enter
PIN and presses OK Alternatives 1. Card
invalid 2. Incorrect PIN
System Response 2. ATM requests PIN from Customer
4. ATM verifies with Bank that Card and PIN are
legal 5. ATM requests transaction type
65
Example Using Flow of Events Ivan Ivanov enters
a store with the intention of buying a toy for
his 8-years old child. 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 yellow doll.
66
Mapping parts of speech to object model
components Part of speech Model component
Example Proper noun object Ivan
Ivanov Improper noun class toy, doll,
customer 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, yellow transitive
verb method enter intransitive verb method
(event) depends on
67
Example - Generation of a class diagram from flow
of events
- The customer enters the shop 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 8 years old. - The assistant
recommends another type of toy, namely a
board-game. - The customer buys the game and
leaves the shop.
price
like()
buy()
68
Identifying Associations An association shows
the relationship between the two or more
classes. E.g. FieldOfficer writes
EmergencyReport
69
Heuristics for Identifying Associations Examine
verbs and verb phrases denoting a state e.g. has,
is part of, manages, reports to, is triggered by,
is contained in, talks to, includes, etc. Every
association must be named, and roles assigned to
each end. Watch out for redundancy -
associations that may be derived from other
associations. Avoid spaghetti models - too
many associations make a model unreadable.
70
Questions to ask - Is the class capable of
fulfilling the task by itself? - If not, what
does it need? - From what other class can it
acquire what it needs?
71
Eliminating redundant association. The receipt of
an EmergencyReport triggers the creation of an
Incident by a Dispatcher. Given that the
EmergencyReport has an association with the
FieldOfficer that wrote it, it is not necessary
to keep an association between FieldOfficer and
Incident Identify as many associations as
possible before identifying attributes - to avoid
confusing attributes and objects
72
Identifying Attributes Attributes are properties
of individual objects - represent stored state as
attributes of entity object. Attributes have a
name and a (data) type.
Attributes of the EmergencyReport class.
73
Heuristics for Identifying Attributes Examine
noun phrases followed by possessive phrases (E.g.
the description of an emergency) and adjective
phrases (E.g. the emergency description)
74
Summary of activities in modeling 1. Formulate
scenarios with help from the end user and/or
application domain expert. 2. Extract the use
cases from the scenarios, with the help of
application domain expert. 3. Analyze the flow
of events, for example with Abbot's textual
analysis. 4. Generate the class diagrams, which
includes the following steps 1. Class
identification (textual analysis, domain
experts). 2. Identification of attributes and
operations (sometimes before the classes are
found!) 3. Identification of associations
between classes 4. Identification of
multiplicities 5. Identification of roles 6.
Identification of constraints
75
Object Modeling in Practice Class Identification
E.g. a banking system
Class Identification Name of Class, Attributes
and Methods
76
Encourage brainstorming!
Naming is important! Is Bar or Foo the right
name? No! Account is much better
77
1. Find New Objects
2. Iterate on Names, Attributes and Methods 3.
Introduce new classes
78

Has
1. Find New Objects
2. Iterate on Names, Attributes and Methods
3. Find Associations between Objects
4. Label the associations
5. Determine the multiplicity of the associations
79
6. Categorize! look for taxonomies, hierarchies
Bank


Name
Has
CustomerId
Savings Account
Checking Account
Mortgage Account
Withdraw()
Withdraw()
Withdraw()
80
Put taxonomies in a separate diagram
Savings Account
Checking Account
Mortgage Account
Withdraw()
Withdraw()
Withdraw()
81
Heuristic Do not put too many classes into the
same package 72 (or even 52)
82
CRC Cards

• ClassResponsibilityCollaboration cards help to
  model interactions between objects
• For a given scenario (or use case)
• Brainstorm the objects
• Allocate to team members
• Role play the interaction

83
CRC Cards
Class Name
Collaborations (aka Interactions)
Responsibilities (aka Tasks)
Collaborations with other classes are listed
here, together with a brief description of the
purpose of the collaboration.
Responsibilities of a class are listed in this
section.
84
Example
Class Name
Client
Responsibilities
Collaborations
Provide client information.
Campaign provides campaign details.
Provide list of campaigns.
Class Name
Campaign
Responsibilities
Collaborations
Provide campaign information.
Advert provides advert details.
Provide list of adverts.
Add a new advert.
Advert constructs new object.
Class Name
Advert
Responsibilities
Collaborations
Provide advert details.
Construct adverts.
85
CRC Cards

• Effective role play depends on an explicit
  strategy for distributing responsibility among
  classes
• For example
• Each role player tries to be lazy.
• Persuades other players their class should accept
  responsibility for a given task.
• May use Post-its to document the associations
  and links on a large whiteboard during a CRC
  session.

86
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
• Statecharts
• A state machine that describes the response of an
  object of a given class to the receipt of outside
  stimuli (Events).
• Activity Diagram
• Special type of statechart where all states are
  action states

87
Dynamic Modeling

• Definition of dynamic model
• A collection of multiple sequence and statechart
  diagrams, one sequence and statechart 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
• ? sequence diagram
• Model dynamic behavior of single objects
• ? statechart diagram

88
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 notation
• Relation to object identification
• Objects/classes have already been identified
  during object modeling
• Further objects may be identified as a result of
  dynamic modeling
• Heuristic
• An event always has a sender and a receiver. Find
  them for each event
• ? These are the objects participating in the use
  case

89
Sequence Diagrams

• Vertical dimension shows time.
• Objects involved in interaction appear
  horizontally across the page and represented by
  lifelines.
• Messages are shown by a solid horizontal arrow.
• The execution of an operation is shown by an
  activation

90
Sequence diagram
91
Object Destruction
Explicit use of destroy() is not mandatory
92
What is an Event?

• Something that happens at some 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 New Change Proposal
  (CP) issued on Thursday September 14 at 930 am.
  
• Event class New CP, Subclass Figure Change
• Attribute of an event class
• CP Update (930 am, 14/9/03)
• Car starts at ( 445 pm, AUBG garage)
• Mouse button down (button, x-y coordinates)

93
Example - Start with Flow of Events from Use Case
Use case name ReportEmergency Entry
condition 1. The FieldOfficer activates the
Report Emergency function of terminal. Flow
of events 2. System responds by presenting a form
to the officer ... 3. The FieldOfficer fills the
form ... 4. The Dispatcher reviews the
information submitted by the FieldOfficer
... Exit condition 5. The FieldOfficer receives
the acknowledgment and the selected response.
94
An Example
Sequence diagram for the ReportEmergency use case
(initiation from the FieldOfficerStation side)
BO CO
BO EO CO
95
Explanation of Sequence Diagrams

• Layout
• 1st column corresponds to the actor who
  initiated the use case
• 2nd column boundary object (that the actor used
  to initiate the use case)
• 3rd column control object that manages the rest
  of the use case
• Creation
• Control object created by boundary object
  initiating a use case
• Further boundary objects created by control
  object
• 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.

96
Sequence diagram for the ReportEmergency use case
(DispatcherStation) continuation of last diagram
Manage
IncidentForm
Incident
Acknowledgment
Dispatcher
EmergencyControl
Boundary
submitReportToDispatcher()
create()
view()
createIncident()
create()
submit()
create()
97
Sequence diagram for the ReportEmergency use case
(acknowledgment on the FieldOfficerStation).
98
What 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.

99
Fork Diagram

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

100
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 help with a specific
  behavior.

101
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!
• Decentralized control structure (Stair)
• The operations have a strong connection
• The operations will always be performed in the
  same order
• Centralized control structure (Fork)
• The operations can change order
• New operations can be inserted as a result of new
  requirements

102
Statechart Diagrams

• Graph whose nodes are states and whose directed
  arcs are transitions labeled by event names.
• Distinguish between two types of operations
• 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

103
State

• An abstraction of the attribute 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 not need to be
  distinguished as far as the control structure of
  the system is concerned
• - Example State of a bank
• gtgt A bank is either solvent or insolvent
• State has a duration (in time)

104
UML Statechart Diagram Notation
Event trigger with parameters
State1
Event1(attr) condition/action
State2
do/activity
entry/action
exit/action
Guard condition
Also internal transition and deferred events
105
Example of a StateChart Diagram
coins_in(amount) / set balance
doCollect Money
Idle
coins_in(amount) / add to balance
cancel / refund coins
item empty
select(item)
changelt0
do test item and compute change
change0
changegt0
do dispense item
do make change
106
Analysis Example

• 1. Analyze the problem statement
• Identify functional requirements
• Identify nonfunctional requirements
• Identify constraints (pseudo requirements)
• 2. Build the functional model
• Develop use cases to illustrate functionality
  requirements
• 3. Build the object model
• Develop class diagrams showing the structure of
  the system
• 4. Build the dynamic model
• Develop sequence diagrams to illustrate the
  interaction between objects
• Develop statechart diagrams for objects with
  interesting behaviour

107
Problem Statement Control for a Toy Car

• Power is turned on
• Car moves forward and car headlight shines
• Power is turned off
• Car stops and headlight goes out.
• Power is turned on
• Headlight shines
• Power is turned off
• Headlight goes out.
• Power is turned on
• Car runs backward with its headlight shining.

• Power is turned off
• Car stops and headlight goes out.
• Power is turned on
• Headlight shines
• Power is turned off
• Headlight goes out.
• Power is turned on
• Car runs forward with its headlight shining.

108
Find the Functional Model Do Use Case Modeling

• Use case 1 Move car forward
• Entry condition Car is stationary, headlights
  are off
• Flow of events
• Driver turns power on
• Exit condition
• Car runs forward with its headlight shining.
• Use case 2 Stop forward moving car
• Entry condition Car moves forward, headlights
  on
• Flow of events
• Driver turns power off, car stops, headlights go
  out.
• Exit condition Car stationary, headlights are
  out.

109

• Use case 3 Move car backward
• Entry condition Car is stationary, headlights
  off
• Flow of events
• Driver turns power on
• Exit condition Car moves backward, headlights on
• Use case 4 Stop backward moving car
• Entry condition Car moves backward, headlights
  on
• Flow of events
• Driver turns power off, car stops, headlights go
  out.
• Exit condition Car stationary, headlights are
  out.

110
Toy Car Object Model
Car
Headlight
Power
Status (On, Off)
Status (On, Off)
Switch_On()
TurnOn()
Switch_Off()
TurnOff()
111
Find the Dynamic Model Create sequence diagram

• Name Drive Car
• Sequence of events
• Driver turns power on
• Headlight goes on
• Wheels starts moving forward
• Wheels keeps moving forward
• Driver turns power off
• Headlight goes off
• Wheels stops moving
• . . .

112
(Partial) Sequence Diagram for Drive Car Scenario
Wheel
Headlight
Driver
Power(on)
Power(on)
Power(off)
Power(off)
113
Toy Car Dynamic Model
Wheel
Forward
power

power

off
on
Stationary
Stationary
power

power

on
off
Backward
114
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
115
When is a model dominant?

• Object model The system has non-trivial data
  structures.
• Dynamic model The model has many different types
  of events input, output, exceptions, errors,
  etc.
• Functional model The model performs complicated
  transformations such as difficult computations
  consisting of many steps.
• Examples
• Compiler Functional model most important.
  Dynamic model is trivial because there is only
  one type input and only a few outputs.
• Database systems Object model most important.
  Functional model is trivial, because its purpose
  is usually only to store, organize and retrieve
  data.
• Spreadsheet program Functional model most
  important. Object model is trivial, because the
  spreadsheet values are trivial and cannot be
  structured further. The only interesting object
  is the cell.

116
Collaborative Analysis

• A system is a collection of subsystems providing
  services
• Analysis of services may be 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

117
Requirements Analysis Document Template
1. Introduction 2. Current system 3. Proposed
system 3.1 Overview 3.2 Functional
requirements 3.3 Nonfunctional
requirements 3.4 Constraints (Pseudo
requirements) 3.5 System models 3.5.1
Scenarios 3.5.2 Use case model 3.5.3 Object
model 3.5.3.1 Data dictionary 3.5.3.2
Class diagrams 3.5.4 Dynamic models 3.5.5
User interface 4. Glossary
118
Section 3.5 System Models
3.5.1 Scenarios - As-is scenarios, visionary
scenarios 3.5.2 Use case model - Actors and use
cases 3.5.3 Object model - Data dictionary -
Class diagrams (classes, associations, attributes
and operations) 3.5.4 Dynamic model - State
diagrams for classes with significant dynamic
behavior - Sequence diagrams for collaborating
objects (protocol) 3.5.5 User Interface -
Navigational Paths, Screen mockups
119
Section 3.3 Nonfunctional Requirements
3.3.1 User interface and human factors 3.3.2
Documentation 3.3.3 Hardware considerations
3.3.4 Performance characteristics 3.3.5 Error
handling and extreme conditions 3.3.6 System
interfacing 3.3.7 Quality issues 3.3.8 System
modifications 3.3.9 Physical environment 3.3.10
Security issues 3.3.11 Resources and management
issues
120
Nonfunctional Requirements Trigger Questions

• 3.3.1 User interface and human factors
• What type of user will be using the system?
• Will more than one type of user be using the
  system?
• What sort of training will be required for each
  type of user?
• Is it particularly important that the system be
  easy to learn?
• Is it particularly important that users be
  protected from making errors?
• What sort of input/output devices for the human
  interface are available, and what are their
  characteristics?
• 3.3.2 Documentation (e.g. User Manuals)
• What kind of documentation is required?
• What audience is to be addressed by each
  document?
• 3.3.3 Hardware considerations
• What hardware is the proposed system to be used
  on?
• What are the characteristics of the target
  hardware, including memory size and auxiliary
  storage space?

121

• 3.3.4 Performance characteristics
• Are there any speed, throughput, or response time
  constraints on the system?
• Are there size or capacity constraints on the
  data to be processed by the system?
• 3.3.5 Error handling and extreme conditions
• How should the system respond to input errors?
• How should the system respond to extreme
  conditions?
• 3.3.6 System interfacing
• Is input coming from systems outside the proposed
  system?
• Is output going to systems outside the proposed
  system?
• Are there restrictions on the format or medium
  that must be used for input or output?

122

• 3.3.7 Quality issues
• What are the requirements for reliability?
• Must the system trap faults?
• Is there a maximum acceptable time for restarting
  the system after a failure?
• What is the acceptable system downtime per
  24-hour period?
• Is it important that the system be portable (able
  to move to different hardware or operating system
  environments)?
• 3.3.8 System Modifications
• What parts of the system are likely candidates
  for later modification?
• What sorts of modifications are expected?
• 3.3.9 Physical Environment
• Where will the target equipment operate?
• Will the target equipment be in one or several
  locations?
• Will the environmental conditions in any way be
  out of the ordinary (for example, unusual
  temperatures, vibrations, magnetic fields, ...)?

123

• 3.3.10 Security Issues
• Must access to any data or the system itself be
  controlled?
• Is physical security an issue?
• 3.3.11 Resources and Management Issues
• How often will the system be backed up?
• Who will be responsible for the back up?
• Who is responsible for system installation?
• Who will be responsible for system maintenance?

124
3.4 Pseudo Requirements (Constraints)

• Pseudo requirement
• Any client restriction on the solution domain
• Examples
• The target platform must be a Pentium 4
• The implementation language must be Java
• The documentation standard X must be used
• A data glove must be used for input
• ActiveX must be used
• The system must interface to a printer

125
Project Agreement

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

126
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

127
Project Management Heuristics

• Explicitly schedule meetings for object
  identification
• First just find objects
• Then try to differentiate them between entity,
  interface (boundary) 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,

128
Summary Requirements Analysis

• What are the transformations?
• Create scenarios and use case diagrams
• Talk to client, observe, get historical records,
  do thought experiments (be proactive)
• 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?
• What is its control structure?
• Create sequence diagrams
• Identify senders and receivers
• Show sequence of events exchanged between
  objects. Identify event dependencies and event
  concurrency.
• Create statechart diagrams
• Only for the dynamically interesting objects.

Functional Modeling
Object Modeling
Dynamic Modeling
129
Two further case studies http//www.cs.gordon.ed
u/courses/cs211/ AddressBookExample/index.html ht
tp//www.math-cs.gordon.edu/courses/cs211/ ATMExam
ple/index.html
130
Questions?
131
Reading Bruegge and Dutoit Chapter 5
Analysis Pressman Chapter 21 -
Object-Oriented Analysis