Part 2: Design Methodology Object-Oriented Modeling and Design 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 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

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 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!

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  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

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 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

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 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

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