Object-Oriented Software Engineering

Using UML, Patterns, and Java

Object Modeling
Chapter 5, Analysis:
 Software Lifecycle Activities

Object
Requirements System Implemen-
Analysis (Detailed) Testing
Elicitation Design tation
Design

Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By

class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Case Model
Objects

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

• What do you see? • Analysis focuses on

producing a model of
the system, called
the analysis model,
which is correct,
complete, consistent,
and verifiable.

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

Recall: System modeling = Functional modeling +

Object modeling + Dynamic modeling
 Last lecture: Functional modeling
• Now: Object modeling
• Activities during object modeling
• Object identification
• Object types
• Entity, boundary and control objects
• Abott’s technique
• Helps in object identification.

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

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5
 Activities during Object Modeling
Main goal: Find the important abstractions
• Steps during object modeling
1. Class identification
2. Find the attributes
3. Find the operations
4. Find the associations between classes
• What happens if we find the wrong abstractions?
• We iterate and revise the model.

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

Class identification is crucial to object-oriented

modeling
• Helps to identify the important entities of a system
• Basic assumptions:
1. We can find the classes for a new software system
(Forward Engineering)
2. We can identify the classes in an existing system
(Reverse Engineering)

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

• Approaches
• Application domain approach
• Ask application domain experts to identify relevant
abstractions
• Syntactic approach
• Start with use cases
• Analyze the text to identify the objects
• Extract participating objects from flow of events
• Design patterns approach
• Identify relevant abstractions that can be reused
(apply design knowledge)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8
 There are different types of Objects

• Entity Objects
• Represent the persistent information tracked by the
system (Application domain objects, also called
“Business objects”)
• Boundary Objects
• Represent the interaction between the user and the
system
• Control Objects
• Represent the control tasks performed by the system.

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

Year Button
ChangeDate

Month
LCDDisplay

Day

Entity Objects Control Object Boundary Objects

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10
Naming Object Types in UML
To distinguish different object types
in a model we use the
UML Stereotype mechanism

<<Entity>> <<Boundary>>
Year <<Control>> Button
ChangeDate
<<Entitity>>
Month <<Boundary>>
<<Entity>> LCDDisplay
Day

Entity Object Control Object Boundary Object

 UML is an Extensible Language
• Stereotypes allow you to extend the vocabulary of the
UML so that you can create new model elements,
derived from existing ones
• Other Examples:
• Stereotypes can also be used to classify method behavior such
as <<constructor>>, <<getter>> or <<setter>>
• To indicate the interface of a subsystem or system, one can
use the stereotype <<interface>> (Lecture System Design)
• Stereotypes can be represented with icons as well as
graphics:
• This can increase the readability of UML diagrams.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
 Graphics for Stereotypes
• One can also use graphical symbols to identify a
stereotype
• When the stereotype is applied to a UML model element, the
graphic replaces the default graphic for the diagram element.
• Example: When modeling a network, we can define graphical
symbols to represent classes of type Switch, Server, Router and
Printer. Graphics for
Class of type
Printer Graphics for
Class of type
Router

Graphics for
Class of type Graphics for
Switch Server Class
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13
Object Types allow us to deal with Change

• Having three types of object leads to models

that are more resilient to change
• The interface of a system changes more likely than the
control
• The way the system is controlled changes more likely
than entities in the application domain
• Object types originated in Smalltalk:
• Model, View, Controller (MVC)
Model <-> Entity Object
View <-> Boundary Object
Controller <-> Control Object

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

• Generalization is the modeling activity that

identifies abstract concepts from lower-level
ones.
• Assume we are reverse-engineering an emergency
management system and discover screens for
managing traffic accidents and fires.

Emergency

TrafficAccident Fire

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

• Specialization is the activity that identifies

more specific concepts from a high-level one.
• Assume that we are building an emergency
management system from scratch

Incident

LowPriority Emergency Disaster

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16
 Finding Participating Objects in Use Cases

• Pick a use case and look at flow of events

• Do a textual analysis (noun-verb analysis)
• Nouns are candidates for objects/classes
• Verbs are candidates for operations
• This is also called Abbott’s Technique

• After objects/classes are found, identify their

types
• Identify real world entities that the system needs to
keep track of (FieldOfficer  Entity Object)
• Identify real world procedures that the system needs
to keep track of (EmergencyPlan  Control Object)
• Identify interface artifacts (PoliceStation  Boundary
Object).
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17
Generating a Class Diagram from Flow of Events
Customer Flow of events:
• The customer enters the store to buy
Store
? a toy
toy. It has to be a toy that his
daughter like
likes and it must cost less
enter() than 50 Euro
Euro. He tries a videogame
videogame,
which uses a data glove and a head-
Daughter mounted display. He likes it.
age

suitable
An assistant helps him. The suitability
*Toy of the game depends on the age of the
Toy
price
buy() child. His daughter is only 3 years old.
buy()
like() The assistant recommends another
toy, namely a boardgame
type of toy boardgame. The
customer buy the game and leaves
VideoGame BoardGame
the store
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
 Mapping grammatical constructs to model
components (Abbot’s Technique)
Grammatical UML model
Example
construct component
Toy Improper noun class
“Monopoly” Proper noun object
Buy, recommend Doing verb operation
Is a being verb inheritance
has an having verb aggregation
must be modal verb constraint
dangerous adjective attribute
enter transitive verb operation
depends on intransitive verb Constraint, class,
association
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19
 Ways to find Objects
• Syntactical investigation with Abbot‘s technique:
• Flow of events in use cases
• Problem statement

• Use other knowledge sources:

• Application knowledge: End users and experts know
the abstractions of the application domain
• Solution knowledge: Abstractions in the solution
domain
• General world knowledge: Your generic knowledge and
intuition

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20
 Order of Activities for Object Identification

1. Formulate a few scenarios with the help from

an end user or application domain expert
2. Extract the use cases from the scenarios, with
the help of an application domain expert
3. Then proceed in parallel with the following:
• Analyse the flow of events in each use case
using Abbot's textual analysis technique
• Generate the UML class diagram.

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

1. Class identification (textual analysis, domain

expert)
2. Identification of attributes and operations
(sometimes before classes are found!)
3. Identification of relations:
• Associations between classes
• Inheritance
• Aggregation
• Multiplicities
• Roles

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22
 Who uses Class Diagrams?

• Purpose of class diagrams

• The description of the static properties of a system
• The main users of class diagrams:
• The application domain expert
• uses class diagrams to model the application
domain (including taxonomies)
• during requirements elicitation and analysis
• The developer
• uses class diagrams during the development of a
system
• during analysis, system design, object design
and implementation.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23
 Who does not use Class Diagrams?

• The client and the end user are usually not

interested in class diagrams
• Clients focus more on project management issues
• End users are more interested in the functionality of
the system.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24
 Developers have different Views on Class
Diagrams
• According to the development activity, a
developer plays different roles:
• Analyst
• System Designer
• Object Designer
• Implementor

• Each of these roles has a different view about

the class diagram (the object model).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25
 The View of the Analyst

• The analyst is interested

• in application classes: The associations between
classes are relationships between abstractions in the
application domain
• operations and attributes of the application classes
• inheritance in the model to reflect the taxonomies in
the application domain

• The analyst is not interested

• in the exact signature of operations
• in solution domain classes

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26
 The View of the Designer

• The designer focuses on solution of problem

(i.e., solution domain)

• Associations between classes are now references

(pointers) between classes in solution domain

• The designer describes interface of subsystems

(system design) and classes (object design)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27
 The View of the Implementor

• Class implementor
• Must realize the interface of a class in a programming
language
• Interested in appropriate data structures (for the
attributes) and algorithms (for the operations)
• Class extender
• Interested in how to extend a class to solve a new
problem or to adapt to a change in the application
domain
• Class user
• The class user is interested in the signatures of the
class operations and conditions, under which they can
be invoked
• The class user is not interested in the implementation
of the class.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28
 Why do we distinguish different Users of
Class Diagrams?
• The key for creating high quality software
systems is the exact distinction between
1. Application and solution domain classes on one side
• Preferred: No solution classes in the analysis model

2. Interface specification and implementation

specification on the other side
• Preferred: We distinguish between analysis model
and object design model.
• The analysis design model does not contain any
implementation specification.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29
 Software Lifecycle Activities:
Analysis Model vs. Object Design model

Object
Requirements System Implemen-
Analysis (Detailed) Testing
Elicitation Design tation
Design

Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By

class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Case Model
Objects

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30
 Analysis Model vs. Object Design model

• Always use the clients’ or end users’ terminology during

analysis

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31
 Analysis Model vs. Object Design model

• The analysis model is constructed during the

analysis phase
• Main stake holders: End user, customer, analyst
• The class diagrams contain only application domain
classes

• The object design model (sometimes also called

specification model) is created during the object
design phase
• Main stake holders: class specifiers, class
implementors, class users and class extenders
• The class diagrams contain application domain as well
as solution domain classes.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32
 Analysis Model vs Object Design Model (2)

• The analysis model is the basis for

communication between analysts, application
domain experts and end users.

• The object design model is the basis for

communication between designers and
implementors.

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

• System modeling
• Functional modeling + object modeling + dynamic
modeling
• Functional modeling
• From scenarios to use cases to objects
• Object modeling is the central activity
• Class identification is a major activity of object modeling
• Easy syntactic rules to find classes and objects
• Abbot’s Technique
• Class diagrams are the “center of the universe”
for the object-oriented developer
• The end user focuses more on the functional model and
usability.

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