Designing a System of Classes

Form groups of three or four people. You should start each group activity by introducing yourself to each member of the group. You may also want to choose one person to write down the group's discussion on the provided index cards as you go.

This project is intended to help you to learn to design and represent a program without worrying about exactly how it will be implemented. It is presented in parts to give you an understanding of how similar abstractions can run through programs in different domains. Along the way you should learn to think of the problem domain as separate from the solution domain.

There are three parts to this activity:

Describing a Design

Your group will attempt to describe how a simulation of a complex system such as a restaurant, shipyard, or business elevator service works. Your description should be detailed enough so that that others can follow it as if they were going to make their own. In particular, focus on determining the important parts of the system and how they would need to communicate to make the system as a whole work. Once you have a design that you think is sufficient, you should create several test cases and hand-simulate them to verify that all system components work as expected. 

You may be asked to demonstrate how your system works in front of the class.

Things to think about

Any complex system is made up of interacting parts (each of which may itself be viewed as a system of parts, etc.). Often, you do not need to think about how these parts work together. For example, to drive a car all you need to think about is the steering wheel, gear shift, and pedals. However, when something breaks, or if you want to maintain your own car, you must learn about how the parts (engine, wheels, and gas tank) interact to make the system (car) work. You must also think about these details in order to be able to create a model of a system within the computer (i.e., a program).

In order to describe a complex system, how do you write it down so that you can be sure you have a good enough understanding to program it? What do you talk about or show, to convey your design? While your program is the ultimate resource and necessary for the computer to simulate your system, it is often not a good way to determine if you are on the right track accurately and quickly. Instead, you need a more concise way to present your design at a variety of levels. A good design presentation will consist of the following things:

  1. The name of the key components in the system.
  2. The purpose, basic function, or main responsibility of each component.
  3. A drawing of the key communication paths between each components and what is communicated.
  4. A list of the services provided by the system and which component will handle each service.
  5. The sequence in which the key components in the system are called upon fulfill their basic function in response to a service request.

For this exercise, you are going to use CRC cards to describe your design. A CRC card is an index card, or small piece of paper, that lists the Component, its Responsibilities, and its Collaborators. The first describes its name and purpose (briefly) within the system. Next, a list of its responsibilities, or what service it provides within the system. And finally, those components that it collaborates with to complete its responsibilities. A single CRC card should be made for each component in your system. For example, a CRC card might look like the following:

These note cards serve to identify what role this part plays in the complete system.  They will also serve as your "script" when your group role plays your system. So any service that your system might supply (and that I may ask you to do in front of the class) needs to be addressed one one of these note cards. Additionally, you may need to pass some information between these components. This may be physical information, like a plate of food, or less tangible data like a time or place. These latter might be written on an index card.

To test your design, you should create several task scenarios that demonstrate how the system would work to complete the given task. For each of these scenarios, each person in the group should "be" one or more classes in your design. This means you should take the CRC card representing your card and try to act like that class should act during program execution. In playing this role, it is important to be extremely literal in your interpretation of the class' responsibilities. One good way to "get into character" is to pretend that your class is a company that is trying to be as profitable as possible. To be profitable, the company must be as accommodating as possible to its clients (collaborators) while at the same time doing as little as possible (i.e., delegating work to other companies (classes)). As you play the role of your class, try to determine whether the work your class is doing is appropriate or should be the responsibility of another class.

When you have successfully completed a scenario to your group's satisfaction, draw the interactions of your classes on a separate piece of paper. Your diagram does not have to be fancy, but should show which class called what to complete the scenario.

Finding Abstractions

The key to any sufficiently complex design is to identify key abstractions within the system being modeled. Partner with another group that designed a system different than yours and compare your designs.What common abstractions, if any, can your groups find? Would it be possible to write a generic simulator that handled all three examples?

Reflection

Finally, individually reflect upon both of your group's experience and post your reflection on your course web page:

Comments?