Analysis

Chapter 8
Part 2: Design Methodology
Object-Oriented Modeling and Design
Byung-Hyun Ha
bhha@pusan.ac.kr
Lecture Outline
 Introduction
 Problem Statement
 Object Modeling
 Dynamic Modeling
 Functional Modeling
 Adding Operations
 Iterating the Analysis
Introduction
 Analysis phase
 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
Introduction
 Overview of analysis process
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
Problem Statement
 Problem statement
 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!
Problem Statement
 Example problem statement
 Section 8.3, page 151
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
Object Modeling
 Object model construction steps
 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
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
Object Modeling
 Identifying object classes
 ATM classes extracted from problem statement nouns

 ATM classes identified from knowledge of problem domain

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
Object Modeling
 Keeping right classes
 ATM example
Object Modeling
 Preparing data dictionary
 Write a paragraph precisely describing each object class
 The data dictionary also describes associations, attributes, and
operations
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)
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
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
Object Modeling
 Initial object diagram for ATM system
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
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)
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)
Object Modeling
 Remaining topics (see the textbook)
 Testing assess paths
 Iterating object modeling
 Grouping classes into modules
 Final ATM object model (next slide)
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
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)
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
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)
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)
Functional Modeling
 Functional model
 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
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
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
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
Functional Modeling
 Describing functions

 Identifying constraint between objects

 e.g. Invariants, preconditions, …
 Specifying optimization criteria
Adding Operations
 Operations from object model
 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
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