What Is Object-Orientation
OBJECTIVES
Introduction
It is a major premise of this book that the object-oriented approach to systems development helps to avoid many of the problems and pitfalls described in earlier chapters. In this chapter we lay the foundations for understanding object-orientation by presenting an explanation of the fundamental concepts. This is important for all readers who are new to object-orientation, but particularly so for those who are already familiar with other approaches to systems analysis and design, for example, structured analysis. There are important differences between the object-oriented approach and earlier approaches. It is necessary to have a sound grasp of the basic concepts in order to be able to apply the techniques of object-orientation in an effective way.
At this stage the most important concepts to grasp are object, class, instance, generalization and specialization, message passing and polymorphism. We explain each of these concepts in turn, showing both what the parts of an object-oriented system are and how they use message passing to isolate different parts of a system effectively from each other, thus controlling the complexity of the interfaces between sub-systems (section 4.2). The discussion is necessarily conceptual in places, but practical examples and analogies are used to illustrate the theoretical points wherever this is appropriate. We then place object-orientation in its historical context, and look at some of the reasons why is has been able to make a contribution to successful information systems development (section 4.3). Finally, we conclude by summarizing the state of evolution that object-oriented languages have reached today (section 4.4).
Basic concepts
The most important concept addressed in this section is the object itself, and it is to this that we first pay attention. The other concepts explained in this section are strongly dependent on each other, and all contribute to an adequate understanding of the way that objects interact, and thus to their significance for information systems. The following explanations on giving an understanding of the territory that later chapters will explore in greater depth.
Objects
In an early book on object-oriented analysis and design, Coad and Yourdon (1990) define object as follows:
Object. An abstraction of something in a problem domain, reflecting the capabilities of the system to keep information about it, interact with it, or both.
This may not immediately appear to help very much, as parts of the definition are themselves a little obscure and raise further questions. In particular, what exactly do we mean by ‘abstraction’, and which ‘system’ are we talking about?
A useful definition of abstraction in this context might be: ‘A from of representation that includes only what is important or interesting from a particular viewpoint.’ To give a common example, a map is an abstract representation. No map shows every detail of the territory it covers (impossible, in any case, unless it were as large as the territory, and made from similar materials!). The intended purpose of the map guides the choice of which details to show, and which to suppress. Road maps concentrate on showing roads and places, and often omit landscape features unless they help with navigation. Geological maps show rocks and other sub-surface strata, but usually ignore towns and roads. Different projection and scales are also used to emphasize parts of the territory or features that have greater significance. Each map is an abstraction, partly because of the relevant features it reveals (or emphasize), and also because of the irrelevant features it hides (or de-emphasize). Objects are abstractions in much the same way. An object represents only those features of a thing that are deemed relevant to the current purpose, and hides those features that are not relevant. This brings us to our second question. To which system are Coad and Yourdon referring? The context of the question makes it reasonably clear that their answer would be something like this:‘ The proposed object-oriented software system, whose development is under consideration’. This seems appropriate-after all, this book is about the development of object-oriented software-but we should note that other systems are also involved. The most important of these is the human activity system that we must understand before beginning the construction of any software.
We should also note that we are using one tool to serve two purposes. As we shall see particularly in chapter 7, objects are used to model an understanding of the application domain (essentially part of a human activity system), yes we shall also see in later chapters that objects are also understood as parts of the resulting software system. These are distinct purposes and these will be some occasion when we may need to take care to be clear about which meaning is intended. Rumbaugh et al. (1991) take a slightly different slant on defining an object. These authors also explicitly recognize the dual Purpose noted in the last paragraph.
We define an object as a concept, abstraction, or thing with crisp boundaries and meaning for the problem at hand. Objects serve two purpose: They promote understanding of the real world and provide a practical basis for computer implementation.
This definition contains a repetition (although this does no harm)-by ‘concept’ we actually mean an abstraction, something that is logical rather than physical. A concept may be intangible, even imaginary (in the sense that not every participant agrees on its meaning, or sometimes even its existence ). In the Agate case study, one concept is the ‘campaign’, While they are clearly important, campaigns are intangible and difficult to define with precision. They really exist only as a relationship between a client (say Yellow Partridge, a jewellery company), the Account Manager, some other staff, some advertisements and various tasks and components that go into creating advertisements. Concepts include many kinds of relationship between people, organization and things. In information systems development, it is often necessary to recognize relationships such as contracts, sales or agreements. While intangible, some of these relationships can be quite long-lasting, and can have a complex influence on how people and other things in the application domain are able to act.
Let us take a simple transaction as an example. Imagine buying a tube of toothpaste in your local supermarket. On one level, this is just a sale, an exchange of money for goods. On a deeper level you might be entering into a complicated relationship with the shop and the manufacturer. This probably depends on other factors, e.g. the warranty may vary depending on the country that you on a loyalty card. Perhaps the packaging includes a money-off coupon for your next purchase. Now suppose you find something wrong with the toothpaste- you might be able to claim a refund or replacement. Maybe you can even sue the shop for damages. The point here is that we cannot understand the business without understanding these possible consequences of the sale in some appropriate way. In this case, the real world ‘sale’ will almost certainly be modelled as an object in the system.
At a fairly abstract level, when choosing the objects we to model-in fact, at the level that corresponds to a mapmaker-we need to ask: ‘What sort of map is this; what details should it show, and what should it suppress?’ In the real world, probably the only common characteristic of all objects is that they exist. However, all objects in a model or in an information system have certain similarities to all other objects, summarized by Booch in the statement that an object ‘has state, behavior and identity’ ( Booch, 1994). Here, ‘state’ represent the particular condition that an objects in at a given moment, ‘behaviour’ stands for the things that the object can do (and that are relevant to the model) and ‘identity’ means simply that every object is unique.
For example, Figure 4.1 lists some characteristics of a person, a shirt, a sale and a bottle of ketchup. Supposing that we wished to model these as objects, we can identify some possible identities, behaviours and states (but note that these are for illustration only, and do not indicate any particular system perspective).
In some texts (e.g. Wirfs-brock et al., 1990), objects are deliberately characterized as if each were a person, with a role in the system that is based on its answers to three questions.
This approach defines an object in terms of its responsibilities and its knowledge, themes that we will encounter again in later chapters.
Class and instance
Let us begin by being clear that we are here dealing with objects as abstractions within an information system-either a model or the resulting software-and not with the real world objects that these represent. The UML specification (OMG, 2001) gives a definition that illustrates the strength of the connection between the three concepts of object, instance and class.
An object represents a particular instance of a class.
Objects that are sufficiently similar to each other are said to belong to the same class. Instance is another word for a single object, but it also carries connotations of the class to which that object belongs: every object is an instance of some class. So, like an object, an instance represents a single person, thing or concept in the application domain. A class is an abstract descriptor for a set of instances with certain logical similarities to each other.
Figure 4.2 shows some classes that might be identified from the Agate case study (Chapter 7 describes a practical approach to identifying classes).
A class and its instances are related in the following manner. For staff at agate, the idea of ‘a campaign’ is an abstraction that could represent any one of several specific campaigns. In an object-oriented software system, the class campaign represents the relevant features that all campaigns have in common. There is one instance of the class to represent each real-world campaign. Some example of campaigns are: a series of magazine adverts for various Yellow partridge jewellery products placed throughout Europe in January 2002; a national series of TV, cinema and magazine adverts for the launch of the Soong motor co’s Granda estate in summer 2002.
Each instance of a class is unique, just as every living person is unique, however closely they resemble someone else. This is true even when two instances have identical characteristics. For example, there could be two members of staff at Agate with the same name-say ‘Ashok Patel’, as this is a fairly common name. It is even possible (though unlikely) that both joined the company on the same date and work in the same section. Yes each remains a separate individual, and would therefore be represented by a separate instance of the class staff member.
Class membership
The idea that instances belong to a class logically implies that there must be a test that determines to which class an instance belongs. Since membership is based on similarity, such a test will also be capable of determining whether any two instances belong to the same class. There are two distinct types of logical similarity which must be tested. First, all objects in a class share a common set of descriptive characteristics. For example, the staff at Agate record a client’s company name, address, telephone number, fax number, e-mail address and so on. Each item is included in the list because it is useful in some way to the users of each item (e.g. the actual company name) will vary from one client to another. But, while the values may differ, this information structure is the same for every client.
To take another example, users of the Agate system also need to know about the member of staff assigned as staff contact to a client. A staff member might be described by a name, staff number and start date. Again, the full list gives a complete description of a staff member. Here, too, the value of each item (e.g. the staff name) will normally vary from one person to another, but again the structure is the same for all staff members. Now compare the two descriptions, summarized in Figure 4.3.
Both staff members and clients have a name, but otherwise there is little in common. The information structure used to describe a client would not be capable of describing a member of staff, and vice versa. Even the sorts of name that would be valid in each case are likely to be different (apart from the relatively unusual cases where a company is known by the name of a person). It I reasonable to consider all clients as members of one class, and all staff as members of one class, but it would not be justified to consider them as members of the same class. When two objects cannot be described by a single set of features, they cannot belong to the same class.
A second logical similarity must also be tested. All objects in a class share a common set of valid behaviors. For example, clients may initiate a campaign, may be assigned a staff contact, may pay for a campaign, terminate a current campaign, and so on. Perhaps
1 What appears in the list depends on the needs of the application. Another team may be developing a system to monitor whether client companies comply with environmental laws. Their list may share some characteristics with ours, but may also add others of no interest to our model.
2 The values that an attribute can take said to be contained within the namespace of the class. This means that each attribute value (for example, a company name) must be unique for its class. An attribute of another class might take the same value (for example, a staff member’s name) but, since this is in a separate namespace, there is no conflict between the two.
No one client will actually do all this in reality, but that does not matter. The point is that any client could do any of these things, and the information system must reflect this. If we consider staff members, we find a different set of valid behaviours, Staff can be assigned to word on a campaign, be assigned to a campaign as staff contact, change grade and maybe other things we do not yet know about. It may be more likely for staff members than for clients that they will actually go through the same sequence of behaviours, but this, too, does not matter. The point again is that a member of staff could do these things.
All clients, then, have a similar set of possible behaviours, and so do all staff members. But clients can do something that a member of staff cannot do, and vice versa. On this count, too, we would consider clients as a class, and staff as a class, but we cannot make a case for considering clients and members of staff as instances of the same class. To summarize the examples, Client is a valid class, and Staff Member is a valid class. We can also note that, while the discussion here has been rather formal, an informal version of this dual test also works. In fact, we have already met this in section 4.2.1: all members of a class give the same answers to the questions ‘What do I know?’ and ‘What can I do?’
Generalization
In this section, we look at the concept of generazation and its application within object-orientation. In the UML Specification (OMG, 2001), generalization is formally defined as:
… a taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element (it has all of its properties, members and relationship) and may contain additional information.
This is perhaps a little much to grasp in one take, so in the sections that follow we will dismantle the definition into its main components, and examine each part on its own. We will highlight the general principles by looking first at an example of species classification (note that this is intended only to illustrate the concept of generalization, and is not a technical presentation of modern biological taxonomy). Later, in Chapter 8, we present an extended practical example from the Agate case study.
Taxonomic relationship
‘Taxonomy’ means a scheme of hierarchic classification-either an applied set of classifications, or the principles by which that set is constructed. The word was originally used for the hierarchic system of classification of plant and animal species, hence the example shown in Figure 4.4.
The taxonomic relationship between the two elements in this hierarchy labelled ‘cat’ and ‘mammal’ can be simple rephrased as ‘the cat belongs to the class of mammals’, or even more simply ‘a cat is a kind of mammal’. Many other relationships are also identified in the diagram. For example, a domestic cat is a cat, as is a tiger, and both are also animals and living things. We can summarize this by saying that in each case the common relationship is that one element ‘is a kind of’ the other element.
A more general element
The mammal is a more general element than the cat, which in turn is more general than the domestic cat or the tiger. Thus any description of a mammal must apply to many different animals: domestic cats, tigers, dogs, whales, etc. A description of a general mammal really means just a description of common characteristics shared by all mammals. This may be rather brief, perhaps consisting of only one characteristic, e.g. that all mammals suckle their young. In the tree diagram, the more general an element is, the nearer it is to the root of the tree.
A more specific element
As an element of the hierarchy, ‘cat’ is more specific than ‘mammal’ and ‘domestic cat’ is still more specific. In other words, the former word in each pair conveys more information. Knowing that an animal is a cat, we can guess something about its diet, general body shape, size (within certain limits), number of legs (barring accidents, etc.), and so on. If we know only that it is a mammal, we can guess little, if anything at all, of its description. The more specialized elements of a hierarchy are those which are further from the root of the tree and closer to the leaves. The most specialized elements of all are those that actually form the leaves of the tree. In Figure 4.4, the leaves are individual species.
Fully consistent with the first element
Whatever is true for a mammal is also true for a domestic cat. If the defining characteristic of a mammal is that it suckles its young, then a domestic cat also suckles its young. This is true for every mammal, whether a tiger, dog or whale. This is an important feature of any hierarchic taxonomy. As an illustration, we can think about what would happen if a zoologist discovers that a defining mammalian characteristic does not apply to an animal previously thought to be a mammal. For example, suppose a research project found conclusive evidence that common field mice lay eggs instead of bearing live young. This alone would give enough grounds either to re-classify the field mouse, or to re-define what distinguishes a mammal from other animals. Perhaps a brand new classification would be invented specifically to accommodate egg-laying mice (as occurred following the discovery of the duck-billed platypus, which in most respects resembles a mammal, except that it lays eggs instead of bearing live young).
Adds additional information
A full description of the domestic cat would contain a great deal more information than that for a general member of the mammal class. For example, we might define a domestic cat by saying that it suckles its young, has a certain skeletal structure, a particular arrangement of internal organs, carnivorous teeth and habit, the ability to purr, and so on. Apart from suckling its young, none of these characteristics apply to all other mammals. A full zoological description of any species contains at least one characteristic (or a unique combination of characteristics) that differentiates it from all other species. Otherwise it would not make sense to consider it a species in the first place.
Using generalization
The main application for generalization in object-orientating is to describe relationship of similarity between classes. Object classes can be arranged into hierarchies much the same as the species example. This has two main benefits. The first results from the use of object classes to represent different aspects of a real-world situation that we wish to understand. Using generalization, we can build logical structures that make explicit the degree of similarity of difference between classes. This is an important aspect of the semantics of a model-in other words, it helps to convey its meaning. For example, to know what hourly-paid and monthly-salaried employees in a business have in common with each other may be just as important as to know how they differ. The former may help to understand that some types of information must be recorded in identical ways for both types of employee. Figure 4.5 illustrates this with an example that might be suitable for a payroll system. In this model, each employee is represented by their date of appointment, date of birth, department, employee number, line manager and name, together with some details that depend on whether they are paid weekly or monthly (these are the only significant differences modelled). A hierarchically structured model allows the close similarity to be shown clearly.
A second benefit comes from the relative ease with which a hierarchy can be extended to fit a changing picture. If this company were to decide that a new, weekly-paid type of employee is required, it is a simple matter to add a new subclass to the hierarchy to cater for this, as shown in Figure 4.6.
Other features of generalization
Three features of generalization that are not mentioned explicitly in the definition given earlier are sufficiently important to deserve some discussion at this point. These are: the mechanism of inheritance, the transitive operation of inheritance and the disjoint nature of generalization hierarchies. Inheritance. This is a mechanism for implementing generalization and specialization in an object-oriented programming language. When two classes are related by the mechanism of inheritance, the more general class is called a superclass in relation to the other, and the more specialized is called its subclass. At a first approximation, the rules of object-oriented inheritance work more or less as shown below, although this is very simplified and will need to be refined shortly.
- A subclass inherits all the characteristics of its superclass.
- The definition of a subclass always includes at least one detail not derived from its superclass.
Inheritance is very closely associated with generalization. Generalization describes the logical relationship between elements that share some characteristics, while inheritance describes an object-oriented mechanism that allows the sharing to occur. Transitive operation. This means that the relationship between two elements at adjacent levels of a hierarchy ‘carries over’ to all more specialized levels. Thus, In Figure 4.4, the definition off an animal applies in turn to all mammals, and thus by a series of logical steps to a domestic cat. So we can rewrite the rules of inheritance given above, as follows.
- A subclass always inherits all the characteristics of all its superclasses.
- The definition of a subclass always includes at least one detail not derived from any of its superclasses.
The name comes from a superficial similarity to biological inheritance, which also takes the form of a hierarchy. But object-oriented inheritance is very different from inheritance in living things, and care should be taken not to confuse the two. We shall see in chapter 8 that inherited characteristics are sometimes over-ridden in a subclass.
Disjoint nature. In a hierarchic system, the branches of the tree diverge as they get further away from root and closer to the leaves. They are not permitted to converge. This means, for example, that a cat cannot be both a mammal and a reptile. In other words, each element in a hierarchy can only be a member of one classification at any given level of the hierarchy (although, of course, it can be a member of other classifications at other level of the hierarchy, due to the transitive nature of the relationship). The disjoint aspect of generalization means that we sometimes need to be careful about the characteristics chosen to express a generalization. For example, we could not use ‘Has four feet’ as the only defining characteristic of a mammal, even supposing that it were true of all mammals-because many lizards also have four feet, and this would make it possible to classify a lizard as a mammal. A class must be defined in terms of a unique set of characteristics that differentiate it from all other classes at its level of the hierarchy. It is worth stressing here that generalization structures are abstractions that we choose to apply, since they express our understanding of some aspects of an application domain. This means that we can also choose to apply more than one generalization structure to the same domain, if it expresses a relevant aspect of the situation. Thus for example, a human might be simultaneously classified as a creature (Homo sapiens), as a citizen (a voter in a city electoral division) and as an employee (an Account Manager in Agate’s Creative department). If each of a human might be an example of multiple inheritance, which means that a subclass is at once a member of more than one hierarchy, and inherits characteristics from every superclass in each hierarchy. We should also note that real-world structures are not compelled to follow the logical rules applied in object-oriented modelling. Sometimes they are not disjoint or transitive, and therefore not strictly hierarchic. This does not detract from the usefulness of hierarchic structures in object-oriented development.
Message passing
In an object-oriented system, objects communicate with each other by sending massages. This might seem a little obvious if we think of the system as a kind of simulation, with objects that represent things in a real-world system collaborating to carry out a collective task. After all, this is how people communicate with each other: we send messages too. In the case of human communication, the means by which we transmit our messages are diverse, and sometimes it is not obvious who is the sender or receiver for a particular message, but all human communication can be seen as made up of messages. For example, everything we say to our friends and family, the emails we read when we log onto the clothes we wear, our tone of voice and our posture-these are all messages of one sort or another. If this is so, then just that is special about saying that objects only communicate via messages?
What makes it special is the fact that software was not constructed in this way until quite recently. Earlier approaches to systems development tended to separate data in a system from the processes that act on the data. This was done for sound analytical reasons, and is still appropriate for some applications, but it can give rise to difficulties. Chief among these is the need for a process to understand the organization of the data that it uses; for such a system, processes are said to be dependent on the structure of the data.
In itself, this is not necessarily a problem-in fact, it is to a certain extent inescapable. But if taken too far, and for insufficient reason, dependency of process upon data structure can cause many problems. For example, if the data structure were changed for any reason (a not uncommon occurrence in business), those processes that use the data may also need to be changed. This is an example of coupling between sub-systems, and we must minimize coupling if we are to construct systems that break down (coupling is discussed in chapters 12 and 13). Object-oriented systems avoid these problems by locating each process, as far as is practicable, with the data it uses. This is another way of describing an object: it is really little more than a bundle of data together with some processes that act on the data. These processes are called operations, and each has a specific signature. An operation signature is a definition of its interface. In order to invoke an operation, its signature mist be given (signatures are sometimes also called message protocols).
In practice, it is not usually possible for all processes to be located with all the data that they must assess, and data and processes are distributed among many different objects. Message passing is a way of insulating each object from needing to know any of the internal details of other objects. Essentially, an object knows only its own data, and its own operations. But in order for collaboration to be possible, the ‘knowledge’ of some objects includes knowing how to request services from other objects, which may include the retrieval of data. In this case, an object knows which other object to ask, and how to formulate the question. But it is unnecessary degree of coupling into the relationship between the two objects. When an object receives a message it can tell instantly whether the message is relevant to it. If the message includes a valid signature to one of its operations, the object can respond. If it does nit, the object cannot respond. So we can think of operations as residing within objects, only able to be invoked by a message that gives a valid operation signature. Meanwhile, the object’s data lies even deeper inside, since the data can only be accessed by an operation of that object. Clearly, then, if the signatures to an object’s operations are not changed, it makes no difference what changes are made to the way that the operations run or the way that the data is stored. Neither of these changes would be visible from the outside. For this reason, the complete set of signatures for an object are sometimes known as its interface. This is called encapsulation, and is illustrated in figure 4.7.
Consider a simple system to print pay cheques for employees in a business. One way of designing this would be to have a class employee, with an instance that represents each person on the payroll. Each Employee object is responsible for knowing about the salary earned by the real employee it represents. Next, there might be a payslip object that is responsible for printing each employee’s pays lip each month. In order to print a payslip, each payslip object must know how much that employee has earned. The object-oriented approach to this is associated, asking how much salary to pay. The payslip object need not know how the Employee object works out the salary. Nor what data it stores. All it needs to know is that if it asks an Employee object for a salary figure, an appropriate response is given. Message passing allows object to encapsulate (i.e. hide) their inter details from other parts of the system, thus minimizing the knock-on effects of any changer to the design or implementation.
Polymorphism
When one person sends a message to another, it is often convenient to ignore many of the differences that exist between the various people that might receive the message. For example, in some situations a mother may use the same phrasing regardless of the age or gender of her child. ‘Go to bed now!’ carries much the same import whether the child is a five-year-old boy or a thirteen-year-old girl. But the precise tasks to be carried out by each child in going to bed may be very different. The five-year-old may set off towards bed by himself, but perhaps then requires help with washing his face, brushing his teeth, putting on his pyjamas and he may also expect to be read a bedtime story. The thirteen-year-old may not require any further help, once convinced that it really is bedtime.
This is rather like polymorphism, which is an important element in the way that object-oriented approaches encourage the decoupling of sub-systems. Polymorphism literally means ‘an ability to appear as many forms’, and it refers to the possibility of identical messages being sent to objects of different classes, each of which responds to the message in a different, yet still appropriate way. This means the originating object does not need to know which class is going to receive the message on any particular occasion. The key to this is that a receiving object is responsible for knowing how to respond to messages.
Figure 4.8 uses a collaboration diagram to illustrate polymorphism in a business scenario (the notation for collaboration diagrams is described fully in chapter 9). The diagram assumes that three are different ways of calculating an employee’s pay. Fulltime employees are paid a salary that depends only on his or her grade; part-time staff are paid a salary that depends in a similar way on grade, but must also take into account the number of hours worked; temporary staff differ in that no deductions are made for the company pension scheme, but the salary calculation is otherwise the same as for a full-time employee. An object-oriented system to calculate pay for these employees might include a separate class for each type of employee, each able to perform the appropriate pay calculation. However, following, the principle of polymorphism, the message signature for all calculate pay operations is the same. Suppose one of the outputs from this system is a print-out showing the total pay for the current month: to assemble the total, a message is sent to each employee object, asking it to calculate its pay. Since the message signature is the same in each case, the requesting object (here called monthly pay print) need not know the class of each receiving object, still less how each calculation is carried out. Polymorphism is a powerful concept for the information systems developer. It permits a clear separation between different sub-systems that handle superficially similar tasks in a different manner. This means that a system can easily be modified or extended to include extra features, since only the interfaces between classes need to be known. The way that each part of the system is implemented (its internal structure and behaviour) is hidden from all parts of the system that do not absolutely need this knowledge. Program designers and programmers have struggled for many years to achieve such a high level of modularity in software. Object-orientation gives the greatest promise yet of practical success.
Object state
In the real world, people and objects do not always behave in exactly the same way in response to similar stimuli. For example, if you have just eaten a good lunch, you will be much more likely to refuse the offer of a large, sticky gateau. However, if you happen to be very hungry at the time, this offer may be much more tempting. A simple way to represent this difference is to say that at any given time you can be in either of two states: well-fed or hungry. Each state is characterized by data that describes your condition-in this case your level of hunger. Each state is also characterized by a difference in behavior. In other words, your response to certain messages differs according to the current value of your data-when well-fed, you refuse food, while when hungry you accept it. Your behavior in response to a stimulus can also change your state. After eating a large gateau, your state changes from hungry to well-fed (perhaps for some people more than one would be required). Objects can also occupy different states, and this affects the way that they respond to messages. Each state is represented by the current values of data within the object, which can in turn be changed by the object’s behavior in response to message. Booch et al. (1999) define state as … a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.
The concept of object state is fundamental to an understanding of the way that the behavior of an object-oriented software system is controlled, so that the system responds in an appropriate way when an external event occurs. The significance of control is perhaps most apparent for safety-critical real-time systems. For example, consider the engine and flight crew take control, but even then it is still the software that directly operates the engine throttles, elevators, and so on. It could be disastrous if all the engines of an airliner were shut down during the final approach to land, and the software is designed to prevent this to occurring. However, it may sometimes be necessary for the pilot to override this constraint during an emergency. The software must also be designed to permit this to occur, and to correctly discriminate between the different situations. In order to ensure safety, the control software must be designed to take account of all possible states of the aircraft (parked, climbing, flying level on auto-pilot, landing), the appropriate control behaviors for each state (shut down engine, full throttle, climb descend, turn), and the external events that can trigger a change in behavior (pilot operates throttle, turbulence causes course deviation, loss of cabin pressure).