UNIT-2

Department of CSE
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1
 PART 1:Deeper View into UML: Static Modelling, Dynamic Modelling, Logical
Architecture.
Dynamic Modelling: Use Case Diagrams, Class Diagrams, Interaction
Diagrams, State Machine Diagrams, Activity Diagrams, Diagram Organization, Diagram
Extensions.
¨ PART 2 :Analysis Concepts: Object Models and Dynamic Models. Entity, Boundary, Control,
Objects. Generalization and Specialization

PART 3:Analysis Activities:

Requirements Model: From Use Cases to Objects
Identifying Entity Objects, Boundary Objects, Control Object.
Mapping Use Cases to Objects with Sequence Diagrams
Modelling Interactions among Objects with CRC Cards.
Identifying Associations, Aggregates, Attributes
Modelling State- Dependent Behavior of Individual Objects
Modelling Inheritance Relationships between Objects.
Reviewing the Analysis Model, Analysis Summary

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4
 Logical Architecture.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6
 Use case diagram
¨ Use Case Diagrams Use cases and actors.
¨ Actors are external entities that interact with the system.
¨ Examples of actors include a user role (e.g., a system administrator, a bank
customer, a bank teller) or another system (e.g., a central database, a
fabrication line).
¨ Actors have unique names and descriptions.
¨ Use cases describe the behavior of the system as seen from an actor’s point
of view. Behavior described by use cases is also called external behavior.
¨ A use case describes a function provided by the system as a set of events
that yields a visible result for the actors.
¨ Actors initiate a use case to access system functionality. The use case can
then initiate other use cases and gather more information from the actors.
When actors and use cases exchange information, they are said to
communicate.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7
 UML Use Case Diagrams

Used during requirements elicitation and analysis

to represent external behavior (“visible from the
outside of the system”)

An Actor represents a role, that is, a type of user of the system

Passenger
A use case represents a class of functionality
provided by the system

Use case model:

PurchaseTicket The set of all use cases that
completely describe the
functionality of the system.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8
 ¨ An actor is a model for an external
Actors entity which interacts
(communicates) with the system:
 User
 External system (Another system)
 Physical environment (e.g. Weather)
¨ An actor has a unique name and an
Passenger optional description
Optional
¨ Examples: Description

Name
 Passenger: A person in the train
 GPS satellite: An external system that
provides the system with GPS
coordinates.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9
 Use Case
• A use case represents a class of functionality
provided by the system
• Use cases can be described textually, with a focus
on the event flow between actor and system
• The textual use case description consists of 6 parts:
1. Unique name
PurchaseTicket
2. Participating actors
3. Entry conditions
4. Exit conditions
5. Flow of events
6. Special requirements.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10
 Textual Use Case
Description Example Passenger
PurchaseTicket

1. Name: Purchase ticket 5. Flow of events:

1. Passenger selects the number of
2. Participating actor: Passenger zones to be traveled
2. Ticket Distributor displays the
3. Entry condition: amount due
¨ Passenger stands in front of ticket 3. Passenger inserts money, at
distributor least the amount due
¨ Passenger has sufficient money to 4. Ticket Distributor returns change
purchase ticket 5. Ticket Distributor issues ticket
6. Special requirements: None.
4. Exit condition:
¨ Passenger has ticket

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11
 Uses Cases can be related
Extends Relationship
 An Extend is a relationship from an extending UseCase (the
extension) to an extended UseCase (the extendedCase) that specifies
how and when the behavior defined in the extending UseCase can be
inserted into the behavior defined in the extended UseCase. The
extension takes place at one or more specific extension points defined
in the extended UseCase.
Includes Relationship
 The Include relationship is intended to be used when there are common
parts of the behavior of two or more UseCases. This common part is
then extracted to a separate UseCase, to be included by all the base
UseCases having this part in common. As the primary use of the
Include relationship is for reuse of common parts, what is left in a base
UseCase is usually not complete in itself but dependent on the
included parts to be meaningful.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
 The <<extends>> Relationship
<<extends>>
¨
relationships model
exceptional or seldom
invoked cases
Passenger ¨ The exceptional event
flows are factored out
of the main event flow
PurchaseTicket for clarity
¨ The direction of an
<<extends>>
<<extends>>relation
<<extends>> ship is to the extended
<<extends>>
use case .
OutOfOrder <<extends>>
TimeOut
¨ Use cases representing
exceptional flows can
Cancel NoChange
extend more than one
use case.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14
 Examples

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15
 Example 1

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16
 Example 2

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17
 Use-case diagram A use case illustrates a unit of
functionality provided by the system. The main purpose of the
use-case diagram is to help development teams visualize the
functional requirements of a system, including the
relationship of "actors to processes, as well as the
relationships among different use cases.

Use-case diagrams generally show groups of use cases -- either

all use cases for the complete system, or a breakout of a
particular group of use cases with related functionality

To show a use case on a use-case diagram, you draw an oval in

the middle of the diagram and put the name of the use case in
the center of, or below, the oval
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19
 CLASS DIAGRAMS
¨ Class Diagrams describe the structure of the system
in terms of classes and objects.
¨ Classes are abstractions that specify the attributes and
behavior of a set of objects.
¨ A class is a collection of objects that share a set of
attributes that distinguish the objects as members of
the collection.
¨ Objects are entities that encapsulate state and
behavior. Each object has an identity: it can be
referred individually and is distinguishable from other
objects.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20
 Class Diagrams
¨ Class diagrams represent the structure of the
system
¨ Used
 During requirements analysis to model application
domain concepts
 During system design to model subsystems
 During object design to specify the detailed
behavior and attributes of classes.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21
 Abstract Class

¨ In the abstract class, no objects can be a direct entity of the

abstract class.
¨ The abstract class can neither be declared nor be instantiated.
It is used to find the functionalities across the classes.
¨ The notation of the abstract class is similar to that of class;
the only difference is that the name of the class is written in
italics.
¨ Since it does not involve any implementation for a given
function, it is best to use the abstract class with multiple
objects.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22
 ¨ An abstract is useful for identifying the functionalities across the
classes.

¨ Let us consider an example of an abstract class. Suppose we have an

abstract class called as a motion with a method or an operation
declared inside of it. The method declared inside the abstract class is
called a move ().

¨ This abstract class method can be used by any object such as a car, an
animal, robot, etc. for changing the current position. It is efficient to
use this abstract class method with an object because no
implementation is provided for the given function. We can use it in any
way for multiple objects.

¨ An abstract class cannot be initialized or instantiated.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23
 Classes
Type
TarifSchedule
Table zone2price
Name Enumeration
getZones()
TarifSchedule Price
zone2price Attributes getPrice(Zone)
Signature
getZones()
getPrice() Operations TarifSchedule

¨ A class represents a concept

¨ A class encapsulates state (attributes) and behavior (operations)
Each attribute has a type
Each operation has a signature

The class name is the only mandatory information

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24
 Actor vs Class vs Object
¨ Actor
 An entity outside the system to be modeled, interacting with the
system (“Passenger”)
¨ Class
 An abstraction modeling an entity in the application or solution
domain
 The class is part of the system model (“User”, “Ticket
Distributor”, “Server”)
¨ Object
 A specific instance of a class (“Joe, the passenger who is
purchasing a ticket from the ticket distributor”).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25
 Associations

TarifSchedule TripLeg

Enumeration Price
* * Zone
getZones()
Price getPrice(Zone)

Associations denote relationships between classes

The multiplicity of an association end denotes how
many objects the instance of a class can
legitimately reference.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26
 Associations and links
¨ A link represents a connection between two objects.
Associations are relationships between classes and
represent groups of links.
¨ Each FieldOfficer object also has a list of
EmergencyReports that has been written by the
FieldOfficer.
¨ In UML, associations can be symmetrical
(bidirectional) or asymmetrical (unidirectional).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27
 Association class
¨ Associations are similar to classes, in that they can
have attributes and operations attached to them. Such
an association is called an association class and is
depicted by a class symbol that contains the attributes
and operations and is connected to the association
symbol with a dashed line.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28
 Roles
¨ Each end of an association can be labeled by a role.
¨ The roles of the association between EmergencyReport and FieldOfficer
are author and reportsGenerated.

¨ Multiplicity Each end of an association can be labeled by a set of

integers indicating the number of links that can legitimately originate
from an instance of the class connected to the association end.
¨ This set of integers is called the Multiplicity of the association end.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29
 Most of the associations we encounter belong to one of the following three types
¨ A one-to-one association has a multiplicity 1 on each end. A one-to-one
association between two classes (e.g., PoliceOfficer and BadgeNumber)
means that exactly one link exists between instances of each class.
¨ A one-to-many association has a multiplicity 1 on one end and 0..n (also
represented by a star) or 1..n on the other. A one-to-many association
between two classes.
¨ A many-to-many association has a multiplicity 0..n or 1..n on both ends.
A many-to-many association between two classes (e.g., FieldOfficer and
IncidentReport) denotes that an arbitrary number of links can exist
between instances of the two classes.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30
 1-to-1 and 1-to-many Associations

Country 1 1 City

name:String name:String

1-to-1 association

Point
Polygon
* x: Integer

y: Integer
draw()

1-to-many association

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31
 Many-to-Many Associations

Company

StockExchange * * tickerSymbol

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32
 From Problem Statement To Object Model

Problem Statement: A stock exchange lists many companies.

Each company is uniquely identified by a ticker symbol

Class Diagram:

* * Company
StockExchange
Lists
tickerSymbol

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33
 From Problem Statement to Code

Problem Statement : A stock exchange lists many companies.

Each company is identified by a ticker symbol

Class Diagram:
StockExchange * * Company
Lists tickerSymbol

Java Code
public class StockExchange
{
private Vector m_Company = new Vector();
};
public class Company
{
public int m_tickerSymbol;
private Vector m_StockExchange = new Vector();
};

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34
 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 classes
Exhaust system

1 0..2

Muffler Tailpipe

diameter diameter

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35
 Qualifiers
Without qualification
1 * File
Directory
filename

With qualification
1 0..1
Directory filename File

¨ Qualifiers can be used to reduce the multiplicity of an

association

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36
 Qualification: Another Example
Company

StockExchange * Lists
* LogoSymbol

StockExchange
*LogoSymbol Lists 1
* Company

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37
 Inheritance
Button

CancelButton ZoneButton

¨ Inheritance is another special case of an association denoting a

“kind-of” hierarchy
¨ Inheritance simplifies the analysis model by introducing a
taxonomy
¨ The children classes inherit the attributes and operations of
the parent class.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38
 Class diagram example

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39
 Class diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40
 Sequence Diagrams
Focus on
Control flow
¨ Used during analysis
TicketMachine  To refine use case descriptions
Passenger
 to find additional objects
selectZone() (“participating objects”)
Messages ->
Operations on
TicketMachine participating Object
insertCoins()
zone2price
selectZone( ¨ Used during system design
)  to refine subsystem interfaces
pickupChange() insertCoins ¨ Instances are represented by
() rectangles. Actors by sticky figures
pickupChang ¨ Lifelines are represented by dashed
pickUpTicket() e() lines
¨ Messages are represented by arrows
pickUpTicke
¨ Activations are represented by narrow
t()
rectangles.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41
 Sequence Diagrams can also model the Flow of Data

ZoneButton TarifSchedule Display

Passenger

selectZone()
lookupPrice(selection)

price
displayPrice(price)
Dataflow
…continued on next slide...

¨ The source of an arrow indicates the activation

which sent the message
¨ Horizontal dashed arrows indicate data flow, for
example return results from a message
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42
 Sequence Diagrams: Iteration & Condition

…continued from previous slide...

ChangeProcessor CoinIdentifier Display CoinDrop

Passenger

*insertChange(coin) lookupCoin(coin)

price
Iteration displayPrice(owedAmount)

[owedAmount<0] returnChange(-owedAmount)
Condition

…continued on next slide...

¨ Iteration is denoted by a * preceding the message name

¨ Condition is denoted by Boolean expression in [ ]
before the message name
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43
 Creation and destruction
…continued from previous slide...

ChangeProcessor
Passenger Creation of Ticket
createTicket(selection)

Ticket
print()

free()
Destruction of Ticket

¨ Creation is denoted by a message arrow pointing to the object

¨ Destruction is denoted by an X mark at the end of the destruction
activation
 In garbage collection environments, destruction can be used to denote the
end of the useful life of an object.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44
 Sequence Diagram Properties

¨ UML sequence diagram represent behavior in

terms of interactions
¨ Useful to identify or find missing objects
¨ Time consuming to build, but worth the
investment
¨ Complement the class diagrams (which
represent structure).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45
 Sequence diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46
 State Machine Diagrams
¨ A UML state machine is a notation for describing the sequence of states an
object goes through in response to external events.
¨ A state is a condition satisfied by the attributes of an object.

For example, an Incident object in FRIEND can exist in four states: Active,
Inactive, Closed, and Archived.
¨ A transition represents a change of state triggered by events, conditions, or
time.
¨ A state is depicted by a rounded rectangle. A transition is depicted by an
open arrow connecting two states. States are labeled with their name. A
small solid black circle indicates the initial state. A circle surrounding
a small solid black circle indicates a final state.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47
¨ Actions are fundamental units
of processing that can take a
set of inputs, produce a set of
outputs, and can change the
state of the system. Actions
normally take a short amount
of time to execute and are not
interruptible.
¨ An internal transition does not
leave the state. Internal
transitions are triggered by
events & can have actions
associated with them.
¨ Nested state machines reduce
complexity. They can be used
instead of internal transitions.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 48
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49
 Applying state machine diagrams

¨ State machine diagrams are used to represent

nontrivial behavior of a subsystem or an
object.
¨ State machines are used to identify object
attributes and to refine the behavior description
of an object, and interaction diagrams are used to
identify participating objects and the services
they provide.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50
 Activity Diagrams
¨ UML activity diagrams represent the sequencing and
coordination of lower level behaviors.
¨ An activity diagram denotes how a behavior is
realized in terms of one or several sequences of
activities and the object flows needed for coordinating
the activities.
¨ Activity diagrams are hierarchical: an activity is
made out of either an action or a graph of sub
activities and their associated object flow.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51
 ¨ Control nodes coordinate control flows in an activity diagram,
providing mechanisms for representing decisions,
concurrency, and synchronization.
¨ The main control nodes we use are decisions, fork nodes,
and join nodes.
¨ Decisions are branches in the control flow. They denote
alternatives based on a condition of the state of an object or a
set of objects.
¨ Fork nodes and join nodes represent concurrency. Fork nodes
denote the splitting of the flow of control into multiple
threads,
¨ while join nodes denotes the synchronization of multiple
threads and their merging of the flow of control into a single
thread.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52
 ¨ Activities may be grouped into swimlanes (also
called activity partitions) to denote the object or
subsystem that implements the actions.
Swimlanes are represented as rectangles
enclosing a group of actions. Transitions may
cross swimlanes.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 53
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 54
 Applying activity diagrams
¨ Activity diagrams provide a task-centric
view of the behavior of a set of objects.
¨ For example, to describe sequencing
constraints among use cases, sequential
activities among a group of objects, or the
tasks of a project.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 55
 Diagram Organization
¨ Models of complex systems quickly become complex
as developers refine them. The complexity of models
can be dealt with by grouping related elements into
packages.
¨ A package is a grouping of model elements, such as
use cases or classes, defining scopes of understanding.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 56
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 57
 ¨A note is a comment attached to a
diagram. Notes are used by developers
for attaching information to models and
model elements.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 58
 Diagram Extensions
¨ UML provides a number of extension mechanisms enabling the modeler to
extend the language. There are two such mechanisms Stereotypes and
Constraints
¨ A stereotype is an extension mechanism that allows developers to classify
model elements in UML.
¨ A stereotype is represented by string enclosed by guillemets (e.g.,
«boundary») and attached to the model element to which it applies, such
as a class or an association.
For example, during analysis, we classify objects into three types: entity,
boundary, and control. All objects have the same structure (i.e., they have
attributes, operations, and associations), but serve different purposes.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 59
 ¨ A constraint is a rule that is attached to a UML model
element restricting its semantics. This allows us to represent
phenomena that cannot otherwise be expressed with UML
¨ For Example: An Incident may be associated with one or
more EmergencyReports from the field. However, it is
important that the Dispatchers are able to view the reports
chronologically. We represent the chronological ordering of
EmergencyReport to Incident with the constraint {ordered
by time of receipt}.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 60
 State machine diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 61
 Activity diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 62
 Analysis
¨ A Overview of Analysis
¨ Analysis Object Models and Dynamic Models
¨ Entity, Boundary, and Control Objects
¨ Generalization and Specialization

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 63
 Analysis
¨ Analysis focuses on producing a model of the system, called the analysis
model, which is correct, complete, consistent, and verifiable.
¨ Analysis is different from requirements elicitation, where the developers
focus on structuring and formalizing the requirements elicited from users.
The analysis model is composed of three individual models:
¨ The functional model, represented by use cases and scenarios,
¨ The analysis object model, represented by class and object diagrams.
¨ The dynamic model, represented by state machine and sequence diagrams .

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 64
 Analysis Object Models and Dynamic Models
¨ The analysis model represents the system under development from
the user’s point of view.
¨ The analysis object model is a part of the analysis model and focuses on
the individual concepts that are manipulated by the system, their
properties and their relationships.
¨ The analysis object model, depicted with UML class diagrams, includes
classes, attributes, and operations.
¨ The dynamic model focuses on the behavior of the system. The dynamic
model is depicted with sequence diagrams and with state machines.
Sequence diagrams represent the interactions among a set of objects
during a single use case. State machines represent the behavior of a
single object.
¨ When working with either the analysis object model or the dynamic
model, it is essential to remember that these models represent user-
level concepts, not actual software classes or components.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 65
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 66
 Entity, Boundary, and Control Objects

Entity objects represent the persistent information tracked by the system.

Boundary objects represent the interactions between the actors and the
system.
Control objects are in charge of realizing use cases.

In the 2Bwatch example, Year, Month, and Day are entity objects; Button
and LCDDisplay are boundary objects; ChangeDateControl is a control
object that represents the activity of changing the date by pressing
combinations of buttons.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 67
 Generalization and Specialization
¨ Inheritance enables us to organize concepts into hierarchies.
Eg: At the top of the hierarchy is a general concept (e.g., an Incident) and at the
bottom of the hierarchy are the most specialized concepts (e.g. CatInTree, TrafficAccident,
BuildingFire, EarthQuake, ChemicalLeak). There may be any number of intermediate
levels in between, covering more-or-less generalized concepts (e.g.LowPriorityIncident,
Emergency, Disaster).

¨ Generalization is the modeling activity that identifies abstract concepts from lower-
level ones. For example, assume we are reverse-engineering an emergency
management system and discover screens for managing traffic accidents and fires.
¨ Noticing common features among these concepts, we create an abstract concept called
Emergency to describe the common (and general) features of traffic accidents and
fires.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 68
¨ Specialization is the activity that identifies more specific concepts from a high-level one.
For example, assume that we are building an emergency management system from
scratch and that we are discussing its functionality with the client.
¨ The client first introduces with the concept of an incident, then describes three types of
Incidents:
 Disasters, which require the collaboration of several agencies,
 Emergencies, which require immediate handling but can be handled by
a single agency and
 LowPriorityIncidents, that do not need to be handled if resources are
required for other.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 69
 Analysis Activities: From Use Cases to Objects
The activities that transform the use cases and scenarios produced during
requirements elicitation into an analysis model.
Analysis activities include:
• 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
• Reviewing the Analysis Model
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 70
 Identifying Entity Objects
¨
Participating objects are found by examining each use case and identifying candidate
objects.
¨ Natural language analysis [Abbott, 1983] is an intuitive set of heuristics for identifying
objects, attributes, and associations from a requirements specification.
¨ Abbott’s heuristics maps parts of speech (e.g., nouns, having verbs, being verbs,
adjectives) to model components (e.g., objects, operations, inheritance relationships,
classes).
Abbott’s heuristics for mapping parts of speech to model components [Abbott, 1983

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 71
 ¨ After a first examination of the ReportEmergency use case ,use application
domain knowledge and interviews with the users to identify the objects
Dispatcher, EmergencyReport, FieldOfficer, and Incident.
¨ The definition of entity objects leads to the initial analysis model . Note that this
model is far from a complete description of the system implementing the
ReportEmergency use case.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 72
 Entity objects for the Report Emergency use case

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 73
 Identifying Boundary Objects
¨ Boundary objects represent the system interface with the actors. In each use case, each actor
interacts with at least one boundary object.
¨ The boundary object collects the information from the actor and translates it into a form that can
be used by both entity and control objects.
For example, boundary objects such as “menu item” or “scroll bar” are too detailed.
First, developers can discuss user interface details more easily with sketches and mock-ups. Second,
the design of the user interface continues to evolve as a consequence of usability tests, even after the
functional specification of the system becomes stable.
Boundary objects for Report Emergency Use case

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 74
 Identifying Control Objects
¨ Control objects are responsible for coordinating boundary and entity objects.
¨ A close relationship exists between a use case and a control object; a control object is
usually created at the beginning of a use case and ceases to exist at its end. It is
responsible for collecting information from the boundary objects and dispatching it to
entity objects.

For example, control objects describe the behavior associated with the
sequencing of forms, undo and history queues, and dispatching information in a
distributed system.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 75
 Mapping Use Cases to Objects with Sequence Diagrams
¨ A sequence diagram ties use cases with objects. It shows
how the behavior of a use case (or scenario) is distributed
among its participating objects.
¨ Sequence diagrams are usually not as good a medium for
communication with the user as use cases are, since sequence diagrams
require more background about the notation.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 76
 ¨ Sequence diagrams also depict the lifetime of objects. Objects that already exist
before the first stimuli in the sequence diagram are depicted at the top of the diagram.
¨ Objects that are created during the interaction are depicted with the «create» message
pointing to the object. Instances that are destroyed during the interaction have a cross
indicating when the object ceases to exist.
¨ Between the rectangle representing the object and the cross (or the bottom of the
diagram, if the object survives the interaction), a dashed line represents the time
span when the object can receive messages. The object cannot receive
messages below the cross sign.
¨ The second column of a sequence diagram represents the boundary
object with which the actor interacts to initiate the use case (e.g.,
ReportEmergencyButton).
¨ The third column is a control object that manages the rest of the use case
(e.g., ReportEmergency– Control). From then on, the control object
creates other boundary objects and may interact with other control
objects as well.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 77
 ¨ The entity object Acknowledgment that was forgotten during initial
examination of the ReportEmergency use case .
¨ The Acknowledgment object is different from an Acknowledgment
Notice: Acknowledgment holds the information associated with an
Acknowledgment and is created before the Acknowledgment Notice
boundary object. When describing the Acknowledgment object, it can be
realized that the original ReportEmergency use case is incomplete. It
only mentions the existence of an Acknowledgment and does not
describe the information associated with it

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 78
 ¨ After obtaining such clarification, the Acknowledgment
object is added to the analysis model.
¨ By constructing sequence diagrams, we not only model the
order of the interaction among the objects, we also distribute
the behavior of the use case. That is, we assign
responsibilities to each object in the form of a set of
operations.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 79
 Modeling Interactions among Objects with CRC Cards
¨ CRC cards (CRC stands for class, responsibilities, and collaborators)
were initially introduced as a tool for teaching object-oriented
concepts to novices and to experienced developers unfamiliar with
object-orientation.
¨ Each class is represented with an index card (called the CRC card).
The name of the class is depicted on the top, its responsibilities in
the left column, and the names of the classes it needs to accomplish
its responsibilities are depicted in the right column.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 80
 Identifying Associations
An association shows a relationship between two or more classes. For example, a FieldOfficer
writes an Emergency Report.
Identifying associations has two advantages.
 It clarifies the analysis model by making relationships between objects explicit (e.g., an
EmergencyReport can be created by a FieldOfficer or a Dispatcher).
 It enables the developer to discover boundary cases associated with links.

Associations have several properties:

 A name to describe the association between the two classes. Association names are
optional and need not be unique globally.
 A role at each end, identifying the function of each class with respect to the
associations (e.g., author is the role played by FieldOfficer in the Writes association).
•
 A multiplicity at each end, identifying the possible number of instances (e.g., *
indicates a FieldOfficer may write zero or more EmergencyReports, whereas 1
indicates that each EmergencyReport has exactly one FieldOfficer as author)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 81
 Identifying Aggregate
¨ Aggregations are special types of associations denoting a
whole–part relationship. For example, a FireStation consists
of a number of FireFighters, FireEngines, Ambulances, and a
LeadCar.
¨ A State is composed of a number of Counties that are, in
turn, composed of a number of Townships . An aggregation
is shown as a association with a diamond on the side of the
whole part.
¨ There are two types of aggregation
 Composition
 Shared.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 82
 ¨ A Composition aggregation indicates that the existence of the
parts depends on the whole.
¨ a Shared aggregation relationship, indicating the whole and
the part can exist independently.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 83
 Identifying Attributes
¨ Attributes are properties of individual objects.
¨ For example, an EmergencyReport, as described in Table 5-2, has an
emergency type, a location, and a description property

¨ Developers should identify as many associations as possible before identifying

attributes to avoid confusing attributes and objects. Attributes have:
¨ A name identifying them within an object. For example, an EmergencyReport may have
a reportType attribute and an emergencyType attribute.
¨ A type describing the legal values it can take. For example, the description attribute of
an EmergencyReport is a string

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 84
 Modeling State-Dependent Behavior of Individual Objects

 State machine diagrams represent behavior from the perspective of a

single object.
 Viewing behavior from the perspective of each object enables the
developer to build a more formal description of the behavior of the object,
and consequently, to identify missing use cases.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 85
 Modeling Inheritance Relationships between Objects
¨ Generalization is used to eliminate redundancy from the analysis
model. If two or more classes share attributes or behavior, the
similarities are consolidated into a superclass.

¨ For example, Dispatchers and FieldOfficers both have a badgeNumber

attribute that serves to identify them within a city.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 86
 Reviewing the Analysis Model

¨ The analysis model is built incrementally and iteratively.

¨ Once the number of changes to the model are minimal and
the scope of the changes localized, the analysis model
becomes stable.
¨ Then the analysis model is reviewed, first by the developers
(i.e., internal reviews), then jointly by the developers and the
client.
¨ The goal of the review is to make sure that the requirements
specification is correct, complete, consistent, and
unambiguous.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 87
 Analysis Summary

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 88