Design Problem


For this exercise each student will create a very high-level design of a software product. The design will be presented as a single UML diagram showing the overall class structure of the system. The diagram should contain only class names – no state or methods – and the relationships among the classes (inheritance, association, aggregation, and possibly cardinality and role labels). A separate section of the document should give brief (1-2 sentence max.) descriptions of the responsibilities for each class. The total document size, including diagrams, must not exceed 3 pages.

Feel free to work with each other during the remainder of the first class and before the second class to develop ideas and strategies. However, each individual is responsible for submitting in a hard copy his or her own design sketch at the start of the second class. This sketch will contribute 5% to your final grade. Students who make a good faith effort to develop a robust design can expect to receive 4 or 5 points, even if the design itself is suboptimal. The goal is to start students on the path to reflecting about design at a higher level than individual classes and methods.

The second class will be divided into three sub-sections. In the first sub-section, small groups (3-4 students each) will quickly sketch consensus designs that incorporate the best aspects of their individual designs. Since you will have to discuss your individual design with your team be sure to have a second hard copy to take into the team session. In the second sub-section, several teams will present their sketches to the class as a whole (5-10 minutes per presentation). In the final sub-section, we revisit the problem and the designs to show how patterns might make it easier to create, discuss, and evaluate designs.

The Problem - Automobile Maintenance and Diagnosis System (AMDS)

You are a member of a software design team working for a major multi-national automobile manufacturer. Your team is developing a software program that assists a mechanic in performing standard matintenance and problem diagnosis on a new line of automobiles. These automobiles contain advanced electronics that place them into a class of vehicle known as "drive-by-wire". Except for a mechanical emergency brake, there is no direct mechanical connection between the driver's input and the drivetrain of the car. All driver actions are input signals to the car's central computer which then sends commands to the engine, transmission, brake, etc. controllers.


  1. The AMDS will support use by one or more mechanics working on multiple automobiles. At any given time there will only be one mechanic working on one car however.
  2. The AMDS will provide the ability to keep track of all work done on an automobile. Work performed on a vehicle is described as individual maintenance tasks with several tasks making one maintenance entry.
  3. The AMDS will support a variety of maintenance tasks such as tune-up, wheel alignment, tire rotation, oil change, etc. Each of these tasks have some elements in common such as the average time for completion, the actual time, a list of needed parts. There are also some activities specific to each task such as a set of instructions for performing the task.
  4. The AMDS will allow the mechanic to access standard maintenance schedules from the automobile manufacturer's website. These schedules can be used as the basis for a maintenance entry.
  5. The user will control the AMDS from a standard graphical user interface. There is also a handheld control unit (HCU) that the mechanic can use to control the AMDS while standing next to the vehicle. The HCU is directly connected to the computer running the AMDS.
  6. The AMDS connects to the automobile's central computer via a pod connection. There are different pods for different cars. The AMDS can detect when a new pod is attached to the system. If an internet connection is available the AMDS will automatically connect to the automobile manufacturer's website to download the appropriate profile information for the pod that was just connected. The AMDS interprets this profile information. Based on this information the AMDS is able to interface with the new pod and provide an appropriate user interface for that particular pod.
  7. The AMDS will use an emissions sensor to read exhaust gas emissions from the car. This sensor is directly connected to the computer running the AMDS.
  8. The AMDS will be able to control the car's engine, transmission and most other car components through the pod. This will allow different test sequences to be run.
  9. The AMDS will allow the mechanic to define custom test sequences. The mechanic will build the test sequence from individual test step building blocks. Pre-defined and custom test sequences can be used as a test step in another test sequence.
  10. The AMDS will allow the mechanic to specify data to be captured while a test is running. Data such as engine speed, emission levels, fuel economy along with a number of other data points can be collected. The AMDS will provide for the real-time display of multiple data streams on a plot. It is expected that some of the data will be noisy. The mechanic can choose any one of several smoothing algorithms to pre-process the data before plotting.
  11. The AMDS will allow results of tests to be stored for later recall and plotting. As test data from multiple tests is gathered the mechanic can do statistical comparisons on the data.

Discussion Question

There is a discussion forum on the myCourses site. In that forum contribute to a discussion about this system concerning the following issues. You can discuss one or more of this issues but try to use separate threads for the different issues unless you see a connection between them.


You have neither enough time nor enough information to do a complete design for this system. You are to do a first-draft of a design that covers the requirements specified above. There will be many details that you will not be able to specify. At this stage that is fine. You will need to learn how to work at different levels of abstraction based on the detail needed and the information that is available to you.

Revision: $Revision: 1.3 $, $Date: 2005/03/09 02:51:28 $