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

4.17 Summary 115
Accidental Properties
There are various programming styles that can be used to ’implement’ a behaviour
specification in POOSL. Most analysis methods recommend to focus on the essence of
the problem domain, and to omit implementation details. Therefore the types that will
be identified during analysis are based on properties and aspects that are related to
the essence of the problem only. Class definitions are written to cover the behaviour
requirements found during analysis.
Imperative behaviour descriptions introduce additional properties that have not been
taken into account in an implementation independent analysis. For instance, the realtime
behaviour of two alternative descriptions may vary substantially, when both descriptions
are implemented straightforward into a particular technology. Such properties
depend on the specification programming style or the subset of constructs that have
been used, and especially the internal structure of the behaviour description. We want
to prevent that such properties are introduced accidentally or unintentionally. This can
only be prevented by taking architecture and implementation requirements into account
during analysis. This approach is a key issue in our method. It prevents iterations and
facilitates system implementation.
Style Guidance
A class defines the implementation and thereby the internal structure of an object of
that class. A type does not define any internal structure or internal representation of
attributes. A type specifies only the external observable behaviour. An object type
embodies all object implementations that satisfy the specification. Therefore the type
concept is not enough to give guidance to the creation of classes.
Implementation constraints may require the definition of a variety of classes for the same
object types. The programming style of a class definition determines the internal structure
of the description and additional properties. System aspects such as concurrency,
distribution, and implementation technology determine what behaviour description
style is most appropriate. To distinguish these aspects we introduce additional concepts
in the following chapter.
4.17 Summary
We defined concepts derived from the many varieties of the object-oriented paradigm.
This chapter focused mainly on how objects can be used for conceptual and static
modelling of a problem domain. We showed that there are various interpretations of
the concept of object, because the concept itself is not yet completely understood. The
most important concepts for handling complexity, such as aggregate, composite, cluster,
have been defined. Besides that concepts for the description of properties of objects
(such as identity, attributes, and operations), as well as properties of composites have
been introduced. Relationships and their properties have been defined to enable socalled
object modelling. For a more complete understanding of objects we describe the
concepts for the description of its dynamic behaviour in Chapter 6.