An Implementation Strategy Using SAAM Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Software Architecture Analysis Methods or SAAM is the first promulgate architecture analysis methods which use quality attributes with the usage of scenarios. It is a good method for the first time users and also it can be used in the heuristic evaluation of other system qualities. The scenarios in SAAM are scrutinized, prioritized and mapped to represent the architecture. After that the scenarios are analyzed and the problem areas are identified. SAAM is a software architecture analysis method which involves group work and produces various outputs from number of inputs.


The implementation of the Software Architecture Analysis Method would help quickly asses the quality attributes such as the modifiability, portability, extensibility, and also the functionality of the system. But for a detail assessment of the quality attributes ATAM is used.

SAAM is used to understand the overall functionality of the system. If a single architecture is analyzed using the SAAM method it will indicate the strong points and the weak points of the architecture. It will help identify the area or the points where the architecture has failed to meet its requirements. SAAM will help identify the strong points and the weak points of the Smart Card system. On the other hand, if two or more different architectures which provide same functionality are analyzed with respect to the requirements SAAM will help produce relative ranking between the two architectures.

The SAAM consists of 6 main steps. They include developing scenarios, describing the architecture, classifying and prioritizing scenarios, individual evaluation of indirect scenarios, assessing scenario interaction and finally creating an overall evaluation of the architecture. The following are the main 6 steps discussed in detail for the implementation of Smart Card system using SAAM.

STEP 1- Develop scenarios

The first step in the Software Architecture Analysis Method is the brainstorm exercise where the type of activities the system should support is identified. For example, the storing of data in Smart Card system, the manipulation of data when required and the relevant information display of the Smart Card system is identified. These activities together with possible anticipated modifications are grouped into so called system scenarios. The challenge in developing the system scenarios is to understand and capture:

- All major uses of the system.

- The users of the system.

- All quality attributes of the system and their associated level that the system must reach.

- Most important all foreseeable future changes to the system.

This brainstorm exercise is generally performed two times during the evaluation. The more the iterations and architectural information is shared the more the scenarios are surfaced by the participants. Thus there is a remarkable influence on each other by the architecture description and the scenario development. The recommendation by most experts is to perform these activities in parallel to each other and hence we have implemented the same strategy on the Smart Card system architecture evaluation.

STEP 2- Describe architecture

In the second step of the SAAM it involves presentations about the Smart Card systems architecture, describing it in detail. This is important because the participants need to know the architectural notations used by the system in detail and must point toward the dynamic behavior of the system as well as the static representation of the system such as the system components, the interconnections of the components and the relation with the environment. This step of SAAM is taken in the form of a natural-language specification of the overall behavior or some other more formal specification.

STEP 3- Classify and Prioritize scenarios

At this stage of the SAAM the developed scenarios are classified in as direct scenarios and indirect scenarios. These are equivalent to UML notations such as use-cases and change-cases respectively. A direct scenario is the scenario which is supported by the candidate architecture because it is based on requirements, which the system has been evolved from. The direct scenarios are perfectly candidates as a metric for the architecture's performance or reliability. An indirect scenario is the scenario in which the sequence of events for which realization or accomplishment the architecture must suffer minor or major changes. After the classification of the scenarios as direct and indirect, the scenarios are prioritized. The prioritization of the scenarios is based on a voting procedure. Since SAAM is addressing the system's modifiability assessment, the voting results will be a set of indirect scenarios that are considered most likely to occur.

STEP 4- Individually evaluate indirect scenarios

In case of a direct scenario the architect demonstrates how the scenario would be executed by the architecture. In case of an indirect scenario the architect describes how the architecture would need to be changed to accommodate the scenario. For each indirect scenario the architectural modifications needed is identified to facilitate that scenario together with the impacted and/or new system's components and also the estimated cost and effort to implement the modification is identified. The diagram below is a sample scenario evaluation table used for the architecture evaluation of Smart Card system.

Figure 1: Scenario Evaluation Table

STEP 5- Assess scenario interaction

Two scenarios are said to interact when two or more scenarios are requesting changes over the same component of the architecture. In Smart Card systems architecture, to assess the scenario interaction, the affected components are modified or divided into sub-components in order to avoid of the interaction of the different scenarios.

STEP 6- Create an Overall evaluation

Finally, based on the relative importance of the scenario to the success of the system, each and every scenario is assigned a weight. The weighting ties back to the business goals supported by the scenario or other criteria like costs, risks, time to market, and so on. Based on this scenario weighting can be proposed on an overall ranking if multiple architecture are compared. Alternatives for the most suitable architecture were able to be proposed, covering the direct scenarios and requiring least changes in supporting the indirect scenarios.


In conclusion we could say that the Software Architecture Analysis Method is an architecture analysis method which gives an in-depth understanding about the system being analyzed. The SAAM evaluation method helps to improve the overall software architecture documentation and helps in providing enhanced communication about the system. It is an evaluation method which helps to identify the potential complexity area of any architecture and helps to estimate the cost and necessary effort for the changes needed by any architecture. SAAM evaluation method proved that the Smart Card systems architecture is viable for implementation.


Pick a design from your software development projects and walk through a small ARID exercise on it. Identify the designer who would represent it during the review. Choose the stakeholder you would want to review. Propose a set of scenarios that exemplify its usage.


Active Review for Intermediate Design or the ARID is an architecture evaluation method which lies between the intersection of two approaches such as ATAM or SAAM and the active design reviews. This evaluation method best suits evaluation infancy designs. It is more of an evaluation method for the understanding of the architecture that can be used for a system. In ARID the architecture does not spring into final form but it emerges slowly and it is much of a lightweight approach that concentrates on suitability. In ARID the whole architecture can be undermined if the intermediate designs are inappropriate.


In this section we will highlight on the Active Review for Intermediate Design exercise carried out on the software development project of Smart Card system. We will be highlighting the participants of the ARID exercise, the steps involved in the ARID evaluation method and benefits gained from the ARID exercise.


The ARID requires three participants.

The ARID review team which includes the facilitator who will prepare and run the review meeting along with the help of the lead designer, The scribe of the review team who will note down the inputs by the reviewers and the results during the meeting, And one or more questioners who help to elicit and craft scenarios during the review meeting. Optionally, the review team can consist of a process observer who can observe and note down the obstacles of the exercise and give suggestions for improvement.

The lead designer for the design of the Smart Card who is also known as the spokes person for the design. The lead designer is responsible for presenting the design during the review and it is the lead designer who will get the results of the ARID evaluation.

Reviewers who have a vested interest in the adequacy and usability of the design of the system. Reviewers are the software engineers who will be using the design of the system.


The ARID exercise has two major phases with a total of 9 steps. The first phase is called the Rehearsal phase which involves steps such as identifying the reviewers, preparing the design briefing, preparing the seed scenarios and preparing the materials.

The second phase is called the review phase which comprise of steps such as presenting the ARID, presenting the design, brainstorming and prioritizing scenarios, applying the scenarios and finally summarizing the issues. These steps will be discussed in detail later in this document.


Identifying the reviewers

The lead designer and the facilitator work together to identify the set of people who should be present at the review. The reviewers are generally the software engineers who will be using the design of the system.

Preparing the design briefing

A briefing is prepared by the lead designer explaining the design of the system. Here, during Phase One, the designer should give a dry run of the presentation to the review facilitator, which is helpful in the following ways.

It lets the facilitator see the design, and ask a set of "first order" questions that the reviewers would probably ask, thus helping the designer prepare.

It helps identify areas where the presentation could be improved.

It helps set the pace for the presentation itself, ensuring that the time slot allocated was not overrun.

It gives the designer practice in presenting the material to a critical audience.

Preparing seed scenarios

A set of seed scenarios, designed to illustrate the concept of scenarios to the reviewers, are produced by the designer and the review facilitator. These seed scenarios act as a sample set for the reviewers. The usage of the seed scenarios in the actual evaluation depends on the reviewers hands. The scenarios may or may not be used in the actual evaluation.

Preparing the materials

Copies of the presentation, seed scenarios, and review agenda are produced for distribution to the reviewers during the main review meeting. The meeting is scheduled, reviewers are invited, and steps are taken to assure the presence of a quorum of reviewers at the meeting.


Presenting the ARID

The review facilitator spends 30 minutes explaining the steps of ARID to the participants.

Presenting the design

Presenting the design is the role of the lead designer. The lead designer presents and walks through the examples in two-hours. During this two hours time of presentation of the design, a ground rule is that no questions regarding the implementation or rationale are allowed, nor are suggestions about alternate designs. The main goal of the presentation is to find out if the design is usable. The goal is not to find out how certain things are done or to find out the implementation secrets of the interfaces. Questions arising from factual clarification are allowed and encouraged. The facilitator ensures this rule is enforced during the presentation.

During this time, the scribe notes down each question or each instance where the designer indicated that some sort of resource was on its way but not yet available. The resulting list is summarized to show potential issues that the designer should address before the design could be considered complete and ready for production. In our case, the list of issues was captured on a whiteboard for all to see, and the facilitator made sure that all reviewers understood each issue and agreed with its wording before the presentation continued.

Brainstorming and prioritizing scenarios

The participants suggest scenarios for using the design to solve problems they expect to face. During brainstorming, all scenarios are deemed fair game. The seed scenarios are put into the pool with all the others. After a rich set of scenarios is gathered-in our case it was 20- a winnowing process occurs. Reviewers might suggest that two scenarios are versions of the same scenario or that one subsumes another and should be merged. In our case, we eliminated five scenarios in this manner. After the pool of scenarios is winnowed, voting occurs. Each reviewer is allowed a vote total equal to 30% of the number of scenarios.

They can allocate their votes to any scenario or scenarios they wish. The scenarios receiving the most votes will then be used to "test" the design for usability. After voting is complete, it is important to make the point that the reviewers have just defined what it means for the design to be usable: If it performs well under the adopted scenarios, then it must be agreed that the design has passed the review. Buy-in has begun.

Applying the scenarios