OOAD

[jimin-kiim]

OOAD

• OOAD: Object-Oriented Analysis and Design
• Object-Oriented Analysis
  • discovering the domain concepts( the objects of the problem domain)
  • investigation of the problem
• Object-Oriented Design
  • defining software objects and how they collaborate to fulfill the requirements
  • logical solution

Applying UML

• conceptual perspective: describe things in a situation of the real world or domain of interest
• sw specification perspective: describe sw abstractions or components with specifications and interfaces, but no commitment to a particular implementation
• sw implementation perspective: describe sw implementations in a particular technology

[jimin-kiim]

Domain Model

• UP domain model is usually both started and completed in the elaboration
• most important classic model in OOA
• related but, not identical to “domain layer” in software architecture
  • domain layer: related to OOD not OOA. domain model is related to OOA
• illustrates noteworthy concepts in a domain.
  • it helps us to understand the domain during early elaboration iterations
• source of inspiration for designing software objects and classes.
  • inspires the software classes of the domain layer in the design model.
  • prevent software from being far away from the reality of the domain
  • lower representation gap between concepts in the domain and the concepts in the domain layer
  • Use software class names in the domain layer inspired from names in the domain model, with objects having domain-familiar information and responsibilities.
• a visual representation of conceptual classes or real- situation objects in a domain.
  • it's not a picture of a software class.
  • Sale+attribute(o), SalesDatabase(x), Sale + methods (x)
• focuses on explaining things and products important to a business domain
• also called conceptual models, domain object models, analysis object models
• does not contain software objects
• illustrated with a set of class diagram without operations
  • domain objects(conceptual classes), attributes, associations only.
  • in OOD, operations are added.

Creating a Domain Model

• find conceptual classes
  • reusing existing models
  • this is the first, best and usually easiest approach
  • there are published, well-crafted domain models and data models for many common domains
  • using category list
  • category - conceptual class examples
  • identification of noun phrases
  • identify the nouns and noun phrases in a textual description of the domain.
  • mechanical noun-to-class mapping might not be possible since natural language is ambiguous
• draw the identified conceptual classes in a UML class diagram
• add associations and attributes to conceptual classes

Discussion

Receipt Object

• the object seems to be noteworthy item
• but it's only a report of other objects
• -> duplicate information

  Attributes v.s. Classes

• If we do not think of X as a number or text in the real world, X is probably a conceptual class, not an attribute.
• Sale- store (x), Sale, Store-phoneNumber
• Flight-destination (x), Flight, Airport-name

  Description Class

• contains information that describes something else.
• add a description class when:
  • there needs to be a description about an item or service, independent of the current existence of any examples of those items or services.
  • deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing.
  • it reduces redundant or duplicated information.

    Associations

  • some meaningful and interesting connection.
  • in UML: the semantic relationship between two or more classifiers that involve connections among their instances.
  • need-to-remember association: associations for which knowledge of the relationship needs to be preserved for some duration
  • associations derived from the Common Associations List
• transaction, role, physically or logically contained in/on, description, known, logged, reported, captured, member of, organizational subunit, uses or manages or owns, next to
  • an association in the domain model is meaningful in a purely conceptual perspective in the real domain.
• many such relationships will be implemented in software as paths of navigation and visibility
• but, the domain model is not a data model
  • two classes may have multiple associations between them.

    Attribute

  • a logical data value of an object.
  • information that we need to remember.
  • in UML: shown in the second compartment of the class box.
• visibility name : type multiplicity = default {property-string}
  • visibility: + (public), - (private), # (protected) or ~ (package)
  • name: the name of the variable
  • type: a data type such as Integer, Date, String etc.
  • multiplicity: the multiplicity of the variable
  • default: the default value for the variable
  • property-string: a property of the variable such as {readOnly} or {frozen}
  • If an attribute is derivable, use / symbol before the attribute name.
    • e.g. - / total: Money

[jimin-kiim]

Requirements to Design Iteratively

• Iteratively Do the Right Thing and Do the Thing Right
  • Iteratively:
  • transition from requirements/OOA to design/implementation occur in each iteration
  • Do the Right Thing:
  • The requirements and OOA have focused on learning to do the right thing.
  • Understanding some outstanding goals, related rules and constraints
  • Do the Thing Right:
  • Design work will stress do the thing right.
  • Skillful designing a solution to satisfy the requirements for its iteration.
• Discover and change some requirements during the design and implementation work. Especially in the early iterations
• Embrace Change
  • Early programming, tests, and demos help provoke the inevitable changes early on.
• By the end of elaboration, 80% of the requirements are reliably defined

[jimin-kiim]

Designing Objects

• Dynamic models
  • designing the logic, the behavior of the code or the method bodies.
  • UML class diagrams
• Static models
  • designing the definitions of packages, class names, attributes, and method signatures (but not method bodies).
  • UML interaction diagrams (sequence diagrams or communication diagrams)
• Spend a short period of time on interaction diagrams (dynamics), then switch to a wall of related class diagrams (statics).
• Drawing UML: a reflection of making decisions about the design.
• Fundamental object design requires knowledge of Principles of responsibility assignment, Design patterns