Object-Oriented Design Process

Page last modified 14:09, 29 Jan 2009 by Joren | Page History

1. Problem to Code
1. 1.1. Analysis
2. 1.2. Design
3. 1.3. Implementation
2. Object and Class Concepts
3. Identifying Classes
4. Identifying Responsibilities
5. Relationships between Classes
1. 5.1. Dependency
2. 5.2. Aggregation
3. 5.3. Inheritance
6. Use Cases
7. CRC Cards
8. UML Diagrams
1. 8.1. Class Diagram
2. 8.2. Sequence Diagram
3. 8.3. State Diagram

1. Problem to Code
1. 1.1. Analysis
2. 1.2. Design
3. 1.3. Implementation
2. Object and Class Concepts
3. Identifying Classes
4. Identifying Responsibilities
5. Relationships between Classes
1. 5.1. Dependency
2. 5.2. Aggregation
3. 5.3. Inheritance
6. Use Cases
7. CRC Cards
8. UML Diagrams
1. 8.1. Class Diagram
2. 8.2. Sequence Diagram
3. 8.3. State Diagram

Problem to Code

The software development process can be broken up in three parts:

Analysis
Design
Implementation

This process however is often not progressed linearly. A program can have many iterations over multiple parts.
Per example; flaws in the design could become apparent during the implementation part.

Analysis

The goal of the analysis phase is a complete description of what the software producs should do.
The result is called a functional specification and should have the following characteristics:

Completely defines the tasks to be performed
Free from internal contradictions
Readable by both experts in the problem domain and by software developers
Reviewable by diverse interested parties
Testable against reality

Design

The goal of Object-Oriented design is the identification of classes, their responsibilities, and the relationships among them.
The result becomes the foundation of the implementation phase, and should consist of the following artifacts:

Textual description of the classes and their most important responsibilities. (CRC Cards)
Diagrams of the relationships among the classes. (UML diagriam)
Diagrams of important usage scenarios.
State diagrams of objects whose behavior is highly state-dependent.

Implementation

The goal of the implementation phase is the programming, testing and deployment of the software product.

Object and Class Concepts

Object: Characterized by its: State, Behavior and Identity.
                    State: The collection of all information held by an object.
                    Behavior: The operations that an object supports.
                    Identity: The characteristic by which 2 objects with the same state and behavior can be told apart. (Eg. Object name or reference)
Class: Objects with the same behavior, and common set of possible states.
Instances: Object belonging to a specific class.    (E.g. My mailbox is an instance of the Mailbox class)

Identifying Classes

To discover classes, look for nouns in the problem description. (E.g. I received mail in my mailbox. Mail & Mailbox could be classes)
However, not all classes should be considered for implementation. Causes can be redundancy or clarity. This is left up to the programmer.
General rules are not to over generalize your classes, and not to over specify them. (E.g. Kitchen-Appliance, Toaster, Blender ; could be Product)

Class names should be nuons in the singular form. Classes can be said to belong to one of the following groups:

Tangible things (E.g. Mail, Mailbox)
Agents (E.g. Scanner, DocumentOperator)
Events and transactions (E.g. MouseEvent)
Users and Roles (E.g. Reviewer, Administrator)
Systems (E.g. MailSystem)
System interfaces and devices (E.g. File)
Foundational classes (E.g. String, Date)

Identifying Responsibilities

To discover responsibilities, look for verbs in the problem description. (E.g. I deleted the message on my voicemail)
Respect the natural layering of abstraction levels. Lowest levels: files, keyboard. Highest level: MailSystem.
The responsibilities of a class should stay at one abstraction level.
(E.g. A MailBox should not concern itself with keystroke handling, low-level, or the initialization of a MailSystem, high-level)

Relationships between Classes

Three types of relationships:

Dependency ("uses")
Aggregation ("has")
Inheritance ("is")

Dependency

A class depends on another class if it manipulates objects of the other class. (E.g. class uses a class)
If a class can perform all of its task without being aware that the other class exists, it doesn't use that class.
It is important to minimize the number of dependency relationships, minimize the coupling between classes.

Aggregation

A class aggregates another if its object contain objects of the other class. (E.g. class has a class)
It is important to track multiplicities in a aggregation.

1 : 1, containing only 1 object.
1 : n, containing n objects.
1 : 0 ... 1/n, containing null to 1 or n objects.

If an class contains a instance field of a very simple type or a foundational type, it is considered a attribute or not aggregation.
The term "very simple type" is interpretable by the programmer.

Inheritance

A class inherits from another if it incorporates the behavior of the other class. (E.g. class is a class)
The more general / parent, class is called the superclass. The more specialized / child, class is the subclass.

Use Cases

A use case lists a sequence of actions that yields a result that is of value to an actor. Example
It should include the variations that describe situations in which the use case could fail, or follow different courses.
Used for analysis.

CRC Cards

CRC: Class Responsibility Collaboration

A CRC card is an index card that describes a class, its high-level responsibilities, and its collaborators. Example 1
Things to look out for when designing:

Omnipotent Classes: Avoid putting all end-responsibilities within one class, thus overburdening the class.
Mission Creep: Class with too many responsibilities. Keep the high level responsibilities down to a maximum of three.
Unrelated responsibilities: A class should represent a coherent concept, with related responsibilities.
Unused responsibilities: Try to keep the responsibilities to a minimum and not add responsibilities that will not be used for the case.
Empty Classes: Classes with no apparent responsibilities should be removed.

Used for design.

UML Diagrams

UML: Unified Modelling Language
A UML diagram illustrates an aspect of an object-oriented design, using a standardized notation.

Class Diagram

A Class diagram shows classes and the relationship among them. Example
In the diagram, classes are drawn as boxes containing the class name. If approriate, they can also contain the attributes and methods of the class.
Class attributes are noted as: attribute : Type . (E.g. text : String )

The connectors to define the relationships between the classes are:

For the "has" relationship, you can also write the multiplicity on the end points of the connection.

any number (0 or more): *
1 or more: 1..*
zero or one: 0..1
exactly one: 1

"One MessageQueue can have any number of Message object"

Sequence Diagram

A sequence diagram shows the time ordering of a sequence of method calls. Example
In UML, underline is used to distinguish object rectangles from class rectangles.
The text in a object rectangle can be made up in three ways:

objectName : ClassName (Full dscription)
objectName (class not specified)
: ClassName (object not specified)

The dashed vertical line that emanates from the object is called the lifeline.
The rectangles along the lifeline are called activation bars. They show when the object has control, executing a method. Self Call Example
If a method creates an object, you can note "«create»" on the arrow to the method. Create Example