Information Analysis:Class diagrams

8.5 Class diagrams

Booch et al. (1999) define a class as 'a description of a set of objects that share the same attributes, operations, relationships, and semantics' (p. 49). A class diagram is a model of the things that are of interest in the problem domain being studied. In different domains there will be different things of interest; in modeling a university the developer might find classes such as 'Student', 'LectureCourse', and 'LectureRoom'. In the context of a theatre classes for consideration could be 'Actor', 'Star', 'Theatre', 'Seat', 'Production', and so on. These are the conceptual categories that help us make sense when structuring our perceptions about the theatre situation. In UML classes are shown as rectangles (figure 8.5).

The class name should be a short noun or noun phrase and begin with a capital letter. The class model typically represents things that last over time – the functionality of the system may change often, but a good class model will either cope with new functionality as is or be capable of being extended without being the subject of a major redesign. It is very unlikely that a 'correct' class diagram will be produced at the first attempt. The class diagram will evolve as the developer understands the domain and the requirements better and, despite our best attempts to separate out analysis and design, it will in all likelihood be impacted by the technical design and the software construction phases of the project.

Classes can represent tangible things, such as the seats in a theatre, and intangible things, such as an account balance in an accounting system. Classes can also be used to model roles, such as the box office manager in a theatre. To find classes in a domain, two approaches are typically used: modeling the vocabulary and modeling the responsibilities of the system. In taking a vocabulary (or data-driven) approach the developer looks at the things that users already use to describe their system (good sources for these things are the use case analyses) and highlights nouns and noun phrases. This is a seemingly simple technique, but experience is needed to decide on what should be kept in, what excluded, and how to rename and restructure the candidate classes. Responsibility modeling of classes is concerned with how responsibilitywill be divided between a group of classes; the aim is to achieve a balance of responsibilities. In a group of classes we do not want one class that is large and complex with too many responsibilities while other classes have trivial responsibilities. The design heuristic is to look at and to redistribute responsibilities evenly. In practice, the OO developer will tend to use a combination of data-driven and responsibility based modeling, although they might struggle to explain exactly how they do this! However, the stereotypes of vocabulary and responsibility are useful as they are a reminder that a good class model will represent the things of interest as well as their collaborations and responsibilities.

It is important to note that the objects being modeled are going to be represented in software. We cannot represent every characteristic of the real-world object being modeled, even for seemingly simple objects. The architect Christopher Alexander (1964) gives the example of the difficulty of modeling the characteristics of a button. Characteristics of a button include the shape, size, colour, number of holes, and the material it is constructed from. However, further characteristics might include weight, oil-resistance, and flammability. Weight might be relevant for sport or space travel; oil-resistance for engineers and anglers; flammability for the fire service. A software model is an abstraction of the problem situation and the developer must understand the context and purpose of the model to know what is relevant and what is not.

In software terms, the system is a collection of collaborating objects. However, there is a connection between the software representation and the things in the problem domain. As a minimum, the software representation needs to be consistent with the things in the problem domain. For example, an asset register of personal computers in the organization might involve stencilling a bar code onto each physical computer so that it can be matched to an object in the software system that holds details of the computer's location, specification, service record, and original purchase price. The development of location aware and context-sensitive devices will lead to a closer integration of software and real-world things. Imagine that each seat in the theatre is made intelligent and can report on its status – 'I need cleaning', 'I have been removed for repair'. In this scenario the act of removing a seat would result in a message to the software system indicating that the seat was no longer available for bookings. The growth in mobile communication will see more and more intelligent devices and therefore a stronger link between the software and the things being modeled or controlled in the problem domain. This suggests that software systems will not only have informational implications, but will have a more immediate and direct physical impact on our world.

8.5.1 Relationships: associations

Classes represent things; relationships represent the connections between things. UML caters for three types of relationship: association, generalization, and aggregation. An association is a structural relationship between things showing that one can navigate from the instances of one class to the instances of another (and possibly vice versa).

Associations are shown as solid lines that connect the same or different classes. In figure 8.6 the association might reflect the real-world business rule in the ABC Company that 'each employee must be allocated to a single department'. The association can be read in two directions – the inverse to figure 8.6 would be that 'each department may have many employees allocated to it'. Each of the directions represents a role of the association; connections between two classes, known as binary associations, have two roles. Just as classes have instances, so do associations. Instances of the Employee/Department association could be 'employee Tom Smith is allocated to the Marketing department' and 'employee Sue Jones is allocated to the Finance department'.

Multiplicity

In the case of figure 8.6 the '1' indicates that an employee must have one – and only one – department. Tom Smith can work for the Marketing department, but cannot work for the Personnel department at the same time. If Tom moves from Marketing to Personnel then a new instance of the Employee/Department association is made, linking Tom Smith (employee instance) to Personnel (department instance). In the XYZ Company it may be

possible for employees to have split posts, in which case there would be a many to many association between Employee and Department. Such an association might have an attribute specifying the percentage of time that each employee is allocated to a particular department with a constraint that the total for each employee must equal 100.

Reading from left to right, figure 8.7 shows the most common association multiplicities. Each of the examples of association multiplicity could reflect the policies of an organization and therefore none is correct or incorrect in an abstract sense – correctness is decided by reference to the problem domain.

8.5.2 Attributes and operations

Attributes

Booch et al. (1999) define an attribute as 'a named property of a class that describes a range of values that instances of the property may hold' (p. 50). More intuitively, an attribute describes the instances of a class. For example, every employee would be expected to have a name, address, and date of birth. An instance of the class Employee could have the values 'Tom Smith', '1 Oak Street', and '20-Jun-1970'. Attributes are shown below the class name and each compound word should begin with a capital with the exception of the first word, e.g., productionType (figure 8.8). Some attributes will be mandatory, such as title, while others are optional, e.g., videoClip. Optionality is not usually shown on the class diagram, although it can be, e.g., videoClip(o).

Operations

'An operation is the implementation of a service that can be requested from any object of the class to affect behaviour' (Booch et al., 1999, p. 51). Operations are listed in the bottom compartment of the class box (figure 8.8). To invoke behaviour in an object, another object sends that object a message. For example, instances of the class Production support the operation 'assessViability'. A production object receiving this message will assess its viability and, let us assume, return a binary value: 'viable' or 'non-viable'. How the Production class implements this method is not the concern of the object sending the message. The production class might carry out the equivalent of flipping a coin, or it might make a forecast of bookings and compare this with production costs such as stage set design. The complexity of the implementation is hidden; the sender of the message invoking the operation need only know how the public interface is defined for the class Production.

8.5.3 Relationships: generalization

Generalization is a relationship between a general thing and a more specific thing. The more general thing is of a supertype class and the more specific thing is of a subtype class. For example, in the Nimbus web development agency, staff can be subtyped into graphic designers and technical staff (figure 8.9). The technical staff work in systems development or in support operations (e.g., database administrator, UNIX specialist). Common characteristics are inherited by subtypes; all IT staff will inherit the properties of their supertype, such as employee number and name and all staff instances will respond to a message invoking the changeSalary operation. However, subtypes must also be different in some way. For example, development staff may hold certification qualifications, such as Microsoft's Certified Professional. The bonus calculation for graphic designers is different from the calculation for technical staff, so the subtypes re-implement this operation as appropriate. The bonus calculation is also different between development and support staff, reflecting the different basis on which they will be assessed. In this case the subtypes implement the bonus calculation differently from their supertype, technical staff.

The third type of association is the aggregation. The aggregation represents a 'whole/part' relationship. In practice it is often difficult to distinguish between associations and aggregations; in many cases the aggregation is just a strong form of association between two classes and is shown by an open diamond (figure 8.10). A composition, shown by a filled diamond, is a stronger form of aggregation. With a composition the parts live and die with the whole and cannot be transferred. For example, it does not make sense to move part of one theatre to another theatre. If a theatre is deleted then the parts of that theatre must go as well. But, one could move seats from one part to another or to another theatre altogether.

8.5.5 The theatre booking system class model

The conceptual class diagram for the theatre booking system is shown in figure 8.11. This diagram will form the basis for design and implementation in later chapters. The model is basic but it does support the core requirements of a simple ticketing system. At the heart of the model is the class Seat At Performance. Instances of this class tie together a performance and a part of a theatre, e.g., 'Hamlet' at 8.00 pm on 5 March 2003 in seat B15 of the circle of the Barchester Playhouse. Because seats can be reserved prior to payment, the association with Transaction is optional. A transaction is simply a device for grouping together seats at a performance for the purposes of payment. A transaction must have a customer, but some of the customers will be members of the theatre club and qualify for a discount on the ticket price.

Because it is possible to get to the class theatre via two routes – performance and part of theatre – a constraint is needed to ensure that the theatre is the same via both routes for a given 'seat at performance'. This situation arises because in the early life of a production no seats have been sold and therefore an association with Theatre is needed via Performance and Production.

Note that the class model includes a Theatre class. This could be instantiated with a single theatre, e.g., the Barchester Playhouse, but it could also be instantiated with multiple theatres and therefore forms the basis for the theatre booking system – a generic multi-theatre booking system suitable for a theatre industry portal site. The model in figure 8.11 provides a basic facility for making Internet ticket sales, but little more. A more sophisticated system might allow customers to go onto a wait list for performances or productions that are full (figure 8.12). The wait list would be for one customer and would specify the number of seats required; the part of theatre preferred would be optional. The wait list is then subtyped into a wait list for a specific performance and a wait list for a production (any performance will be considered).

8.5.6 Navigability

We will assume that the default for a class diagram is that associations are navigable in both directions. Therefore, in the theatre booking system class model it is possible to find all the seats at a performance for a given performance and for a given seat at performance it is possible to navigate to that seat's performance. As the conceptual class diagram is refined into a design specification and software implementation model then navigation is added. The arrow in figure 8.13 shows that a performance knows about the seats at performance and that it is possible to navigate from a specific performance to the seats at the performance. Conversely, it is not the responsibility of a seat at performance to know about the performance. The design implication of this is that one of the attributes of Performance might be implemented as a collection of seats at performance.

8.5.7 Recursion

A common modeling situation is the hierarchy, where each part is made up of further parts through a number of levels. In figure 8.14 (a) the ABC Company is organized into divisions and departments, which can be modeled as in figure 8.14 (b).

The system has been built using the class structure in figure 8.14 (b) and is running smoothly for a number of months until the ABC Company decides to reorganize and add another tier to its structure in response to fast growth of its business (figure 8.15 (a)). This would result in the class model of figure 8.14 (b) being redesigned to show that departments are made up of sub-departments. A more robust solution that will cater for changes to the organization structure without requiring accompanying changes to the class diagram is a recursive class structure. Figure 8.15 (b) shows that organizational units are made up of further organizational units. It is optional at both ends as one unit – the company – does not have a parent and some units (sub-have children. The aggregation shows that there is a strong association between the parts and the wholes and the specialization allows the company to be represented with its specific attributes and operations.