How often Domain class diagrams is asked

Where it was asked

• May/Jun 202120 marks
• Oct/Nov 202033 marks

The questions

1. May/Jun 2021, Q5.120 marks

   Consider the following scenario about a small vehicle/car repair shop, which is to be used to answer Question 5.1: The repair shop consists of two offices, an electronic workshop and two repair workshops. The owner (I) or the shop employs many employees, and each employee works only for this shop. A job is done by many employees, and an employee performs many jobs; this many-to-many relationship creates a challenge when analysing working hours, since working hours must be recorded both as information about the employee and as information about the jobs done. Some of the jobs are done by engineers, and an engineer is assigned to many jobs. Engineers are either full-time or part-time. For every engineer the following data must be stored: Engineer number, Engineer name, Professional No, and Tel number. In addition, for full-time engineers an Annual salary is stored, while for part-time engineers an Hourly rate and Hours worked are stored. Using the car repair shop scenario described above, develop a domain class diagram that correctly represents the offices, workshops, employees, jobs, and the full-time and part-time engineers, including all the attributes mentioned (Engineer number, Engineer name, Professional No, Tel number, Annual salary for full-time engineers, and Hourly rate and Hours worked for part-time engineers), along with the relevant relationships and multiplicities between employees and jobs, and engineers and jobs.

2. Oct/Nov 2020, Q4.14 marks

   This question refers to a domain model diagram consisting of three classes. The 'Order' class is connected to the 'Order-History' class via an aggregation relationship (shown with an open diamond on the Order side), and the 'Order-History' class is in turn connected to the 'PaymentType' class via another aggregation relationship (open diamond on the Order-History side). The 'Order' class lists the following attributes: customerID (char), dispatchNo (char), dispatchDate (date), firstName (String), orderDate (date), orderID (char), and surname (char). The 'Order-History' and 'PaymentType' classes are shown without any listed attributes. Looking specifically at the attributes listed under the Order class (customerID, dispatchNo, dispatchDate, firstName, orderDate, orderID and surname), identify and explain what design problem this combination of attributes suggests.

3. Oct/Nov 2020, Q4.211 marks

   This question refers to a domain model diagram consisting of three classes. The 'Order' class is connected to the 'Order-History' class via an aggregation relationship (shown with an open diamond on the Order side), and the 'Order-History' class is in turn connected to the 'PaymentType' class via another aggregation relationship (open diamond on the Order-History side). The 'Order' class lists the following attributes: customerID (char), dispatchNo (char), dispatchDate (date), firstName (String), orderDate (date), orderID (char), and surname (char). The 'Order-History' and 'PaymentType' classes are shown without any listed attributes. Drawing on your understanding of object classes, propose a solution to the problem identified in question 4.1, and redraw the domain model diagram to reflect this solution. You should only use the attributes already given in the original diagram (customerID, dispatchNo, dispatchDate, firstName, orderDate, orderID and surname, plus the Order-History and PaymentType classes), and you may assume reasonable relationships between the classes where needed. A sketch is sufficient.

4. Oct/Nov 2020, Q5.118 marks

   A case study is provided for ICT2622 (Oct/Nov 2020): Drones appear small and self-contained, but must always be kept in pristine condition, so for good maintenance purposes drones may be supplied by many suppliers, and a supplier supplies a drone. Suppliers are divided according to the type of part they specialise in: frames are provided or sold by AllRobot, rotors come from AltiGator, and batteries come from KZNElectrics. All suppliers share the attributes supplier number, name and contact cell number. A drone is described by a drone identification number, its location, and its status. A drone belongs to one pilot, but a pilot may have many drones; some pilots own no drones at all because they are instead involved in training and overseeing drone operations. The drone aviation committee wants to keep a record of the parts used by the drones, modelled as follows: a supplier supplies many parts or items, and an item is supplied by many suppliers. A problem arises when they want to update the inventory, namely whether the item number, available quantity and re-order quantity should be stored in the supplier class or the item class. To resolve this, the designers decided to introduce an inventory class, modelled as an association class, to track this information. The item information includes the item number, item name and its category. Using the drone-supplier case study narrative provided, construct a domain class diagram that correctly represents the entities described (suppliers such as AllRobot, AltiGator and KZNElectrics, drones, pilots, parts/items, and the inventory association class), including their attributes and the relationships and multiplicities between them, worth 18 marks in total.