Goal-Oriented Approach
to Software Architectural Evolution


Just about everything changes in our everyday lives --- new discoveries, paradigms, styles, technologies, etc. Frequently the success, not to mention even the survival, of software systems depends largely on how well they can adapt to rapidly changing environments.

Software architectures are abstractions at the highest level of solutions. As such, it is expected that software architectures can provide conceptual guidance on what parts of the system need to be changed and what not. The architectures of many software systems, however, have often evolved from an uncoordinated build-and-fix attitude, and the original rational behind them is unclear, or worse, not available when needed.

This project proposes a goal-oriented approach to software architectural evolution, in order to remedy the problems associated with a lack of methodical support during maintenance of software systems. In the approach, high-level requirements are treated as goals to be achieved, which are clarified through decompositions, prioritized, and operationalized into architectural alternatives. Through tradeoff analysis, then, a particular architecture gets chosen. Being incremental, this approach can be used for both initial software architecture development and subsequent evolution in a seamless manner.

A preliminary study has been carried out using a system which provides support for collaboratively modelling system behavior. The initial results of this study indicate that the goal-oriented approach to software architecture evolution makes it easier to carry out impact analysis, reusability analysis, and analysis of completeness and soundness of architectural evolution.

This study also presents a number of open issues, such as scalability, applicability and tool support. These and some other issues are discussed at the end.
 

Rejuvenating Table of Contents
Sections Description
Introduction Evolution of Software Architecture
How to Make Architectural Evolution More Sense
Goal-Oriented Software Architectural Evolution
Framework:
Requirements, Architectural Alternatives, Changes
Using Change in Requirements to Drive the Process
Analyses of Evolution Completeness, soundness, minimality, clarity
Guidelines semi-automatic nature of the process

Introduction

Using a comprehensive scenario analysis, this part firstly describes the process of specifying requirements on the system in terms of an enterprise model (domain theory), a software system model, and possibly a developer's world model. Each of the three models consists of both functional and non-functional requirements. Using the scenario set, this part then describes the process of identifying and selecting software architectural components. ----------------------- The approach to architectural component identification is goal-directed, i.e., organizational requirements are treated as goals to be achieved, which are then operationalized in terms of organizational tasks, which are in turn allocated to organizational agents and the system (agent). This process would involve a number of alternative design options for operationalization and a number of alternative allocation options. ------------------------ As a first-cut approximation, the set of all tasks allocated to the system will be considered as the set of architectural components. Through out the process, non-functional requirements on the enterprise (to be satisficed partially through non-functional requirements on the system) will, on the one hand, will be satisficed through a number of operationalized tasks, and act as the criteria for selecting among alternatives for functional choices on the other. Hence, the transition between the two processes of requirements engineering and system/software architectural design will be seamless.

Evolution of Software Architecture

How to Make Architectural Evolution More Sense

Goal-Oriented Software Architectural Evolution

Framework

Requirements, Architectural Alternatives, Changes

Using Change in Requirements to Drive the Process

Analyses of Evolution
Completeness, soundness, minimality, clarity

Guidelines
semi-automatic nature of the process
Partial collaboration some collaboration, and some distributed autonomy, for requirements eliciation, specification, validation, architectural componentization architectural connection, architectural design verification and collaborative integration if any distributed processing is involved The two modes of collaboration can have several variants, and be combined . For example, a goal-oriented compositional requirements modelling would be a variant. Here, the starting point would be an overall
understanding of the high-level objectives and goals to be achieved. Then, each local team may try to optimize system operations (involving various types of agents) at their own organizational units, and later put a concerted effort with other teams for a global optimization.

A goal-oriented compositional architectural design would be another variant. In this kind of architectural design, an architecture is built out of existing software components for most of which implemented systems
are readily available. The design process will still be goal-oriented in that the components are selected, possibly among competing alternative s located at multiple sites over the networks, according to the given requirements, which can possibly be modelled either distributively or collaboratively.

One objective of this project is to investigate a flexible mechanism through which all modes of collaboration can easily be supported.

 
Context Analysis In the distributed, cooperative processing paradigm, humans are expected to collaborate during observation, understanding, discovery, learning, analysis, problem formulation and solving, evaluation (and of course entertainment too). Central to this paradign is the notion of collaborative knowledge networks - networks of intelligent agents (capable of) performing a wide variety of tasks through reasoning with, and about, knowledge to achieve shared goals. These networks utilize the underlying multimodal communication networks and computers, and intended to enrich the set of existing modalities and their interactions.

To conquer the inherent complexity of a collaborating society, the COBRA tool set will assist the distributed agents with sharing of knowledge, detection and resolution of conflicts, coordination of distributed tasks, individualization, differentiation and integration of products. Ultimately the tool set is intended for quicker adaptation of the project to changes , flexible sharing of resources, more accurate system modelling, reduction in duplicated efforts, decreased cost of travel, more flexible scheduling of deadlines and task durations, easier coordination, reduction in project cycle and cost, more creative productivity, etc.  Using Scenarios for Goal-Oriented Software Architectural Design Scenario analysis facilitates goal-oriented analysis of a system supporting the distributed, cooperative processing paradigm. During scenario analysis, goals are identified of both functional and non-functional for the system as well as  for its context/enterprise (and possibly the development world as well). During scenario analysis, goals are related and co-related to each other, operationalized, supported by evidences or denied by counter-evidences, and prioritized.

Scenarios can be used: in modelling requirements (forward engineering); in designing architectures (forward engineering); in evaluating if existing architectures/components can meet new requirements (reverse engineering); in constructing old requirements or in bridging the gap between existing; architectures/components and defective old requirements (reverse engineering); in system evolution

The Scenario Assistant (SA) is used to analyze the behavior of a particular software system, e.g., a mobile communication system, being developed by a particular organization. The Scenario Assistant will work together
with the Goal Assistant (the FR Assistant and the NFR Assistant) and the Architecture Assistant  to define the
requirements as the problem to be solved and to construct an architecture as a solution to the problem. Functional SA =09 Functionality of the organization, =09 e.g., produce a model of (software) system behavior =09 Functionality of the system, =09 e.g., support the production through basic model constructor, =09 simulator, animator, etc. =09 Relationship between the two, =09 to establish both forward and backward traceabilities Non-Functional SA =09 Quality concerns of the organization, =09 e.g., increased competitiveness, maximum resource sharing, =09 reduced production cost and cycle, increased product quality =09 =09 Quality concerns on the software system, =09 e.g., maximum support for coordination, =09 maximum support for conflict & synergy detection, =09 fast communication, maximum transparency of locality =09 Relationship between the two, =09 e.g., maximum support for conflict detection HELPs =09 increased product quality, =09 but could HURT fast system response Agent Dependency SA =09Functionality of the organization --Task allocation-->
=09 =09Functionality of domain agents, hardware agents, and system agent
=09=09Functionality of system agent -->Task allocation--> =09 =09 Operationalization of functional goals, e.g., =09 domain agents: =09=09 requirements engineers go through (distributed) RAD =09 to build a model of system behavior =09 system agent: keeps track of meetings, records information, =09=09=09 and possibly produces a preliminary version of =09=09=09 a model of system behavior =09 =09 =09 Operationalization of non-functional goals, e.g.,=09 =09 Relationship between agents in the organization and =09 the system agent, to identify whose work will be supported =09 by the system (backward traceability) and to assure domain =09 goals and tasks are effectively supported by the system Script/Sequence SA =09 Refine domain functions, system functions, and domain =09 agents to carry out domain functions and use system functions, =09 which have been identified though Functional, Non-Functional =09 and Agent Dependency SAs. =09 =09 For each use, construct episodes and scripts =09 Conflict & Synergy SA =09 Detect conflicts and synergy between NFRs during operationalizatio= n =09 =09 Detect conflicts and synergy between FRs during operationalization =09 Detect conflicts and synergy between NFRs and FRs =09 during operationalization =09 =09 Through episodes and scripts, carry out more complete analysis =09 of conflicts and synergy between NFRs, FRs, NFRs and FRs, =09 during operationalization =09 Class & Instance SA =09 From classes to instances, for agents, episodes and scripts =09 =09 From instances to classes, for agents, episodes and scripts =09 Criticality & Domain Characteristics SA =09 vital few trivial many, priority and dominance =09 for NFRs, FRs, Agent Dependency =09 =09 workload on domain and system tasks, =09 availability of domain and system agents =09 Component SA =09 System functions as components of the software architecture =09 hang together when subjected to classes and instances of =09 episodes and scripts with criticality and domain characterstics =09 appropriately taken into consideration. =09 This is to illustrate both normal sequences of interactions, between the agents in the environment and the system, and "what can go wrong" lines of hypothetical reasoning that can be applied to the mostly normal scenario set for the distributed, cooperative process. This is also to take a deeper look at the mostly normal and failure scena= rio sets by raising "who, when and where" kinds of questions, in order to ens= ure that the set is satisfactorily complete, sound, consistent, and clear. Ultimately, then, we will have confidence in the completeness, soundness and clarity of our investigation into the problems of user-centered Knowledge Network (K= N) and into potential solutions utilizing the underlying communication netwo= rk. Collaboration Cycle Preparatory collaboration =09Prepare a preliminary schedule =09 (initial, interim and final progresses and evaluations). =09 Determine who will participate, when, and any special arrangement= s =09 Draft a criteria to judge when the work can be said to be complet= e =09 =09Make sure all participants expected are virtually present =09 Let the first session get started, with all participants as a who= le =09 or split in several groups. During collaboration =09Work according to the preliminary schedule. =09 Make sure expected participants do participate according to the =09 schedule. =09 Make sure all special arrangements are met. =09 =09 Keep track of work progress. =09 Find any deviation of the work from the expected quality, time, =09 and cost. =09 Detect, record, negotiate and resolve any conflicts. =09 Detect, record, and maximally complement each other and =09 utilize synergy. =09 At the end of collaboration =09 Get a consensus that the work is completed =09 Ensure the work is readily evolvable with a proper =09 version management =09 Detect, record, negotiate and resolve any conflicts. =09 Detect, record, and maximally complement each other and =09 utilize synergy. =09 The Scenario Assistant in Action KN (Knowledge Network) level observations:


Functional Requirements

The tool set under development will assist in handling distributed, cooperative processing. To start with, it will offer basic utilities for defining and validating (e.g., through animation and simulation) a system behavioral model. Towards an enabling technology for the new paradigm, a number of functions will be offered for: communication--- both synchronous and asynchronous, =09=09=09 both simple and more complex, =09=09=09 both immediate and delayed, etc coordination--- plan (who does what and when), do, =09=09=09 check (has everything done according to the plan?), =09=09=09 act (if any deviation from the plan, any defects, =09=09=09=09 rectify them integration--- detect boundaries and differences between the models =09=09=09developed by different agents, negotiate if =09=09=09any inconsistencies are found, =09=09=09merge consistent parts and negotiation--- resolve inconsistencies through individual =09=09 decisions and consensus

The tool set will also use the NFR Assistant to define vital "-ilities" for realizing the new paradigm, to investigate methods for achiving them, to built them into the new process, and to validate during operation that they are indeed met. As a test-bed, we are working on the modelling and analysis of system beh= avior using Augmented Petri Net (APN), a formalism which is expressively more powerful than Finite State Machines. Just like Petri Net, APN offers three modelling features, i.e., decision making, concurrency, and synchronization. However, APN is expressively more powerful conceptually than Petri net, as it allows for general expressions to be associated with transitions as triggering/activation conditions (e.g., agent interaction <>, temporal events, internal events), and for various forms of actions to be associated with transitions as atomic transactions (e.g., agent interaction <>, temporal event generation, internal event generation --- which bring about changes).

The tool set will be implemented using Java/JavaBeans so as to enhance platform-independence, interoperability, composability (plug-and-play), and distributability. An incremental approach will be used in developing the tool set so as to have a running system throughout the project. Members of the COBRA project, as well as non-member practitioners in industry can play with the tool to debug deficiencies in both the problem statemen= t and its solution.

At the most general level, the COBRA tool will be used to model possible scenarios of the new paradi= gm: i) distributed (and centralized cooperation); ii) distributed and coopera= tive. Through these (meta-models of) scenarios as both a starting point and an aid for analysis, models of the paradigm will be built, analyzed and understood. This process will be repeated until a high level of confidence in the problem statement is reached.

One particular concern at this level lies in the modelling and analysis of distributed, cooperative, multimedia-based workflows. The result of this part of our research will help understand how to make a smooth transition from the traditional groupware technology, which enforces more of fixed routes, rules and roles, to any enabling technology for the new distributed, cooperative processin= g paradigm, which should allow for more flexibility for the planning of routes, rules and roles, for the tracking of work progress, and for the adjustment of the old plan. Identifying synchronization and concurrency control patterns

Using the NFR Assistant to analyze the quality of the general distributed, cooperative process model, improve it, and make it amenable to customization for the modelling of the particular types of processes.

At the most specific level, the COBRA tool will be used to model the behavior of a variety of system = types, including a mobile communication system. Hence, we will be using a particular scenario for the particular system c= hosen to be modelled.


Non-Functional Requirements Decomposition of "-Ilities"

Each architectural choice can make either positive or negative contributi= ons towards the satisficing of non-functional requirements (NFRs). There are two cases:


Componentization
The Generative Process The quality of the architecture is as good as the decisions. Rely on your intuition, consider a small number of alternatives at each d= ecision point, prune the tree by making informed decisions considering "-ilities"= , and generate a first-cut approximation both functionality-wise and quality-wise. Repeat the process while making improvements by considering more alternatives and making better decisions at various decision points by considering more "-ilities" and perhaps a different prioritization scheme. Guidelines

The process of system/software architectural design can take into consideration the following guidelines:

Back to my home page Requirements Next to Architecture= <= /a> Top

--part0_890500049_boundary--