Database Reference
In-Depth Information
of representation of behavior are reached when dealing with the concepts we have gathered
in the maps of the architecture. In other words, the more sophisticated the behavior to be
modeled, the more complex and hard it is to specify maps
TTT
and especially
T
. Because of
T
this, we propose a kind of refi nement that facilitates the specifi cation of both maps, and that
allows the expression of the desired degree of detail. For instance, map
T
could be refi ned
T
by dividing it into several maps, specifying a chain of
Intermediate Snapshot Stages
start-
ing from the Snapshot Layer (see Figure 3). These stages represent intermediate situations
between two consecutive statuses, as they are necessary to detail the usually hard passage
from a current status to another. For instance, Diagram 3 of Figure 2 represents one of these
intermediate situations for the particular thermostat example. Our perspective has been
inspired by the literature: for instance, in the original fi rst Statecharts semantics (Harel et
al., 1987), the concept of
micro-step
was introduced to alleviate the diffi culties in defi ning
the noticeably more complex concept of
step.
With regard to how many intermediate stages
should be specifi ed, and therefore the number of maps, this decision is left to the discre-
tion of the analyst, who has to take into account that the greater the number of stages, the
greater the degree of detail. Whatever the number, the composite
T
n+1
T
n+1
T
°
T
n
° ... °
T
2
T
2
T
°
T
1
T
1
T
must
give map T as a result.
System Development Issues
The proposed architecture provides an interpretation of behavioral features that can help
in system development at different levels of abstraction, according to the different views that
several kinds of users (software engineers, tool developers, method engineers, etc.) have on
the subject. For instance, a system analyst or designer would use this approach to behavior
to get a more accurate interpretation of the system being modeled. In particular, this model-
ing task would be facilitated if the language chosen by the software engineer to model the
behavioral features was precisely described following the guidelines of the architecture.
In turn, such behavioral modeling languages can be supported by CASE tools, which
have been recognized as being of great value in software development. The consideration
of the proposed architecture can provide guidance for the analysis of existing CASE tools
and the development of new ones, according to the developers' purposes. Focusing again
on the statecharts formalism, and as has been previously stated, a standard statechart model
Figure 3: Refi nement of map T of the architecture
