Objects

When we look up the word object in a dictionary we may find definitions such as ``a thing that can be seen or touched''; ``a person or thing to which action, thought, etc. is directed''; or in more philosophical terms ``anything that can be perceived by the mind''.

In Software Engineering or Computer Science, though, the term has acquired a new or more specialized meaning. A software object is still an entity. The difference is that this object ``lives'' in the computer or software world and not in the real world. But to be useful in some way, the software object must have a more or less direct mapping to a real object in the application domain. A software object may represent a physical object in a particular domain but it may also represent an abstract concept or idea. According to the Object Management Group (OMG) of the ACM an object is ``an entity that has unique identity, a set of operations that can be applied to it, and state that stores the effect of the operations'' [OMG, 2003].

Therefore, an object is made up of three basic components: an identity, a state, and a behavior [Booch, 1994b]. The identity is the property that enables distinguishing two objects with an identical state and behavior. The identity is unique and may not be shared between different objects, even at different time and does not change during the object lifetime. The object state represents the different possible internal conditions that the object may experience during its lifetime. Finally the object behavior is the way a particular object will respond to received messages.

A class is an abstract group of objects that behave the same way. Every existing object is the instance of a class. Not every class though may have instances. A class that cannot be instantiated is called an abstract class. A class is basically made up of a unique name, a number of attributes and a set of operations (the implementation of which is called method). The attribute values of a concrete object in a given moment define this object state. Thus attributes in a class define the possible states in which an instance of that class may be. On the other hand, the behavior of an object depends on the class operations plus the particular state of the object as operations may respond differently to input messages depending on the current state. And again according to the OMG, a class is ``a classifier that describes a set of objects that share the same specifications of features, constraints, and semantics [OMG, 2003].

An object oriented system may be viewed exclusively as a set of objects that are related and exchange messages, all collaborating to accomplish a common goal that is related to the functional requirements of the system (we will thoroughly define what a system is in section 1.2.1). An OO message is made of a receiver, a selector and an optional list of arguments. The receiver is the object that will receive the message. The selector informs the receiving object of which of all the possible messages it can interpret is being sent. And finally the the optional list of arguments holds the values with which the receiver will interpret the message.

The way that objects are related in run-time is defined by the way the classes are associated in the logical view of the system. There are basically four kinds of class relationships: association, aggregation/composition, dependency and inheritance. Each relationship is established between two classes and, apart of the ``kind'' of relationship, we should describe its navigability (whether objects in both ends of the relation are able to see each other or this navigation is restricted in only one direction) , and cardinality (how many instances of each class can participate in the relationship). Other less important attributes in the relationship such as its name, roles of the participants or visibility may also be included.

An association is the most basic - and weakest - form of relationship. It basically represents that instances of one class know of the whole or part of instances of the other class. That means that instances of one end can access operations or attributes in the other end. All other relations, except for inheritance, can be viewed as particular cases of an association.

A stronger form of association is known as aggregation. An aggregation represents a relationship between some ``parts'' and a ``whole''. In an aggregation, instances in one end of the relationship ``contain'' or are ``made up'' objects of the other end. A particular case of aggregation is a composition. In a composition the life of the parts is connected to the life of its whole. When a part is instantiated, it must be already created as belonging to a whole and when the whole is destroyed, its parts are also destroyed.

Probably the most powerful technique associated to object oriented methods is the inheritance relationship. If a given class A derives from class B, class A is said to be a subclass of B while B is said to be a superclass or a base class for A. A derived class inherits all the behavior implemented in its base class but is also allowed to add or override behavior. A rule of thumb for identifying if a given class can be modeled as a subclass of another one is the 'is a rule': if the sentence ``A is a B'' makes sense, then probably A is a subclass of B (e.g. ``A dog is a mammal'').