Object-oriented design

Object-oriented design (OOD) moves from what the system must do (analysis artefacts: use cases, domain model, system sequence diagrams and contracts) to how software objects will collaborate to do it. The key activity is assigning responsibilities to classes, guided by design patterns, and expressing the result in interaction (collaboration/communication and sequence) diagrams and design class diagrams. MCQs focus on GRASP patterns, visibility types and diagram notation.

Key concepts

Analysis to design

• Analysis artefacts feed design: use-case text gives the scenarios; system operations from SSDs become the starting messages; contracts' postconditions say what the design must achieve; the domain model inspires software class names (low representational gap).
• Design produces interaction diagrams (dynamic view) and design class diagrams (static view), often drawn in parallel.
• Architecture is usually layered: UI layer → application/domain layer → technical services. System operations arrive from the UI into a controller object in the domain layer.

Describing and elaborating use cases

• In each iteration, selected use cases are elaborated in more detail: real (concrete) use cases specify design decisions such as UI widgets, while essential use cases remain technology-free.
• Scenarios are refined; extensions and special requirements are added; use cases are ranked (by risk, coverage and business value) to choose what to design next.

Collaboration (communication) diagram

• Shows objects as boxes linked by links, with numbered messages along the links: 1: makePayment(cashTendered), nested numbering 1.1, 1.2 shows calls made inside message 1.
• Notation: instance :Sale or s:Sale; conditional message [condition] msg(); iteration *; creation message create() (often stereotyped «create»); multi-object for collections.
• Sequence diagram carries the same information arranged in time order with lifelines and activation bars — easier to read for order; a collaboration diagram shows structure (links) better and uses space efficiently.

Objects and patterns

• Responsibilities: knowing (own data, related objects, things it can derive) and doing (doing something itself, creating objects, controlling/coordinating others).
• GRASP (General Responsibility Assignment Software Patterns), Larman:
  • Information Expert: give a responsibility to the class that has the information to fulfil it (e.g. Sale computes its total).
  • Creator: B creates A if B contains/aggregates A, records A, closely uses A, or has A's initialising data (e.g. Sale creates SalesLineItem).
  • Controller: a non-UI object receives and coordinates system events — a façade controller (represents the whole system/device) or a use-case (session) controller. Avoid bloated controllers.
  • Low Coupling and High Cohesion: evaluative principles for all choices.
  • Polymorphism, Pure Fabrication (an invented class for cohesion, e.g. a persistence storage class), Indirection (an intermediate object to decouple), Protected Variations (wrap points of change behind stable interfaces).
• GoF design patterns (Gang of Four, 23 patterns) in three groups: creational (Singleton, Factory Method, Abstract Factory, Builder, Prototype), structural (Adapter, Facade, Composite, Decorator, Proxy, Bridge, Flyweight), behavioural (Observer, Strategy, Command, State, Template Method, Iterator, etc.).

Determining visibility

• For object A to send a message to B, B must be visible to A. Four kinds:
  1. Attribute visibility: B is an attribute of A — permanent, most common.
  2. Parameter visibility: B is passed as a parameter to a method of A — temporary.
  3. Local visibility: B is a local variable in a method of A (e.g. returned by another call or newly created) — temporary.
  4. Global visibility: B is globally accessible (e.g. via a Singleton) — permanent, least desirable.
• Parameter and local visibility are often converted to attribute visibility when the link must persist.

Design class diagram (DCD)

• Shows software classes with attributes and methods, attribute types, navigability arrows on associations (direction of attribute visibility), dependency lines (dashed arrows) for non-attribute visibility, interfaces and their realisation, and multiplicities.
• Built from the interaction diagrams: every message received by an object becomes a method in its class; collaborators reached by attribute visibility become associations with navigability.
• Visibility markers: + public, - private, # protected, ~ package. Static members underlined; abstract in italics.
• Generally omit trivial get/set methods and constructors (create).

Domain model	Design class diagram
Conceptual classes (real world)	Software classes
No methods	Methods included
Associations without navigability	Navigability arrows
Analysis artefact	Design artefact

High-yield points

• GRASP has nine patterns: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.
• Four visibilities: attribute, parameter, local, global.
• A DCD shows methods and navigability; a domain model shows neither.
• Collaboration diagrams order messages by numbers (1, 1.1, 1.2).
• GoF: 23 patterns — creational, structural, behavioural.

Worked example

In a POS system, who should (a) compute the sale total, (b) create a SalesLineItem, (c) first receive enterItem() from the UI?

1. Sale knows all its line items → Information Expert → Sale computes the total.
2. Sale contains SalesLineItems → Creator → Sale creates them.
3. A non-UI object such as Register (façade) or a ProcessSaleHandler → Controller.

Exam tips

• "Assign the responsibility to the class with the information" = Information Expert.
• The controller is the first object beyond the UI layer that receives a system operation.
• Navigability arrows appear in a DCD, not in a domain model.
• Of the four visibilities, attribute visibility is the most common and global the least preferred.
• In a collaboration diagram the sequence is shown by message numbers; in a sequence diagram by vertical position.

Exam-style questions

From Calmon's question bank, which has 25 questions on this topic.

1. What is the main purpose of elaborating use cases in object-oriented analysis and design?

• A. To describe the detailed sequence of actor–system interactions, including alternative and exceptional flows
• B. To write the source code for each class
• C. To select the hardware platform for deployment
• D. To design the database indexes

Answer: A. Elaborating a use case expands it into a detailed description of the flow of events between actors and the system, including alternative and exception scenarios.

2. What is the purpose of determining visibility in object-oriented design?

• A. To identify the actors and their interactions with the system
• B. To determine which objects can see or reference other objects so they can send them messages
• C. To identify the classes and their relationships
• D. To decide the programming language for implementation

Answer: B. Visibility is the ability of one object to see or hold a reference to another; it must be established before one object can send a message to another.

Practise ACtE08 questions →