Skip to content

4. Analysis and Design

Domain models [3]

  • domain models illustrates meaningful conceptual classes in problem domain, and used during analysis.
  • represents real world problems, not software components
  • software-oriented class diagrams are represented later, during the design.
  • features of domain models:
    • domain classes: represent a real-world object (customer, agent), business objects (Contact, Invoice), business events (Sale, Hire, Charge, Payment). usually a noun in the requirements.
    • attributes: represent property in the domain class.
    • associations: represent relationship between domain classes, the association has a role indicating the details of the relationship.
    • additional rules: complex rules can be attached to domain classes.

2.5.1 Identifying Concepts

  • concept name is always a noun phrase, eg. KeyChecker.
  • we start from the periphery of the system by assigning concepts that handle the interactions between the system and outer world aka. between actors and the system.
  • each actor has at least one boundary object (concept) that converts data to internal objects when receiving data from the actor, or converting internal objects to data accepted by the actor when sending data to the actor.
  • organizations has persons-of-contact (POC) to handle communications with other organizations. => Controller object (concept)
  • during analysis: objects only used to represent possible system state, no effort to describe the system’s behavior.
  • during design: the behavior of the objects can be discussed.
  • UML does not have designated symbols for domain concepts, so it is usual to adopt the symbols that are used for software classes.
  • concepts are classified into 3 categories:
    • boundary
    • control
    • entity

2.5.2 Concept Associations and Attributes

  • associations describe who (concepts) needs to work together and why (not how they work together).
  • usually, associations belongs to the same package

Associations

  • attributes: refers to the concept attributes, where each concepts may need an internal state, params ..etc. eg. Lock model needs internal state indicating open, locked
  • when an attribute may go into multiple different concepts, put it in the controller.

2.5.4 Contracts: Preconditions and Postconditions

  • contracts:
    • express important conditions about the attributes in the domain model.
    • include facts about forming or breaking relations between concepts.
    • define time-points of where objects should should be created, then destroyed.

Design Goals, principles, and guidelines [2]

  • Goals:
    • desired quantity of the software
    • driven by cost/benefit economics
    • examples: clean code, design for change, clarity, simplicity, reuse…
  • Principles:
    • guidelines for designing software
    • supports one or more design goals
    • examples: Information hiding, low representation gap, low coupling, high cohesion…
  • heuristics:
    • guidelines for low-level design decisions
    • supports design principles and design goals
    • example: Creator, Expert, Controller…
  • Patterns:
    • general solutions for reoccurring problems.
    • supports design goals, but may add complexity or involve tradeoffs.
    • examples: Decorator, Strategy, Template Method…

2.6 Design: Assigning Responsibilities

  • design:
    • is assigning responsibilities to the software objects acquired in domain analysis.
    • concepts are converted to classes (one concept can be converted to one or more classes).
  • Dynamic object interactions can be represented using UML sequence diagrams.
  • Controller participates in every interaction with the actor.
  • good software designs are characterized by:
    • short communication chains between objects.
    • balanced workload across objects
    • low degree of connectivity (associations) among objects
  • design heuristics:
    • used to achieve optimal design.
    • bottom-up (inductive): applying design principles and design patterns locally at the level of objects (micro-level design).
    • top-down (deductive): applying architectural styles globally at the system level, then decomposing system into sub-systems (macro-level design)

2.6.1 Design Principles for Assigning Responsibilities

  • A popular approach to micro-level design is known as responsibility-driven design (RDD).
  • types of responsibility objects can have:
    1. knowing: memorizing data or references (properties of objects/classes).
    2. doing: performing computation (methods).
    3. communicating: communicate with other objects (invoking methods of other objects).
  • Important design principles at the local, objects level include:
    • Expert Doer principle
    • High Cohesion principle
    • Low coupling principle

important design principles

  • As seen, design principles are not always in agreement with each other. Enforcing any particular design principle to the extreme would lead to absurd designs.
  • it is left out to the developer judgment to mix the design principles in a way that serves the optimal design.
  • it is essential to document the the judgment process and the reasoning behind favouring one design principle over the others, and document the alternative solutions considered even if they haven’t been used.

Expert doer principle

  • anybody who know how to do a task can do it.
  • the first objects who can do the task should do it, and there is no need to chain it to other objects
  • communication chain becomes shorter.

High Cohesion principle

  • do not take too many responsibilities of type 2 (doing)
  • objects should have as less methods as possible
  • single non-trivial responsibility per object
  • balancing the workload across objects and keep them focused.
  • Object’s functional cohesion is inversely proportional to the number of computing responsibilities assigned to it

example

  • left indicates low cohesion, right indicates high cohesion
  • right path is better, where: A class has moderate responsibilities in one functional area and collaborates with other classes to fulfill tasks

Low coupling principle

  • do not take too many responsibilities of type 3 (communication)
  • objects should have as lass other objects as possible in their implementation.
  • reduce the number of associations among objects.
  • Objects coupling is directly proportional to the number of number of messages the object sends to other objects.
  • a module should depend on as less modules as possible.
  • enhances code understandability (limited contexts are easier to understand)
  • reduces the cost of change: when changing model’s interface, less modules are affected.
  • enhances reuse: fewer dependencies => easier to adapt to new contexts.
  • A class with high coupling is undesirable, because:
    • changes in related classes force local changes (and vice versa).
    • harder to understand in isolation.
    • harder to re-use because of its dependencies.
    • difficult to extend (changes in many places).

coupling example and solution

  • prefer composition to inheritance, to reduce coupling
  • Prefer coupling to interfaces over coupling to implementations

Low representational gap principle [2]

  • get inspired by the problem naming when naming your classes.
  • create software class for each domain class along with corresponding relationships.
  • this pattern is not important.

Law of Demeter [2]

  • each module should have only limited knowledge about other modules
  • in other words: do not talk to strangers
a.getB().getC().foo(); // violates the law of Demeter
a.getB().invokeFoo(); // better, a knows about b only.
// the logic of getting c, and calling c.foo() extracted to a method in B.

controller principle [2]

  • controller is:
    • a coordinator, does not much work itself.
    • delegates work to other objects
  • types of controllers:
    • sub-system controller: each sub-system starts with a controller that controls the logic within this sub-system.
    • system controller: the object that manages the overall system is a controller of the system, system controller may consult the sub-system controllers.
    • use case controller: the object that controls the use case scenario where the system event happens.
  • benefits of controller principles:
    • reduce coupling: all modules are imported in the controller, then controller coordinates the relationships between modules.
    • reduces the cost of change: changes in individual modules only affects the controller
    • supports reuse: classes are independent of each other, create more controllers according to the use case.
  • controllers work as mediators between domain logic and classes.
  • nested controllers may be used to organize complex logic: controller that delegate to the more appropriate controller.

2.6.2 Class Diagram

  • class diagram notation is standardized by UML, while domain models are not.
  • The number of operations in a class correlates with the amount of responsibility handled by the class
  • The number of methods in each class should be similar (balanced), if you find classes with strange number of methods (eg. all classes have 3-5 methods, but one have 20) then there may be undiscovered classes or responsibility miss-assignments

example class diagram

  • all classes must be traceable back to domain concepts.
  • a domain concept can be represented by one (or more) software classes.
  • all domain concepts must be traceable back to class(es), if one domain concept has no corresponding class, then:
    • the requirement has low priority, no need to think about it now.
    • the requirement has dropped and no longer needed.

domain model to class diagram traceability matrix

Class Relationships

  • relationship between classes:
    • use: one-to-one: a class has one instance of another class.
    • aggregate: a class has multiple instances of another class, (eg.. a class contains a collection of objects from another class).
  • symbols of class diagram (within a class):

Generic Object Roles

  • As a result of having specific responsibilities, the members of object community usually develop some stereotype roles:
    • Structurer
    • Bridge

references