1. CSCE 606: Design
Some material from B. Meyer, M. Oriol, B. Schoeller at ETH Zürich

2. Outline From requirements to design UML class diagrams
From analysis classes to implementation classes
More of UML
9/20/2018
CSCE 606 Design

3. From Requirements to Design
S, D  R
S = specification
D = domain properties
R = requirements
Come up with a design that satisfies S
9/20/2018
CSCE 606 Design

4. Semantic Gap  Semantic Gap  A requirements specification
IEEE Std , UML use cases,… 
Semantic Gap 
A complete description of the design
9/20/2018
CSCE 606 Design

5. 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/20/2018
CSCE 606 Design

6. Role of Object-Oriented Analysis
Analysis object model later refines to object model
Analysis object and dynamic models basis of system design
9/20/2018
CSCE 606 Design

7. Analysis Developers formalize requirements specification OO Analysis
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/20/2018
CSCE 606 Design

8. 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/20/2018
CSCE 606 Design

9. Outline From requirements to design UML class diagrams
From analysis classes to implementation classes
More of UML
9/20/2018
CSCE 606 Design

10. Basic UML Models Functional model Object model Dynamic 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
9/20/2018
CSCE 606 Design

11. 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/20/2018
CSCE 606 Design

12. ER Diagrams
9/20/2018
CSCE 606 Design

13. 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/20/2018
CSCE 606 Design

14. 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/20/2018
CSCE 606 Design

15. UML Class Diagrams: Features
Classes: name, attributes, operations
Associations
navigation arrows
multiplicities
qualifications
roles
Association classes
Aggregations
Inheritance
9/20/2018
CSCE 606 Design

16. Outline From requirements to design UML class diagrams
From analysis classes to implementation classes
More of UML
9/20/2018
CSCE 606 Design

17. 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/20/2018
CSCE 606 Design

18. 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/20/2018
CSCE 606 Design

19. Some Methods Abbott Booch Coad and Yourdon Shlaer-Mellor
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/20/2018
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.
9/20/2018
CSCE 606 Design

21. 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.
9/20/2018
CSCE 606 Design

22. 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
depends on
intransitive verb
constraint/class/association
9/20/2018
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/20/2018
CSCE 606 Design

24. 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/20/2018
CSCE 606 Design

25. Is the previous technique useful?
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
9/20/2018
CSCE 606 Design

26. 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/20/2018
CSCE 606 Design

27. No Fool-Proof Methodology
Must settle for some hints and warnings
9/20/2018
CSCE 606 Design

28. 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/20/2018
CSCE 606 Design

29. 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/20/2018
CSCE 606 Design

30. What Classes to Reject? Should floor be a class?
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/20/2018
CSCE 606 Design

31. 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/20/2018
CSCE 606 Design

32. What Classes to Reject? Mixed abstractions Premature classification
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
ADT == abstract data type
MFC == Microsoft Foundation Class, DC == Display Coordinate
9/20/2018
CSCE 606 Design

33. 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/20/2018
CSCE 606 Design

34. Class Elicitation Principle
Class elicitation is a dual process:
class suggestion
class rejection
9/20/2018
CSCE 606 Design

35. 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).
9/20/2018
CSCE 606 Design

36. What to Consider? Analysis classes Design 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
Describe data abstractions introduced for the internal needs of the algorithms
9/20/2018
CSCE 606 Design

37. 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/20/2018
CSCE 606 Design

38. 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/20/2018
CSCE 606 Design

39. 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/20/2018
CSCE 606 Design

40. Object Kinds in Digital Watch
Year
Button
ChangeDate
Month
LCDDisplay
Day
Entity Objects Control Objects Boundary Objects
9/20/2018
CSCE 606 Design

41. 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/20/2018
CSCE 606 Design

42. 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/20/2018
CSCE 606 Design

43. 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/20/2018
CSCE 606 Design

44. Outline From requirements to design UML class diagrams
From analysis classes to implementation classes
More of UML
9/20/2018
CSCE 606 Design

45. 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/20/2018
CSCE 606 Design

46. 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
9/20/2018
CSCE 606 Design

47. 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/20/2018
CSCE 606 Design

48. Example
9/20/2018
CSCE 606 Design

49. Example (cont.)
9/20/2018
CSCE 606 Design

50. 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
9/20/2018
CSCE 606 Design

51. 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
9/20/2018
CSCE 606 Design

52. Example
9/20/2018
CSCE 606 Design

53. Statechart Usage Understanding Model checking
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/20/2018
CSCE 606 Design

54. More UML to Learn More on statecharts Object diagrams
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/20/2018
CSCE 606 Design