Software Design Methodology 205
8.2 DESIGN SPACE OF ARCHITECTURAL ELEMENTS
To a certain extent, design is to ‘find the right component of a structure’ .
Therefore, it is of vital importance to understand the variety of components so that
the right component can be found and used as well as the variety of ways that
components can be put together. The structure of such varieties forms a space in
which particular designs are elements. In this section, we consider the variety of
software architectural elements and apply the theory of design space to such
elements. Here, by software architectural elements, we meant both components and
connectors. We systematically present knowledge about software architectural
elements as a design space. To do so, we examine various observable properties of
software architectural elements.
Notice that, software design has a fundamental difference from the designs of
other physical artefacts. As discussed in Chapter 3, software systems are invisible;
hence the notion of observable properties for physical artefacts does not make
much sense for software. However, properties of software artefacts can be divided
into two types: behaviour features and static features. They are similar to the
functional features and observable properties, respectively. Therefore, we will first
examine the behaviour features of various software architectural elements and then
discuss the static features of software architectural elements.
8.2.1 Behaviour features
Behaviour features of an architectural element represent the dynamic behaviour of
the element over time. The execution of an architectural element can be viewed as
a series of contiguous temporal ‘episodes’. Each episode is a continuous period of
time in which the element is continuously active under at least one thread of
control. Figure 8.2 illustrates the temporal view of the execution of a single
architectural element in one episode. There are two threads of control flow through
the element. The thread A begins at time t
and terminates at time t
. The thread B
starts at t′
and terminates at time t′
. The figure also shows that data entering and
leaving thread A via the arrows labeled d
, and d
, and entering and leaving thread
B via d′
. The time t
are the instants when the episode starts and
206 Chapter 8. Architectural Design Space
Figure 8.2 Illustration of the temporal view of architectural elements
The behaviour features of a software architectural element are concerned with
the temporal relationships between the run-time events of the elements. For
example, whether or not does the acceptance of data always happen at the same
time when control is accepted? Whether or not a second thread of control can be
accepted? And so on. For this reason, behaviour features are called temporal
features in [
4]. Questions like these fall into the following 6 groups. Different
answers to such questions form various behaviour attributes.
(1) Times of control acceptance. Attributes in this group are concerned with when
the acceptance of control can happen with respect to the start of the episode.
Different answers to this question lead to the following attributes.
y Non-executable (Not accept control): The element does not accept control
at any time, i.e. the element is not executable.
y Accept control at start time: The time t
that the element accepts control
can be the start time of the system t
y Accept control during execution: The time t
that the element accepts
control can be any time after the system start time t
(2) Times of control transmission. Attributes in this group are concerned with
when the transmission of control can happen with respect to the end of the
episode. Similar to the above, different answers to this question lead to a set of
y Transmit control at termination: The element may transmit control at the
when the episode terminates.
y Transmit control during execution: The element may transmit control
before the time t
that the episode terminates.