Designing Software Architectures to Achieve Quality Attribute Requirements

Abstract:

In order to have a software architecture design method that achieves quality attribute requirements several aspects of the method must be in place.

• • First there must be some way to specify quality attribute requirements so that it can be determined whether the designed architecture can achieve them.

  • Secondly, there must be some way for modularising the knowledge associated with quality attributes so that the design method does not need to know how to reason about all of the multiplicity of quality attributes that exist.

  • Finally, there must be some way for managing the interactions among the quality attributes so that either the requirements can be satisfied or the ones that cannot be satisfied are identified.

The authors describe a structure called a ‘reasoning framework’ as a modularisation of quality attribute knowledge. The requirements that the architecture must satisfy are specified as concrete quality attribute scenarios. Each reasoning framework provides mechanisms that will transform the architecture with respect to a given quality attribute theory. Within a reasoning framework, the authors distinguish between an architectural model and a quality attribute model and characterise the actions that a reasoning framework undertakes as basic architectural transformations.

Finally, the process of identifying interactions among reasoning frameworks is begun so that conflicting requirements can be managed. The use of reasoning frameworks is situated inside an existing architectural design method so that a useful method exists while the open issues of designing to achieve quality attribute requirements are resolved.

Introduction:

Designing an architecture so that it achieves its quality attribute requirements is one of the most demanding tasks an architect faces. It is demanding for several reasons including a lack of specificity in the requirements, a shortage of documented knowledge of how to design for particular quality attributes, and the trade-offs involved in achieving quality attributes.

It would be desirable to have a method that guides the architect so that any design produced by the method will reliably meet its quality attribute requirements. Any such method must have several features:

• • It must have provision for including a wide variety of quality attribute knowledge. ISO 9126 -1 [1] lists six primary quality attributes and 21 secondary quality attributes and this list is not complete, e.g. it omits variability among others. A quality attribute requirement can affect any attribute whether on the list or not and so a method to achieve all quality attribute requirements must embody great breadth in reasoning about quality attributes.

  • It must have provision for managing trade-offs that is outside any of the existing quality attribute specific knowledge. Some formal knowledge exists about trade-offs between specific attributes but any method that claims to be able to design to achieve any quality attribute requirement must be able to manage trade-offs among arbitrary quality attributes. Such broad knowledge does not yet exist.

  • It must have provision for interpreting quality attribute knowledge in terms of software architectures and for interpreting a software architecture in terms of the quality attribute knowledge. Software architectures are described in terms of software elements and their relations. This can include hardware elements in addition to behavioural descriptions. Quality attribute knowledge is embodied in other terms. The model of modifiability we use [2] considers dependencies among modules, probabilities of change propagating and cost of modification. These concepts can be translated into software architecture concepts such as relations among modules and properties of modules and relations but any method must have a provision for making that translation.

In this paper we propose a modularisation of quality attribute knowledge that encapsulates both quality attribute models and the relationship between these models and software architecture and give examples of this encapsulation. We define what it means to have a trade-off in terms of the modular concept. Finally, we embed these concepts into a pre- existing design method to give some structure to their use.

Quality Attribute Requirements:

Our desire to keep quality attribute knowledge encapsulated has two implications. One that we have discussed is to keep quality attribute knowledge inside the modular structure. This is the purpose of the reasoning framework in this work. Keeping quality attribute knowledge inside the reasoning framework means keeping it out of the general design method. That is, the general design method should not know specifics of any particular quality attribute.

One consequence is that the general design method should have a form for specifying quality attribute requirements that is suitable for specifying any quality attribute requirement, regardless of quality attribute. We use quality attribute general scenarios for this purpose.

A general scenario is a system independent description of a quality attribute requirement. It has six parts:

• • Stimulus: a phenomenon that needs to be considered when it arrives at a system (either executing or in development). Examples are an event arriving at an executing system or a change request arriving at a developer.

  • Source of the Stimulus: the entity (e.g. a human or computer system) that generated the stimulus. For example, a request arriving from a trusted user of the system will in some circumstances be treated differently than a request arriving from an untrusted user.

  • Environment: the conditions under which the stimulus occurs. For example, an event that arrives when the system is in an overload condition may be treated differently than an event that arrives when the system is operating normally.

  • Artifact: the artifact affected by the stimulus. Examples include the system, the network, or a subsystem.

  • Response: the activity undertaken after the arrival of the stimulus. Examples include processing the event for event arrival or making the change without affecting other functionality for a change request.

  • Response Measure: the attribute-specific constraint that must be satisfied by the response. Examples are that the event must be processed within 100 ms or that the change must be made within two person-days. Response measures can also be Boolean such as ‘The user has the ability to cancel a particular command (yes or no)’.

Future Work and Conclusions:

We have described a set of concepts intended to support a formal design process. In particular our definition of the elements of a reasoning framework makes explicit the distinction between architectural models and quality attribute models and the requirement for a mapping between them. Some of the important points of our approach are:

• • All quality attributes are treated in the same terms. There is a set of concepts that each reasoning framework must include and the output of each reasoning framework is a transformation. This enables a method that uses quality attribute reasoning frameworks to treat them in a ‘plug and play’ fashion.

  • A formal approach does not support designing for non- explicit requirements. Normal practice is to separate and encapsulate most identifiable large blocks of responsibility. Use of a reasoning framework for modifiability only supports separating and encapsulating those blocks of responsibility that are explicitly included in quality attribute requirements. Similarly for performance requirements. This places a burden on the ensuring that the quality attribute requirements are complete.

  • We have begun to identify what is meant by interaction among the reasoning frameworks. The use of trade-offs is not appropriate when using a formal approach such as we are advocating here.

  • The reasoning frameworks require a level of formality in specification of variables that is not always natural to an architect. This suggests that their use requires tool support.

We have, in fact, produced a prototype system named ArchE (Architecture Expert) to support our extensions to ADD. Space precludes going into any detail about ArchE here although it was ArchE that was used in the commercial design effort we alluded to earlier.

One item that we plan to focus on in the immediate future is the managing of trade-offs and how to more systematically manage the interactions among the reasoning frameworks. Within this context, we also plan to investigate the impact of using a less stringent form of specifying quality attribute requirements that allows for differentiation between different values of the response measure. This will, of course, introduce substantial new functionality to our system.

In conclusion, although the use of reasoning frameworks as an adjunct to a design method is not yet ready for industrial strength use, we believe that we have demon- strated that reliance on quality attribute specific reasoning frameworks provide a means for generating a design and holds promise for the ability to scale to be industrial strength. The uses of reasoning frameworks have the qualities that we asserted in the introduction were necessary for any formal method that supports the achievement of quality attribute requirements.