SOFTWARE ARCHITECTURE AND DESIGN PATTERNS

UNIT-II: Analyzing Architectures

• Architecture Evaluation
• Architecture design decision making
• ATAM (Architecture Trade off Analysis Method )
• CBAM (Cost-Benefit Analysis Method )
• Moving from one system to many
• Software Product Lines
• Building systems from off the shelf components
• Software architecture in future.

Architecture evolution is the process of maintaining and adapting an existing software architecture to meet changes in requirements and environment.

As software architecture provides a fundamental structure of a software system, its evolution and maintenance would necessarily impact its fundamental structure.

Architecture activities

• Architectural analysis
• Architectural synthesis
• Architecture evolution

​

Architecture supporting activities

• Knowledge management and communication is the act of exploring and managing knowledge that is essential to designing a software architecture. 
• Design reasoning and decision making is the activity of evaluating design decisions.

Architectural analysis is the process of understanding the environment in which a proposed system will operate and determining the requirements for the system.

The input or requirements to the analysis activity can come from any number of stakeholders and include items such as:

​

what the system will do when operational (the functional requirements)

​

how well the system will perform runtime non-functional requirements such as reliability, operability, performance efficiency, security, compatibility defined in ISO/IEC 25010:2011 standard

​

development-time of non-functional requirements such as maintainability and transferability defined in ISO 25010:2011 standard

​

business requirements and environmental contexts of a system that may change over time, such as legal, social, financial, competitive, and technology concerns

The Architecture Tradeoff Analysis Method (ATAM)

The Architecture Tradeoff Analysis Method (ATAM) is a method for evaluating software architectures relative to quality attribute goals. Method evaluations expose architectural risks that potentially inhibit the achievement of an organization’s business goals.

A trade-off (or tradeoff) is a situational decision that involves diminishing or losing one quality, quantity or property of a set or design in return for gains in other aspects.

In simple terms, a tradeoff is where one thing increases and another must decrease.

Need of Architectural Analysis?

The earlier you find a problem in a software project, the better off you are.�An unsuitable architecture will bring disaster on a project.�Architecture evaluation is a cheap way to avoid disaster

​

Participants in ATAM:

1. The evaluation team

team leader

evolution leader

scenario and processing scribe

timekeeper

process observe

2. Project decision makers

3. Architecture stakeholders

developers

testers

users

builders of systems

The method consists of nine steps:

• Present the ATAM.
• Present business drivers.
• Present architecture.
• Identify architectural approaches.
• Generate quality attribute utility tree.
• Analyze architectural approaches.
• Brainstorm and prioritize scenarios.
• Analyze architectural approaches.
• Present results.

Phases of the ATAM

​

Phase 0

activity: preparation

participants: evaluation team leadership and key project decision makers

typical duration: proceeds informally as required, perhaps over a few weeks

​

Phase 1

activity: evaluation (steps 1-6)

participants: evaluation team and project decision makers

typical duration: 1 day followed by a hiatus of 2 to 3 weeks

​

Phase 2

activity: evaluation (steps 7-9)

participants: evaluation team, project decision makers and stakeholders

typical duration: 2 days

​

Phase 3

activity: follow-up

participants: evaluation team and evaluation client

typical duration: 1 week

Outputs of ATAM

A concise presentation of the architecture.

Articulation of business goals.

The quality requirement in terms of a collection of scenarios.

Mapping of architectural decisions to quality requirements.

A set of identified sensitivity and tradeoff points.

A set of risks and non-risks.

A set of risk themes.

Software Architecture Evaluation Methods

• ATAM, Architecture Trade-off Analysis Method.
• CBAM, Cost Benefit Analysis Method.
• SAAM, Software Architecture Analysis Method.
• ALMA, Architecture Level Modifiability Analysis.
• FAAM, Family – Architecture Analysis Method.

Cost-Benefit Analysis Method (CBAM)

• CBAM an architecture-centric method for analyzing the costs, benefits and schedule implications of architectural decisions.
• SAAM and ATAM considered the design decisions with respect to architectural quality attributes like modifiability, performance, availability, usability, and so on.
• CBAM is different from the former methods, it add the costs (and implicit budgets or money) as quality attributes.

​

Context of CBAM

Prerequisites and Inputs for CBAM

Inputs in a CBAM evaluation session are:

- The business goals presentation.

- The architectural decisions and possible tradeoffs resulted in a former ATAM session.

- The quality attributes expectation level and economical constraints. (Budget)

​

CBAM Steps

CBAM Outcomes and Strengths

• The method provides values as a basis for a rational decision making process in applying certain architectural strategies
• The method provides a business measure that can determine the level of return on investment of a particular change to the system.
• The method will help organizations in analyzing and pre-evaluating the resource investment in different directions by adopting those architectural strategies that are maximizing the gains and minimize the risks.

Architecture design decision making

In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.

Architectural decisions influence and impact the non-functional characteristics of a system.

Each architectural decision describes a concrete, architecturally significant design issue (a.k.a. design problem, decision required) for which several potential solutions (a.k.a. options, alternatives) exist.

An architectural decision captures the result of a conscious, often collaborative option selection process and provides design rationale for the decision making outcome, e.g., by referencing one or more of the quality attributes addressed by the architectural decision and answering "why" questions about the design and option selection.

Architectural decisions concern a software system as a whole, or one or more of the core components of such a system.

Types of architectural decisions are the selection of architectural tactics and patterns, of integration technologies, and of middleware, as well as related implementation strategies and assets (both commercial products and open source projects).

Decision management steps

Decision identification

Before a decision can be made, the need for a decision must be articulated: how urgent and how important is the AD?

Decision making

A number of decision making techniques exists, both general ones and software and software architecture specific ones, for instance, dialogue mapping.

Group decision making is an active research topic.

Decision documentation

Many templates and tools for decision capturing exist, both in agile communities and in software engineering and architecture design methods

Decision enactment (enforcement)

Architectural decisions are used in software design; hence they have to be communicated to, and accepted by, the stakeholders of the system that fund, develop, and operate it.

Architectural decisions also have to be considered when modernizing a software system in software evolution.

​

Decision sharing (optional step)

Many architectural decisions recur across projects; hence, experiences with past decisions, both good and bad, can be valuable reusable assets when employing an explicit knowledge management strategy.

Making decisions

• To make each design decision, the software engineer uses:
• Knowledge of
• the requirements (use cases, UI prototype, supplementary specification document, class diagrams, interaction diagrams …)
• the design as created ‘so far’
• Available technologies (RMI, RPC, xml, jsp, servlets, html, jdbc, etc. etc.) given a development environment
• software design principles and ‘best practices’
• what has worked well in the past

​

• Sometimes there is no single, best solution.

​

• Sometimes they conflict – each presenting pros and cons

Principles Leading to Good Design

• Overall goals of Good Design:
• Increase profit by reducing cost and increasing revenue
• Ensure design accommodates requirements
• Speed up development for use / competing in marketplace
• Increase qualities such as
• Usability – learnability; ease of use; on-line help…
• Efficiency
• Reliability
• Maintainability
• Reusability to reduce cost and increase revenues

Software Product Line

Software product line is defined as “A set of software-intensive systems sharing a common managed set of features that satisfy the specific needs of a particular market segment or mission”

These Systems are developed from a common core of assets (e.g. a common architecture) in a prescribed way.

The creation and validation of product line software architectures are inherently more complex than those of software architectures for single systems.

​

​

​

​

​

​

PLA Development Process

PuLSE-DSSA Process

​

• PuLSE (Product Line Software Engineering) Domain-Specific Software Architecture
• The PuLSE-DSSA is a customizable process that integrates product line architecture creation and evaluation
• The input is a scope definition and a domain model,
• The scope definition determines the commonalities and variations of applications within the product line.

​

​

�PuLSE-DSSA Process Steps �

1. Create Scenarios

• Determine the most important requirements captured in scenarios that describe critical use-cases

​

• Conventional scenarios are described on an instance level, which makes it difficult to convey the variability information needed for product line requirements

​

• We need to create generic scenarios that represent commonalities and variabilities

2. Group and Sort Scenarios

• This step yields the architecture creation plan that defines the iterations in which the architecture development is performed.
• The first iteration deals with the most important group of scenarios, the second one with the second most important group and so forth

​

​

3. Define Test Cases

• For each group of scenarios, test cases are defined that will be used to evaluate the architecture at the end of each iteration.
• evaluating the architecture is based on specific kinds of system level quality objectives such as maintainability, understandability, and reusability.

4. Apply Scenarios

• The group of scenarios associated with the current iteration is used to create the initial architecture or to refine/extend an already existing, partial architecture.
• This step also includes the possible integration of existing components (legacy or COTS) as well as prototyping.

5. Evaluate Architecture

• In this step, the architecture resulting from the previous step is evaluated according to the architecture evaluation plan
• Evaluation has to address instance-specific as well as family specific aspects and relies on a defined instantiation mechanism.

​

​

​

​

​

6. Analyze Problems

• In this step, the underlying problems from the evaluation step are examined in order to determine how the architecture development process can be continued.
• The examination focuses on whether the current group of scenarios could be applied successfully to the architecture that resulted from the previous iterations.

​

​

​

​

​

Building systems from off the shelf components�