Information Analysis:The unified modeling language (UML)

8.3 The unified modeling language (UML)

As object-oriented (OO) programming rose in popularity during the 1980s the ideas were taken from software development upstream into systems design and systems analysis. In the early 1990s a number of OO analysis and design methods were proposed. All had strengths and weaknesses: the Booch (1994) method was strong on design and real-time applications, the object modeling technique (OMT) of Rumbaugh et al. (1991) on analysis and data-intensive applications, and the use case approach of Jacobson (1994) on business process modeling.

In 1994 Booch, Rumbaugh, and Jacobson got together and pooled their ideas in a unified modeling language (UML), taking the best ideas from each and bringing some standardization to the wide range of methods and notations for OO analysis and design. We adopt UML here as it is fast becoming an

industry standard, has OMG (Object Management Group) acceptance, and a rich set of resources and software development tools available (e.g., the Rational Rose modeling software). This chapter is concerned with information system analysis, i.e., with what is required, and the UML is therefore used at the conceptual system level to support analysis.

The core UML techniques used in information analysis are:

• Use cases

• Class diagrams

• Interaction diagrams

Sequence diagrams

Collaboration diagrams

• State transition diagrams

• Activity diagrams.

We will illustrate these modeling techniques using the theatre booking system. As the UML is grounded firmly in object-orientation it will be useful to first lay out the ideas that characterize the object-oriented paradigm.

8.3.1 Fundamentals of object-orientation

Fundamental concepts of object-orientation include classes and instances, encapsulation, communication by messages, inheritance, and polymorphism.

Objects

An object is perhaps best defined simply as a 'thing'. An object could be a physical thing such as one of the seats in the stalls of the theatre. In software terms, objects are used to represent things of interest in the problem domain, such as customers, theatre seats, and ticket sales. Objects have identity, state, and exhibit behaviour.

Objects have identity, which means that each object is distinct, even if they happen to look the same to the naked eye or happen to have exactly the same attributes. Identity persists even though the characteristics of the object may change. For example, imagine a motorcar that has been painted a different colour, had a new engine, and been re-registered with a new vanity plate. The motorcar has a continuing existence that is not dependent solely on the values of its attributes. In practice, identity can pose difficulties. We might like to identify our customers by name, but a customer can change his or her name and still be the same person, although they might have a new legal 'identity'. Identity is therefore not just about attributes. An old broom might have had three new heads and two new handles – is it still the same broom? In a physical sense it is clearly not the same broom, but if the broom has been in the corner

of the kitchen for the last 25 years, then in a contextual and historic sense it is in some way the same broom.

Objects have state. The state of an object is given by the sum of its attributes. For example, a training course booking could be provisional or confirmed. Objects exhibit behaviour in response to stimuli. When a customer pays in full a provisional booking becomes a confirmed booking, i.e., it undergoes a state change. The training course booking object can receive and respond to messages. How it responds will depend on the values of its attributes; if the booking object receives a message requesting confirmation and it is already in the state 'confirmed' it might return an error code to the sender of the message.

Classes and instances

A class is a category that defines common characteristics, structure, and behaviour of objects. For example, 'Person', 'Vegetable', and 'Motor Vehicle' are classes that we would recognize as a way of perceiving things in the world. An object is an instance of a class, such as an individual person, a particular carrot, or the motorcar parked outside my house. The instances of a class have shared attributes, such as the height of a person, the weight of a carrot, or the recorded mileage of a motorcar. To underline the importance of distinguishing between classes and instances one OO trainer has been known to hold up a banana and proclaim: 'this is an object – it is a member of the class banana'.

We will use the terms 'object' and 'instance' interchangeably. However, the word 'instance' makes it clear that we are talking about this or a customer rather than the general class of Customer, especially when we come to look at UML class models and need to be able to differentiate between the class and the object.

Encapsulation and communication by messages

Encapsulation requires a service view of data (what does the object do?) to be adopted rather than an implementation view (how is the object constructed?). The representation of the object is hidden and therefore the only means of accessing and modifying an instance of a class is via the external interface operations defined for that instance's class. The external interface supported by a class is implemented as a set of operations. To get an object to do something, i.e., exhibit behaviour, we need to send it a message invoking an operation. An operation specifies the way in which the object will behave when it receives a message. For example, we would expect the Motor Vehicle class to support an operation such as 'accelerate', which when invoked will cause a motor vehicle to increase its speed. How the operation is implemented is hidden from the sender of the message. The class of which the object is a member defines the operations that the object supports and therefore the messages to which it can respond. The packaging of behaviour and data structure such that they are hidden behind an interface is referred to as encapsulation.

The concept of encapsulation (or information hiding) therefore requires objects to communicate via narrowly defined interfaces using messages. To change the bodywork colour of a motor vehicle requires that a message be sent with a colour as an argument (note that the colour used as an argument is an object that is a member of the class Colour – everything is an object and therefore a member of some class). The operation invoked is responsible for changing the representation of the motor vehicle object. To find out what colour interior a motor vehicle currently has also requires a message to be sent because direct inspection of an attribute value would violate the requirement for encapsulation. As usual in OO, how the operation is executed and how the representation of motor vehicle objects is maintained is hidden from the sender of the message.

Inheritance

A class can inherit both structure and behaviour from another class, known as a supertype class. For example, if the attribute bodywork colour is defined for the class Motor Vehicle, then all subtype classes of Motor Vehicle, such as Public Passenger Vehicle and Private Vehicle, inherit that characteristic. The operations supported by the class structure can also be inherited. If the operation 'calculate road tax' has been defined for the class Motor Vehicle then it will be inherited by the subtype classes of Motor Vehicle.

Where the basis for calculation of road tax is different by class then the subtype classes might need to re-implement the operation 'calculate road tax'. For example, it may be that Public Passenger Vehicle calculates road tax based upon the number of passengers the vehicle is licenced to carry and Private Vehicle on the basis of engine size. Any other vehicles that are instances of the supertype class Motor Vehicle will use the original 'calculate road tax' operation. When a new type of motor vehicle is needed it can be added to the class structure and inherit the common attributes and operations of existing classes (generalization) and add new attributes and operations as needed to differentiate it from existing classes (specialization).

Polymorphism

Because an object knows which class it belongs to it knows which messages it can respond to. The same operation can apply to many classes and result in different behaviour depending upon the class of the object. For example, assume that the class Clock has the subclasses AnalogueClock and DigitalClock. Clocks of both types will respond to the message 'display time' but will behave differently. The sender of the message need not be aware of

the type of clock the recipient is when sending the message 'display time' – the recipient will respond according to its class. New types of clock can be added, e.g., Sun Dial, and as long as the new subclasses support the generic operation 'display time' then no further changes will be needed to the clock system.

Encapsulation, inheritance, and polymorphism are the fundamentals of OO that help reduce the complexity of large software systems, promote flexibility, reuse, and extensibility.