Architecting Quality: A Goal-Oriented, Knowledge-Based Approach

Lawrence Chung

Department of Computer Science

The University of Texas at Dallas

ABSTRACT

Architectural design is becoming increasingly important, one important reason being the shift in software engineering paradigm from centralized, stand-alone, built-from-scratch systems to distributed, cooperative, componentized systems. Achieving quality, however, remains a difficult task. The success depends on our capability to formulate quality, and to design the right parts and their relationships accordingly. Nonetheless, quality such as adaptability, performance and security is usually ill-defined, tentative, conflicting, subjective and knowledge-intensive. Furthermore, there can be a large number of allowable parts and relationships, hence leading to a combinatorial explosion, in the space of architectural alternatives.

This paper presents a systematic framework to help architects achieve quality requirements during architectural design. In the framework, quality requirements are explicitly represented as "softgoals" to be "satisficed". Throughout the architectural process, softgoals are incrementally refined, architectural alternatives are considered, design tradeoffs are analyzed, and design decisions are rationalized. The entire process can be supported by a knowledge-based tool, and concisely and precisely recorded in a "softgoal interdependency graph" which enhances comprehensibility, traceability and evolvability.

1. INTRODUCTION

Architectural design portrays the infrastructure of the system components, interactions, constraints and rationale behind choices at a high-level of abstraction [Shaw] [Bass]. As such, architectural design is becoming increasingly important, one important reason being the shift in software engineering paradigm from centralized, stand-alone, built-from-scratch systems to distributed, cooperative, componentized systems. This new paradigm is expected to yield a nice benefit: "the whole can be greater in utility, or quality, than the sum of its parts", as the synergistic relationships between the parts can add to the value of the system.

Achieving greater quality, however, remains a difficult task, since quality such as adaptability, performance and security is usually ill-defined, tentative, conflicting, subjective and knowledge-intensive. Although quality has long been regarded as an essential property of any software system since the early days of software engineering [Boehm76, Bowen85, Brooks87, Thayer90], much of Software Engineering has focused on dealing with the functional aspect of a software system. If quality is as crucial to system success as we profess them to be, however, we should aim to properly address it as early in the development cycle as possible, just as there are techniques for dealing with the functional aspect of the system.

Furthermore, there can be a large number of allowable types of parts and relationships between the parts for the target design. The dominant macroscopic system architecture, for example, can be among many different styles, such as client-centric, server-centric, database-oriented, transaction-oriented, groupware-oriented, data warehouse-oriented, NC (Network Computer)-centric, PC (Personal Computer)-centric, etc. Parts of the system can communicate with each other through a variety of mechanisms, such as point-to-point direct procedure calls, implicit invocation, middleware, etc. At the microscopic level, there already has been identified a number of software architectural styles including pipe-and-filter, process-control, layered, blackboard, passive central repository, object-oriented, etc. Even within the same style, there can be sub- and hybrid- styles, with many different numbers and types of components, interactions, constraints and patterns. Blessing as this broad diversity may be, it can lead to a combinatorial explosion in the space of architectural alternatives, naturally many of them with undesirable properties or quality.

This paper presents a goal-oriented, knowledge-based framework to help formulate quality and build quality in the architecture in terms of “good-enough” parts and relationships between the parts accordingly. This is an adaptation of the NFR Framework [CNYM99] which was developed as a process-oriented framework to provide a systematic approach to dealing with non-functional requirements. Unlike approaches that perform evaluations on completed designs or finished products, the approach puts non-functional requirement up-front as goals to be achieved and explores, and chooses among, alternatives at many points during the software development process hence narrowing down on the potentially infinite space of design and building quality in.

In the framework, quality requirements (non-functional requirements or NFRs) are explicitly represented as "softgoals" to be "satisficed". Throughout the architectural process, softgoals are incrementally refined into more concrete ones, architectural alternatives are considered in terms of the allowable parts of the system and relationships between the parts, design tradeoffs are analyzed as conflicts and synergies are discovered, and design decisions are rationalized in relation to the characteristics of the intended application domain. The entire process can be supported by a knowledge-based tool, and concisely and precisely recorded in a "softgoal interdependency graph" which enhances comprehensibility, traceability and evolvability. This way, desired non-functional properties serve to systematically guide selection among design alternatives.

Section 2 presents the goal-oriented approach of the framework. Section 3 presents the knowledge-based approach for the capture and reuse of NFR-related and architecture-specific knowledge. Section 4 discusses related work and experiences with the approach. A summary of the contributions and future research are described at the end.

2. GOAL-ORIENTED ARCHITECTING

In order to properly build quality in the system/software architectural design, the architect needs a systematic approach to formulating architectural quality, as perceived by the stakeholders of the system, and then designing the right parts of the architecture and the right relationships between the parts accordingly. Such an approach should also help the architect explore as many allowable parts and relationships between the parts, at least initially, and then narrow down on the number of alternatives later on by discarding those with undesirable properties or quality.

Taking quality concerns into account at an early stage is especially important since system-wide properties are usually determined as architectural decisions are made [CNY95]. Conventional approaches to quality typically evaluate several fully-specified architectures at the end of the architectural design process, thus severely limiting the range of options considered and their impacts. The NFR Framework’s goal-oriented approach encourages and supports the exploration of partially-specified alternatives at numerous decision points throughout the process and uses goals to guide selection within a potentially infinite space of alternatives.

The approach being presented in the paper advocates exactly this systematic approach through an adaptation of the NFR Framework [CNYM99]. In the NFR Framework, non-functional requirements of the stakeholders are explicitly represented as softgoals to be satisficed and incrementally clarified into more concrete ones. In relation to the softgoals, then, design alternatives are considered, design tradeoffs are analyzed, design rationale is recorded while accommodating the characteristics of the intended application domain, and design choices are made. The entire process can be concisely and precisely recorded in a "softgoal interdependency graph" which enhances comprehensibility, traceability and evolvability.

Adaptation of the NFR Framework is achieved by treating architectural styles, patterns, components, interactions and constraints as design components, or operationalizations of the stated softgoals and how they affect the softgoals. This way, NFRs act as the criteria for choosing among myriads of architectural design techniques and alternatives throughout the entire architectural design process, hence helping narrow down the set of architectural designs to be further considered for the target design.

Consider the development of a simple electronic order processing system (EOPS hereafter). The system should receive orders from the customers, issue invoices, ship the goods, accept payments and issue receipts. In addition to these functional requirements, the system should also meet non-functional requirements – good performance, easily extensible, user-friendly, security and highly reusable.

The architect represents NFRs explicitly as softgoals to be satisficed, i.e., goals to be satisfied not in a clear-cut sense but within acceptable limits. Figure 1 shows how some of the NFRs are represented as top-level softgoals of a softgoal interdependency graph.

Figure 1: Representation of NFRs as softgoals

Since NFRs often invite many different interpretations from different people, they need to be clarified as much as possible through refinements in discussions with the stakeholders. For example, the user-friendly requirement is refined into EasyAccess and IntuitiveInterface of EOPS. As in this example, each softgoal consist of two parts, the type (e.g., EasyAccess) and the topic (e.g., EOPS). A refinement is then carried out either on the type or on the topic, or both. Figure 1 also shows how to disambiguate the meaning of performance through a couple of refinemens. It is done first by introducing its topic [EOPS], i.e., the stakeholders’ concern lies in the performance of EOPS, not of any other things such as credit card verification systems, humans, etc. It is further refined, this time on its types, into three more concrete softgoals: Space [EOPS], Time [EOPS] and Responsive [EOPS], respectively referring to “minimize space consumption and response time, and maximize responsiveness, of EOPS”.

In addition to disambiguation, this kind of refinements also help the architect exploit the conventional “divide-and-conquer” paradigm to separate concerns and consider finer-grained design techniques. Through refinement, the Framework allows the architect to break the requirements down into smaller components, until their significance for design decisions becomes apparent.With sufficient refinements on NFRs, the architect can now consider design techniques specifically to achieve the leaf NFR softgoals, i.e., their operationalizations. For example, the architect considers a graphics-rich interface (a thick circle) in order to satisfice the IntuitiveInterface [EOPS] softgoal. A graphics-rich interface will display colorful pictures of the stock items the cutomer can choose from, the status of shipments and payments, etc.

Figure 2 illustrates this operationalization in an expanded softgoal interdependency graphfrom Figure 1 with more top-level NFR softgoals.

Figure 2: A softgoal interdependency graph with correlations.

Unfortunately, however, this operationalization can hurt the response time of EOPS (as shown as a dotted negative correlation), since the construction of a fancy interface can take up a significant processing time. Then the question is whether to use a graphics-rich interface in this conflicting situation.

Softgoals can be prioritized, and used in a conflict resolution, as well as in the allocation of time and resources. For example, the end-users may be expected to be naïve users and consequently an intuitive interface may be more important to satisfice than fast processing of user interface, assuming of course the response time will not go up intolerably. Note in Figure 3 how the expected user characteristics is recorded in the form of a claim (a dotted circle) which acts as the rationale for supporting the particular prioritization.

In order to ensure that this conditional claim holds, the architect feels the need to further decompose Time [EOPS], since a graphics-rich interface will not hurt every, but only a certain, aspect of the system response time. A decomposition results in the introduction of the response time concerning the user interface, along with the response times concerning data storage and other main processing. This decomposition makes it clear that a graphics-rich interface will hurt that part of the response time concerning the user interface only. The architect feels that this is tolerable and consequently makes IntuitiveInterface a higher-priority softgoal (an !) than the response time concerning the user interface, hence offering a graphics-rich interface.

Figure 3: A softgoal interdependency graph with a claim and a correlation specialization.

Having clarified NFRs and considered NFR-specific design techniques and tradeoffs, the architect now looks at the functional side of EOPS. The starting point again will be the requirements, here, the functional requirements (FRs). There can be a combinatorial explosion in the design space, due to time, manpower and cost constraints. Since exhaustive exploration is impractical, only some will have to be chosen, at various points during the process of architectural design, for further consideration out of a satisfactory number of alternatives. The basic cycle will involve operationalization of FRs through (architectural) componentization and composition, while integrating NFR-specific design techniques into the architectural alternatives as a whole. This would result in different styles, patterns, components, connections and constraints. Throughout this cycle, NFRs will be used to explore alternatives and narrow down on the number.

Consider, for example, componentization. The architecture may have only a single component carrying out all the processingin. In another componentization, a large number of tiny components may carry out bits and pieces of the needed processing. Neither of these two extremes may be satisfactory, but the number of components may need to be close to the number of main functions in the functional requirements, for example from four to six components. Figure 4 illustrates the use NFRs during componentization. In the architectural alternative with four components, one component interleavingly carries out both the generation of the invoices and the shipment of the goods ordered, since the two activities can overlap, e.g., in the generation of address labels, the recording of the dates, etc. In the other one with five components, two distinct components carry out the two tasks separately. The former may result in faster processing than the latter, but at the expense of low cohesion, hence hurting enhanceability.

Note that new NFRs can be introduced and decomposed during the functional mapping process, as needed.

There can also be a number of alternatives for styling. For example, a simple repository as the architectural style may result in faster processing than a repository with an event manager, since enforcing an event manager involves detection, announcement and control of (concurrent) events which can induce significant overhead. On the other hand, a repository with an event manager allows for a higher level of process independence, hence extensibility.

Figure 4: A softgoal interdependency graph with functional mapping for EOPS.

Similarly, concerning the architectural patternization, a long chain of sequential processes, when compared to a highly coupled one, may improve process independence, hence extensibility, but possibly at the expense of performance, both space and time, due to data duplication.

Sub-styling is another decision point. Will the main processing components be objects, communicating directly with each other, or filters which do not. Consideration of control is yet another. Does the architecture need a master control or the control is distributed more or less equally among the processing components? Consideration of interfaces is yet another task. How many interfaces should be provided for an object, how many parameters, what parameter types, etc.? How about constraints on the components and connections?

All the activies of the FR-specific activities should, of course, be carried out in consideration of the NFR-specific design techniques, which have to be integrated into the candidate architectural alternatives. This integration may result in …

As can be seen in these illustrations, there are usually a number of NFR operationalizing softgoals, i.e., design techniques that can be used to satisfice NFRs, There can also be a number of FR operationalizing softgoals, i.e., design alternatives, due to the presence of multiple ways of componentization and composition. The goal-oriented approach helps the architect consider these alternatives, carry out tradeoff analysis in consideration of the domain characteristics, such as the workload, user background and expected usage scenario, and represent them as claims as a way to rationalize the design decisions. The approach also makes it possible to use NFRs as the criteria for reducing the number of choices to be further explored at various decision points during the mapping of the functional requirements. All these interleaving architectural activities are captured in an historical record "softgoal interdependency graph", hence clearly establishing traceability between requirements, both NFRs and FRs, and the design for later review and evolution.

3. KNOWLEDGE-BASED ARCHITECTING

By taking a goal-oriented approach, the architect can become systematic, namely, to be explicit about quality concerns, consider various techniques to clarify and satisfice NFR softgoals, as well as FR-specific design alternatives, and carry out tradeoff analysis while considering priorities and other domain characteristics. One difficulty in architecting quality lies in the acquisition of the needed know-how for carrying out the numerous types of activities, which can be quite time-consuming and costly. Many types of know-how are usually scattered around, often thinly, in the literature or in the minds of software practitioners. Once gathered, such precious know-how is used only once, then resides only implicitly in the minds of the architect, soon to be forgotten.

In order to alleviate the difficulty with this kin dof search, thus, the architect needs the ability to systematically search for the needed know-how, namely, the various precious know-how of NFRs and architectural design, and encode them for later extension, tailoring and reuse. Put differently, the architect needs a knowledge-base of catalogues (like a "cook book") for considering architectural alternatives, tradeoffs, decisions and rationale.