SA Seminar Report 78 88

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



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.



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



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



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



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).



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.



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.

http://www.dotnetblocks.com/post/2011/09/06/Software-Architecture-Analysis-Method-%28SAAM%29.aspx

http://www.dotnetblocks.com/post/2011/09/06/Software-Architecture-Analysis-Method-%28SAAM%29.aspx



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)



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.



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

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



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.



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



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



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



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).



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.



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



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.



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.



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.



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.



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.



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.



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)

http://en.wikipedia.org/wiki/Revision_Control_System



http://en.wikipedia.org/wiki/Software_architecture_analysis_method





SA Seminar Report 78 88

Documents

Transcript of SA Seminar Report 78 88