Design in CommUnity with Extension Morphisms - Formal Methods and Hybrid Real-Time Systems - page 436

self-managing architectures, which not only implement the concept of dynamic
change, but also initiate, select and assess the change itself without the assistance of
an external user. We are currently interested in ADLs with support for dynamic soft-
ware architectures and that also support the essential engineering concept of hierar-
chical design. Examples of ADLs, which support such a view, are Dynamic Wright
[11], Darwin [31] and Dynamic Acme [19][38]. An assessment of these languages
can be found in [13] and a more thorough review of their language constructs, associ-
ated styles of specification and mechanisms to achieve dynamic reconfiguration can
be found in [27]. However, these ADLs have important shortcomings in relation to
their support for hierarchical design and having a formal semantics that enable us to
perform useful analyses.
CommUnity [15, 29, 30] was designed to study the problem of the 'magic step'
from specification to program, in the context of component based design using tempo-
ral and multi modal logics for component specification. It is always the case that the
languages used for specifications and programs are ontologically very different.
Specifications are about properties, whilst programs are about operational behaviour,
even if this behaviour is described abstractly. For one thing, a programming language
has no facility to express properties of programs; a meta language of properties is
required for this. So, programs and specifications occupy different conceptual worlds
and there is not a simple notion of homomorphism or refinement that relates them
directly: hence the reference to the 'magic step' above. What is the relationship be-
tween specifications and programs and how can one remove the magic? We cannot
talk about the program being a refinement of a specification, as refinement is an inter-
nal notion in the language of component specifications. We might introduce a notion
of realization , which relates a program to its specification by assigning to the program
a minimal (not unique and minimum) specification, which is a refinement of the
specification.
CommUnity explored this space and addressed the important issue of composition-
ality in this context: when can we say that a program constructed from parts, where
each part is a correct realization as a program of the corresponding specification part,
is correct with respect to the specification constructed from the component specifica-
tions in a way that mimics the construction of the program? Not too surprisingly,
compositionality in this sense is not an easy property to achieve. Given an arbitrary
specification language and some programming language, not every program con-
structed from parts is correct with respect to the corresponding specification. This is
not surprising, as the structural properties of the specification category may not mimic
that of the category of programs, or vice versa .
We have been extending CommUnity to encompass features we regard as essential
for architecture based design, namely hierarchical organization of subsystems and
dynamic reconfiguration [26]. However, in this paper the new features of DynaComm
are not essential for the presentation, so, for the sake of clarity, we avoid the presenta-
tion of its extra details and features.
Recently, we have been exploring the issue of 'early aspects' [39], attempting to
see if these ideas can be rationalized, based on traditional software engineering prin-
ciples of modularity and hierarchy, by analyzing them at the architectural level. After
numerous case studies, we have come to the conclusion that aspects are just the soft
goals or non functional requirements traditionally found in requirements engineering,