CSC/ECE 517 Fall 2011/ch4 5a sp

Introduction to Object Oriented Design(OOD)

This page serves as a knowledge source for understanding the concepts covered in Lecture14- Introduction to Object Oriented Design(OOD).

Overview

Lecture 14 <ref name="CSC517">OOD, CSC 517 Lecture14</ref> of CSC 517 covered various aspects of the object oriented design including the basics of OOD principles along with the design criteria and the Class Responsibility Collaboration card tool.

Object-oriented design can be defined as the process of planning a 'system of interacting objects' for the purpose of solving a software problem. It is one approach to software design that revolves around the basic entity called object. An object contains data and procedures grouped together to represent an entity(class). Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis.

Basic Object Oriented Concepts

The five basic concepts of object-oriented design are the implementation level features that are built into the programming language. They can be considered as the general vocabulary required to implement an object oriented design solution <ref name="OOD vocabulary">OOD Vocabulary, OOD Vocabulary</ref>. These terms are explained in brief:

• Object: A class is a tight coupling or association of data structures with the methods or functions that act on the data. An object is an instance of the class serving a separate function. An object is defined by its properties.

• Information Hiding/Encapsulation: The ability to protect some components of the object from external entities i.e. protecting parts of the program from extensive modification if the design decision is changed. This is achieved by language keywords to enable a variable to be declared as private or protected to the owning class.

• Inheritance: inheritance is a way to reuse code of existing objects and thus ability for a class to extend or override functionality of another class. Inheritance is realized by establishing a subtype from an existing object, or both, depending upon programming language support.

• Polymorphism: The ability to replace an object with its subobjects. The ability of an object-variable to contain, not only that object, but also all of its subobjects.

• Interface: Interface can be defined as the ability to defer the implementation of a method or the process to define the functions or methods signatures without implementing them.

Criteria for Elegant Software Design

Listed below are the different criteria for elegant software design. There are nine different design considerations, out of which the first five address correctness of the software and the rest consider the performance.

Usability: Usability can be measured by the ease of use for the client.

Completeness: A software program/application is complete if it solves all the client needs.

Robustness: A good design is one that can deal with unusual situations gracefully and avoid crashing.

Efficiency: The application performs the necessary computations in a reasonable amount of time.

Scalability: An application is scalable if it performs correctly and efficiently when the problems grow in size by several orders of magnitude.

Readability: If it is easy for another programmer to read and understand the design and code, the design is readable.

Modifiability: If the software can easily be enhanced or restricted by adding new features or removing old features without breaking existing code, the design is modifiable.

Reusability: Resuability checks the ability to be reused in another completely different setting.

Simplicity: The simplicity criteria check if the design and/or the implementation unnecessarily complex.

Design Concepts

Listed below are the major components for building a design solution for a problem:

• Defining objects, creating class diagram from conceptual models and map the entities to classes.

• Identifying attributes for each class/entity.

• Use design patterns <ref name="Design Patterns">Design Patterns Elements of Reusable Object Oriented Software by Erich Gamma</ref> to solve a problem that can be used in many different situations and/or applications.

• Identifying persistent objects i.e. to know objects that last longer than a single runtime.

• Identify the application framework to take advantage of the existing code and reuse whatever possible.

Design Principles

Listed below are the main principles that need to be followed for building an effective design solution<ref name="Design Principles">Object Oriented Design Principles</ref>:

• Open Close Principle: This principle states that software entities like classes, modules and functions should be open for extension but closed for modifications.

• Dependency Inversion Principle: This principle states that high-level modules should not depend on low-level modules and both should depend on abstractions.

• Interface Segregation Principle: This principle states that clients should not be forced to depend upon interfaces that they do not use.

• Single Responsibility Principle: This principle states that a class should have only reason to change.

• Liskov's Substitution Principle: This principle states that derived types must be completely substitutable for their base types.

OOD: The CRC Method

Class-Responsibility-Collaboration card is a very useful tool for software design that determine the classes needed along with the types of interactions.

CRC cards are created from index cards on which are written:

1. The class name
2. Its Super and Sub classes (if applicable)
3. The responsibilities of the class.
4. The names of other classes with which the class will collaborate to fulfill its responsibilities.
5. Author

The use of small card minimizes the complexity of the design. It forces the designer to refrain from giving the class too many responsibilities. These cards are portable and thus can easily be laid out on a table and re-arranged while discussing the design with other people.

A specification for the program being designed is studied and then the cards that need to be created are designed. The cards contain the class names(generally nouns) along with the responsibilities(verbs) and the collaborators associated with the class. When choosing classes, we need to make sure that the class name,

1. is a singular noun,
2. does not really have the same functionality as some other class,
3. is not simply a primitive type,(because u need not write code for primitive types)

Example 1: Flight reservation system

Requirements for the Flight Reservation System

• The mission is to allow round-trip airline tickets to be bought over the Web.
  
• Each customer specifies an origination airport, a destination airport, and dates for outbound and return flights.
  
• The customer reserves one outbound flight and one return flight from a menu presented by the system.
  
• Each choice that the system presents consists of one or more flight segments (there may be a change of planes).
  
• The customer may buy tickets for one or more passengers.
  
• No more tickets can be sold for a flight than there are seats on the plane.
  
• Each passenger is assigned to a specific seat.
  
• The system calculates the total cost of the tickets by adding the cost of the individual segments.
  
• If dissatisfied with the cost, the customer may select alternate flights.
  
• After a customer has bought a ticket, (s)he will be e-mailed a confirmation
  

Some class names for the present scenario are

Customer
Flight
Airport
Segment
Ticket
Cost

Some nouns that are not classes are

Seats
Alternate Flights
Outbound Flight
Inbound Flight

Some of the responsibilities of the Customer class and their collaborators are

• to make payment(R) shopping cart(C)
• to choose the flight(R) Flight Segment(C)

Example 2: Address Book

Requirements Statements
The software to be designed is a program that can be used to maintain an address book. An address book holds a collection of entries, each recording a person's first and last names, address, city, state, zip, and phone number.

It must be possible to add a new person to an address book, to edit existing information about a person (except the person's name), and to delete a person. It must be possible to sort the entries in the address book alphabetically by last name (with ties broken by first name if necessary), or by ZIP code (with ties broken by name if necessary). It must be possible to print out all the entries in the address book in "mailing label" format.

It must be possible to create a new address book, to open a disk file containing an existing address book to close an address book, and to save an address book to a disk file, using standard New, Open, Close, Save and Save As ... File menu options. The program's File menu will also have a Quit option to allow closing all open address books and terminating the program.

The initial requirements call for the program to only be able to work with a single address book at a time; therefore, if the user chooses the New or Open menu option, any current address book will be closed before creating/opening a new one. A later extension might allow for multiple address books to be open, each with its own window which can be closed separately, with closing the last open window resulting in terminating the program. In this case, New and Open will result in creating a new window, without affecting the current window.

The program will keep track of whether any changes have been made to an address book since it was last saved, and will offer the user the opportunity to save changes when an address book is closed either explicitly or as a result of choosing to create/open another or to quit the program.

The program will keep track of the file that the current address book was read from or most recently saved to, will display the file's name as the title of the main window, and will use that file when executing the Save option. When a New address book is initially created, its window will be titled "Untitled", and a Save operation will be converted to Save As ... - i.e. the user will be required to specify a file.<ref name="Address Book Example">Address Book Example</ref>

The class names for the present scenario are

User
AddressBook
FileSystem
AddressBookController
Person
AddressBookGUI

The responsibilities of some of the classes and their collaborators are
Person
Responsibilities

• Create a new object,given an individual's name,address,city,state,ZIP, and phone
  
• Furnish the individual's first name
  
• Furnish the individual's last name
  
• Furnish the individual's address
  
• Update the stored information(except the name) about an individual
  

There are no collaborators for this class

File System
Responsibilities
Read a stored address book from a file,given its file name
Save an adddress book to a file,given its file name

The collaborator for both the responsibilities is
AddressBook

Example 3: Course Registration

Requirements for the Course Registration System

• The mission is to automate registration of students for courses at a university.
  
• Each student takes one or more courses, which are identified by name and course number.
  
• Each course is worth one or more credit hours.
  
• A student can register for up to 21 credit hours.
  
• For each course that is taught, the students are placed into sections, which may meet at different times and be taught by different instructors.
  
• If more than 50 students want to take the same class, another section will be added.
  
• If fewer than 5 students register for a section, it will be canceled.
  
• If no instructor can be persuaded (or hired) to teach a class, it will be canceled.
  
• Students may specify alternate courses or sections, in case of a time conflict, or if their first-choice class is canceled.
  
• After a student has registered for courses, (s)he will be e-mailed a class schedule.
  

Some class names for the present scenario are

Instructor
Student
schedule
class
Course

Some of the responsibilities of the Customer class and their collaborators are

Instructor(C) offer course(sections)(R)

Student(C) takesCourse(R) Course(Colloborators)

Example 4: Other Example

Requirements for the bus navigator system:

• The mission is to allow students to plan trips around NCSU and Raleigh by bus.
  
• Each rider specifies an origination stop and a destination stop .
  
• The system presents a list of departure times, arrival times, and transfer points, and a map of the trip.
  
• Each item on the list consists of one or more of trip segments.
  
• Each trip segment consists of a departure point and time, and an arrival point and time.
  
• If it would significantly reduce the time of the trip, the system may suggest walking between two nearby stops.
  
• Each segment may be on a Wolfline bus, a CAT bus, or a TTA bus.
  
• Each bus has a schedule, which is a set of trips, with each trip consisting of a set of stops and times.
  
• The fare is 0 on a Wolfline bus, $1 on a CAT bus, and $2 ($2.50 for express) on a TTA bus.
  
• The system calculates the total cost of the trip by adding the cost of the individual segments.
  

The class names for the present scenario are
stop
map
segment
walk
bus
Trip

The responsibilities of the Tripclasse and their collaborators are
Know your Stops(R) Know your Stopping Times(R)

Stop(C)

References

<references />