Software Design Methodology

Software Design Methodology 181

could go wrong when combining a number of architectural styles into one design to

form a simultaneous heterogeneous architecture which inherits all the

disadvantages of the styles without any benefit of their advantages.

7.2.3 Locationally heterogeneous styles

A software system seldom appears in the exact form of an architectural style as

theoretically defined in the previous chapter. For example, the Java virtual machine

described in Chapter 6 can be regarded as in the virtual machine architecture if we

focus on the subset of components and connectors within the boxed area in Figure

7.2, which is reproduced below.

Figure 7.2 Example of locationally heterogeneous style: JVM

A software system’s architecture is in a locationally heterogeneous style if it

can be considered as in one style when taking a subset of its components and

connectors, meanwhile it can also be viewed as in another style when taking a

different subset of the components and connectors.

For example, if we redraw the architecture diagram of the Java virtual

machine as in Figure 7.3 below, we can find that it is in the main-program-and-

subroutine with shared data style.

Class files

Class Loader

Method Area

Java Stacks

Heap

PC Registers

Execution

Engine

Native

Method

Stacks

182 Chapter 7. Using Styles in Design

Figure 7.3 Alternative view to the architecture of JVM

Software systems’ architectures in locationally heterogeneous styles exist for

the following reasons.

First, the theoretical definitions of architectural styles are abstractions of

collections of software systems that have common features in their architecture

structures and behaviours. Those components and connectors have no significant

impact on the systems’ most important features hence do not necessarily appear in

all of the systems and are therefore hidden from the theoretical definition. This

enables the most important and dominating features and dynamic behaviours of the

systems to be clearly demonstrated and inferred from the definition without

interference of unnecessary and less important components. However, in practical

uses of a style, it is inevitable to add and/or modify some of the structural or

behavioural features into the architectural design of the systems. For example, the

theoretical definition of the virtual machine architectural style has ignored the issue

how programs and initial data are loaded on to the virtual machine. This issue

cannot be ignored in the design of Java virtual machine because it must allow the

program code for classes to be dynamically loaded to the system. It is, therefore, no

surprise to see a class loader component in the architecture of JVM in addition to

those relatively standard components of a virtual machine.

Second, the architectural styles that we have recognised are still far away

from a complete catalogue. In fact, it is doubtful if such a complete catalogue could

even be developed. Therefore, it is inevitable that sometimes we can only partially

recognise the architectural style of a system and have several different such partial

understandings of a software system’s architectural style. When there are several

different views of a system’s architectural style, a question remains for which style

Controller

Instruction A

Instruction B

Instruction C

Instruction Z

…

Class files

Class Loader

Method Area

Java Stacks

Heap

PC Registers

Native

Method

Stacks