CS 3050

Object Oriented Analysis and Design

Fall Semester 2005

DESIGN GROUP PROJECT

Analysis and Design using CRC Modeling

PART I – Finding Candidate Classes

In this part of the project you will explore the process of finding classes/objects as described in the lectures. You will complete this lab with other members of a working group. You will be assessed by the other team members regarding your participation and contributions. This input will be reflected in your overall grade for the project.

Scenario: Your team has been delivered a requirements specification for an automated teller machine design. Analyze the specification (given below) with your team members and use the techniques discussed in class to come up with a list of viable candidate classes. In addition, use the list to create hierarchies of related classes, indicating superclasses and subclasses. Your team should produce:

a) CRC cards showing class names and any related super- or subclasses. On the back of each card, justify each of these classes by adding a short phrase describing the purpose of each class.

b) Gen/spec diagrams detailing any hierarchies you have deduced.

The object-oriented approach may be described by four primary stages in the decomposition process:

1. Brainstorming

Review brainstorming principles at the beginning of the meeting to remind everyone that this is a group activity and personal style should be put aside. State specific session objectives such as: “Today we want to come up with a list of candidate classes for the student project.” Circle the nouns and underline the verbs in the requirements specification. The nouns represent candidate classes and the verbs represent potential operations. Use a round-robin technique to allow the group to proceed at an even tempo but give people enough time to think. A facilitator should keep the discussion on target, and a scribe should take notes. The brainstorming stops when each person in the group has to “pass” because he or she cannot think of another class to suggest.

2. Filtering

Discuss the classes. Take the tentative list of classes and determine which are the core classes in the problem solution. Identify duplicate classes. Eliminate classes that don’t pertain to the problem domain. Determine a final list of classes. Record class names on CRC cards.

3. Scenarios

The goal of this phase is to assign responsibilities to each class. Responsibilities are the tasks that each class must perform, and are eventually implemented as subroutines. Focus only on what the tasks are, not how they will be implemented. The team should use play acting to test different scenarios. Each member of the team plays the role of one of the classes. Scenarios are “what if” scripts that allow participants to act out different situations. When a class has been sent a message, the actor holds up the CRC card and responds to the message, sending messages to others as needed. As the scripts are being acted out, missing responsibilities are unearthed and unneeded responsibilities are detected. Sometimes the need for new classes surfaces. The output from this phase is a set of responsibilities and collaborations, each of which should be recorded on the appropriate CRC cards.

4. Responsibility Algorithms

Eventually, the algorithms must be written for the responsibilities. Because of the process of focusing on data rather than actions in the object-oriented view of design, the algorithms for carrying out responsibilities tend to be fairly short. Thus, the top-down method of designing an algorithm is usually appropriate for designing responsibility algorithms.

Automated Teller Machine Requirements Specification

An automated teller machine (ATM) is a machine through which bank customers can perform a number of the most common financial transactions. The machine consists of a display screen, a bank card reader, numeric and special input keys, a money dispenser slot, a deposit slot and a receipt printer. These elements are arranged as shown in the figure below:

When the machine is idle, a greeting message is displayed. The keys and deposit slot will remain inactive until a bank card has been entered.

When a bank card is inserted, the card reader attempts to read it. If the card cannot be read, the user is informed that the card is unreadable, and the card is ejected.

If the card is readable, the user is asked to enter a personal identification number (PIN). The user is given feedback as to the number of digits entered at the numeric keypad, but not the specific digits entered. If the PIN is entered correctly, the user is shown the main menu (described below). Otherwise, the user is given up to two additional chances to enter the PIN correctly. Failure to do so on the third try causes the machine to keep the bank card. The user can retrieve the card only by dealing directly with an authorized bank employee.

The main menu contains a list of the transactions that can be performed. These transactions are:

· Deposit funds to an account

· Withdraw funds from an account

· Transfer funds from one account to another

· Query the balance of any account

The user can select a transaction and specify all relevant information. When a transaction has been completed, the system returns to the main menu.

At any time after reaching the main menu and before finishing a transaction (including before selecting a transaction), the user may press the cancel key. The transaction being specified (if there is one) is canceled, the user’s card is returned, the reciept of all transactions is printed, and the machine once again becomes idle.

If a deposit transaction is selected, the user is asked to specify the account to which the funds are to be deposited and the amount of the deposit, and is asked to insert a deposit envelope.

If a withdrawal transaction is selected, the user is asked to specify the account from which funds are to be withdrawn and the amount of the withdrawal. If the account contains sufficient funds, the funds are given to the user through the cash dispenser.

If a transfer of funds is selected, the user is asked to specify the account from which the funds are to be withdrawn, the account to which the funds are to be deposited, and the amount of the transfer. If sufficient funds exist, the transfer is made.

If a balance inquiry is selected, the user is asked to specify the account whose balance is requested. The balance is not displayed, but is printed on the receipt.

Criteria Checklist for Finding Classes/Objects

1. Use Requirements Specification.

- No requirement specification? (Write your own.)

2. Look for noun phrases

- Obvious classes/objects

- Obvious nonsense

- Don’t know???

3. Model physical objects.

4. Model conceptual entities that form a cohesive abstraction.

5. If more than one word is used for the same concept, choose the one that is most meaningful in terms of the rest of your system.

6. Be wary of adjectives. Does it suggest a different kind of object, a different use of the same object, or is it totally irrelevant? Does the object represented by the noun behave differently when the adjective is applied to it?

7. Be wary of sentences in the passive voice. Recast the sentence in the active voice. Is it masking a subject that might be a class required by your application, or is it masking nothing of importance?

8. Model categories of classes. These may become superclasses later.

9. Model known interfaces to the outside world, such as the user interface, or operating environment interfaces.

10.Model the values of attributes of objects, but not the attributes themselves.

PART II – Identifying Responsibilities

Continue your analysis of the Automated Teller Machine described in Part I. Use the guidelines and suggestions discussed in class to assign responsibilities to the candidate classes derived in the earlier part of the project. You will complete this project with other members of a working group.

At the end of this part of the analysis, your team should produce:

a) CRC cards from Part I with responsibilities indicated on the appropriate parts of the card.

b) Any revisions or additions to the Gen/spec diagrams from Part I.

Criteria Checklist for Finding Responsibilities

1. Use Requirements Specification.

2. List Verbs.

3. Note where information storage is mentioned.

- A composite and its parts usually retain information about each other.

4. Look at previously identified classes.

- Name of class

- Statement of purpose

5. Evenly distribute system intelligence.

6. State responsibilities as generally as possible.

- Can you assign the responsibility to a superclass?

7. Keep behavior with related information.

8. Keep information about one thing in one place.

9. Share responsibilities

10. Perform system walk-throughs

PART III – Finding Collaborations

Continue your analysis of the Automated Teller Machine. Use the guidelines and suggestions discussed in class to assign collaborations to the candidate classes derived in the earlier parts of the project. You will complete this project with other members of a working group.

At the end of this part of the analysis, your team should submit:

a) CRC cards from Parts I & II with collaborations indicated on the appropriate parts of the card.

b) Any revisions or additions to the Gen/spec diagrams from Parts I & II.

Criteria Checklist for Finding Collaborations

1. Analyze interactions of each class.

2. Examine responsibilities for dependencies.

3. Trace the fulfillment of a responsibility.

4. For each responsibility, ask

- Is the class capable of fulfilling this responsibility itself?

- If not, what does it need?

- From what other class can it acquire what it needs?

5. For each class, ask

- What does this class do or know?

- What other classes need the result or information?

6. A class that collaborates with no other classes, either as a client or a server, should be discarded.

7. Composite classes typically collaborate with its parts.

Your Design Group should prepare the following:

I. A written report containing the following sections:

· An abstract summarizing the problem statement.

· A description in English of the proposed solution to the problem, stating initial conditions, assumptions, and how these data were deduced.

· The CRC cards generated from your design complete with class name, responsibilities, collaborations, and purpose clearly indicated.

· Any Gen/Spec or Whole/Part Hierarchy diagrams formulated from the analysis with a description of how each one is important in fulfilling the design requirements.

· A comprehensive summary with concluding comments about the key issues the design group confronted in solving the software design.

II. A detailed presentation in class that explains your strategies and end-result in solving the computing problem. This presentation may include a few overheads or PowerPoint slides as necessary.