L12 ObjectModeling Ch05lect1

Object-Oriented Software Engineering
Using UML, Patterns, and Java
Object Modeling
Chapter 5: Analysis,
Outline
Recall: System modeling = Functional modeling +

Object modeling + Dynamic modeling
Last week: Functional modeling
Today: Object modeling
Activities during object modeling
Object identification
Object types
Entity, boundary and control objects
Stereotypes
Abotts technique
Helps in object identification.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2
From Use Cases to Objects
Level 1 Level 1 Use Case
Level 2 Level 2 Level 2 Use Cases
Level 3 Level 3 Level 3 Level 3 Use Cases
Operations
Level 4 Level 4
A B
Participating
Objects
From Use Cases to Objects: Why Functional
Decomposition is not Enough
Level 1 Scenarios
Level 2 Level 2 Level 1 Use Cases
Level 3 Level 3 Level 3 Level 2 Use Cases
Operations
Level 4 Level 4
A B
Participating
Objects
Activities during Object Modeling
Main goal: Find the important abstractions
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
What happens if we find the wrong abstractions?
We iterate and revise the model
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)
Why can we do this?
Philosophy, science, experimental evidence.
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
Use reusable design patterns
Component-based approach
Identify existing solution classes.
Class identification is a Hard Problem
One problem: Definition of the system

boundary:
Which abstractions are outside, which abstractions are
inside the system boundary?
Actors are outside the system
Classes/Objects are inside the system.
An other problem: Classes/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?
Scenarios and use cases => Functional model
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.
Example: 2BWatch Modeling
To distinguish different object types
in a model we can use the
UML Stereotype mechanism
Year Button
ChangeDate
Month
LCDDisplay
Day
Entity Objects Control Object Boundary Objects
Naming Object Types in UML
UML provides the stereotype mechanism to
introduce new types of modeling elements
A stereotype is drawn as a name enclosed by angled double-
quotes (guillemets) (<<, >>) and placed before the name of a
UML element (class, method, attribute, .)
Notation: <<String>>Name
<<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
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 and
graphics:
This can increase the readability of UML diagrams.
Icons for Stereotypes
One can use icons to identify a stereotype

When the stereotype is applied to a UML model element, the
icon is displayed beside or above the name
Year ChangeDate Button WatchUser
Entity Object Control Object Boundary Object Actor
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, define graphics for
representing classes of type Switch, Server, Router, Printer,etc.
Graphics for
Class of type
Router
Graphics for
Class of type Graphics for
Switch Server Class
Pros and Cons of Stereotype Graphics
Advantages:
UML diagrams may be easier to understand if they contain
graphics and icons for stereotypes
This can increase the readability of the diagram, especially
if the client is not trained in UML
And they are still UML diagrams!
Disadvantages:
If developers are unfamiliar with the symbols being used, it can
become much harder to understand what is going on
Additional symbols add to the burden of learning to read the
diagrams.
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
Next topic: Finding objects.
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 Abbotts 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).
Example for using the Technique
Flow of Events:
The customer enters the store 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 3 years old.
The assistant recommends another type of
toy, namely the boardgame Monopoly".
Mapping parts of speech to model
components (Abbots Technique)
Example Part of speech UML model component
Monopoly Proper noun object
Toy Improper noun class
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,
Bernd Bruegge & Allen H. Dutoit
association 19
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Generating a Class Diagram from Flow of Events
Customer Flow of events:
The customer enters the store
store
? to buy a toy.
toy It has to be a
toy that his daughter likes and
enter() it must cost less than 50 Euro.
videogame which
He tries a videogame,
daughter uses a data glove and a head-
age mounted display. He likes it.
suitable An assistant helps him. The
*Toy depends
suitability of the game depends
toy
price on the age of the child. His
buy()
buy() daughter is only 3 years old.
like() The assistant recommends another
type of toy
toy, namely a boardgame.
boardgame
videogame boardgame
The customer buy the game and
leaves the store
Ways to find Objects
Syntactical investigation with Abbots 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
intution
Order of Activities for Object Identification
1. Formulate a few scenarios with 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.
Steps in Generating Class Diagrams
1. Class identification (textual analysis, domain

expert)
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 inheritance
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.
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.
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
Abbots Technique
Class diagrams are the center of the universe
for the object-oriented developer
The end user focuses more on the functional model and
and usability.
Additional Slides
What is This?
What is This?
Face
1..2
Eye
Modeling in Action
If it is a Face
What are its Attributes?
Sad, Happy
Or is it a Mask?
Investigate the
functional model
Who is using it? -> Actors
Art collector
Bankrobber
Carnival participant
How is it used? -> Event flow
Napkin design of a Mask to be used at the
Venetian Carnival
Pieces of an Object Model
Classes and their instances (objects)

Attributes
Operations
Associations between classes and objects
Associations
Types of Associations
Canonical associations
Part-of Hierarchy (Aggregation)
Kind-of Hierarchy (Inheritance)
Generic associations
Attributes
Detection of attributes is application specific

Attributes in one system can be classes in
another system
Turning attributes to classes and vice versa
Operations
Source of operations
Use cases in the functional model
General world knowledge
Generic operations: Get/Set
Design Patterns
Application domain specific operations
Actions and activities in the dynamic model
Object vs Class
Object (instance): Exactly one thing

This lecture on object modeling
A class describes a group of objects with similar
properties
Game, Tournament, mechanic, car, database
Object diagram: A graphical notation for
modeling objects, classes and their relationships
Class diagram: Template for describing many instances
of data. Useful for taxonomies, patters, schemata...
Instance diagram: A particular set of objects relating to
each other. Useful for discussing scenarios, test cases
and examples
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).
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
(difference to E/R models!)
The analyst uses inheritance in the model to
reflect the taxonomies in the application domain
Taxonomy: An is-a-hierarchy of abstractions in an
application domain
The analyst is not interested
in the exact signature of operations
in solution domain classes
The View of the Designer
The designer focuses on the solution of the
problem, that is, the solution domain
The associations between classes are now
references (pointers) between classes in the
application or solution domain
An important design task is the specification of
interfaces:
The designer describes the interface of classes and the
interface of subsystems
Subsystems originate from modules (term often used
during analysis):
Module: a collection of classes
Subsystem: a collection of classes with an interface
Subsystems are modeled in UML with a package.
Goals of the Designer
The most important design goals for the

designer are design usability and design
reusability
Design usability: the interfaces are usable from
as many classes as possible within in the
system
Design reusability: The interfaces are designed
in a way, that they can also be reused by other
(future) software systems
=> Class libraries
=> Frameworks
=> Design patterns.
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.
Why do we distinguish different Users of
Class Diagrams?
Models often dont distinguish between
application classes and solution classes
Reason: Modeling languages like UML allow the use of
both types of classes in the same model
address book, array"
Preferred: No solution classes in the analysis model
Many systems dont distinguish between the
specification and the implementation of a class
Reason: Object-oriented programming languages allow
the simultaneous use of specification and
implementation of a class
Preferred: We distinguish between analysis model and
object design model. The analysis design model does
not contain any implementation specification.
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 contains 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.
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.
Summary 2
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
Abbots Technique
Analysts, designers and implementors have
different modeling needs
There are three types of implementors with
different roles during
Class user, class implementor, class extender.

L12 ObjectModeling Ch05lect1

Uploaded by

Copyright:

Available Formats

L12 ObjectModeling Ch05lect1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

L12 ObjectModeling Ch05lect1

Uploaded by

Copyright:

Available Formats

Object-Oriented Software Engineering

Using UML, Patterns, and Java

Recall: System modeling = Functional modeling +

Level 2 Level 2 Level 2 Use Cases

Level 3 Level 3 Level 3 Level 3 Use Cases

Level 2 Level 2 Level 1 Use Cases

Level 3 Level 3 Level 3 Level 2 Use Cases

Class identification is crucial to object-oriented

One problem: Definition of the system

Entity Objects Control Object Boundary Objects

Entity Object Control Object Boundary Object

One can use icons to identify a stereotype

Year ChangeDate Button WatchUser

Entity Object Control Object Boundary Object Actor

Having three types of object leads to models

Next topic: Finding objects.

Pick a use case and look at flow of events

After objects/classes are found, identify their

Use other knowledge sources:

1. Formulate a few scenarios with help from an

1. Class identification (textual analysis, domain

Purpose of class diagrams

The client and the end user are usually not

Classes and their instances (objects)

Detection of attributes is application specific

Object (instance): Exactly one thing

Each of these roles has a different view about

The analyst is interested

The most important design goals for the

The analysis model is constructed during the

The object design model (sometimes also called

The analysis model is the basis for

The object design model is the basis for

You might also like