sa seminar report 78 88
TRANSCRIPT
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 1/26
A Seminar Report on
Scenario-Based Analysis of Software Architecture
Submitted by
Jeevan Sequeira (09IT78)
Sungremthang (09IT88)
In partial fulfillment of the course
Software Architecture
of
VIII Semester, Bachelor of Technology
in
Information Technology
at
Department of Information Technology
National Institute of Technology Karnataka, Surathkal.
2012 – 2013
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 2/26
ABSTRACT
Analyzing a proposed software system to determine how well it meets quality criteria is a
difficult process. Analysts may lack both a common understanding of high-level design and a
fundamental understanding of quality attributes. Even with the recent focus on software
architecture and the resulting clarification of some high-level design issues, there is still no
satisfactory way to express and analyze context-dependent quality attributes like safety and
portability.
To address this problem, a Software Architecture Analysis Method (SAAM) has been proposed.
This method makes use of scenarios to gain information about a system‟s ability to meet desired
quality attributes. Scenarios are brief narratives of expected or anticipated system uses form both
the user and the developer view. And these scenarios provide a look at how the system satisfies
quality attributes in various use contexts. Although SAAM was developed for application early
in design, it was validated in an analysis of several existing industrial systems. A case study of a
control/configuration management system based on RCS is also carried out for evaluation of the
proposed method.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 3/26
TABLE OF CONTENTS
Index Title Page no.Cover page
Abstract
1 Introduction 1
2 Literature Survey 2
2.1 Software Architecture Definition And Description 2
2.2 Why Focus On Software Architecture? 22.3 Architectural Views 3
2.4 Software Architecture Analysis Method (SAAM) 3
2.5 Scenarios 4
3 Methodology 6
3.1 SAAM Activities 6
3.1.1 Describe The Candidate Architecture 6
3.1.2 Develop Scenarios 7
3.1.3 Evaluate Each Scenario 7
3.1.4 Reveal Scenario Interaction 8
3.1.5 Weight Scenarios And Scenario Interactions 8
3.1.6 Dependencies 9
3.2 WRCS: Case Study 9
3.2.1 WRCS System Context/Purpose 9
3.2.2 Applying SAAM 10
3.2.2.1 Describing Candidate Architecture 10
3.2.2.2 Develop Scenarios 12
3.2.2.3 Evaluate Each Scenario 12
3.2.2.4 Reveal Scenario Interactions 13
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 4/26
3.2.2.5 Weigh Scenarios And Scenario Interactions 15
3.2.2.6 Results Of Case Study 15
3.2.2.7 Conclusion On The Case Study 16
4 Results 17
4.1 SAAM Enhance Communication 17
4.2 Improvement Of Traditional Architectural Metrics 17
4.3 Determining The Proper Level Of Architectural Description 18
4.4 Efficient Scenario Generation 19
5 Conclusion 20
6 References 21
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 5/26
LIST OF FIGURES
Page no.
Figure 1: Activities and dependencies in scenario-based analysis -------------------------------------6
Figure 2: WRCS activities (shaded) and artifacts-------------------------------------------------------10
Figure 3: Architectural Representation of WRCS-------------------------------------------------------11
Figure 4: Fish-eye Representation of Scenario Interactions in WRCS-------------------------------15
LIST OF TABLES
Page no.
Table 1: Scenario evaluations for WRCS----------------------------------------------------------------13
Table 2: Scenario interactions by module for WRCS---------------------------------------------------14
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 6/26
1
1. INTRODUCTION
While software architecture has become an increasingly important research topic in recent years,
insufficient attention has been paid to methods for evaluation of these architectures. Evaluating
architectures is difficult for two main reasons. First, there is no common language used to
describe different architectures. Second, there is no clear way of understanding an architecture
with respect to an organization‟s life cycle concerns— software quality concerns such as
maintainability, portability, modularity, reusability, and so forth. Several studies have shown that
50% to 70% of the total lifecycle cost for a software system is spent on evolving the system.
Since incorporating anticipated changes generally requires considerably less effort than
unanticipated changes, it is important to prepare a software system for likely changes during
development. We believe, if done early on, architectural analysis can reduce that cost by
revealing a design‟s implications. This, in turn can lead to early detection of errors and to themost predictable and cost-effective modifications to the system over its life-cycle. Moreover,
architectural analysis can be done inexpensively, without detailed knowledge of the system.
This paper addresses these shortcomings by describing three perspectives by which we can
understand the description of a software architecture and then proposing a five-step method for
analyzing software architectures called SAAM (Software Architecture Analysis Method).
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 7/26
2
2. LITERATURE SURVEY
2.1 SOFTWARE ARCHITECTURE DEFINITION AND DESCRIPTION
The software architecture (SA) of a system is defined as “ the structure or structures of the
system, which comprise software components, the externally visible properties of those
components, and the relationships among them”. This definition focuses only on the internal
aspects of a system and most of the analysis methods are based on it. For an analysis of
flexibility, the external environment is just as important as an internal entity of a system. The SA
definition consists of two parts, namely a macro-architecture which focuses on the environment
of the system, and a microarchitecture which covers the internal structure of a system.
The research in the SA description addresses the different perspectives one could have of the
architecture. Each perspective is described as a view. Although there is still no general
agreement about which views are the most useful, the reason behind multiple views is always the
same: Separating different aspects into separate views help people manage complexity. Several
models have been proposed that introduce a number of views that should be described in the SA.
The view models share the fact that they address a static structure, a dynamic aspect, a physical
layout, and the development of the system.
2.2 WHY FOCUS ON SOFTWARE ARCHITECTURE?
There are several reasons to consider architectural view. First, architecture is often the first
design artifact that represents decisions on how requirements of all types are to be achieved. As
the manifestation of early design decisions, it represents design decisions that are hardest to
change and hence most deserving of careful consideration. Second, an architecture is also the key
artifact in successfully engineering a product line. Product line engineering is the disciplined,
structured development of a family of similar systems with less effort, expense and risk than
would be. Finally, the architecture is usually the first artifact to be examined when the
programmer unfamiliar with the system begins to work with.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 8/26
3
2.3 ARCHITECTURAL VIEWS
As we have seen, software architecture describes “a high level configuration of system
components and the connections that coordinate component activities”. There are several aspect s
of this definition. First, even though we say “software” architecture, quite often high level
configurations describe functionality that will ultimately be performed by software or hardware.
Second, we say a high-level-configuration rather than the high-level-configuration because a
system can comprise more than one type of component. Each decomposition will therefore have
its own configuration.
A system may, for example, comprise set of modules as well as a set of cooperating sequential
processes, each of which resides in one or more modules. Both the process and module
viewpoints are valid, and both are architectural in nature. However, they carry different
information. From the process viewpoint, we can describe system interaction as during
executions in terms of how and when process becomes active or dormant, pass or share data, or
otherwise synchronize. From the module viewpoint, we can describe the interaction of the teams
responsible for building the modules in terms of the information they are allowed to share,
required to share or prohibited from sharing. The process viewpoint has implications for
performance; the module viewpoint has implications for maintainability. The point is that
different views support the analysis of different architectural qualities.
2.4SOFTWARE ARCHITECTURE ANALYSIS METHOD (SAAM)
Software Architecture Analysis Method (SAAM) is a methodology used to determine how
specific application quality attributes were achieved and how possible changes in the future will
affect quality attributes based on hypothetical cases studies. Common quality attributes that can
be utilized by this methodology include modifiability, robustness, portability, and extensibility.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 9/26
4
Quality Attribute: Application Modifiability
The Modifiability quality attribute refers to how easy it changing the system in the future will be.
In order for SAAM to be properly applied for checking this attribute specific hypothetical case
studies need to be created and review for the modifiability attribute due to the fact that various
scenarios would return various results based on the amount of changes.
Quality Attribute: Application Robustness
The Robustness quality attribute refers to how an application handles the unexpected. The
unexpected can be defined but is not limited to anything not anticipated in the originating design
of the system. For example: Bad Data, Limited to no network connectivity, invalid permissions,
or any unexpected application exceptions.
Quality Attribute: Application Portability
The Portability quality attribute refers to the ease of porting an application to run in a new
operating system or device.
Quality Attribute: Application Extensibility
The Extensibility quality attribute refers to the ease of adding new features to an existing
application without impacting existing functionality.
2.5 SCENARIOS
Analysts can use a description of software system architecture to evaluate the system‟s ability to
exhibit certain quality attributes. Software architecture describes a high-level configuration of
system components and the connections that coordinate component activities. Different
architectural views, such as module or process, provide different kinds of information. A good
understanding of system design at the architectural level makes it easier to detect design errorsearly on and easier to modify the system later.
However, evaluating an architecture to determine how the resulting system will satisfy properties
or qualities such as modifiability or security is difficult. Quality attributes tend to be vague and
provide little procedural support for evaluating an architecture. There are no simple (scalar)
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 10/26
5
“universal” measurements for attributes such as safety or portability. Rather, there are only
context-dependent measures, meaningful solely in specific circumstances. Safety benchmarks are
a fine example. If there was a universal measurement of safety, benchmarks would be
unnecessary. As it is, a benchmark represents data about a system executing with particular
inputs in a particular environment.
Scenarios offer a way to review these vague qualities in more specific circumstances by
capturing system use contexts. Scenarios have been widely used to compare design alternatives,
but they have not been applied as we use them in SAAM. By using scenarios to express
particular instances of each quality attribute a customer deems important, developers can analyze
the architecture with respect to how well or how easily it satisfies the constraints imposed by
each scenario.
Scenarios differ widely in breadth and scope. Our scenarios are one-sentence descriptions,
probably closer to vignettes. We do, however, have an extensive scope, including scenarios for
all roles that involve the system. We include not only the common role of system operator, but
also the roles of system designer and modifier, system administrator, and others, depending on
the domain. We believe this wide scope is important because decisions may be made to
accommodate any of these roles.
Scenarios also force designers to consider the future uses of, and changes to, the system. Instead
of asking to what degree a system can be modified, designers must ask how the architecture will
accommodate a particular change in the system, or how the architecture will accommodate a
class of changes. Scenarios, in effect, channel architectural analysis into an inspection of the
architecture and focus attention on potential trouble spots.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 11/26
6
3. METHODOLOGY
3.1 SAAM ACTIVITIES
SAAM was initially developed to help in comparing architectural solutions, but the method
evolved to a set of steps that provide a structured scenario-based architectural analysis. For most
applications of SAAM, scenarios are used as the foundation for illuminating architectural
properties and from these applications emerged a stable set of activities and interdependencies.
SAAM therefore may be considered a canonical method for scenario-based architecture analysis
of computer-based systems; particular analysis efforts may be carried out using a subset or
variation of SAAM as appropriate.
Figure 1: Activities and dependencies in scenario-based analysis
Figure 1 shows the steps of SAAM and the dependency relationships between those stages. The
steps of SAAM, and the products of each, are:
3.1.1 DESCRIBE THE CANDIDATE ARCHITECTURE
For any analysis, we must first have an architectural representation of the product with a well
specified semantic interpretation that describes what it means to be a component or a connector.
The description should be in a syntactic architectural notation that all parties involved in the
analysis can understand. The architectural description should indicate the system‟s computation
and data components, as well as all component relationships (sometimes called connectors), and
their interfaces. Moreover, a software architecture may have more than one representation. A
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 12/26
7
typical representation will distinguish between components that are active (transform data) and
passive (store data) and also depict data connections (passing information between components)
and control connections (one component enabling another to perform its function).
This simple lexicon provides a reasonable static representation of the architecture. Moreover, we
need a description of how the system behaves over time, a dynamic representation of the
architecture. This can be a natural language specification of the overall behavior or some other
formal and structured specification.
3.1.2 DEVELOP SCENARIOS
Develop task scenarios that illustrate the kinds of activities the system must support and the
kinds of changes which it is anticipated will be made to the system over time. In developing
these scenarios, it is important to capture all important uses of a system. Thus scenarios will
represent tasks relevant to different roles such as: end user/customer, marketing, system
administrator, maintainer, and developer.
3.1.3 EVALUATE EACH SCENARIO
For each scenario, we should determine if the architecture can execute it directly, or if a change
is required to execute it. If no architectural change is required, the scenario is direct. Otherwise,
it is indirect. We are interested primarily in indirect scenarios because they represent the extra
functions the architecture must satisfy; direct scenarios represent functions the architecture
already has. Direct scenarios are interesting only insofar as they indicate a component's potential
complexity. For each indirect scenario, we should list the changes necessary for the architecture
to execute the scenario and estimate the cost of performing the change in terms of, say, person
hours required or lines of code affected. Modifying the architecture means introducing a new
Component or connection or changing the specification of an existing component or connection.
By the end of this stage, we should have a summary table that lists all direct and indirectscenarios. For each indirect scenario, we should describe the impact (set of changes) the scenario
has on the architecture. We have found it sufficient to list the existing Components and
connections that must be altered, a rough cost measure of those alterations, and the new
components and connections that must be introduced and their cost. SAAM does allow for more
sophisticated cost functions if they are needed. A tabular summary is especially useful when
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 13/26
8
comparing alternative architectural candidates because it lets you easily determine which
architecture better supports a collection of scenarios.
3.1.4 REVEAL SCENARIO INTERACTION
When two or more indirect scenarios necessitate changes to some component, they are said to
interact. Revealing this scenario interaction is important because we are exposing how the
product‟s functionality is allocated in the design. Scenario interaction shows us which modules
are involved in which tasks. A high degree of interaction may mean that the functionality of a
particular component is poorly isolated. The designer can then see and correct this trouble spot.
The amount of scenario interaction is related to metrics such as structural complexity, coupling,
and cohesion and so is likely to be strongly correlated with the number of defects in the final
product.
When determining scenario interaction, we identify scenarios that affect a common set of
components. Scenario interaction measures the extent to which the architecture supports an
appropriate separation of concerns.
3.1.5 WEIGHT SCENARIOS AND SCENARIO INTERACTIONS
Once we have determined the scenarios, mapped them onto the structural description, and
revealed all scenario interactions, the scenario implications should be clear. We should now
weight each scenario and scenario interaction in terms of relative importance and use that
weighting to determine an overall ranking. „This is a subjective process that involves all
stakeholders in the system. The weighting reflects the relative importance of the quality factors
that the scenarios manifest.
In essence, we will have a collection of small metrics for comparing architectures rather than a
single architectural metric. With these mini-metrics (per-scenario analyses), we can use SAAM
to compare competing architectures on a per-scenario basis. When candidate architectures
outscore each other on different scenarios, it is up to us to determine which scenarios are most
important and thus which architecture is most desirable. In other words, this step is impossible to
perform without first understanding specific organizational requirements.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 14/26
9
3.1.6 DEPENDENCIES
As Figure 1 shows, the first and second steps are highly interdependent. Deciding the appropriate
level of granularity for an architecture will depend on the kinds of scenarios we wish to evaluate
(though not all scenarios are appropriate, such as a code-size scenario). Determining a reasonable
set of scenarios also depends on the kinds of activities we expect the system to be able to
perform, and that is reflected in the architecture. One important relationship between the first and
second steps is the role that direct scenarios plays in helping us understand an architectural
description. For example, they can help us determine static architectural connections and form
more structured descriptions of an architecture‟s dynamic behavior. Other dependencies may
also exist.
For example, when performing an architectural analysis of a system in its design phase, the
evaluation of individual scenarios or scenario interaction may cause the designers to modify the
architectural representation.
3.2 WRCS: CASE STUDY
In this section we will discuss the application of SAAM to a commercially available revision
control system, based upon RCS, which we will call WRCS.
3.2.1 WRCS SYSTEM CONTEXT/PURPOSE
WRCS provides the functionality to allow developers of projects the ability to create archives,
compare files, check files in and out, create releases, backup to old versions of files, and so on.
“Project” in this context means any group of related files that, when linked together
appropriately, form a finished product. For example these files might be source code for a
computer program, text for a book, or digitized audio and video for the creation of a video clip.
WRCS keeps track of changes made to these files as they evolve over time. It provides
capabilities for multiple users to work on the same project within their own private work areas,
allowing each developer to modify and test the system in isolation, without disturbing other
developers' work and without corrupting the primary copy of the system. Managerial functions,
such as production of reports, are also provided. WRCS‟s functionality has been integrated with
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 15/26
10
several program development environments, and can be accessed through these tools, or through
WRCS‟s own graphical user interface.
3.2.2 APPLYING SAAM
In this section we present the steps of SAAM taken to arrive at an architectural evaluation of
WRCS, as shown in Figure 1, and the evaluation itself.
Figure 2: WRCS activities (shaded) and artifacts
3.2.2.1 DESCRIBING CANDIDATE ARCHITECTURE
For any evaluation to take place we require an architectural representation of the product with a
well specified semantic interpretation (principally what it means to be a component or a
connector). Creating an architectural description proved to be one of the most difficult tasks in
evaluating WRCS. At the start of this project there was no architectural description of the
product, and so they needed to devise a way of eliciting this information. This information had to
be analyzed and grouped in a way that it would aid in the construction of an architectural
diagram.
Their sources of information were limited: they consisted of interviews with some of the
members of the development team, the product's documentation, and the product itself. In
particular, they had no access to the source code or the product's specifications. This is
appropriate in that software architecture is supposed to concern itself with a level of abstraction
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 16/26
11
above code. In essence, their task was reverse engineering: to create a design document out of a
finished product.
The product's architectural description was arrived at iteratively. At each stage we studied the
products existing description, the product itself (executables and libraries), and its
documentation, and devised a new set of questions. The answers to the questions in each stage
helped us to clarify the current description. Each new stage allowed us to obtain more insight on
the product and motivate new questions to be asked in order to arrive at the next stage. Since we
didn't have any previous representation we chose to start with a gross listing of the modules
along with their basic relationships, and from there iterate, adding structure as we went. The
process of eliciting scenarios also helped to clarify the architecture.
It took three iterations to obtain a representation which was satisfactory for architectural
evaluation. This representation is shown in Figure .
Figure 3: Architectural Representation of WRCS
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 17/26
12
3.2.2.2 DEVELOP SCENARIOS
During the process of describing the architecture, scenarios were continually developed that
represented the various stakeholder roles in the system. For WRCS these roles were: users,
developers, maintainers, and system administrators. Scenarios can be thought of as descriptions
of tasks associated with system roles. We elicited a set of 15 tasks from the WRCS domain
expert. The list of scenarios below reflects the more significant tasks. A complete evaluation of a
more complex system than WRCS would involve dozens of scenarios. Scenario enumeration is
simply a particular form of requirements elicitation and analysis. These scenarios were
developed in discussion with all the stake-holders in the system, in order to try to characterize all
current and projected uses of the system. The scenarios formed the basis for all further
architectural evaluation.
For the user role, scenarios included:
Compare binary file representations.
Configure the product‟s toolbar.
Port to another operating system.
Make minor modifications to the user interface.
Change access permissions for a project.
Integrate with a new development environment.
3.2.2.3 EVALUATE EACH SCENARIO
Once the scenarios have been created, we then need to classify them as direct (i.e. those that can
be satisfied by executing the system being developed) or indirect (i.e. those which require a
change to some of the components or connections within the architecture). The direct/indirect
classification is a first indication of the fitness of an architecture with respect to satisfying a set
of scenarios. For example, looking at scenario 2 above, if one can reconfigure a product‟s toolbar
within the product, then we say that this is a direct scenario with respect to WRCS‟s architecture.
If one needs to modify the architecture to achieve this change then the task is indirect, and so the
architecture is less desirable with respect to the feature. At this stage, we also want to estimate
the difficult of the change (say, in terms of person-hours required, or lines of code impacted).
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 18/26
13
One might simply modify an ASCII resource file and re-start the product, in which case the
architectural implications of this indirect scenario are minimal. One might need to change an
internal table and re-compile, in which case the implications of scenario 2 are moderate. Or one
might need to dramatically re-structure the user interface code, in which case the implications are
considerable.
Table 1 : Scenario evaluations for WRCS
3.2.2.4 REVEAL SCENARIO INTERACTIONS
When two or more indirect task scenarios necessitate changes to some component of a system,
they are said to interact. Scenario interaction is an important consideration because it exposes the
allocation of functionality to the product's design. In a very explicit way it is capable of showing
which modules of the system are involved in tasks of different nature. High scenario interactions
reveal a poor isolation of functionality in a particular component of a design, giving a clear
guideline on where to focus the designer's subsequent attention. As it is shown in the results
section, the amount of scenario interaction is related to metrics such as structural complexity,
coupling, and cohesion, and so it is likely to be strongly correlated with number of defects in the
final product.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 19/26
14
Table 2: Scenario interactions by module for WRCS
Table 2 shows the number of changes required in each module. In this table all 15 scenarios
elicited in the WRCS analysis are taken into account, not just the subset presented earlier.
Because each scenario imposes a single change to the architecture, the number of changes per
module indicates the level of indirect scenario interactions for that module.
To highlight scenario interactions, a fish-eye view of the architecture is used in which the
module size is proportional to the number of interacting scenarios that affect it. Figure 4 shows
this representation. This contrasts to the view in Figure 3, in which all modules are of equal size.
Figure 3 shows that the WRCS module clearly has the most scenario interactions, so it is a
natural focus for future development efforts. Main and hook also suffer from high scenario
interaction, with visdiff and ctrls having slightly less. This view shows at a glance the most
architecturally significant features and where designers and developers should allocate time and
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 20/26
15
effort. It is found to be a highly effective device for focusing communication among WRCS team
members.
Figure 4: Fish-eye Representation of Scenario Interactions in WRCS
3.2.2.5 WEIGH SCENARIOS AND SCENARIO INTERACTIONS
Once the scenarios have been determined, mapped onto the structural description, and all
scenario interactions have been determined, the extent of the implications of the scenarios is
made manifest. All that remains to be done is to prioritize the scenarios which have been
identified as potentially problematic, in order to arrive at an overall evaluation of the
architecture.
3.2.2.6 RESULTS OF CASE STUDY
The WRCS analysis identified a number of severe limitations in achieving the extra-functional
qualities of portability and modifiability. A major redesign of the system was recommended.
Having gone through an analysis procedure such as SAAM before implementation would have
substantially contributed to avoiding the problems which the WRCS developers now face.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 21/26
16
3.2.2.7 CONCLUSION ON THE CASE STUDY
Within the organization the evaluation itself obtained mixed results. Senior developers and
managers found a very important tool in architectural analysis and plan to impose it in future
developments of new products. They realized that they can identify many potential problems
early in the software life cycle and at an extremely low cost. Within the WRCS team, however,
this evaluation was regarded as just an academic exercise. This was attributed to the fact that
senior developers and managers have enough perspective to understand that the majority of the
software development life cycle is spent in maintenance and feature enhancements. For this
reason, any effort aids in improving a product's support for extra functional qualities is
significant. However, the developers within the WRCS team did not have this broad perspective.
When one is concerned with meeting the next release deadlines, or with finding a bug, there is no
time for the luxury of contemplating major changes to the architecture. In the words of one
senior manager: “they have features to implement”. This is why architectural analysis must be
done early. Otherwise, it will never be done or, if done, it will be meaningless.
SAAM allowed an insight to the product capabilities that could not be easily achieved from
inspections of code and design documents. In a very simple, straightforward and cost-effective
way it exposed specific limitations of the product. Furthermore, this was accomplished with only
scant knowledge of the internal workings of WRCS. As mentioned earlier, the researchers had no
access to the WRCS source code.
Most importantly, the process, and its frustrating lack of real usable results, has caused the
WRCS team to change their practice for future development. It has convinced them of the need
for architectural analysis upfront.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 22/26
17
4. RESULTS
Having known them performed architectural evaluations on half a dozen small to medium sized
software architectures and two large industrial systems, we begin to see patterns emerging in the
ways that architectural analysis proceeds, and in the benefits which accrue to the process.
4.1 SAAM ENHANCE COMMUNICATION
The strengths of SAAM are largely social. The process of analysis helps to focus attention on the
important details of the architecture, and allows users to ignore less critical areas. The use of
scenarios has proven to be an important tool for both communication among a team of
developers and for communication between a development team and upper-level managers. The
use of scenarios suggests where to: refine an architectural description, ask more questions, and
refine an analysis. It is diff icult to get agreement on an “appropriate” set of scenarios; the process
of doing so forces the systems stakeholders to talk and reach consensus. A collection of scenarios
particularly scenarios which have caused problems for similar systems in the past can provide a
benchmark with which to evaluate new designs.
Finally, visualization has proven to be an effective tool in communicating design problems to the
stakeholders. The visualization of an architecture, emphasizing scenarios and scenario interaction
focuses attention, effectively proposing areas for discussion.
4.2 IMPROVEMENT OF TRADITIONAL ARCHITECTURAL METRICS
Architectural evaluation has an interesting relationship with the more traditional design notions
of coupling and cohesion. Good architectures exhibit low coupling and high cohesion in terms of
some breakdown of functionality. What does this mean in terms of a SAAM analysis? Low
coupling means that a single scenario doesn‟t affect large numbers of structural components.High cohesion means that structural components are not host to scenario interactions. The
implication of this correspondence is that architectural analysis is a means of determining
coupling and cohesion in a highly directed manner.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 23/26
18
Architectural metrics such as structural complexity, as well as metrics for coupling and cohesion,
have been criticized as being crude instruments of measure. SAAM improves upon these metrics
by allowing one to measure coupling and cohesion with respect to a particular scenario or set of
scenarios. In this way the instruments of measures become much sharper, and hence more
meaningful. For example, in the standard interpretation of coupling, if two components are
coupled, they are coupled irrespective of whether they communicate once (say, for initialization)
or repeatedly. Similarly, structural complexity measures (based upon data inflows and outflows
from components) do not consider predicted future changes to a given part of the architecture.
They simply record a part of the architecture with a high structural complexity as being “bad”.
Scenarios, on the other hand, will tease cases such as these apart.
4.3 DETERMINING THE PROPER LEVEL OF ARCHITECTURAL DESCRIPTION
Viewing software from a higher level of abstraction (that of software architecture) means that
you must choose an appropriately high level of description. The level of description you choose
is dictated by the scenarios. This is exactly what happened when we iterated through our three
versions of the representation of the WRCS system.
To illustrate this point, however, let us look at part of the WRCS system. When first describing
the system‟s software architecture, the designers will arbitrarily choose a level of description.
When the architecture has been given its initial structural description, we need to map the
scenarios onto the structure. In particular, for each indirect scenario, we need to highlight the
components and connections which will be affected by the change that the scenario implies. We
are primarily interested in indirect scenarios as they represent the extra-functional qualities
which the direct scenarios represent the system‟s function. Direct scenarios, and their
interactions are interesting only insofar as they indicate a component‟s potential complexity.
The mapping of scenarios onto the structural description serves two purposes: it aids in
validating scenario interaction (a difficult process without this step, as describes); and it guides
the process of architectural evaluation.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 24/26
19
4.4 EFFICIENT SCENARIO GENERATION
Given the great emphasis that SAAM places on scenarios, an interesting question is: “when has
one generated a sufficient number of scenarios to adequately test the architecture”? , Or put
another way: “when should one stop generating new scenarios”? There are two possible answers
to this question. The simple answer is: “when you run out of resources”. The more complex, and
more meaningful answer involves reflecting back on the analysis technique. One can stop
generating scenarios when the addition of a new scenario no longer perturbs the design. In this
way scenario generation is much like software testing: we cannot prove that you have a sufficient
number of test cases, but we can determine a point at which the addition of new test cases is
providing negligible improvement to the software.
One way of minimizing the number of scenarios needed (again, on analogy with testing), is to
group scenarios into equivalence classes. However, this merely generates a new question. Given
the emphasis on classes of scenarios to determine architectural cohesion, how can we determine
whether scenarios are appropriately grouped into classes. If two scenarios, A and B, are not
clustered in an architecture, but they should be (i.e. they are of the same class), then they must be
allocated to at least two distinct structural components. If these components contain functionality
which is irrelevant to the satisfaction of scenarios A and B, then we can always devise an
additional scenario which will cause interaction in the components to which A and B were
allocated. If, on the other hand, the components contain only the functionality germane to the
satisfaction of scenarios A and B, then we should see the following pattern in our analysis: the
same set of structural components affected by both scenarios A and B, and no other components
are affected by these scenarios.
Another way of thinking about the problem of scenario classes is: all domain experts should
cluster scenarios the same way. If they do not, they have additional, implicit scenarios in mind,
and these must be elicited.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 25/26
20
5. CONCLUSION
After seeing results of many case studies conducted in scenario-based architectural analysis, it is
observed that in almost all instances, developers benefit from the analysis. The primary benefits
were a deepened understanding of the system; enhanced communication both among the
development team and among developers, managers, and customers; the ability to make high-
level comparisons of competing designs and to document those comparisons; and the ability to
consider and document the effects of sets of proposed system changes.
7/28/2019 SA Seminar Report 78 88
http://slidepdf.com/reader/full/sa-seminar-report-78-88 26/26
6. REFERENCES
[1] R. Kazman, Gregory Abowd, Len Bass and Paul Clements, “Scenario Based Analysis of Software Architecture”,
IEEE Software, pp. 47-55, Nov.1996.
[2] R. Kazman et al., “SAAM: A Method for Analyzing the Properties of Software Architectures,” Proc. Int‟l Conf.
Software Eng., IEEE CS Press, Los Alamitos, Calif., 1984, pp. 81-90.
[3] W. Tichy, “RCS-A System for Version Control,” Software-Practice and Experience, July 1985, pp. 637-654.
[4] Kazman, R., Bass, L., Abowd, G., Webb, M., “SAAM : A Method for Analyzing the Properties of Software
Architectures”, Proceedings of ICSE 16, Sorrento, Italy, May 1994, 81 -90.
[5] Liliana Dobrica and Eila Niemela, “A Survey on Software Architecture Analysis Methods”, IEEE Transactions
on Software Engineering, Vol. 28, No. 7, July 2002
[6] http://en.wikipedia.org/wiki/Revision_Control_System (Accessed: 3/5/2013)
[7] http://en.wikipedia.org/wiki/Software_architecture_analysis_method (Accessed: 3/5/2013)