1. Part 2: Design Methodology Object-Oriented Modeling and Design
Analysis
Chapter 8
Part 2: Design Methodology
Object-Oriented Modeling and Design
Byung-Hyun Ha

2. Lecture Outline Introduction Problem Statement Object Modeling
Dynamic Modeling
Functional Modeling
Adding Operations
Iterating the Analysis

3. Introduction Analysis phase Purpose of object-oriented analysis
Devising a precise, concise, understandable, and correct model of the real-world
Understand the requirements and the real-world environment
Purpose of object-oriented analysis
To model the real-world system so that it can be understood
To do this, we must
examine requirements, analyze their implication, and restate them rigorously; and
abstract important real-world features first and defer small details until later
Successful analysis model
states what must be done, without restricting how it is done; and
avoids implementation decisions

4. Introduction
Overview of analysis process

5. Introduction Importance of each model (O/D/F) depends on the problem
Almost all problems have useful object models derived from real-world entities
Problems concerning interactions and timing, such as user interfaces and process control, have important dynamic models
Problems containing significant computation, such as compilers and engineering calculations, have important functional models
Analysis cannot always be carried out in rigid sequence
Large models are built up iteratively
Analysis is not a mechanical process
The analyst must communicate with the requestor to clarify ambiguity and misconceptions

6. Problem Statement Problem statement Task of analyst
states what is to be done and not how it is to be done
Problem scope, what is needed, application context, assumptions, and performance needs
should be a statement of needs, not a proposal for a solution
is just starting point for understanding problem, not an immutable documents
Task of analyst
To resolve ambiguity, incompleteness, and inconsistency
To separate the true requirements from design and implementation decisions disguised as requirements
To work with the requestor to refine the requirements so they represent the requestor’s true intent
If you do exactly what the customer asked for, but the result does not meet the customer’s real needs, you will be probably blamed anyway!

7. Problem Statement
Example problem statement
Section 8.3, page 151

8. Object Modeling Object model precedes other models, because
static structure is usually better defined,
less dependent on application details,
more stable as the solution evolves, and
easier for humans to understand
Information for the object model comes from
the problem statement,
expert knowledge of the application domain, and
general knowledge of the real world
Object diagrams promote
communication between computer professionals and application-domain experts

9. Object Modeling Object model construction steps  Operations
Identify objects and classes
Prepare a data dictionary
Identify associations (including aggregations) between objects
Identify attributes of objects and links
Organize and simplify object classes using inheritance
Verify that access paths exist for likely queries
Iterate and refine the model
Group classes into modules
 Operations
Add operations to classes later as a by-product of constructing the dynamic and functional models

10. Object Modeling Identifying object classes
Not all classes are explicit in the problem statement; some are implicit in the application domain or general knowledge
Don’t be too selective; write down every class that comes to mind
Classes often correspond to nouns; for example, in a statement “a reservation system to sell tickets to performance at various theaters” tentative classes would be Reservation, System, Ticket, Performance, and Theater
Don’t worry much about inheritance or high-level classes

11. Object Modeling Identifying object classes
ATM classes extracted from problem statement nouns
ATM classes identified from knowledge of problem domain

12. Object Modeling Unnecessary and incorrect classes Redundant classes
Keep the most descriptive one
Irrelevant classes
Vague classes
Attributes
Names that primarily describe individual objects
Operations
Roles
The name of a class should reflect its intrinsic nature and not a role that it plays in an association
Implementation constructs
Later during design

13. Object Modeling
Keeping right classes
ATM example

14. Object Modeling Preparing data dictionary
Write a paragraph precisely describing each object class
The data dictionary also describes associations, attributes, and operations

15. Object Modeling Identifying associations
Any dependency between two or more classes is an association
A reference from one class to another is an association
Attributes should not refer to classes; use an association instead
Associations often correspond to stative verbs or verb phrases
physical location: next to, part of, contained in, …
direct actions: drives, …
communication: talks to, …
ownership: has, part of, …
satisfaction of some condition: works for, married to, nanages, …
etc.
Association for the ATM example (next slide)

17. Object Modeling Unnecessary and incorrect associations
Associations between eliminated classes
Irrelevant or implementation associations
Actions
An association should describe a structural property, not a transient event
e.g. ATM accepts cash card: part of interaction cycle, not a permanent relationship
Ternary associations
Cashier enters transaction for account  Cashier enters transaction + Transaction concerns account
Derived associations
Grandparent of vs. Parent of
Sometimes they are needed

18. Object Modeling Specifying semantics of associations
Name of association
Names are important to understanding and should be chosen with great care
Role names
Add role name where appropriate
Qualified associations
Multiplicity
Don’t put too much effort into getting it right, as multiplicity often changes during analysis
Challenge multiplicity values of “one”
Missing associations

19. Object Modeling
Initial object diagram for ATM system

20. Object Modeling Identifying attributes
Attributes usually correspond to nouns followed by possessive phrases
e.g. the color of car, the position of cursor
Attributes are less likely to be fully described in the problem statement
Fortunately attributes seldom affect the basic structure of the problem
Do not carry discovery of attributes to excess
Derived attributes should be omitted or clearly labeled
Link attributes should also be identified

21. Object Modeling Unnecessary and incorrect attributes Objects Qualifier
Names
Names are often better modeled as qualifiers rather than object attributes
Identifiers
Link attributes
Link attributes are usually obvious on many-to-many associations
Internal values
Fine detail
Discordant attributes
They are sign of splitting a class into distinct classes
ATM object model with attributes (next slide)

23. Object Modeling Refining with inheritance Two directions
By generalizing common aspects of existing classes into a superclass (bottom up)
By refining existing classes into specialized subclasses (top down)
Avoid excessive generalization and refinement!
Multiple inheritance may be used to increase sharing, but only if necessary
It increases both conceptual and implementation complexity
ATM object model with inheritance (next slide)

25. Object Modeling Remaining topics (see the textbook)
Testing assess paths
Iterating object modeling
Grouping classes into modules
Final ATM object model (next slide)

27. Dynamic Modeling Dynamic model
Time-dependent behavior of the system and the objects in it
Begin dynamic analysis by looking for events
Dynamic model is insignificant for a purely static data repository, such as a database
Dynamic model is important for interactive systems
Construction steps
Prepare scenarios of typical interaction sequences
Identify events between objects
Prepare an event trace for each scenario
Build a state diagram
Match events between objects to verify consistency

28. Dynamic Modeling Preparing scenario A scenario is a sequence of events
Prepare for normal cases (without error condition), and then special cases
For each event, identify the actor and parameters
Normal ATM scenario and ATM scenario with exception (next slide)

30. Dynamic Modeling Interface formats
Most interactions can be separated into two parts: application logic and user interface
The analyst should concentrate first on the information flow and control, rather than the presentation format
Possible ATM layout

31. Dynamic Modeling Identifying events
Examine scenarios to identify all external events
An action by an object that transmit information is an event
Event trace
An ordered list of events between different objects
Event flow diagram
Summarizing events between classes, without regard for sequence
Dynamic counterpart to object diagram
Event trace and event flow diagram for ATM scenario (next two slides)

34. Dynamic Modeling Building a state diagram
Prepare a state diagram for each object class with nontrivial dynamic behavior
Pick a trace showing a typical interaction and only consider the event affecting a single object
Interval between any two events is a state; give each state a name if a name is meaningful
Find loop within the diagram; replace finite sequences of events with loops when possible
Merge other scenarios into the state diagram
Add boundary cases and special cases
Test completeness and error-handling capabilities of a class
Posing “What if” question
Etc. (Blah-blah-blah…)
State diagrams for class ATM, Consortium, and Bank (next two slides)

37. Functional Modeling Functional model Construction steps
Which values depend on which other values and functions that relate them
Functions are expressed in various ways, including natural language, mathematical equations, and pseudocode
Processes on a data flow diagram corresponds to activities or actions in the state diagram of classes
Flows on a data flow diagram correspond to objects or attribute values in an object diagram
Construction steps
Identify input and output values
Build DFD showing functional dependencies
Describe functions
Identify constrains
Specify optimization critera

38. Functional Modeling Identifying input and output values
Input and output values are parameters of events between the system and the outside world
Input and output values for ATM system

39. Functional Modeling Building data flow diagram
How each output value is computed from input values
Work backward from each output value to determine the function that computes it
DFD is usually constructed in layers
Top level data flow diagram for ATM

40. Functional Modeling Building data flow diagram (cont’)
Expand each nontrivial process in the top-level diagram into a lower-level data flow diagram
DFD for ATM perform transaction process

41. Functional Modeling Describing functions
Identifying constraint between objects
e.g. Invariants, preconditions, …
Specifying optimization criteria

42. Adding Operations Operations from object model Operations from events
Reading and writing attribute values and association links
Operations from events
Each event sent to an object corresponds to an operation on the object
Operations from functions
Each function in DFD corresponds to an operation on the object
Shopping list operations
Meaningful operations in objects’ own right
They provide an opportunity to broaden the base of an object definition beyond the narrow needs of the immediate problem
Simplifying operations

43. Iterating the Analysis
Refining the analysis model
Reexamine the model carefully
Sometimes major restructuring in the model is needed as your understanding increases
Restating the requirements