Specification of Reactive Hardware/Software Systems - Electronic ...

4.2 Objects 61
wonder what other objects expect from us. If we think this way, we are very likely
to discover new objects that were not defined yet. An object must be a recognisable
concept or thing in the problem domain or the implementation domain. It must be
possible to give it a name that covers a recognisable phenomenon. This highly improves
comprehensibility of a model. Some arbitrary combinations of services are not likely to
form an object. An object is an autonomous entity with properties that are relevant for
the problem.
The concept of ’object’ is not unambiguous. So far, we gave a very abstract understanding
of what an object is. The definitions did not seem to show conflicts, but this
is misleading. It will appear that various concepts such as continuous existence, concurrency,
state, subtyping, inheritance and internal behaviour determine the precise
semantics of object. The semantics are completely dependent on the specific composition
of concepts that are used. Most current object-oriented specification methods
define objects by rather abstract descriptions. This has the advantage that it leaves the
possibility to implement a specification in different (object-oriented) languages. We do
not have the option to leave the definition rather abstract. Simulation is necessary for
complex hardware/software systems as a means to get in depth understanding of various
aspects of system behaviour. Executable behaviour descriptions are necessary to
enable simulation. Executable specifications require precise semantics. Various aspects
and properties that make objects suitable to model complex hardware/software systems
must be chosen. These concepts must be suitable for informal communication among
people and must fit into a formal semantics.
4.2.5 Abstraction Capabilities
Defining an object implies ’drawing’ a boundary in the problem domain. This boundary
encapsulates data and services into a shell, called an object. ’Objects are the granules that
constitute a system. Objects are the fundamental unit of granularity’ [Weg90]. For the outside
world, an object is a data abstraction. Data abstractions hide the representation of data
and the implementation of operations. ’The essence of object-orientation is the encapsulation
of data and operations in objects and the protection of individual objects against each other’
[Ame89]. It is the object’s interface, at its boundary, that hides the internal representation
of data and the implementation of operations. The interface enables co-operation with
other objects.
4.2.6 Real World and Artefact Objects
Some objects are so-called real world objects. They model a thing or concept that can be
observed during a study of the problem domain. Coad and Yourdon [CY91a] emphasise
the real world object approach in OOA (Object-Oriented Analysis). The real-world
approach suggests that objects somehow already exist. Analysis creates a model of
objects that is an image of existing real world objects. This approach is adequate for a
variety of problem domains. However, complex reactive systems seem to have a ’heart’
of objects that have been constructed creatively. These objects are artefacts that must be