Received 21 August 2001; revised 7 January 2002; accepted 6 February 2002
Abstract
Recently, the coupling of goal-based and user-centered approaches has resulted in a tremendous impact on the research of software engineering. However, there is no systematic way in the extant approaches to handling the effects of requirements on the structuring of software architectures. As an attempt towards the investigation of the interactions among goals, scenarios, and software architectures, we proposed, in this paper, a goal-driven architecture trade-off analysis method to analyze and construct software architectures in an incremental manner. We also identi®ed criteria for architecture evaluation and veri®cation and explored the possible types of realization of software architectures for goals. The proposed approach is illustrated using the problem domain of virtual university environment. q 2002 Elsevier Science B.V. All rights reserved.
Keywords: Goal; Use case; Software architecture; Trade-off analysis; Virtual university
1. Introduction
Recently, the coupling of goal-based and user-centered approaches has resulted in a tremendous impact on the research of software engineering. As goals information is valuable in identifying, organizing and justifying software requirements, goal-based requirements analysis methods have attracted an increasing attention in requirements analy- sis [1,2,6,9,34]. The tenet of goal-based approaches focuses on why systems are constructed, which provides the moti- vation and rationale to justify software requirements.
Meanwhile, use case have been recognized as an important modeling tool in requirements engineering, as the user-centered concept is useful in elicitation, analysis and documentation of requirements [7,8,14,26±28]. Klaus Pohl [25] also emphasizes that one of the main goals of requirement engineering process is to accomplish a common agreement on the views of the involved users.
Use case elicit requirements from a user's point of view, and are seen as a good way to reach such an aim.
The importance of software architecture has also been noticed in serving as a communication vehicle among stake- holders, helping in making early design decisions, and
making easy the transferable abstraction of a system [3].
The software architecture of a system describes how it is decomposed into components, how these components are interconnected, and how they communicate and interact with each other and with the environment. Software archi- tectures represent critical, system-wide design decisions that affect quality, recon®gurability and reuse, and the cost for development and maintenance [12,13,24].
However, there is little support for building or modifying a software architecture to meet a set of functional and non- functional requirements [33]. Mary Shaw proposes a maturity model and possible ways to develop software architecture in the coming future [30]. Shaw claims that the software architecture is well into the phase of develop- ment and extension, and that enhancement and exploration are beginning in earnest. Research remains to be done, espe- cially in the area of showing the range of utility of various styles, formalisms, design techniques, and tools.
Inspired by Shaw's work, we propose an extension of our previous research on goal-driven use cases (GDUC) [20,21]
(called goal-driven architecture trade-off analysis method, GAAM) as an attempt towards the analysis and construction of software architectures based on the interactions among goals, scenarios, and software architectures. Furthermore, we also investigate the criteria for evaluating the software architecture derived from goals, scenarios and use case model, as well as explore the possible types of realization
0950-5849/02/$ - see front matter q 2002 Elsevier Science B.V. All rights reserved.
PII: S0950-5849(02)00021-6
* Corresponding author. Tel.: 1886-34227-151; fax: 1886-34222-681.
E-mail addresses: yjlee@selab.csie.ncu.edu.tw (J. Lee), glenn@selab.csie.ncu.edu.tw (K.-H. Hsu).
of the software architecture for its corresponding goals.
There are three phase involved in GAAM:
² Goals are used to structure use case models and to derive use cases: A use case is viewed as a process that can be associated with a goal to be achieved, optimized, main- tained, ceased, or impaired by the use case.
² Stable kernel in a goals hierarchy is used as a basis for establishing the architecture; Goals are organized to form several alternatives based on the types of goals and the interactions analyzed to form a goals hierarchy; and a software architecture is constructed using re®nement operators (i.e. append, add computational component, add data access, insert, arbitrator, compromise, and mutual exclusive) in an incremental fashion based on the stable kernel found in the goals hierarchy.
² Evaluation are made through exploring the types of reali- zation of the architecture: Architecture are evaluated by identifying the multiple execution paths, and by investi- gating the realization between goals and architecture components. A graph grammer based veri®cation is also provided for further architecture checking.
As good architectural design has been a major factor in determining the success of software system [31], the lack of a common understanding of the software architecture can lead to major error while developing, testing, and maintain- ing a system. To serve as a communication basis among involved participants, architecture description notations are in need to describe the software architecture. After examining various architecture description notations for describing software architecture, we found the key idea of an architecture description notation is to describe the components and connectors as a basis for communication among involved users. Instead of creating a new architec- ture description language (ADL) which might result in unnecessary confusion, using the ADL proposed in Soft- ware Architecture Analysis Method (SAAM) [16] will be suf®cient during the construction of architecture in this paper.
We chose the virtual university environment as an exam- ple throughout this paper to illustrate our approach for that (1) the demand for educational software systems is growing exponentially with the surge of interest in distance learning over the internet, and (2) the developing of the virtual university software can help us address the real world chal- lenges for requirements analysis and architecture design.
In the sequel, we ®rst describe background work on trade- off analysis methods in Section 2. We then fully discuss the GAAM concepts from its origin as a methodology assists system development to the architecture construction of the software system in Section 3. Virtual National Central University (VNCU) as a case study is addressed in Section 4. Issues that are not addressed in this paper are discussed in Section 5. Finally, we conclude by outlining bene®ts of the proposed approach and our future research plan in Section 6.
2. Background work: Trade-off analysis methods A number of researches in the area of trade-off analysis have [4,10,19] made its mark on our goal-driven architec- ture trade-off analysis method in various developing phases.
In the requirements analysis phase, a major challenge in requirements engineering is that the requirements to be captured are imprecise in nature and usually con¯icting with each other. Our previous work on requirements trade-off analysis technique [19] addressed the issue of how to formally model vague requirements. Con¯icting and cooperative degrees between any two individual requirements are formulated. Relationships between indivi- dual requirements are identi®ed based upon their con¯icting and cooperative degrees. Requirements are converted into the disjunctive normal form to obtain a uniform representa- tion of the requirements, and then arranged into an extended hierarchical aggregation structure, where requirements in each disjunction are expanded to form a requirements hier- archy. A requirements hierarchy is established based on the notion of criticality and the cooperative degree. Parameter- ized aggregation operator, fuzzy and/or, are selected to combine individual requirements. A compromise overall requirement can be obtained through the aggregation of individual requirements based on the hierarchical require- ments.
Easterbrook [10] proposes a framework for representing con¯icting viewpoints in a domain model. A viewpoint in his framework is a self-consistent description of an area of knowledge representing the context in which a role is performed. In evolving viewpoints, a new viewpoint will need to be split if it causes inconsistency. The new view- point and its negation are placed in different descendants of the original viewpoint, so that each remains self-consistent individually. The detection of con¯ict might be based on detection of logical inconsistencies. Thus, a hierarchy of viewpoints is established as the elicitation proceeds. The inheritance structure implies that the higher an item in the hierarchy, the more widely agreed it is. One of the aims of using viewpoints is to reduce the need for consistency checks. This approach allows many viewpoints to be combined into a single domain model without necessary resolving con¯icts between them. Con¯icts are treated as an important part of the domain, and are to be represented and understood.
The pioneer work by Boehm and In is to identify and diagnose quality-attribute con¯icts [4]. Their approach QARCC focuses on domain-independent con¯icts involving high-level quality-attribute and architecture-strategy con¯icts to achieve generality and scalability. For example, a layered architecture has a positive in¯uence on portability, but a negative in¯uence on performance.
In the architecture evaluation phase, Kazman et al.
propose in Refs. [15,17] to evaluate the competing architec- tures. In SAAM, the evaluation is imposed on candidate architectures developed by architects by testing the
executability of the architecture and by observing the satisfaction degree of the system scenarios. In order to increase the satisfaction degree, modi®cation to the architecture is in need, which may cause con¯icts occur in the architecture design on some architecture components called interact points. To this end, SAAM favors the architecture with the fewest scenario con¯icts. In the overall evaluation, we need to weigh each scenario and the scenario interactions in terms of their relative importance and to use that weighting to determined an overall ranking. The chosen from overall ranking based on the weight will re¯ect the relative importance of the quality factors that the scenarios manifest.
Kazman et al. also proposed another method called ATAM [17] to evaluate the software architecture. As an improved version of architecture analysis method, ATAM introduce trade-off analysis into the evaluation process. Candidate architectures are generated based on engineering design principles, requirements, and scenarios that collected from involved users. The candidate architectures must be described in terms of the architectural elements and properties that are rele- vant to each of the important quality attributes. The sensitivity point is then determined based on the analyses of each quality attribute with respect to each architecture. After the sensitivity points are determined, ®nding trade-off points is simply the iden- ti®cation of architectural elements to which multiple attributes are sensitive. Designer can then proceed to a more detailed level of design based on the analyses that shows the system's predicted behavior comes adequately close to its requirements.
The main problem with these works on architecture trade- off analysis is that they only focus on the choice of compet- ing architectures by rating the ®tness among the candidates which may result in wasting of time on constructing these candidates that might not be suitable for the working project. Moreover, constructing the software architecture driven by the information obtained from goal trade-off analysis can help reduce the effort on comparing among candidate architectures.
3. Goal-driven architecture trade-off analysis method As Borgida et al. pointed out in Ref. [5], a good require- ment modeling approach should take the problem of describing nature kind into account, which usually runs the risk of being subject to contradiction. Our goal-driven architecture trade-off analysis method (GAAM) (see Fig. 1)1 is spawn based on such a belief. There are three phases involved in GAAM.
1. to construct a goals hierarchy through the analysis of interactions among goals. In this phase, the interactions between goals (i.e. cooperative, con¯icting, irrelevant, or counter-balanced) are analyzed in order to form a con¯ict free kernel;
2. to establish an architecture based on the stable kernel in the goals hierarchy in a syntactic architecture notation.
Architectures are formed using re®nement operators (i.e.
append, add computational component, add data access, insert, arbitrator, compromise, and mutual exclusive) in an incremental manner based on the realization: realize, enhance, impair, or cease, between goals and architecture components; and
3. to perform architecture evaluation by identifying the execution paths, and investigating the realization between goals and architecture components. The rela- tionships between goal and use cases (i.e. achieve, opti- mize, maintain, cease, or impair), can be used as a basis for verifying the satisfaction degree of the software archi- tecture. For veri®cation, a graph grammar based produc- tion rules are applied to verify the integrity of the software architecture.
3.1. Establishing a goals hierarchy
One of the major objectives of use cases is to model a system's functional requirements by describing different scenarios of system usage. The basic concepts of a use case approach are actor and use case. An actor is a speci®c role played by a system user, and represents a category of
Fig. 1. Overview of GAAM.
1 Use cases and scenarios are used interchangeably in this paper.
users that demonstrate similar behaviors when using the system. The way an actor uses the system is described by use cases. A use case has one basic course and several alternative courses. The basic course is the simplest course, the one in which a request is delivered without any dif®- culty. On the other hand, variants of the basic course, and errors that can occur are described in alternative courses.
A use case model is created for a system to specify the relationships between use cases, as well as relationships between use cases and actors. Two powerful concepts that are used to structure and relate use cases are extend and include. An extend relation speci®es how one use case may be embedded into another one, and thus extends its functionality. An include relation is used for re®nement by extracting similar parts of two or more use cases. In this way we only have to describe the similar part once instead of showing this behavior in all use cases.
3.1.1. Goals and use cases
An important advantage of use case driven analysis is that it helps to manage complexity, as it focuses on one speci®c aspect of usage at a time. Use cases focus the expression of requirements on users, starting from the very simple view- point that a system is built ®rst and foremost for its users.
The organization of the approach is performed with respect to the interaction of a single category of users at a time; this participating of the set of requirements considerably reduces the complexity of requirements determination. However, the current use case approaches are somewhat limited in supporting a formalization of use cases, and in structuring and managing large use case models.
Our previous work on goal-driven use cases [20] extends use cases with goals to alleviate the above problems:
² goals are used to structure use case models and to derive use cases;
² soft goals are differentiated from the rigid ones to handle non-functional requirements that are imprecise in nature;
² goals information are embedded in the use cases, andand relationships between requirements are analyzed by investigating the interactions between goals and use cases.
We start from modeling the inner working in our univer- sity by using UML.2There are three steps to construct use cases:
² Identify actors. An actor is an outside entity that interacts directly with a system, which may be a person or a quasi- autonomous object, such as machines, computer tasks, and other systems. More precisely, an actor is a role played by such an entity.
² Identify goals. A faceted classi®cation scheme is
proposed for identifying goals from domain descriptions and system requirements. Each goal can be classi®ed under three facets we have identi®ed competence, view and content.
Competence. The ®rst facet is related to whether a goal is completely satis®ed or only to a degree. A rigid goal describes a minimum requirement for a target system, which is required to be satis®ed utterly. A soft goal describes property for a target system, and can be satis®ed to a degree. A soft goal is related to a rigid one in the sense that the existence of the soft goal is dependent on the rigid one. That is, there exists a weak relationship between a rigid goal and its soft goals.
View. This facet concerns whether a goal is actor- speci®c or system-speci®c. Actor-speci®c goals are objectives of an actor in using a system; meanwhile, system-speci®c goals are requirements on services that the system provides. On the other hand, a system- speci®c goal takes into consideration `what kinds of properties the system should have in supporting services to all users?', or `what are the requirements on the services for the system to provide?'.
Content. Requirements can be classi®ed into func- tional and non-functional requirements based on their content [19]. The construction of functional require- ments involves modeling the relevant internal states and behavior of both the component and its environ- ment. Non-functional requirements usually de®ne the constraints that the product needs to satisfy. Therefore, a goal can be further distinguished based on its content, that is, a goal can be either related to the functional aspects of a system or associated with the non-functional aspect of the system. A functional goal can be achieved by performing a sequence of opera- tions. A non-functional goal is de®ned as constraints to qualify its related functional goal.
² Build use case models. Each use case in the approach is viewed as a process that can be associated with a goal to be achieved, optimized, or maintained by the use case. To start with, original use cases to guarantee that the target system will be at least adapted to the minimum require- ments are ®rst concerned. Each original use case in our approach is associated with an actor to describe the process to achieve an original goal which is rigid, actor-speci®c and functional. Building original use cases by investigating all original goals will make the use case model satisfy at least all actors' rigid and func- tional goals. To extend the original use cases to take into account different types of goal, extension use cases are created in various situations: optimizing/maintaining a soft goal, achieving system-speci®c goal, and achieving a non-functional goal.
These steps will ensure that goals, if they are playing a vital role in the software system, will guide the discovery of all relevant use cases. The system then comprises those use
2Uni®ed Modeling Language (UML) [11].
cases that re¯ect system's requirements as described in the goal-driven use case model.
3.1.2. Goals and stable kernel
Interactions between goals are evaluated through the following steps (see Fig. 2):
1. Analyze the relationships between use cases and goals by investigating the effects on the goals after the use cases are performed: To better characterize the relationships between use cases and goals, we have adopted predicates proposed by Mylopoulos et al. [23]: satis®ed, denied, satis®able, and deniable. A goal can be either satis®ed or denied, if the goal is achieved or ceased utterly, respectively. On the other hand, the predicates satis®able and deniable are used to describe a goal that can be satis®ed or denied to a degree. In addition, a predicate independent is introduced to describe the situation that a goal will not be affected by performing a designated use case. A use case is designed to achieve, optimize or maintain its directly associated goals. However, it may occur that goals not directly associated with the use case can also be affected, called side effects.
2. Explore the interactions between goals in the use case level: Relationships between goals can be considered in two different levels: use case level and system level. The former concerns the relationships between goals with respect to (wrt) a speci®c use cases, and the latter focuses on the overall system. In the use case level, two goals are said to be con¯icting wrt a use case, if the satisfaction of one goal is increased, while other is decreased after the
use case is performed. On the other hand, two goals are said to cooperate with each other, if both the satisfaction degrees of the goals are either increased (positively coop- erative) or decreased (negatively cooperative). The third possibility is that the satisfaction degrees of goals remain unchanged. In this case, the goals are said to be irrele- vant.3
3. Derive the relationships between goals in the system level: In the use case level, relationships between any two goals are analyzed wrt a speci®c use case, whereas relationships between goals in the system level are mainly on the use case models where related use cases are amalgamated together. Relationships between goals in the system level can be derived based on use case model and relationships between use cases in the use case level.
Instead of putting heavy efforts on resolving con¯icts at the beginning of system design which may overload analysts, we start with constructing a model to meet a set of con¯ict-free requirements. To this end, we organize the goals into several alternatives based on the interactions analyzed such that each alternative contains a set of goals that are not con¯icting with each other. In other words, no con¯ict is allowed in an alternative. More speci®cally, goals organized into alternatives must satisfy the constraints below:
² for any two goals Gi and Gj in an alternative, the
Fig. 2. Three steps to requirements evaluation.
Fig. 3. An illustration on how to establish a goals hierarchy.
3 Similar ideas are also advocated in our previous work [19].
interaction between Gi and Gj is either cooperative or irrelevant;
² for any two alternatives Ai and Aj, there exist goals Gi[ Ai and Gj[ Aj such that the interaction between Giand Gjis either con¯icting or counterbalanced; and
² for any alternative Ak and goal Giwhere GiÓ Ak, there exists a goal Gk[ Aksuch that the interaction between Gi
and Gkis either con¯icting or counterbalanced.
In order to explore all the possible alternatives, we utilize the notion of a goals hierarchy in which alternatives are obtained by tracing each path from a leaf node up to the root. As functional goals are usually the basic requirements that must be satis®ed, they are placed on the root of the hierarchy and therefore included in every alternative.
Fig. 3(b) illustrates how a goals hierarchy is established.
The goals G2, G3and G5are added incrementally to the root to form an alternative. Since adding the goal G6or G4to the alternative will result in a con¯ict, we backtrack to create another alternative. By doing so, we come up with three different alternatives: {G2, G3, G5}, {G2, G6} and {G4, G3, G5} (see Fig. 3(c)).
3.2. Establishing the architecture in an incremental manner Essentially, a kernel contains all the functional require- ments and a set of non-functional requirements that are either cooperative or irrelevant to each other (i.e. no con¯ict is allowed). A kernel is stable in the sense that no engage- ment in the annoying con¯icts resolution is required, and that it can be used to serve as a basis for further re®nement.
To choose a stable kernel from the alternatives found in Section 3.1.2, the cooperative degree and importance degree of an alternative are introduced. A cooperative degree of an alternative is de®ned as the total numbers of cooperative interactions within the alternative. In Fig. 3(c), the cooperative degree of the alternative A1is equal to 1 since there is a cooperative interaction between G3and G5. The importance degree of an alternative is the sum of the weights of goals in the alternative. We adopt Satty's pair- wise comparison approach to the assignment weights to goals [29]. That is, the relative weights of each goal pair are used to form a reciprocal matrix, and the absolute weight of each goal is obtained from the normalized eigenvector using eigenvalue method.
To build the software architecture, we ®rst identify the basic functionalities that the system needs to achieve. As a basis of the ®nal software architecture, an initial architecture based on the basic (i.e. basic goals) functionalities will be built at this stage.
We start with constructing an initial software architecture to meet a set of con¯ict-free requirements instead of putting heavy efforts on resolving con¯icts at the beginning of the architecture design which may overload developers. To this end, the root node of the alternative with highest weight of importance is used to form the initial architecture. As
pointed out in Section 3.1.2, the root node of an alternative contains all the functional requirements, and therefore the initial software architecture will satisfy the minimum func- tion requirements of the target software system.
By traversing from the root to the leaf of the alternative, the architecture is built from one goal to another in an incre- mental manner. To each node of the alternative, the appro- priate architecture component is added to the initial architecture and make suitable changes to the architecture.
At the later stage of constructing the software architec- ture, some con¯icting goals might need to integrate into the architecture. In order to handle con¯icts, we explore the root of con¯icts to lead us to the resolution of con¯icts or even better the prevention of con¯icts.
3.2.1. Root of con¯icts
Competing resources. A con¯ict occurs when goals are competing with a mutually exclusive resource (i.e. the resource can not be shared at the same time). For example, in a library system, patrons wish to keep books as long as they need, whereas the librarians wish to keep books avail- able in the library. A con¯ict arises because patrons and librarians are competing with the resource `books'.
Divergent expectations. A con¯ict whenever goals have divergent expectations on their common interest. For exam- ple, the goal MaxPro®ts from producers and the goal MinCosts from customers are both interested in the cost of a product. A con¯ict arises in that they have divergent expectations on the production's price. The common inter- est of goals may be an object's properties (e.g. the price of a product), an object's behavior, or a relationship between objects.
Side effects. A con¯ict between goals arise whenever a use case to achieve a goal has a side effect on other goals.
Con¯icting goals in this case do not necessarily have a common interest. It should be noted that the con¯icts are caused by the side effects of use cases, rather than divergent expectations on a common interest or competing with a common resource.
3.2.2. Con¯icts resolution
A con¯ict can be resolved based on the con¯ict, the possi- bility of occurrence of the con¯ict, and the severity of the con¯ict consequences. Three resolution technique are proposed to handle con¯icts: to avoid the occurrence of con¯icts by prevention, to reach a consensus between con¯i- citing goals by compromise, and to achieve a goal without regard to another by competition.
Prevention. The best strategy of handling con¯icts is to prevent con¯icts from happening. Con¯icts can be prevented by adding arbitrators to arbitrate the con¯ict between use case or seeking alternative use cases, based on the causes of con¯icts.
Compromise. To reach a compromise, each goal involved in the con¯ict should make some concessions. Compromise can be reached by specializing an object class into disjoint
subclasses with different associations linked to the corre- sponding subclasses.
Competition. Resolving con¯icts by competition refers to satisfying one of the con¯icting goals without regard to the others. The competition between goals depends on: (1) the importance degree of each goal involved in the con¯ict; and (2) the degree of impairment4to each goal when it cannot be satis®ed.
Supposing that G1con¯icts with G2, IG2 G1 is the degree of impairment of G1when G2is satis®ed. IG2 G1 . IG1 G2 denotes that achieving G1is more bene®cial than achieving G2(since the overall impairment of achieving G1is less than that of achieving G2).
3.2.3. Construction of architecture
To construct the software architecture, a syntactic archi- tecture notation introduced in SAAM [16] (see Fig. 4) is used to reveal how the architecture is constructed from smaller connected pieces. Square-cornered boxes with solid lines represent processes, or independent threads of control. Round-cornered boxes represent computational components which only exist within a process or within another computational component. Square cornered shaded boxes represent passive data repositories (typically, ®les).
Round-cornered shaded boxes represent active data reposi- tories (e.g. an active database). Solid arrows represent data
¯ow (uni- or bi-directional) and grey arrows represent control ¯ow (also uni- or bi-directional).
We adopted a formal treatment to software architectures using graph context-free grammar from Metayer's work [22]. A grammar is a 4-tuple [NT,T,PR,AX], where NT and T are sets of non-terminal and terminal symbols, PR is a
®nite set of production rules, and AX is a speci®c non-term- inal called the axiom (the origin of the derivation). The production rules are pairs (l,r) where l is a singleton A(x1,¼,xi) (with A a non-terminal of arity i) and r is a set of terms B(y1,¼,yi) with B [ NT < T. All the non-terminal and terminal symbols that we use in our approach are listed in Fig. 5. Symbols starting with `R' stand for non-terminal nodes, for example, RP represents processes, RC represents control ¯ows, and RPCC represents computational compo- nents. Others list as follows: P, process; PCC, computational component; AD, active data storage; PD, passive data storage; CF, control ¯ow; PDFR, passive data ¯ow read;
PDFW, passive data ¯ow write; ADFR, active data ¯ow read; ADFW, active data ¯ow write; APDFR, active to passive data ¯ow read; and APDFW, active to passive data ¯ow write. For simplicity, we use RDS to represent all data storages and RDF for data ¯ows.
In the following, we formally de®ne various types of re®nement operator by the production rules based on the notion of goals (see from Figs. 6±12). In Section 3.3, we
Fig. 4. Architectural notations.
Fig. 5. List of NT, T, entities and link types.
Fig. 6. Append operator and its production rules.
Fig. 7. Add computational component and its production rules.
4 A use case is said to impair a goal if the performance of the use case may result in the dissatisfaction of the goal.
will also show how to use these production rules to verify the software architecture using graph context-free grammar.
² Append operator (Fig. 6). This operator is used to add a new process component to the software architecture which can be used to satisfy the rigid goals by performing a sequence of operations. The production rules of the append operator are showed in Fig. 6(e). The starting A (in rule 1) is an axiom in {AX} in the 4-tuple and is taken as the root of the architectures. This rule must be applied
®rst to obtain the initial process of the architecture for further derivation. Rule 2 adds two items into the graph grammar. One is a new non-terminal node that stands for a new process and the other stands for the control ¯ow linking the two processes. Fig. 6(a) and (b) show the change before and after applying this rule. In Fig. 6(c) and (d), the appending process (p2) is already existed in the architecture which differed from the situation in Fig.
6(a) and (b). To append this process, rule 3 is applied and a new control ¯ow from p2to p1is created for linking the two processes. The last three rules (rules 4±6) are used to derive terminal nodes. Rule 4 is used to eliminate a process that is no longer used. Rule 5 turns a non-term- inal process into a terminal process when there is no more process entering this architecture. Rule 6 turns a non- terminal control ¯ow into a terminal one with the same reason as in rule 5.
² Add computational component (Fig. 7). Since soft goals are dependent on its rigid goal, we apply this operator to relate the soft goal to its rigid one. Fig. 7(a) and (b) show the concept of adding a computational component (p.cc) into a process (p). Its production rules are showed in Fig.
7(c). Rule 1 adds a non-terminal computational compo- nent to the architecture, and Rule 2 turns the non-terminal computational component into a terminal one when there is no further derivation for this computational compo- nent.
² Add data access (Fig. 8). The above two operators only describe system control ¯ow, which is not enough for developing a software architecture. Therefore, a third operatorÐadd data access is introduced for the purpose of adding data repositories and data ¯ows to the software architecture. There are two types of data storage (passive data storage and active data storage) and ®ve types of data ¯ow (i.e. between process and passive data storage, process and active data active data storages) in the archi- tecture notations. To simplify the representation of the derivation process while using production rules, we use RDS as non-terminal nodes to represent data storages and RDF as non-terminal nodes to represent data ¯ows.
Moreover, we use a passive data storage (ds) to illustrate how the operator add data access can be performed. In general, the passive data storage can also be replaced by the active data storage as needed.
Rules 1 and 2 show different kinds of derivation for
`add data access' for a process in the architecture in different situations. Rule 1 is used when the data storage is not in the architecture (showed in Fig. 8(a) and (b)), while rule 2 is suited for the situation that the data storage is already in the architecture (showed in Fig. 8(c) and (d)).
Rules 3 and 4 are designed in the same manner as rules 1 and 2 except for the process (p) in rules 1 and 2 being replaced by a data storage (RDS) (see from Fig. 8(e)±(h)).
Rules 5±10turn a non-terminal data ¯ow into two data
¯ows. One is terminal and the other is non-terminal that can be used for further derivation. Rule 11 is applied when a non-terminal data ¯ow is no longer used, and the last two rules turn a non-terminal data storage into a terminal data storageÐpassive data storage (PD) and active data storage (AD).
² Insert operator (Fig. 9). This operator is applied while the goal is rigid, system-speci®c, and non-functional. The insert operator stands for a control ¯ow change is needed while the system is making modi®cation or adding a sub- routine module to the system during re®nement. Usually, an kincludel relation in the use case model will trigger the use of this operator in the architecture re®nement stage since kincludel often stands for a subroutine in the use cases model. We use a two-step insertion of production rules to de®ne this operator (Fig. 9(e)). First, we derive the original control ¯ow (non-terminal) into a new process and a 3-tuple control ¯ow (rule 1) that connects the three processes (all non-terminal). Then we use rule 2 to convert the 3-tuple control ¯ow into two 2-tuple control ¯ows. Fig. 9(a) and (b) show the architecture before and after applying rules 1 and 2 and a new process (pInsert) is inserted into the architecture between the two processes (p0and p1). Rule 3 is used to change the origi- nal control ¯ow from an old process to a new one that is added by performing the ®rst rule, which is different from the previous case showed in Fig. 9(a) and (b). In Fig. 9(c) and (d), the control ¯ow from p0to pAlreadyExistis replaced by the new control ¯ow from pInsert to pAlreadyExist after applying rule 3.
Con¯icts arise only when some speci®c conditions mentioned in Section 3.2.1 occur. A coordinator is intro- duced to deal with these speci®c conditions and to resolve the con¯icts while adding con¯icting goals into the software architecture. The task of the coordinator is expressed by conditional graph rewrite rules similar to the de®nition used in above operators for the rewrite system associated with graph grammar except that there are additional condi- tions in coordination rules. With the condition being checked, we can determine whether the coordinator is needed to be applied or not. Differing from the four basic re®nement operators (i.e. append, add computational component, add data access, and insert), coordinators achieve re®nements with a higher level of abstraction.
Therefore, to avoid possible derivation errors or other
syntax errors, a veri®cation mechanism is proposed to deal with these problems which is discussed later in Section 3.3.
We use the notion of coordinator to formally de®ne the following three operators:
² Arbitrator operator (Fig. 10). This operator is used
for con¯ict resolution. When a resource competing con¯ict occurs, we can insert an arbitrator process for the purpose of resource management to resolve the con¯ict. Fig. 10shows the coordinator of arbitra- tor operator that adds a new process to arbitrate the access to the data storage. Differing from the
Fig. 8. Add data access operator and its production rules.
Fig. 9. Insert operator and its production rules.
previous production rules de®ned for the four re®ne- ment operators, the coordinator is only used when the boolean value of variable `compete' in the passive data storage is true. In the concept of the entity passiveDataStorage, each entity de®nes public and private variables, output and input links and entity names. The public variables can be checked (but not assigned) by the coordinator. The public variable v of an entity a is denoted by a.v.
The commands of the language are very much in the spirit of CSP except for the following generalization: the seman- tics of input and output commands of the form a [ L!E correspond to the establishment of a rendezvous with any entity a linked to the current entity through a link of name L.
When the coordinator applied, it test p1and p2link to the passiveDataStorage via data ¯ow(d). If the two processes are different, the variable complete will be set to true to
activate the coordinator rule to add a new process (p3) and two control ¯ows (CF) to arbitrate the access to the data storage.
² Compromise operator (Fig. 11). With the specialization of the data repository, the con¯icting component makes a concession to the competing resource by accessing the specialized active data repository. The two active data repositories act as ®lters that only allow speci®c resource access to the back-end passive data repository. Fig. 11 shows the coordinator of the compromise operator. The Boolean value of variable `compromise' determines whether the coordinator is needed to be applied. In the coordinator rule, two active data storages are added, and the original data ¯ows (PDFW) are replaced by data
¯ows between data storages (APDFW) and bi-directional data ¯ows (ADFR, ADFW).
² Mutual exclusive operator (Fig. 12). When the added
Fig. 10. Arbitrator operator and its coordinator.
Fig. 11. Compromise operator and its coordinator.
goal has side effect on the previous goal within the same process component, this operator can be applied to resolve the con¯ict. This operator can be achieved by splitting the two computational components with side effect on each other and by adding a select process with a selection repository to restrict the control ¯ow.
The coordinator of mutual exclusive operator is showed in Fig. 12. It can only be applied when the value of the Boolean variable `mutual' is true which means that the computation components in the process have con¯icts.
The rule of this coordinator means that a new process (Psep) and an active data storage (AD) are added to the architecture, and the original process (P1) with two computational components inside is derived to two sepa- rate processes (P1, P2), and each process contains one computational component that is originally in the origi- nal process.
With these operators, we can re®ne an architecture by asso- ciating different types of goal with their corresponding opera- tors. Table 1 indicates the situations when to apply these
re®nement operators. For example, in Fig. 18, the soft goal
`Max.CourseInfoAvailable' that optimizes the rigid goal
`Register A-Course' is added into the architecture as a sub- component by applying `Add Computational Component' operator which actually adds a computational component
`Obtain Course Info' to the `Enroll Course' process. In Fig.
14, the use case `MultipleLoginCheck' must perform prior to those use cases with kincludel relation linkage.
To resolve the con¯icts while adding con¯icting goals into the software architecture, three operators can be appliedÐarbitrator, compromise, and mutual exclusive.
² To prevent a con¯ict resulted from competing resources, a resource arbitrator can be introduced to distribute the resources. Using this heuristic rule, the con¯icts between concurrent database accesses can be prevented by intro- ducing a database arbitrator.
² To reach a compromise, we can apply the compromise operator to make such a concession to resolve the con¯ict.
² To prevent a con¯ict resulted from side effects, a mutual exclusive operator is proposed to avoid concurrently executing the con¯ict processes that will impair the satis- faction degree of the software system.
Refer to the Virtual National Central University example, several original goals that are required in the virtual univer- sity environment are identi®ed:
² course lecturing: there must be some ways for knowledge to be obtained by the students.
² discussion: higher education should teach students to think and tasks/problems followed by discussion is the essential combination of methods to teach thinking.
² feedback: skills are learned best by practice in small steps with immediate feedback.
Fig. 12. Mutual exclusive operator and its coordinator.
Table 1
Applying re®nement operators (R: rigid, A: actor-speci®c, F: functional, S:
soft, Y: system-speci®c, N: non-functional) Classi®cation of goals Types of operator
(R, A, F) Appenda
(R, A, N) Append and add data access
(R, Y, F) Inserta,b
(R, Y, N) Append and add data access
(S, A, F) Add computational component
(S, A, N) Add computational component
(S, Y, F) Add computational component
(S, Y, N) Add computational component
a With include relation in use case model.
b Data access may need to apply.
Building software architecture from rigid goals in the stable kernel will ensure that the target architecture satis®es the minimum functional requirements of the virtual univer- sity software system. Also, applying the con¯ict resolution operators will ensure that the satisfaction degree of the architecture won't be impaired by con¯icting goals.
To better characterize the realization between goals and architecture, we have identi®ed several types of relation- ship:
² realize and enhance. A goal is said to be realized in the architecture by some architecture components or elements if the goal can be achieved by executing these architecture components or elements. The meaning of execution here is to perform the tasks in the processes or computational components. If the goal can only be satis®ed to a degree (i.e. soft goal), we said that the architecture components or elements is used to enhance this goal. Realize and enhance are positive realization for goals in the architecture level.
² impair and cease. If the satisfaction degree of a goal is
decreased after performing the tasks in some architecture components or elements, we said that this goal is impaired by these architecture components. The goal may also be ceased if inappropriate architecture compo- nent is placed and preventing the goal to be satis®ed. In this case, the architecture needs to adjust to avoid this kind of con¯icting design. Stable kernel is to help avoid the impair realization of the architecture.
To an end, we want to have the ®nal architecture with a higher degree of positive realization, and to eliminate possi- ble impairments of the architecture. The process of evaluat- ing built software architecture can be used to ®nd out the possible ¯aws in the previous step-wise re®nement and serve as a basis for correcting or further optimizing the architecture.
3.3. Evaluating and verifying software architecture A good architecture will impact the system largely in the implementation phase. Software architecture as pointed in Ref. [15] describes `a high level con®guration of system
Fig. 13. Applying arbitrator operator.
Fig. 14. Goal-driven use case model-student.
components and the connections that coordinate component activities'. It is also said in Ref. [17] that the achievement of qualities such as performance, availability, and modi®abil- ity depends more on the overall software architecture than on code-level practices such as language choice, detailed design, algorithms, data structure, testing, and so forth.
To be able to verify the software architecture, we propose a veri®cation mechanism to evaluate the architecture. As mentioned in Section 2, by testing the executability of the architecture component, each scenario can be veri®ed. Since the architecture is connected through directional control
¯ows, we can formulate the architecture as a graph and use the execution path to determine the executability of the software architecture. Here we de®ne an execution path to be a path that starts from the starting architecture component to a component such that the represented goal can be ful®lled along this path. If there are multiple execution paths that can be used to ful®ll the same goal, there must exists an optimal path with fewest components that can make the software architecture more concise.
To ®nd multiple execution paths (see Algorithm 1), we starts from a component that the goal represented by this chosen component is to be veri®ed. Then it backtracks to an entry component of the software architecture. An entry component is as de®ned a component that has no incoming control ¯ows. We also de®ne a critical component as a component with more than one entering control ¯ows.
When the algorithm stops, the result shows whether the architecture needs further re®nement or not. If there exists critical components (i.e. the goal represented by the compo- nent has multiple ways to be achieved), the architecture
1. choose a component and label it 1. (The goal represented by this component is to be veri®ed)
2. Given the component labeled k, backtrack along the control ¯ow to previous components(s).
(a) If there is only one incoming control ¯ow. Assume component C1; C2; ¼; Ckhave been traveled, label this component k 1 1; repeat step 2 with this component.
(b) If there are more than one control ¯ow entering this component, mark this component as a critical compo- nent. Assume components C1, C2,¼, Ck have been traveled. Select one of the unlabeled components and label it k 1 1; repeat step 2 with this component.
(c) If the component is an entry component of the architecture.
i. If there exists critical components with branches that have not been visited, backtrack to the previous critical component.
ii. If there is no such critical components exists, stop.
To further explain the relationships between goals and the architecture, we investigate the satisfaction degree of the architecture. For a goal to be realized, it must be achieved, maintained, or optimized by the corresponding use cases.
And if the goal can be positively realized by the architec- ture, the architecture is said to satisfy the requirements captured in the use cases model since the use case model is used to achieve optimize the goals.
A use case can be achieved by performing a series of tasks in processes or computational components. In SAAM, architecture evaluation is done by testing the excut- ability of the architecture which is said that the system scenarios can be covered during the execution of the archi- tecture. It uses the term execute, but it does not point out how the execution can be done. In order to ®nd ways to verify the excutability, we use the execution path to indicate
Fig. 15. Interaction between goals in the system level.
Fig. 16. Initial architecture of student side and its production rules.
how a use case cab be achieved through a series of tasks in the architecture view. If all use cases can be covered during the excitability test, we can conclude that the goals can be realized by the architecture. Otherwise, if the goal is impaired by the execution path, we should go back to the architecture re®nement phase and check whether the opera- tors are suitable or not.
Most formal veri®cation methods for software architec- tures suffer from state explosion problem. Consequently,
many techniques have been proposed to cope with the problem. Equivalence is the main concept shared in these techniques. Two system models are considered to be equivalent if no distinction can be made between them [32].
With the production rules of the four basic re®nement operators, we can generate all the architectures we are developing. On the other hand, coordinators provide another kind of derivation to help resolve the con¯icts. But the derivation of these coordinators in not based on the four
Fig. 17. Architecture with adding the goal MCCS.
Fig. 18. Architecture with resolving the side effect con¯ict
basic re®nement operators which might cause derivation errors during re®nement by applying the coordinators. To solve this problem, we need a veri®cation mechanism to check the logic correctness of the graph grammar. Logic correctness here is de®ned as that derivation errors or syntax errors of the graph grammar won't happen during architec- ture re®nement process. As the state explosion problem will also occur in the build-up of software architecture, the concept of equivalence class gives a way to tackle logic correctness veri®cation and state explosion problem.
Our focus of the veri®cation is on the logic correctness of the derivation and not on the properties preservation
between each re®nement since the architecture has changed after applying re®nement operators. Therefore, the equiva- lence class means that the correctness of the graph grammar is preserved during derivation. The architecture is veri®ed by using the rewrite rules based on the graph context-free grammar that can be used to prove the equivalence between architectures. An equivalence class of software architec- tures is de®ned as architectures represented by graph gram- mars before and after applying some re®nement operators can be derive the same graph grammar using a right-to-left reading of the production rules in the four basic re®nement operators denoted as !21A :
Fig. 20. Architecture after adding the goal Login Veri®cation Fig. 19. Architecture before adding the goal Login Veri®cation
Suppose an architecture is de®ned as a 4-tuple:
Architecture NT; T; PR; AX
we then consider the graph rewrite system !21A obtained by a right-to-left reading of the rules in PR. For example, the
!21A rewrite rule of Add Computational Component operator will be:
RP p; RPCC p:cc !21A RP p
and
PCC p:cc !21A RPCC p:cc
The main goal of the veri®cation is to verify that the archi- tecture during re®nement can derive to the same graph grammar using the graph rewrite system !21A : We denote it as Gn!21A G; where Gnmeans the possible graph gram- mar existed during architecture re®nement and G is the graph grammar that can be obtained from derivation of Gns which stands for `derive to the same graph grammar'.
We choose the original axiom in {AX} as the `the same graph grammar'. Since it is the root of all architectures and only contains `A' (in rule 1 of append operator), we can easily obtained the graph grammar by reversing the production rules in the four basic re®nement operators
(i.e. the graph rewrite system !21A ). For example, suppose we have an architecture with its graph grammar as follows:
P p; PCC p:cc
First, we apply the !21A rewrite rules to convert the terminal nodes to non-terminal nodes (using rules PCC(p.cc)!21A RPCC(p.cc) and P(p) !21A RP(p)) and get RP(p), RPCC(p.cc). Next, applying the !21A rewrite rules of Add Computational Component, we can derive this architecture that has a process with a computational component inside to another architecture that has a process without a computa- tional component inside. (i.e. RP p) Finally, the !21A rewrite rule of `append operator', is applied to obtain `A' (using the rule RP p !21A A)Ðthe root of the architecture, which means that original architecture and `A' are in the same equivalence class.
But for coordinators (arbitrator, compromise, and mutual exclusive), the correctness can not be veri®ed in the same manner (by reversing the rule in coordinators) since coordi- nators replace the terminal nodes directly with other term- inal nodes, which differs from the four basic operators. The coordinator Coo de®nes a second graph rewrite relation
!Coo and the checking algorithm must ensure that for all graphs G, we have:
G !21A {AX} and G !Coo G0) G0!21A {AX}
Fig. 21. Goal-driven use case modelÐteacher.
Fig. 22. Goal-driven use case modelÐmaintainer.
Fig. 23. Goal-driven use case modelÐcourse scheduler.
Fig. 24. Architecture with adding the goal RAC.
P p; P p1; P p2; PD ds; CF p; p1; CF p; p2;
PDFW p1; ds; PDFW p2; ds
After applying the arbitrator operator (that is, the coordinator Carbitrator), we can obtain the new graph grammar:
P p; P p1; P p2; P p3; PD ds; CF p; p1; CF p1; p2;
CF p1; p3; PDFW p3; ds
We want to verify the new graph grammar to see if it is still in the same equivalence class as the original graph is (which is said that both graphs are in {AX}). First, we apply rules P p !21A RP p; PD ds !21A RDS ds; and CF p0; p1 !21A RC p0; p1 to convert the terminal nodes to non-terminal ones. For the terminal node PDFW, there is no direct rule to convert it into a non-terminal one, therefore, the following two rules are needed: é !21A RDF p; ds (in order to gain the RDF and to activate the next rule) and PDFW p; ds; RDF p; ds !21A RDF p; ds: Then we can obtain the grammar:
RP p; RP p1; RP p2; RP p3; RDS ds; RC p; p1;
RC p; p2; RC p1; p3; RC p2; p3; RDF p3; ds
Using the rule RP p; RDS p; ds; RDF p; ds !21A RP p;
(from the add data access operator), we can eliminate the date access.
RP p; RP p1; RP p2; RP p3; RC p; p1; RC p; p2;
RC p1; p3; RC p2; p3
Next, applying the rule RP p2; RC p0; p1; RC p2; p1 !21A RP p2; RC p0; p1 and RP p1; RP p0; p1; RP p0 !21A RP p0 (both in the append operator) to get:
RP p; RP p1; RP p2; RC p; p1; RC p; p2
By using the rule RP p1; RP p0; p1; RP p0 !21A RP p0; we can obtain the grammar:
RP p
Finally, applying the rule RP p !21A A to get the ®nal result A, that is, in {AX} in the 4-tuple NT; T; PR; AX; which means that the new graph grammar after applying arbitrator operator is still in the same equivalence class.
seamless, cost-effective and high-quality learning environ- ment for postsecondary education. Goal-driven architecture trade-off analysis method (GAAM) is discussed as a feasible approach to alleviating the problems encountered in model- ing software system in virtual university
4.1. The problem
the example re¯ects the Virtual National Central Univer- sity system constructed by software engineering lab in National Central University. Its main purpose is to provide a seamless environment for users in this environment to achieve their own tasks or jobs. In order to make it possible for university to operate in the virtual environment, several features need to be taken into consideration.
² Users in this environment must be identi®ed, such as students, teachers, faculties. Also
² the main functionalities must be modeled associated to each user. For students, their main goals in the virtual university environment are to enroll courses, attend courses, discuss with others, and be able to retrieve course material. Other users should also have their main goals in this environment.
We must be capable to provide these needs in this envir- onment with less usage overhead and more ¯exibility.
4.2. Use cases model
By investigating all possible types of users who interacts with the system directly, four actors are identi®ed student, teacher, course scheduler, and system maintainer. In the second step, we identi®ed goals from domain descriptions, system requirements and the system usage associated to each actor. Finally use cases are constructed to achieve, optimize, or maintain their associated goals. Fig. 14 shows the use case diagram from students' view.5
4.3. Software architecture
By applying GAAM, we construct the software archi- tecture from stable kernel (showed in Fig. 15) in an incre- mental fashion.
First, we build the initial architecture with basic functions needed in the target system (see Fig. 16). At the right hand side of the same ®gure shows the graph grammar that is
5 The other three use case diagrams are described in Appendix A.
obtained by applying production rules 1 and 2 of the append operator. Then according to the goal hierarchy, each goal is added into the architecture by applying the re®nement opera- tors. For example, the goal `MCCS' is ®rst added by using the operator `Append' (see Fig. 17). And the goal `LV' is added to the architecture using the operator `Insert' since the goal stands for a control ¯ow change. Figs. 19 and 20show the change before and after applying Insert operator. But con¯icts with goals `SIWT', `MCIA', and `MIS' occur while adding the goal MCCS. To resolve the con¯ict, the `Mutual Exclusive' operator is applied. Finally, the architecture as shown in Fig.
18 is re®ned to avoid the con¯ict. Fig. 18 is also the ®nal version of student side architecture since all the goals in the goals hierarchy are added into the architecture. Details of the architecture re®nement and production rules derivation can be found in Appendix B.
4.4. Architecture evaluation and veri®cation
After the architecture is built, we then apply the Algo- rithm 1 to see if there is any multiple execution path and
to verify the realization between goals and architecture.
For example, the goal `Max. Convenient Class Schedule' (MCCS) is with the execution path starts from `Attend Class. 2: Course Replay' to `Select' to `Login Veri®ca- tion' to `Main'. Comparing to the use cases model, the actor (Student) uses the extension use case `Course Replay' of origin case `Attend Course Live' which opti- mize the goal MCCS. Therefore, we can say the goal is realized by the architecture through the execution path.
Execution paths for other components can be evaluated in the same way, and the results of the evaluation show that each use case is covered in the execution paths which is said that the architecture is correct without any redundant component or con¯ict.
Next, we apply the graph grammar veri®cation. The veri-
®cation is starting from using the !21A rules of add data access and add computational component to eliminate data storages and computational components. Next, the rules in `append operator' apply to the processes left in the architecture, which will lead to A in the axiom (AX) and complete the veri®cation.
Fig. 25. Architecture with adding the goal HD.
Fig. 26. Architecture with adding the goal CMR.
Fig. 27. Architecture with adding the goal LV.
Fig. 28. Architecture with adding the goal CUP.
5. Discussion
There are still two issues remained to be addressed.
First, it is hard for developers to gain domain speci®c knowledge in every ®eld they are working on. There- fore, the requirements analysis would be dif®cult task.
Second, how soft goals (NFRs) regarding performance, reliability, or portability are re®ned into high perfor- mance, reliable, or portable architecture. To answer the ®rst question, the ability to incorporate domain speci®c knowledge during goal modeling phase is in need, which can be accomplished through goal decom- position.
The concept of aspect-oriented approach [18]
proposed by Kiczales et al. seems to be a promising way to address the second issue. The notion `aspects' is used to solve problems encountered during making design decisions that are hard to capture because they cross-cut the systems' basic functionality. To make use of this concept, we can take these soft goals (e.g.
performance, reliability, or portability) as aspects, and incorporate the techniques provided by aspect-oriented approach into the incremental building process. Once the aspects are ful®lled, the soft goals then can be satis®ed by the architecture.
6. Conclusion
In this paper, a goal-driven architecture trade-off analysis method is proposed to bridge between requirements and software architecture.
² deriving scenarios from requirements based on the notion of goals;
² constructing architecture incrementally based on the stable kernel in the goals hierarchy; and
² evaluating the architecture by exploring the execution paths and verifying the architecture through graph grammar.
Our example shows that GAAM can be useful mechanism for capturing user's requirements and reducing the time to build application in the virtual university environment.
GAAM makes it easy to identify the needed functionalities and users involved in the system. Based on the goals hierarchy, the time to do the iterated process of constructing different candidate architectures can be reduced before implementing the entire system. In this paper, our efforts not only provide new avenues for learning in a seamless environment, but also give us a new insight of developing a software system in an ef®cient way by using goals information. The proposed approach can be considered as one of the attempts towards the combination of the requirement engineering and architec- ture evaluation.
In order to further extends this research area, our future work consists of the following tasks:
1. to incorporate domain knowledge into the goal modeling phase to capture system requirement more precisely, and 2. to bring in the concept of aspect-oriented programming into
the software architecture construction phase to further improve the satisfaction degree of soft goals (NFRs).
Acknowledgements
This research was supported by National Science Council (Taiwan, ROC) under grants NSC 89-2213-E-008-003.
Fig. 29. Architecture with adding the goal SIWT.
Fig. 30. Architecture with adding the goal MCIA.
Fig. 31. Architecture with adding the goal MIS.
