Frequently-asked questions »

Question »

Questions

OO class modelling 1 »

OO class modelling 2 »

Data/ Attribute Normalisation »

Fact Gathering »

DFDs and STDs 1 »

DFDs and STDs 2 »

First, it is important to remember to answer each part of the question.  Make it clear which part of the question you are answering by using the question parts indicated (a, b, c and d). It is useful to start each part of your answer on a new page, allowing you to add extra detail after your initial answer. 

• Answer to part a
• Answer to part b

• Answer to part c

• Answer to part d

Part a

A class is a generic description of a set of 'things', each of which share properties in common.

Classes can be shown in a class model which shows the key classes in a system and their interrelationships modelled as associations between classes.

In addition to classes, it is possible to define sub-classes.  A sub-class is a class which represents a slight variation (in terms of attributes, operations and/or associations) between its members and those members of the main class.  For example, if you have the class CUSTOMER, you might have a sub-class called CREDIT CUSTOMER which represents the subset of customers who pay by credit.

Inheritance is where a sub-class is defined, not only in terms of its own attributes, operations and associations, but also inherits, or 'takes on', the properties of the main or parent class.

Inheritance is a powerful property in object oriented modelling, although can be difficult to master.  It enables developers to model the specialisation-generalisation relationship between classes and is effectively a shorthand notation.

Sometimes, when a sub-class inherits the operations of the main class, it is necessary to implement the operation in a different manner to the main parent class.  For example, if the parent class has an operation called 'charge customer' which involves generating an invoice and presenting it for payment, a sub-class describing credit customers may implement the operation 'charge customer' in a different way, by directly debiting the customer's credit account.  This redefinition of the implementation of the 'charge customer' operation is known as operator overloading.

It is important to understand that the redefinition or overloading of an operation should only relate to the different ways in which the operation is to be implemented.  In both the parent class and the sub-class, the conceptual intent of the operation must be the same, i.e. in the above example the intent is to charge a customer.

Part b

A training company runs information technology courses [class] for the public at their training headquarters (public courses) [specialisation of class] and for companies at their own site (on-site courses) [specialisation of class].  Public courses only run with a minimum number of attendees [an additional attribute of the sub-class], whilst on-site courses always run, since they are guaranteed by a client [an additional attribute of the sub-class].  For this reason, on-site courses have separate invoicing procedures to public courses [a redefinition of the invoice operation in the parent class].  A class named course already exists with standard attributes (course code and course name) and invoicing procedures.

Each course is assigned to a manager [new class] who has responsibility for managing a number of courses, although a course is only ever managed by a single manager [association].  From time to time managers of courses change and are assigned and deassigned course [operations for manager] management responsibilities as required.

The training company employs a number of instructors [new class] who give course presentations.  Instructors [new class], in common with managers ['in common' means that there is a parent class for these two sub-classes], each have a record detailing their name, address and bank account details [identifies the attributes for the parent class].  Although standard procedures exists for the recruitment (hiring) and dismissal (firing) of all employees [identifies operations for the parent class], special arrangements [indicates redefinition of operations] apply to instructors as they are strictly not company employees, but paid consultants.

For each course, a number of presentations are run [new class- presentation].  Each presentation is given by exactly one instructor, although an instructor may give more than one presentation whilst hired by the company.[association]  Each presentation is assigned a unique presentation reference number.[attribute of presentation]  When a course presentation is to be given, an instructor is assigned.  Sometimes it is necessary to reschedule an instructor when the dates of an on-site course have to change [operation].  Under these circumstances, a check is made to see if the original instructor is available for the revised date.  If they are available, the presentation is rescheduled, otherwise the instructor is released from course assignment.

Part c

The key issue in producing the model in part b was to establish legitimate and representative class hierarchies.  Class hierarchies, which use the power of inheritance, are a key feature in object oriented modelling and represent both its strength and weakness.

In this case study the question to be asked of the two sets of classes is "are they really related by a common parent class?"

In the answer produced above, I have made assumptions about the class which have led to the solution provided; these are explained below.

Firstly, I have treated instructors and managers as belonging to a parent class called employee.  This is because each sub-class share a number of common attributes, such as name, address and bank account details.  Furthermore, in principle both types of employee are 'hired' and 'fired'.   However the process by which hiring and firing takes place is different for each sub-class and therefore in the definition of the class instructor, I have overridden the implementation.  

This solution is acceptable if there was no problem calling instructors, employees.  The case study hints that this might be a problem since they are explained to be consultants.  The alternative therefore would have been to treat each sub-class as separate, independent classes, but then we loose the advantages of the parent class employee.  It may also be that the system needs to know all employees, whether they are instructors or managers.

As far as the sub-classes public course and on-site course is concerned, the issue is the same, although the solution is more straightforward.  The case study presents no reasons for treating these as separate classes.

Part d

Show comments »