Midterm Sample Solution
Note: As with the other samples, this sample was created with System Architect, a rather expensive and cruddy (but UML compliant) CASE tool available on some CCS-maintained Andrew machines. If you can't get Softera (also pretty cruddy) to work on your machine at home, you might want to give this a try. I know for a fact that it's available on the first three rows of the cluster in Cyert Hall.

Overview: Repair tracking system initial design

This document reflects approximately how I attacked this problem, in step-by-step order.  The notes associated with each problem are part of the solution, and if you were doing a design like this for a real business, you would probably want to present notes such as these with your diagrams.  Again, the emphasis here is on communication and readability more than cleverness of notation.

Problem #1: Top-Level UML Use Case diagram for the repair tracking system

In this system, the Mechanic actor is separated from the Analyst actor to reflect the assumption that the two major operations in this system would be done in different parts of the business by people with different rights.  This diagram has no detail at all on the sub-behaviors of the system, and so only reflects that:

Problem #2: First pass at classes for the repair tracking system

The next step is a first-pass class diagram.  This amounts to identifying the classes in the system and then assigning the given list of data to be tracked as attributes to the classes.  This process will usually cause one of a few sensations:

Problem #3: Preconditions and Postconditions for the two capabilities

Operation: addRepair (Date d, Vehicle v, RepairTask[] t, RepairFacility f, Currency cost, boolean isRoutine, int mileage)
Overview: The Add Repair Event use case occurs when the Mechanic wishes to add record of a repair to a particular car.  The Mechanic selects the task and vehicle from the current store of data.  The date and facility are auto-entered by the GUI.  The system then adds record of the repair(s) that took place.
  • Date must be valid
  • Vehicle, RepairTasks, RepairFacility are objects that already exist
  • cost is non-negative
  • mileage is non-negative and at least as large as any other mileage entry for this vehicle
  • An unmodifiable RepairEvent object is created 
  • It represents the repair event being added by having its attributes set correctly
  • It is associated with the given vehicle, repair tasks, and facility

Operation: printRepairReport (String vehicleMake, String vehicleModel, int year)
Overview: The Print Report use case occurs when the Analyst wishes to print a report of the number and type of repairs that are made to a particular make, model, and year of car, in comparison to other kinds of cars.  (Some of you interpreted "frequency of repair" to mean the repairs made to a single car, which was fine.)  The system then generates the report, changing no data in the system
  • Year must be a valid model year
  • A report is generated of the collective repair records of all cars whose make, model, and year match the specified criteria, or "no data available" is given.
  • The system is not modified in any way.  In other words, this operation is read-only.


Problem #4: Methods and collaborations for the repair tracking system

After writing a bit about what I expected the top-level operations to be able to do, I added them as methods to the system, along with some other methods that seemed necessary to support the work of the top-level methods.  Here is the second-pass class diagram:


These methods call each other as described by the following collaborations:

Note: Here, the variables VIN, description, cost, isRoutine, mileage, and name are pulled from GUI fields.  Date is the current date.  The results of the findVehicle, etc. calls are bound to variables v, t, and f, which are then passed to addRepair.

Note: Here, ma, mo, and y are variables representing the make, model, and year of the car type to be reported on, and are pulled from GUI fields.  The vehicles (if any) that match these descriptions are determined during the call to findVehicles, and then each of those vehicles' history is determined with calls to getRepairs.  The results are then compiled during printRepairReport and used to generate the report.