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

4.13 Object Class Models 103
Another useful set of sorts is defined in the method OOSE by Jacobson et al. [J
Interface objects model behaviour and information that is dependent on the interface
to the system, between the users and the system.
Entity objects model information in the system that should be held for a longer
time.
Control objects model functionality that is not naturally tied to any other object, for
example, behaviour that consists of operating on several different objects, doing
some computations and then returning the result to an interface object.
In addition to these sorts Jacobson defines ’subsystems’ comparable to clusters, and
’blocks’ which are design objects, normally aiming to implement analysis objects.
The sorts we discussed here are defined to be able to reason about the design of the
object model. They offer a meta-level in the form of ’object class types’. We do not have
the intention to formalise these sorts in any way into the model. Therefore we do not
offer specialised representations for these ’types’. Any model is constructed with data
objects, process objects, clusters, and their respective classes. A method such as OOSE,
offers separate representations for interface objects, control objects, and entity objects
[J
92]. We decided to keep the number of representations and primitives that we offer
as small as possible. A wish to distinguish or reveal various sorts must be handled by
finding appropriate names for the objects.
4.13 Object Class Models
An Object Class Model is a collection of diagrams. These diagrams visualise object
classes and their relations. An Object Class Model gives a rather abstract, so-called
conceptual view, on the system to be designed. Most object-oriented analysis methods
[R
91, C
94, CY91a, CY91b, J
92]:
92, Boo91, Mor94, SM88] offer such models. We call it
Object Class Model to distinguish it clearly form Object Instance Models. Usually they
are called Object Models. There is an overwhelming amount of publications and books
on object modelling. In contrast to object instance modelling, object class modelling is
relative mature.
Our goal is to achieve improvements in the modelling of reactive distributed and embedded
systems for hardware/software implementations. Therefore we spent less research
effort in Object Class Modelling. In contrast to improving object modelling, we developed
an analysis approach that focuses simultaneously on ’class modelling’, ’instance
modelling’, ’behaviour modelling’ and ’architecture modelling’. In our point of view
class modelling is strongly overemphasised in most methods. We organised our work
to be complementary to existing work, as much as possible. Concerning object class
modelling we integrate the valuable results of work of others. However some of this
work revealed that there are fundamental problems, such as the inheritance anomaly
[MY93] and the difference between inheritance and subtyping [Coo89]. These problems
can cause consistency problems and formalisation problems in a method. Consequently