CSCE 606: Design

Some material from B. Meyer, M. Oriol, B. Schoeller at ETH Zrich

Outline
From requirements to design
UML class diagrams
From analysis classes to implementation
classes
More of UML
9/15/2014 CSCE 606 Design 2
From Requirements to Design
S, D R
S = specication
D = domain properties
R = requirements
Come up with a design that satises S
9/15/2014 CSCE 606 Design 3
Semantic Gap
A requirements specication
IEEE Std 830-1998, UML use cases,

Semantic Gap

A complete description of the design
9/15/2014 CSCE 606 Design 4
How to Bridge the Semantic Gap
Lots of advice available
But hard to give concrete methods or truly
endorse most of it
Our advice focuses on going from OO analysis
to OO design, and then implementation
Not all languages are OO, but OO seems to
give a usable starting point for understanding
systems and designs




9/15/2014 CSCE 606 Design 5
Role of Object-Oriented Analysis
Analysis object model later
refines to object model
Analysis object and dynamic
models basis of system design
9/15/2014 CSCE 606 Design 6
Analysis
Developers formalize requirements
specification
Examine exceptional cases, boundary conditions
Clients engaged
OO Analysis
Developers build an object model of the application
domain
Extend model with how actors and system interact
with the application domain objects
9/15/2014 CSCE 606 Design 7
Trade-Offs
Create design that matches requirements as
closely as possible?
Or reuse existing designs/implementations as
much as possible, at expense of less direct
match to requirements?
Create class hierarchy that closely matches
problem domain?
Or create class hierarchy that supports
extensibility, reuse, etc. and uses abstractions
from implementation domain?
9/15/2014 CSCE 606 Design 8
Outline
From requirements to design
UML class diagrams
From analysis classes to implementation
classes
More of UML
9/15/2014 CSCE 606 Design 9
Basic UML Models
Functional model
Functionality of the system from the users point of view
Use case diagrams
Object model
Structure of the system
objects, attributes, associations, operations
analysis object model system design object model design
object model
Dynamic model
Describes the behavior of objects (states and state transitions,
control and data flow)
Interaction diagrams
State machines
Activity diagrams
9/15/2014 CSCE 606 Design 10
Describing Static Structure of
a System
What kind of objects are in the system
Representing classes
Representing relations between classes
Many notations exist
ER models
Purely about entities and their relations
UML class diagrams
Clear OO flavor, and a mapping to implementation using
OO technologies
9/15/2014 CSCE 606 Design 11
ER Diagrams
9/15/2014 CSCE 606 Design 12
Using UML Class Diagrams
Used
During requirements analysis to model application
domain concepts (taxonomies)
During system design to model subsystems
During object design to specify classes in detail,
including their methods and attributes
Thus used by both analysts and developers
9/15/2014 CSCE 606 Design 13
Object vs. Class
An object (instance): exactly one thing
A class describes a group of objects with similar
properties

object diagram a graphical notation for modeling
objects and their relationships
class diagram template for describing many
instances of data; useful for
taxonomies, patterns, and schemata
instance diagram a particular set of objects relating to
each other; useful for discussing
scenarios, test cases and examples
9/15/2014 CSCE 606 Design 14
UML Class Diagrams: Features
Classes: name, attributes, operations
Associations
navigation arrows
multiplicities
qualifications
roles
Association classes
Aggregations
Inheritance
9/15/2014 CSCE 606 Design 15
Outline
From requirements to design
UML class diagrams
From analysis classes to implementation
classes
More of UML
9/15/2014 CSCE 606 Design 16
Object Modeling
One of the motivations of object-orientation is that one can
model reality with objects
Goal of object modeling: find important abstractions
Classes
Primarily to understand the system
Secondarily to serve as the blueprint of an implementation
Analysis class hierarchy does not have to match with the
implementation class hierarchy
Some classes might be represented as relations, relations as
classes, classes as attributes, attributes as classes, etc.
Perhaps a useful guideline: implementation should be a
refinement of analysis classes
9/15/2014 CSCE 606 Design 17
Basic Process of Class Design
Iterate in some order, until convergence
Identify classes
Find attributes
Find operations
Find associations between classes
Above too vague
Some guidance exists
9/15/2014 CSCE 606 Design 18
Some Methods
Abbott
R. Abbott, Program design by informal English descriptions,
CACM, vol. 26, no. 11, 1983
Analyze textual descriptions of flows of events in scenarios
and use cases
e.g., nouns are candidates for objects/classes
e.g., verbs are candidates for operations
Booch
Data flow analysis, followed by identifying concrete and
abstract objects (e.g., from data stores)
Coad and Yourdon
Look for things or events remembered, devices, roles, sites,
and organizational units
Shlaer-Mellor
Tangible entities, roles, incidents, interactions, and
specifications
9/15/2014 CSCE 606 Design 19
Example, Abbotts Technique
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 euros.
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 3
years old. The assistant
recommends another type
of toy, a boardgame. The
customer buys the game
and leaves the store.

9/15/2014 CSCE 606 Design 20
Example, Abbotts Technique
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 euros.
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 3
years old. The assistant
recommends another type
of toy, a boardgame. The
customer buys the game
and leaves the store.
9/15/2014 CSCE 606 Design 21
Mapping Grammatical Constructs
to Model Components
Example Grammatical construct Model component
Monopoly proper noun object
Toy improper noun class
buy, recommend doing verb operation
is a being verb inheritance
has a having verb aggregation
must be modal verb constraint
dangerous adjective attribute
enter transitive verb operation
depends on intransitive verb constraint/class/association
9/15/2014 CSCE 606 Design 22
Class Diagram
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 euros.
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 3
years old. The assistant
recommends another type
of toy, a boardgame. The
customer buys the game
and leaves the store.

9/15/2014 CSCE 606 Design 23
Class Diagram
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 euros.
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 3
years old. The assistant
recommends another type
of toy, a boardgame. The
customer buys the game
and leaves the store.

9/15/2014 CSCE 606 Design 24
Discussion
Is the previous technique useful?

At best, use with caution
Nouns can
Suggest notions that do not yield classes
Fail to suggest notions that should yield classes
Explicit use of Abbotts technique seems like a
game/toy
9/15/2014 CSCE 606 Design 25
Many Other Criteria for
Identifying Classes
Existing designs, reuse
Domain knowledge and solution knowledge
General world knowledge
Extensibility, variation points

Find key abstract data types

9/15/2014 CSCE 606 Design 26
No Fool-Proof Methodology
Must settle for some hints and warnings
9/15/2014 CSCE 606 Design 27
How Directly to Follow
Requirements Specification?
Not too directly
Crucial abstractions may not be directly
deducible from the requirements
Tends to suggest a specific, non-reusable
solution
Implies we do not refactor code
Remember: good requirements do not
prescribe a solution
9/15/2014 CSCE 606 Design 28
What Classes to Reject?
Abstract data types that are not semantically rich enough
Know the business domain and what is relevant to it
We concretize by observing shortcomings of grammar-based
techniques:
The elevator will close its door before it moves to another floor.
Should door be a class?
Might just be a Boolean member of an elevator class
Might be important enough to warrant its own class
Clear that grammar games next to useless question to ask:
Is door a separate data type with its own clearly identified operations,
or are all the operations on doors already covered by operations on
other data types, such as elevator?
9/15/2014 CSCE 606 Design 29
What Classes to Reject?
The elevator will close its door before it moves to
another floor.
Should floor be a class?
Likely integers is a sufficiently close abstraction
Possible reasons for a proper floor class
properties, such as floor access rights
integers support too many operations (what
operations do not make sense?
What would it mean to add or multiply to floors?
9/15/2014 CSCE 606 Design 30
What Classes to Accept?
A database record must be created every time the
elevator moves from one floor to another.
Important class move easily missed with
grammar-based method

class move {
initial, final: floor // or int
record (database& d) { . . . }
}
9/15/2014 CSCE 606 Design 31
What Classes to Reject?
Mixed abstractions
E.g., MFCs coordinate functions tied to DCs
Should be split into several classes, one per abstraction
Premature classification
taxomania
Use ADT view: a new class should add or modify a
feature, or strengthen the invariant
Known examples of bad/poor class choices for the
specific domain
Antipatterns commonly used, but ineffective patterns
9/15/2014 CSCE 606 Design 32
Other Danger Signals
Class with a verb name (infinitive or imperative)
Perhaps better modeled as a routine
Class described as performing something
May not be a proper data abstraction
Class with a single public routine
Maybe again better modeled as a routine
Using objects as lambdas useful, but such classes not
likely to appear during analysis
Class with no routines
Maybe some routines missing, or maybe not an ADT at all
9/15/2014 CSCE 606 Design 33
Class Elicitation Principle
Class elicitation is a dual process:
class suggestion
class rejection

9/15/2014 CSCE 606 Design 34
Meyers Ideal Class Typical
Properties
Clearly associated abstraction, which can be described as a data
abstraction (or abstract machine)
Class name is a noun or adjective, adequately characterizing the
abstraction
Class represents set of possible run-time objects - its instances (some
classes have only one instance during an execution)
Several queries available for instance properties
Several commands available to change instance state (in some cases,
instead of commands there are functions producing objects of the same
type, e.g. integer operations)
Abstract properties can be stated, (preferably formally, describing: how
the results of the various queries relate to each other (this will yield the
invariant); under what conditions features are applicable (preconditions);
how command execution affects query results (postconditions).
9/15/2014 CSCE 606 Design 35
What to Consider?
Analysis classes
Belong to the problem space
Describe data abstractions directly drawn from the
domain model
Design classes
Belong to the solution space
Describe architectural choices
Implementation classes
Belong to the solution space
Describe data abstractions introduced for the
internal needs of the algorithms
9/15/2014 CSCE 606 Design 36
Finding the Design Classes
Understand the importance of reuse: beware of
the NIH (Not Invented Here) syndrome
Reuse previous known designs in the same
domain
Avoid bugs!
Know standard design patterns
Avoid reinvention!
Consider describing abstractions as
machines rather than objects
9/15/2014 CSCE 606 Design 37
Finding the Implementation
Classes
Reuse!
Know and use the classical data structures and
algorithms
Know and use existing libraries of your language
Standard libraries
Company/group libraries
A waste to write your own string, array, tree,
class
9/15/2014 CSCE 606 Design 38
Different Kinds of Objects
Often the following categories can be identified
Suggested in: Jacobson, Booch, Rumbaugh: The Unified
Software Development Process. Addison-Wesley, 1999
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
Somewhat related to a model-view-controller architecture
9/15/2014 CSCE 606 Design 39
Object Kinds in Digital Watch
Entity Objects Control Objects Boundary Objects
9/15/2014 CSCE 606 Design 40
Year
Month
Day
ChangeDate
Button
LCDDispla
y
Identifying Entity Objects
Recurring nouns in requirements
Real-world entities that system must track
Real-world processes that system must track
Data sources or sinks
9/15/2014 CSCE 606 Design 41
Identifying Boundary Objects
Boundary objects collect information from user
Boundary objects translate information into
format for entity and control objects
User interface controls to initiate actions
Forms to enter data
Messages the system uses to respond
9/15/2014 CSCE 606 Design 42
Identifying Control Objects
Control objects coordinate boundary and entity
objects
Control objects do not have a concrete
counterpart in the real world
Identify one control object per business task
9/15/2014 CSCE 606 Design 43
Outline
From requirements to design
UML class diagrams
From analysis classes to implementation
classes
More of UML
9/15/2014 CSCE 606 Design 44
Sequence Diagrams
Ties use cases with objects
Shows how behavior of use case distributed
among its participating objects
More concise (and possibly more precise) than
textual use case descriptions
9/15/2014 CSCE 606 Design 45
Sequence Diagrams: Notation
Each column represents an object
Horizontal arrows are messages or stimuli
Vertical rectangle is an activation of an operation
Length represents time of being active
Triggered by a message
Messages can originate from operations
Time proceeds from top to bottom
Lifetime also depicted
Objects on top row exist from start
Other objects created with create messages
Vertical dashed line expresses objects life time
Time span an object can receive messages
Cross depicts destruction
9/15/2014 CSCE 606 Design 46
Sequence Diagram
Conventions
First column: initiating actor
Second column: boundary object
Third column: control object managing the rest of the
use case
Control objects created by boundary objects
Boundary objects created by control objects
Entity objects accessed by control and boundary objects
Entity objects never access control or boundary objects
Entity objects stay reusable across use cases
9/15/2014 CSCE 606 Design 47
Example
9/15/2014 CSCE 606 Design 48
Example (cont.)
9/15/2014 CSCE 606 Design 49
State Machine Diagrams
State machines represent a systems behavior
from a single objects perspective
(Sequence diagrams represent a systems
behavior from a single use cases perspective)
Cross-checking (which actions trigger which
transitions) between both views useful
Can reveal new use cases
Can reveal missing states
Can reveal ambiguities, incoherencies
9/15/2014 CSCE 606 Design 50
State Machine Diagrams:
Notation
Largely based on Harels statecharts (1987)

Exactly like finite state machines, but features added to keep
presentation manageable
Not all states need to be shown simultaneously
Can focus on one aspect of state independent of others
Notation for nesting states and state machines (OR states)
Orthogonal regions (AND states)
Notation for triggers and actions
Entry and exit actions
Internal transitions
9/15/2014 CSCE 606 Design 51
Example
9/15/2014 CSCE 606 Design 52
Statechart Usage
Understanding
What is the sequence of states for a particular
sequence of events?
Model checking
Is it possible for the machine to get into an
erroneous state?
This is answered by exhaustively exploring all
possible paths from a start state
9/15/2014 CSCE 606 Design 53
More UML to Learn
More on statecharts
Guard conditions and actions
Object diagrams
Like class diagrams, but snapshots of objects
Collaboration diagrams
Like sequence diagrams, but emphasis on structure instead of timing
Activity diagrams
Show flow of data and control in system
Arrows represent data between activities (boxes)
Component diagrams
Show system organization and dependencies
Deployment diagram
Show how components map to processing nodes
Extending UML
Stereotypes
9/15/2014 CSCE 606 Design 54