Transcript Lecture 1 for Chapter 5, Analysis - ICAR-CNR

Conquering Complex and Changing Systems
Object-Oriented Software Engineering
Chapter 5, Analysis:
Object Modeling
Outline








From use cases to objects
Object modeling
Class vs instance diagrams
Attributes
Operations and methods
Links and associations
Examples of associations
Two special associations
 Aggregation
 Inheritance
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
2
Products of requirements elicitation and analysis
Requirements
Elicitation
system
specification
:Model
Analysis
analysis model
:Model
Next chapter
System
Design
system model
:Model
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
Next chapter
3
The analysis model
use case
diagram:View
class
diagram:View
functional
model:Model
object
model:Model
statechart
diagram:View
sequence
diagram:View
dynamic
model:Model
analysis
model:Model
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
4
From Use Cases to Objects
Level 1 Use Case
Level 1
Level 2
Level 3
A
Level 3
Level 3
Level 4
Level 2 Use Cases
Level 2
Level 3 Use Cases
Operations
Level 4
B
Participating
Objects
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
5
From Use Cases to Objects: Why Functional
Decomposition is not Enough
Scenarios
Level 1
Level 2
Level 3
A
Level 3
Level 3
Level 4
Level 1 Use Cases
Level 2
Level 2 Use Cases
Operations
Level 4
B
Participating
Objects
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
6
From Use Cases to Objects
Starting from use cases and scenarios, analysis activities
performed to obtain the analysis model are:
 Identifying entity objects
 Identifying boundary objects
 Identifying control objects
 Mapping use cases to objects
 Identifying associations among objects
 Identifying object attributes
 Modeling behavior with statecharts
 Modeling generalization relationships
 Reviewing the analysis model
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
7
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
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
8
Class identification




Class identification is crucial to object-oriented modeling
Objects are not just found by taking a picture of a scene or
domain
The application domain has to be analyzed.
Identify the boundaries of the system
 What object is inside, what object is outside?

Identify the important entities in the system
 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
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
9
Pieces of an Object Model


Classes
Associations (Relations)
 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
Methods
 Detection of methods
 Generic methods: General world knowledge, design patterns
 Domain Methods: Dynamic model, Functional model
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
10
UML: Class and Instance Diagrams
Inspector
joe:
Inspector
mary:
Inspector
Class Diagram
anonymous:
Inspector
Instance Diagram
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
11
Attributes and Values
Inspector
name:string
age: integer
joe:Inspector
name = “Joe”
age = 24
Bernd Bruegge & Allen Dutoit
mary: Inspector
name = “Mary”
age = 18
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
12
Links and Associations


Links and associations establish relationships among objects
and classes.
Link:
 A connection between two object instances. A link is like a tuple.
 A link is an instance of an association

Association:
 Basically a bidirectional mapping.
 One-to-one, many-to-one, one-to-many,
 An association describes a set of links like a class describes a set of
objects.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
13
1-to-1 and 1-to-many Associations
Hascapital
Country
name:String
City
name:String
One-to-one association
Workorder
StickyNote
*
schedule()
x: Integer
y: Integer
z: Integer
One-to-many association
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
14
Object Instance Diagram
Example for 1-to-many
:Sticky
:WorkOrder
x,y,z=(-1,0,5)
:Sticky
x,y,z=(1,10,1)
:Sticky
x,y,z=(10,1,2)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
15
Many-to-Many Associations
Mechanics
Bernd Bruegge & Allen Dutoit
*
Work on
*
Plane
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
16
Do UML associations have direction?
A association between two classes is by default a bi-directional
mapping.
B
A


Class A can access class B and class B can access class A
Both classes play the agent role.
If you want to to make A a client, and B a server, you can make the
Direction
Name of association
association unidirectional.
The arrowheadName
points
to the server role:
Association Direction
accesses
A
B
Class A ( the “client”) accesses class B (“the server”). B is also called navigable
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
17
Aggregation



Models "part of" hierarchy
Useful for modeling the breakdown of a product into its
component parts (sometimes called bills of materials (BOM) by
manufacturers)
UML notation: Like an association but with a small diamond
indicating the assembly end of the relationship.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
18
Aggregation
Automobile
Engine
serial number
year
manufacturer
model
color
weight
horsepower
volume
on
off
drive
purchase
3,4,5
Wheel
diameter
number of bolts
Bernd Bruegge & Allen Dutoit
*
Brakelight
on
off
2,4
Door
open
close
Battery
amps
volts
charge
discharge
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
19
Inheritance



Models "kind of" hierarchy
Powerful notation for sharing similarities among classes while
preserving their differences
UML Notation: An arrow with a triangle
Cell
BloodCell
Red
Bernd Bruegge & Allen Dutoit
White
MuscleCell
Smooth
Striate
NerveCell
Cortical
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
Pyramidal
20
Aggregation vs Inheritance

Both associations describe trees (hierarchies)
 Aggregation tree describes a-part-of relationships (also
called and-relationship)
 Inheritance tree describes "kind-of" relationships (also
called or-relationship)

Aggregation relates instances (involves two or more
different objects)

Inheritance relates classes (a way to structure the
description of a single object)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
21
Other Associations

Uses:
 A subsystem uses another subsystem (System Design)

Contains:
 Sometimes called “spatial aggregation”
 ... contains ...
 Example: A UML package contains another UML package

Parent/child relationship:
 ... is father of ...
 ... is mother of ...

Seniority:
 ... is older than ...
 ... is more experienced than ...
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
22
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 boundary of a system changes more likely than the control
 The control of the system change more likely than the application
domain

Object types originated in Smalltalk:
 Model, View, Controller (MV)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
23
Example: 2BWatch Objects


UML provides several mechanisms to extend the language
UML provides the stereotype mechanism to present new
modeling elements
<<entity>>
Year
<<entity>>
Month
<<control>>
ChangeDateControl
<<boundary>>
ButtonBoundary
<<boundary>>
LCDDisplayBoundary
<<entity>>
Day
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
24
Roles



A role name is the name that uniquely identifies one end of an
association.
A role name is written next to the association line near the class
that plays the role.
When do you use role names?
 Necessary for associations between two objects of the same class
 Also useful to distinguish between two associations between the
same pair of classes

When do you not use role names?
 If there is only a single association between a pair of distinct classes,
the names of the classes serve as good role names
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
25
Example of Role
Problem Statement : A person assumes the role of repairer
with respect to another person, who assumes the role of
inspector with respect to the first person.
Person
Person
Creates Workorders
Person
Bernd Bruegge & Allen Dutoit
*
*
inspector
Creates Workorders
repairperson
Person
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
26
Roles in Associations

Client Role:
 An object that can operate upon other objects but that is never
operated upon by other objects.

Server Role:
 An object that never operates upon other objects. It is only
operated upon by other objects.

Agent Role:
 An object that can both operate upon other objects and be operated
upon by other objects. An agent is usually created to do some work
on behalf of an actor or another agent.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
27
How do you find classes?

Learn about problem domain: Observe your client
Apply general world knowledge and intuition
Do a textual analysis of scenario or flow of events (Abbott
Textual Analysis, 1983)
Take the flow of events and find participating objects in use cases
Apply design patterns
Try to establish a taxonomy

Nouns are good candidates for classes





Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
31
Mapping parts of speech to object model components
[Abbot 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
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
32
Example: Scenario from Problem Statement





Jim Smith enters a store with the intention of buying a toy for
his 3 year 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.
Jim selects a dangerous toy which is unsuitable for the child.
The store owner recommends a more yellow doll.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
33
Object Modeling in Practice: Class Identification
Foo
Balance
CustomerId
Deposit()
Withdraw()
GetBalance()
Class Identification: Name of Class, Attributes and Methods
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
34
Object Modeling in Practice:
Encourage Brainstorming
“Dada”
Foo
Balance
Balance
CustomerId
CustomerId
Deposit()
Withdraw()
GetBalance()
Deposit()
Withdraw()
GetBalance()
Account
Balance
CustomerId
Naming is important!
Bernd Bruegge & Allen Dutoit
Deposit()
Withdraw()
GetBalance()
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
35
Object Modeling in Practice: A Banking System
Account
Bank
Name
Balance
AccountId
Customer
*
Has
Deposit()
Withdraw()
GetBalance()
Name
CustomerId
Find New Objects
Iterate on Names, Attributes and Methods
Find Associations between Objects
Label the associations
Determine the multiplicity of the associations
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
36
Object Modeling in Practice: Categorize!
Account
Bank
*
Name
Balance
AccountId
Customer
*
Has
Deposit()
Withdraw()
GetBalance()
Name
CustomerId
Savings
Account
Checking
Account
Mortgage
Account
Withdraw()
Withdraw()
Withdraw()
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
37
Avoid Ravioli Models
Account
Bank
Name
*
Balance
AccountID
Customer
*
Has
Deposit()
Withdraw()
GetBalance()
Name
CustomerId
Don’t put too many classes into the same package:
7+-2 (or even 5+-2)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
38
How to identify entity objects







terms that developers or users need to clarify in order to
understand the use case
recurring nouns in the use cases (e.g., Incident)
real-world entities that the system needs to keep track of (e.g.,
FieldOfficer, Dispatcher, Resource)
real-world activities that the system needs to keep track of (e.g.,
Emergencyoperationsplan)
use cases (e.g., ReportEmergency)
data sources or sinks (e.g., Printer)
always use the user’s terms
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
39
How to identify boundary objects




Identify forms and windows the users needs to enter data into the
system (e.g., EmergencyReportForm, ReportEmergencyButton).
Identify notices and messages the system uses to respond to the
user (e.g., AcknowledgmentNotice).
Do not model the visual aspects of the interface with boundary
objects (user mock-ups are better suited for that).
Always use the user’s terms for describing interfaces as opposed
to terms from the implementation technology.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
40
How to identify control objects

Identify one control object per use case or more if the use case
is complex and if it can be divided into shorter flows of events.

Identify one control object per actor in the use case.

The life span of a control object should be extent of the use
case or the extent of a user session. If it is difficult to identify
the beginning and the end of a control object activation, the
corresponding use case may not have a well-defined entry and
exit condition.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
41
An example: the ReportEmergency use case
Use case name:
ReportEmergency
Entry condition:
The FieldOfficer activates the “Report Emergency” function of
her terminal.
Flow of events:
1. FRIEND responds by presenting a form to the officer. The form includes an emergency
type menu (Genera1 emergency, fire, transportation), a location, incident description,
resource request, and hazardous material fields.
2. The FieldOfficer fills the form, by specifying minimally the emergency type and
description fields. The FieldOfficer may also describes possible responses to the
emergency situation and request specific resources. Once the form is completed, the
FieldOfficer submits the form by pressing the “Send Report” button, at which point, the
Dispatcher is notified.
3. The Dispatcher reviews the information submitted by the FieldOf f icer and creates an
incident in the database by invoking the OpenIncident use case. Al1 the information
contained in the FieldOfficer’s form is automatically included in the incident. The
Dispatcher selects a response by allocating resources to the incident (with the
AllocateResources use case) and acknowledges the emergency report by sending a
FRIENDgram to the FieldOfficer.
Exit condition:
Bernd Bruegge & Allen Dutoit
The FieldOfficer receives the acknowledgment and the selected
response.
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
42
Entity objects in the example
Dispatcher
Police officer who manages Incidents. A Dispatcher opens, documents,
and closes Incidents in response to Emergency Reports and other
communication with FieldOfficers. Dispatchers are identified by badge
numbers.
EmergencyReport
Initial report about an Incident from a FieldOfficer to a Dispatcher. An
EmergencyReport usually triggers the creation of an Incident by the
Dispatcher. An EmergencyReport is composed of a emergency level, a
type (fire, road accident, or other), a location, and a description.
Fieldofficer
Police or fire officer on duty. A FieldOfficer can be allocated to, at most,
one Incident at a time. FieldOfficers are identified by badge numbers.
NOT TRUE in this UC. Here FieldOfficers are actors, they can be entity
objects in the Allocateresource UC
Incident
Situation requiring attention from a FieldOfficer. An Incident may be
reported in the system by a FieldOfficer or anybody else external to the
system. An Incident is composed of a description, a response, a status
(open, closed, documented), a location, and a number of FieldOfficers.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
43
Boundary Objects in the example
AcknowledgmentNotice
Notice used for displaying the Dispatcher’s acknowledgment to the FieldOfficer.
DispatcherStation
Computer used by the Dispatcher.
ReportEmergencyButton
Button used by a FieldOfficer to initiate the ReportEmergency use case.
EmergencyReportForm
Form used for the input of the ReportEmergency. This form is presented to the
FieldOfficer on the FieldOfficerstation when the “Report Emergency” function is
selected. The EmergencyReportForm contains fields for specifying all attributes
of an emergency report and a button (or other control) for submitting the form
once it is completed.
FieldOfficerStation
Mobile computer used by the FieldOfficer.
Incident Form
Form used for the creation of Incidents. This form is presented to the Dispatcher
on the DispatcherStation when the EmergencyReport is received. The Dispatcher
also uses this form to allocate resources and to acknowledge the FieldOfficer’s
report.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
44
Control objects in the example
ReportEmergencyControl
Manages the report emergency reporting function on the
FieldOfficerstation. This object is created when the FieldOfficer
selects the “Report Emergency” button. It then creates an
EmergencyReportFom and presents it to the FieldOfficer. After
submission of the form, this object then collects the information from
the form, creates an EmergencyReport, and forwards it to the
Dispatcher. The control object then waits for an acknowledgment to
come back from the DispatcherStation. When the acknowledgment is
received, the ReportEmergencyControl object creates an
AcknowledgmentNotice and displays it to the Fie1dOfficer .
ManageEmergencyControl
Manages the report emergency reporting function on the
DispatcherStation. This object is created when an EmergencyReport is
received. It then creates an IncidentFom and displays it to the
Dispatcher. Once the Dispatcher has created an Incident, allocated
Resources, and submitted an acknowledgment,
ManageEmergencyControl forwards the acknowledgment to the
FieldOfficerstation.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
45
Summary
In this lecture, we reviewed the construction of the object model
from use case model. In particular, we described:
 Identification of objects (entity, boundary, control)
 Refinement of objects with attributes and operations
 Generalization of concrete classes
 Identification of associations
 Reduction of multiplicity using qualification.
In the next lecture, we describe the construction of the dynamic
model from the use case and object models.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
46