Object-oriented analysis and design

What are some of the basic principles of object-oriented software design?  Good analysis and design are an essential aspect of software development.  Before we can write any programs, we first have to decide what to write.  In the object-oriented world, a big part of this is to decide what the objects are.  Some questions the designer has to answer:

• How to divide a problem into a set of interacting objects; that is, identify the classes needed to solve the problem
• What the behavior of each object should be
• What the interface to each object should be
• How each object is related to other objects
• When to use inheritance and when to use composition in defining classes

These are not easy problems to solve.  There are entire books and courses on the subject of software design in general and object-oriented design in particular.  There are no right or wrong answers to these questions, but many tools and methodologies have been developed to help answer them.  We'll look at a few of them:

• CRC cards
• UML -- the Unified Modeling Language
• use case diagrams
• sequence diagrams
• class diagrams

We first give an overview of a basic design methodology, based on three steps:  plan, build, and release.

1.    Planning, that is, analysis and design

• analysis -- Identify the problem to be solved.  What are the requirements of the software system?  What objects (classes) are required?  What are their responsibilities?  How should they interact with each other?  Identify appropriate uses of inheritance.
• design -- Refine the classes identified in the analysis phase.  Identify implementation classes.  Identify appropriate uses of existing classes (like the Java API).  Specify the attributes and methods of each class.  Decide on specific data structures and algorithms to use.

2.    Build

• Code
• Debug
• Unit test

3.    Release

• Integration test
• Learn
• Maintain

Object-oriented analysis

1. Object discovery


• What are the objects?
• Look for nouns and verbs in the problem description.  Nouns --> objects.  Verbs --> methods.
• Look at roles played by people who will interact with the system.
• Look at events that must be recorded and remembered by the system.


2. Evaluate candidate objects


• Identify use of inheritance or composition.  Use the "is-a", "has-a" test.
• Can classes be combined?  Smaller is usually better.
• An object must do something to justify its existence; that is, it should have some methods.
• An object usually has some instance variables, but not always.  Consider, for example the Expression Manager of the Calculator program.
• All attributes and methods should apply to all members of the class.  If this is not the case, it may indicate a place to use subclassing.


3. Discover object attributes


• An object asks "What state information do I need to keep over time (i.e., between calls) in order to carry out my responsibilities?"


4. Discover object operations


• An object asks "What services must I provide to other objects to fulfill my responsibilities?"

UML Use Cases

A use case describes a group of scenarios -- that is, sequences of steps representing interactions between actors (users) and the system.

example  Consider a software system to be developed for a library.  One use case is the borrowing of a book by a patron.  One scenario for this use case would consist of the following steps:

1. Patron chooses a book to borrow and hands it to a librarian.
2. Librarian identifies the patron in the system.
3. Librarian identifies the book in the system.
4. Librarian lends the book to the patron.
5. The borrowing is recorded by the system.

A single use case may be associated with several scenarios.  In this example, we might have different scenarios if the book is a reference book which may not be checked out, or if the librarian discovers that the patron already has several overdue books checked out.

Use cases may be used iteratively, adding levels of detail at each stage.  The first stage might be to name the use cases, then outline a typical scenario for it.  Later, additional or more detailed scenarios may be added.  The objective is to identify actors, objects, and interactions between them.

UML defines a graphical representation for use cases.  A use case diagram shows the actors and the use cases.

• Actors are represented with stick figures.
• Use cases are represented with ovals.
• An actor is connected to a use case if the actor is involved in the use case.
• Relationships between use cases are indicated by arrows.  Two types of relationship exist between use cases:
• The uses relationship occurs when there is some common behavior that exists in multiple use cases that can be factored out into a separate use case (e.g., logging in to a terminal).
• The extends relationship is used when one use case is similar to another but adds some additional steps.

CRC cards

CRC cards were developed as a design aid by Kent Beck and Ward Cunningham.  CRC stands for Class-Responsibility-Collaboration.  The CRC card methodology uses index cards to identify the classes in a system.  Each card contains a class name at the top of the card.  On the left side of the card, the responsibilities of the class are listed.  These should be short, concise descriptions of what the class knows about, and what it does with that information.  On the right side of the card, the collaborators of the class are listed.  These are the classes which provide information or services to the class at hand.  These are the classes that this class uses, not the ones that use it.

CRC cards are intended to be used in sessions among a group of designers.  They are useful for identifying classes and exploring the interactions between them. Cards can be used to walk through various use case scenarios.  Out of the discussion comes an understanding of the system and how it should work.

UML Sequence Diagrams

UML sequence diagrams are used to illustrate the dynamic behavior of a system, by showing the actors and objects which comprise the system and the messages sent between them.  The actors and objects are represented by rectangles, drawn left-to-right across the top of the diagram.  Below each of these actor/objects, the diagram shows a timeline for the actor/object.  A narrow vertical rectangle is used to indicate the lifetime of the object; a dotted line is used to indicate the part of the timeline when the object does not exist.  Between the timeline rectangles, arrows are drawn to indicate messages (method calls and replies) sent between objects.

Here is an example of a sequence diagram for the Calculator program from lab 5:

UML Class Diagrams

A class diagram consists of several classes (represented by rectangles) connected by relationships (represented by lines or arrows).  Different notations are used to indicate different types of relationship (inheritance, collaboration, etc.)

The rectangle representing a class is divided into three parts:  the name of the class, its attributes, and its methods.  Attributes are written in the form "attribute-name : datatype".  Methods are written in the form "method-name(parameter-list) : return datatype".  Visibility of each attribute and method is indicated by a + (public), - (private), or # (protected).  For example, a portion of the Ball class from Ballworld would be diagrammed as follows:





Inheritance is represented with an arrow from child to parent, with an open arrowhead:

Abstract classes are written with their names in italics.  Interfaces are written with the word "<<interface>>" above the name.  When a class implements an interface, a dotted arrow is drawn from the class to the interface:



Aggregation is used when a class is comprised of a group of components in a "part-whole" relationship.  UML models this as a hierarchy with the "whole" class at the top and the "parts" below.  An arrow (with an open diamond as arrowhead) connects the parts to the whole:


The "1"s indicate the multiplicicty of the relationship.  If a laptop had 2 battery packs, that would be indicated with a "2"; "one or more" is represented by "1..*".

A composite is a strong form of aggregation.  Each component in a composite can belong to just one whole.  A composite is indicated by a closed diamond arrowhead.

example  A UML class diagram for part of the Calculator program

Some Design Guidelines

• Get the Big Picture
• Understand the problem
• Think objects
• Encapsulation
• Maximize encapsulation
• Minimize coupling
• Separate the GUI
• Designing Classes
• A Class Needs a Purpose
• Classes vs. Attributes
  
• Composition vs. Inheritance
• Don't Make Classes Too Big
• Inheritance
• Use the Is-A Test
• Move Attributes and Operations as High as Possible (But Not Too High)
• Look for Superclasses
• General Guidelines
• Choose appropriate names
• Don't reinvent the wheel
• Refine the design
• Keep it simple
• Plan for the future