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.
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 |
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.
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.
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:
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 <
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.
Each architectural choice can make either positive or negative contributi=
ons
towards the satisficing of non-functional requirements (NFRs).
There are two cases:
When and how to exchange knowledge:
=09=09 types of metadata,
=09=09 transmission of metadata - one data at a time
=09=09 vs. a chunk at a time. E.g., merging a state and a
=09=09 transition (color, radius, coordinate, length,
=09=09 thickness).
=09=09 The whole model each time or only differentials.
=09=09 Message queue handler.
=09 When and how to incorporate new knowledge:
=09=09 Compute model differences, detect inconsistencies,
=09=09 merge compatible differences both internally and
=09=09 externally.
=09 When and how to negotiate for coordination and conflict
=09=09 resolution:
=09=09 Classify types of (potential) inconsistencies, protocols
=09=09 for negotiation and resolution. Even process definitions.
=09=09 Classify modes of negotiation - e.g., broadcast,
=09=09 one-to-one.
=09=09 Allow for recording justifications leading to consensus.
=09=09 Keep track of what has been resolved and what not.
=09
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
Non-Functional Requirements
Decomposition of "-Ilities"
=09
=09
=09
=09
=09
=09
=09
=09
=09
=09
=09
=09
=09
Componentization
=09
=09
=09
=09
=09
=09
=09
=09
=09
=09
=09
=09
=09
=09
=09=09
=09
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