CSCE 606: Design
Some material from B. Meyer, M. Oriol, B. Schoeller at ETH Zürich
Outline
• From requirements to design
• UML class diagrams
• From analysis classes to implementation
classes
• More of UML
10/7/2015
CSCE 606 Design
2
From Requirements to Design
• S, D  R
• S = specification
• D = domain properties
• R = requirements
• Come up with a design that satisfies S
10/7/2015
CSCE 606 Design
3
Semantic Gap
• A requirements specification
• IEEE Std 830-1998, UML use cases,…

Semantic Gap

• A complete description of the design
10/7/2015
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
10/7/2015
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
10/7/2015
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
10/7/2015
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?
10/7/2015
CSCE 606 Design
8
Outline
• From requirements to design
• UML class diagrams
• From analysis classes to implementation
classes
• More of UML
10/7/2015
CSCE 606 Design
9
Basic UML Models
• Functional model
• Functionality of the system from the user’s 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
10/7/2015
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
10/7/2015
CSCE 606 Design
11
ER Diagrams
10/7/2015
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
10/7/2015
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
class diagram
instance diagram
10/7/2015
a graphical notation for modeling
objects and their relationships
template for describing many
instances of data; useful for
taxonomies, patterns, and schemata
a particular set of objects relating to
each other; useful for discussing
scenarios, test cases and examples
CSCE 606 Design
14
UML Class Diagrams: Features
• Classes: name, attributes, operations
• Associations
•
•
•
•
navigation arrows
multiplicities
qualifications
roles
• Association classes
• Aggregations
• Inheritance
10/7/2015
CSCE 606 Design
15
Outline
• From requirements to design
• UML class diagrams
• From analysis classes to implementation
classes
• More of UML
10/7/2015
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
10/7/2015
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
10/7/2015
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
10/7/2015
CSCE 606 Design
19
Example, Abbott’s 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.
10/7/2015
CSCE 606 Design
20
Example, Abbott’s 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.
10/7/2015
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
10/7/2015
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.
10/7/2015
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.
10/7/2015
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 Abbott’s technique seems like a
game/toy
10/7/2015
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
10/7/2015
CSCE 606 Design
26
No Fool-Proof Methodology
• Must settle for some hints and warnings
10/7/2015
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
10/7/2015
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?
10/7/2015
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?
10/7/2015
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) { . . . }
}
10/7/2015
CSCE 606 Design
31
What Classes to Reject?
• Mixed abstractions
• E.g., MFC’s 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
10/7/2015
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
10/7/2015
CSCE 606 Design
33
Class Elicitation Principle
• Class elicitation is a dual process:
• class suggestion
• class rejection
10/7/2015
CSCE 606 Design
34
Meyer’s “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).
10/7/2015
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
10/7/2015
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”
10/7/2015
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
10/7/2015
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
10/7/2015
CSCE 606 Design
39
Object Kinds in Digital Watch
Year
Button
ChangeDate
Month
LCDDispla
y
Day
Entity Objects
10/7/2015
Control Objects
CSCE 606 Design
Boundary Objects
40
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
10/7/2015
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
10/7/2015
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
10/7/2015
CSCE 606 Design
43
Outline
• From requirements to design
• UML class diagrams
• From analysis classes to implementation
classes
• More of UML
10/7/2015
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
10/7/2015
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 object’s life time
• Time span an object can receive messages
• Cross depicts destruction
10/7/2015
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
10/7/2015
CSCE 606 Design
47
Example
10/7/2015
CSCE 606 Design
48
Example (cont.)
10/7/2015
CSCE 606 Design
49
State Machine Diagrams
• State machines represent a system’s behavior
from a single object’s perspective
• (Sequence diagrams represent a system’s
behavior from a single use case’s 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
10/7/2015
CSCE 606 Design
50
State Machine Diagrams:
Notation
• Largely based on Harel’s 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
10/7/2015
CSCE 606 Design
51
Example
10/7/2015
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
10/7/2015
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
10/7/2015
CSCE 606 Design
54
Descargar

Document