ooad1-5 Exercise 1: Reading the Bike Shop Diagram ===================================================== shop.class.mmd (Mermaid): classDiagram direction LR class Customer class Bike class RepairJob { +invoice(pricing) int } class JobPart { quantity } class Part class Mechanic class Pricing { <> +price(job) int } class LabourPricing Customer "1" --> "0..*" Bike Bike "1" --> "0..*" RepairJob RepairJob "1" *-- "0..*" JobPart JobPart "*" --> "1" Part RepairJob "*" --> "1" Mechanic LabourPricing ..|> Pricing RepairJob ..> Pricing ANSWERS (a) Deleting a RepairJob deletes its JobParts: the filled diamond (composition) sits at RepairJob, so the job owns them. The Parts are not deleted: JobPart --> Part is a plain association, and a Part is stocked independently of any job. (b) No. The arrow RepairJob --> Mechanic means a job can reach its mechanic; there is no arrow back, so a Mechanic does not hold a list of jobs. To list a mechanic's jobs you would search all jobs, or add a navigable link. (c) No. In "Customer "1" --> "0..*" Bike" the multiplicity next to Customer is 1: every Bike has exactly one Customer. (Read the number at the end you are asking about: how many customers per bike.) (d) "RepairJob ..> Pricing" (dotted, open arrow) is the dependency. RepairJob uses Pricing, here as a parameter of invoice(pricing), but keeps no field of that type. (e) No: Pricing is marked <>, so it has no implementation. You can create LabourPricing, which realises it (dotted line, hollow triangle). WHY THIS WORKS AS AN ANSWER --------------------------- Each answer comes from one feature of the notation: the diamond for lifetime, the arrowhead for navigation, the multiplicity at the near end for "how many", the dotted open arrow for a brief use, and the stereotype for what can be instantiated. The diagram renders correctly; if you render it afterwards you will see the filled diamond on RepairJob's side of the line to JobPart and the dotted arrows described.