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

108 Abstraction of a Problem Domain
the data (attributes) are determined by the need to exchange data via communication
flows. The natural need for new objects to be defined, comes from the need to contract
out operations. An accompanying need to transport and store data determines additional
attributes. The classes containing these objects are specified after playing various
scenarios of behaviour in Message Flow Diagrams. Therefore, depending on the sort
of communication that is used, links to objects can yield attributes in a natural way.
When the Object Class Modelling approach is used at least a part of the relationships
must also be implemented this way. It will be clear that both modelling approaches
have advantages and disadvantages. The instance approach is quite implementation
and construction-oriented, and leads to quick results. The Object Modelling approach
is useful for a conceptual approach, and is more appropriate to define the real world
problem domain. This definition is however time consuming. There are uncountable
possibilities to combine various decisions to refine relations into attributes, objects or
operations. Only mature judgement will lead to a balanced result, that redeems some
of the promises of object-orientation, such as reusability.
4.14.2 Variables
Attributes become variables in the formal behaviour description of the object classes in
POOSL. The abstraction level where POOSL descriptions are created is lower than the
abstraction level of Object Modelling. Variables model the attributes specified during
conceptual modelling, but they also support lower level needs such as local data and
identifiers of acquaintances.
There are various ways to define sorts of variables for various purposes. For instance,
Smalltalk offers private variables in the form of Instance variables and Temporary variables.
Besides that there are variables that can be accessed by more that one object: Class
variables, Global variables, and Pool variables [GR89]. The latter three types are all used
for sharing variables among objects. They are shared respectively by instances of a single
class, by instances of all classes, and by instances of a set of classes. The Smalltalk
language is untyped. This is in contrast to Eiffel [Mey88] which is a second example
of an object-oriented language. Eiffel is a statically typed language. Every attribute of
a class is declared with a unique type. Private local variables are used by routines to
perform their computations. Eiffel does not support any form of shared variables. These
two examples of languages show already that there is a world of alternative concepts in
the design of methods and languages.
Currently, POOSL is an untyped language, just as Smalltalk is. POOSL offers instance
variables and temporary (local) variables, but no form of shared variables. To enable
adequate static checking of specifications, POOSL will become a statically typed language
(see also Subsection 4.3.4). To achieve this, we will have to define a formal type
system. Such a system is not formally developed yet. For the time being, however, we
will assume that each variable is assigned a type. This type is specified by indicating
the class of the instances to which the variable is allowed to refer.