AnalysisChapter 8Part 2: Design MethodologyObject-Oriented Modeling and DesignByung-Hyun Habhha@pusan.ac.kr

Lecture OutlineIntroductionProblem StatementObject ModelingDynamic ModelingFunctional ModelingAdding OperationsIterating the Analysis

IntroductionAnalysis phaseDevising a precise, concise, understandable, and correct model of the real-worldUnderstand the requirements and the real-world environmentPurpose of object-oriented analysisTo model the real-world system so that it can be understoodTo do this, we mustexamine requirements, analyze their implication, and restate them rigorously; andabstract important real-world features first and defer small details until laterSuccessful analysis modelstates what must be done, without restricting how it is done; andavoids implementation decisions

IntroductionOverview of analysis process

IntroductionImportance of each model (O/D/F) depends on the problemAlmost all problems have useful object models derived from real-world entitiesProblems concerning interactions and timing, such as user interfaces and process control, have important dynamic modelsProblems containing significant computation, such as compilers and engineering calculations, have important functional modelsAnalysis cannot always be carried out in rigid sequenceLarge models are built up iterativelyAnalysis is not a mechanical processThe analyst must communicate with the requestor to clarify ambiguity and misconceptions

Problem StatementProblem statementstates what is to be done and not how it is to be doneProblem scope, what is needed, application context, assumptions, and performance needsshould be a statement of needs, not a proposal for a solutionis just starting point for understanding problem, not an immutable documentsTask of analystTo resolve ambiguity, incompleteness, and inconsistencyTo separate the true requirements from design and implementation decisions disguised as requirementsTo work with the requestor to refine the requirements so they represent the requestors true intentIf you do exactly what the customer asked for, but the result does not meet the customers real needs, you will be probably blamed anyway!

Problem StatementExample problem statementSection 8.3, page 151

Object ModelingObject model precedes other models, becausestatic structure is usually better defined,less dependent on application details,more stable as the solution evolves, andeasier for humans to understandInformation for the object model comes fromthe problem statement,expert knowledge of the application domain, andgeneral knowledge of the real worldObject diagrams promotecommunication between computer professionals and application-domain experts

Object ModelingObject model construction stepsIdentify objects and classesPrepare a data dictionaryIdentify associations (including aggregations) between objectsIdentify attributes of objects and linksOrganize and simplify object classes using inheritanceVerify that access paths exist for likely queriesIterate and refine the modelGroup classes into modulesOperationsAdd operations to classes later as a by-product of constructing the dynamic and functional models

Object ModelingIdentifying object classesNot all classes are explicit in the problem statement; some are implicit in the application domain or general knowledgeDont be too selective; write down every class that comes to mindClasses 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 TheaterDont worry much about inheritance or high-level classes

Object ModelingIdentifying object classesATM classes extracted from problem statement nouns

ATM classes identified from knowledge of problem domain

Object ModelingUnnecessary and incorrect classesRedundant classesKeep the most descriptive oneIrrelevant classesVague classesAttributesNames that primarily describe individual objectsOperationsRolesThe name of a class should reflect its intrinsic nature and not a role that it plays in an associationImplementation constructsLater during design

Object ModelingKeeping right classesATM example

Object ModelingPreparing data dictionaryWrite a paragraph precisely describing each object classThe data dictionary also describes associations, attributes, and operations

Object ModelingIdentifying associationsAny dependency between two or more classes is an associationA reference from one class to another is an associationAttributes should not refer to classes; use an association insteadAssociations often correspond to stative verbs or verb phrasesphysical 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 ModelingUnnecessary and incorrect associationsAssociations between eliminated classesIrrelevant or implementation associationsActionsAn association should describe a structural property, not a transient evente.g. ATM accepts cash card: part of interaction cycle, not a permanent relationshipTernary associationsCashier enters transaction for account Cashier enters transaction + Transaction concerns accountDerived associationsGrandparent of vs. Parent ofSometimes they are needed

Object ModelingSpecifying semantics of associationsName of associationNames are important to understanding and should be chosen with great careRole namesAdd role name where appropriateQualified associationsMultiplicityDont put too much effort into getting it right, as multiplicity often changes during analysisChallenge multiplicity values of oneMissing associations

Object ModelingInitial object diagram for ATM system

Object ModelingIdentifying attributesAttributes usually correspond to nouns followed by possessive phrasese.g. the color of car, the position of cursorAttributes are less likely to be fully described in the problem statementFortunately attributes seldom affect the basic structure of the problemDo not carry discovery of attributes to excessDerived attributes should be omitted or clearly labeledLink attributes should also be identified

Object ModelingUnnecessary and incorrect attributesObjectsQualifierNamesNames are often better modeled as qualifiers rather than object attributesIdentifiersLink attributesLink attributes are usually obvious on many-to-many associationsInternal valuesFine detailDiscordant attributesThey are sign of splitting a class into distinct classesATM object model with attributes (next slide)

Object ModelingRefining with inheritanceTwo directionsBy 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 necessaryIt increases both conceptual and implementation complexityATM object model with inheritance (next slide)

Object ModelingRemaining topics (see the textbook)Testing assess pathsIterating object modelingGrouping classes into modulesFinal ATM object model (next slide)

Dynamic ModelingDynamic modelTime-dependent behavior of the system and the objects in itBegin dynamic analysis by looking for eventsDynamic model is insignificant for a purely static data repository, such as a databaseDynamic model is important for interactive systemsConstruction stepsPrepare scenarios of typical interaction sequencesIdentify events between objectsPrepare an event trace for each scenarioBuild a state diagramMatch events between objects to verify consistency

Dynamic ModelingPreparing scenarioA scenario is a sequence of eventsPrepare for normal cases (without error condition), and then special casesFor each event, identify the actor and parametersNormal ATM scenario and ATM scenario with exception (next slide)

Dynamic ModelingInterface formatsMost interactions can be separated into two parts: application logic and user interfaceThe analyst should concentrate first on the information flow and control, rather than the presentation formatPossible ATM layout

Dynamic ModelingIdentifying eventsExamine scenarios to identify all external eventsAn action by an object that transmit information is an eventEvent traceAn ordered list of events between different objectsEvent flow diagramSummarizing events between classes, without regard for sequenceDynamic counterpart to object diagramEvent trace and event flow diagram for ATM scenario (next two slides)

Dynamic ModelingBuilding a state diagramPrepare a state diagram for each object class with nontrivial dynamic behaviorPick a trace showing a typical interaction and only consider the event affecting a single objectInterval between any two events is a state; give each state a name if a name is meaningfulFind loop within the diagram; replace finite sequences of events with loops when possibleMerge other scenarios into the state diagramAdd boundary cases and special casesTest completeness and error-handling capabilities of a classPosing What if questionEtc. (Blah-blah-blah)State diagrams for class ATM, Consortium, and Bank (next two slides)

Functional ModelingFunctional modelWhich values depend on which other values and functions that relate themFunctions are expressed in various ways, including natural language, mathematical equations, and pseudocodeProcesses on a data flow diagram corresponds to activities or actions in the state diagram of classesFlows on a data flow diagram correspond to objects or attribute values in an object diagramConstruction stepsIdentify input and output valuesBuild DFD showing functional dependenciesDescribe functionsIdentify constrainsSpecify optimization critera

Functional ModelingIdentifying input and output valuesInput and output values are parameters of events between the system and the outside worldInput and output values for ATM system

Functional ModelingBuilding data flow diagramHow each output value is computed from input valuesWork backward from each output value to determine the function that computes itDFD is usually constructed in layersTop level data flow diagram for ATM

Functional ModelingBuilding data flow diagram (cont)Expand each nontrivial process in the top-level diagram into a lower-level data flow diagramDFD for ATM perform transaction process

Functional ModelingDescribing functions

Identifying constraint between objectse.g. Invariants, preconditions, Specifying optimization criteria

Adding OperationsOperations from object modelReading and writing attribute values and association linksOperations from eventsEach event sent to an object corresponds to an operation on the objectOperations from functionsEach function in DFD corresponds to an operation on the objectShopping list operationsMeaningful operations in objects own rightThey provide an opportunity to broaden the base of an object definition beyond the narrow needs of the immediate problemSimplifying operations

Iterating the AnalysisRefining the analysis modelReexamine the model carefullySometimes major restructuring in the model is needed as your understanding increasesRestating the requirements