Convert quality requirements to functionality

The three types of architecture transformation techniques discussed in the sections above are primarily concerned with reorganizing the functionality already present in the architecture. By reorganizing the functionality in new structures, the quality attributes of the architecture are improved. However, this is not always sufficient. Often, it is necessary to add additional functionality to the system not concerned with the application domain but primarily with improving the quality attributes.

sensor concrete sensor abstract sensor strategy update strategy trigger periodic update on change update client update

Transformation of Software Architectures

The fourth and final type of transformation is the conversion of a quality require- ment into a functional solution that consequently extends the architecture with functionality not related to the problem domain but used to fulfil the requirement. Although this type may require minor reorganizations of the existing architecture, the primary effect is the addition of new components and functionality. Exception handling is a well-known example that adds functionality to a component to increase the fault-tolerance of the component.

Many examples of this type of transformation exist, although we have traditionally not necessarily considered these examples as quality attribute-improving transfor- mations. In the next section, two examples are discussed, i.e. self-monitoring and redundancy. Section 6.2 presents an example of this type of transformation.

6.1 Converted quality requirements and quality attributes

The type of transformation discussed in this section is different from the types dis- cussed earlier since it adds functionality to the architecture, rather than reorganizes the already present functionality. In this section, we discuss two examples of this type of transformation.

Self-monitoring. Although an architecture may provide the required functionality

under ideal circumstances, it often is unclear how well it handles unexpected situa- tions, such as failing components, hardware that breaks and external systems that go down. To address this, one solution is to add self-monitoring to the system. Analogous to the architectural patterns for GUI, i.e. MVC and PAC, two alterna- tives exist. One can add a layer on top of the system that monitors the behavior of the system, similar to the base-layer of the system that monitors relevant behavior in the real-world. Alternatively, the self-monitoring behavior is modeled as a hier- archy that mirrors the existing component hierarchy. Independent of the alternative chosen, the behavior of the monitoring includes not just identifying and reporting problems, but generally also actions to solve the problems. Below, the effect of add- ing self-monitoring functionality to the architecture on the quality attributes is dis- cussed.

• Self-monitoring adds an additional subsystem (either logical of virtually) to the architecture that requires computational resources, but is unrelated to the application domain. Consequently, there is a, sometimes considerable, per-

formance impact.

• The subsystem for self monitoring increases the system size which has an

immediate negative effect on maintainability. However, there is an addi- tional effect as well: the code related to the application domain has to be

Convert quality requirements to functionality

mixed with the code for monitoring in order to detect erroneous situations. This increases the complexity of existing architecture, with corresponding effects on maintainability.

• Although this transformation has a negative impact on both performance and

maintainability, reliability is definitely improved. The ability of the system to detect problems and take countermeasures is increased.

• The same line of reasoning holds for safety. The ability to detect potentially hazardous situations, increases the likelihood that the system, or part of it, can be brought to a fail-safe state.

• Self monitoring can be used to identify errors, but also to detect suspicious patterns of behavior, which could be used for improving security. However, this type of application is less frequent than the earlier two.

Redundancy. To increase the fault-tolerance of software, the notion of redundancy,

originating from hardware, has also been applied to software. Since it serves little use to use multiple copies of the same software module, different implementations of the same requirement specification are required, i.e. N-version programming [Storey 96]. N-version programming is often complemented with recovery blocks, allowing the system or a module, upon the detection of an error, to abort and return to a system or module state saved earlier at a recovery point. Typical computation consists of creating a recovery point, for each version of a module, compute the results and test the values for acceptance, and finally accept the values as correct data, allowing the module to create the next recovery point. An alternative approach is to order the implementations as primary, secondary, etc. and to only execute the, e.g. secondary, version if the acceptance test for the, e.g. primary, ver- sion failed.

• The performance of the system is seriously decreased using N-version pro-

gramming, especially when using the first approach. However, this can, at least partially, be addressed by using a multi-processor system and executing the versions in parallel on different processors.

• Obviously, N versions of the same module will also need to be changed

when the requirements change, thus having a considerable impact on main-

tainability. In addition, the use of recovery points complicates the code con-

siderably.

• Obviously, the primary reason for using redundancy is to increase the reli-

ability and the safety of the system. The risk for the system failing due to

software errors is decreased considerably.

Transformation of Software Architectures

6.2 Example

In the example fire alarm system, there are quality requirements related to self- monitoring and availability. In certain cases, detected faults should be handled using hardware redundancy, whereas in other cases problems should be indicated to the fire brigade or the persons responsible for system maintenance. These require- ments are, at least, partially fulfilled by transforming them to functional require- ments similar to the basic alarm requirements. The corresponding architecture extended with entities dealing with self-monitoring is presented in figure 21.

FIGURE 21. Self-monitoring in the fire-alarm system architecture

The above solution is a typical case where a logical additional layer is added to the system for self-monitoring. In the dialysis system, we used an alternative approach. As discussed in chapter 3, the primary archetype in the dialysis system architecture is the Device. As shown in figure 22, each domain device may have one or more alarm detector devices associated with it that monitor for potentially hazardous sit- uations. Once an alarm has been detected, the alarm detector device activates an appropriate alarm handler by sending an alarm event.