Medium-Scale Design

This recitation also deals with the system described in recitation 4. You are hired to design the software, starting from a conceptual object model which is given to you in diagram and textual form (i.e., do not use the model you developed in recitation 4).

• Choose the classes that will need to be written, and draw a code object model to represent the structure of the system as it will be implemented.
• Discuss the likely dependencies between classes (for example, will one class have instance variables or methods with arguments from another type). Draw a Module Dependency Diagram to represent this.
• Suggest a plan for writing and testing the software, given two programmers. That is, decide how to divide responsability for the classes between the programmers, propose an order for coding, and deal with any dependencies in testing (perhaps by proposing stubs or test harnesses).
• If you have time, give the specification for each class.

The conceptual object model has the following domains of objects

• Machine, each element is a single piece of equipment such as a particular Nautilus machine
• Kind, each element is a sort of equipment (eg Nautilus)
• Person, each element is a human who can use the gym equipment

• WorkingMachine and BrokenMachine are a partition of Machine. The partition is not static (that is, a machine can change between the two subsets).
• RepairableKind and ThrowAwayKind are a static partition of Kind; a machine which is an instance of a ThrowAwayKind is simply discarded when it breaks, either because it can't be fixed, or because it is not economically worth the effort of fixing it (a jump-rope might be an example).
• Staff and Member are disjoint static subsets of Person. Staff contains the people who are employed by the gym (are are therefore automatically entitled to use the equipment). Member contains the people who have taken out membership, either for a year or for life. Note that some users are neither staff nor members (e.g. they walked in from the street).
• LifeMember is a subset of Member.

• hasKind relates a Machine to the Kind that it is an instance of. Each Machine has a fixed single Kind. There may be zero or more Machines related to a Kind.
• using relates a Person to a WorkingMachine if the person is currently exercising with the machine. The multiplicity is zero or one person to a machine, and zero or more machines to a person.
• fixing relates a Staff to a BrokenMachine if the staff member is currently fixing the machine. The multiplicity is zero or more staff to a machine, and zero or more machines to a staff.
• canFix relates a Staff to a RepairableKind of equipment, if the staff has the training needed to repair broken instances of the Kind. The multiplicities are zero or more on both ends of the relation.
• waitingFor relates a Member to a Kind if the Member has priority to use this sort of machine as soon as one becomes available. A Member can wait for zero or more Kinds, and a Kind may have zero or more Members waiting for it. Note that we do not record requests by non-member customers to have priority in waiting.

• when a Staff is fixing a BrokenMachine, the Machine hasKind a RepairableKind and the Staff canFix that RepairableKind.
• a LifeMember can't change to belong to a different subset of Person (however, LifeMember is not a static subset, because a year-by-year member can become a lifemember).