You are on page 1of 14

Software architecture refers to the high level structures of a software system, the discipline of creating such

structures, and the documentation of these structures. These structures are needed to reason about the
software system.

Characteristics
Multitude of stakeholders:
Separation of concerns:
Quality-driven:
Recurring styles:
Conceptual integrity:
Architectural Synthesis or design is the process of creating an architecture. Given the architecturally
significant requirements determined by the analysis, the current state of the design and the results of any
evaluation activities, the design is created and improved. See

[3]:pp.311326[23]

for a discussion of various techniques

for improving a current design.


Architecture Evaluation is the process of determining how well the current design or a portion of it satisfies
the requirements derived during analysis. An evaluation can occur whenever an architect is considering a
design decision, it can occur after some portion of the design has been completed, it can occur after the final
design has been completed or it can occur after the system has been constructed. Some of the available
software architecture evaluation techniques include Architecture Tradeoff Analysis Method (ATAM)and TARA.
[27]

Frameworks for comparing the techniques are discussed in frameworks such as SARA Report

Architecture reviews: practice and experience.

[15]

and

[28]

Architecture Evolution is the process of maintaining and adapting an existing software architecture to meet
requirement and environmental changes. As software architecture provides a fundamental structure of a
software system, its evolution and maintenance would necessarily impact its fundamental structure. As such,
architecture evolution is concerned with adding new functionality as well as maintaining existing functionality
and system behaviour.
Architecture requires critical supporting activities. These supporting activities take place throughout the core
software architecture process. They include knowledge management and communication, design reasoning
and decision making, and documentation.

Architectural Structures and Views

Definition

View
A representation of a set of elements and the relations among them.

Structure
The set of elements itself, as they exist in software or hardware

Restrict our attention at any one moment to one (or a small number) of the software syste
structures.

To communicate meaningfully about an architecture, we must make clear which structure


we are discussing at the moment

SOFTWARE STRUCTURES

Module structures
Elements are modules, which are units of implementation.
* What is the primary functional responsibility assigned to each module?
* What other software elements is a module allowed to use?
* What other software does it actually use?

Decomposition
* shows how larger modules are decomposed into smaller ones recursively

Uses
* The units are: modules, procedures or resources on the interfaces of modules
* The units are related by the uses relation

Layered
* "uses relations" structured into layers

Class, or generalization

* shows the inherits-from or is-an-instance-of relations among the modules

Component-and-connector structures
Elements are runtime components (units of computation) and connectors (communication
among components)
The relation is attachment, showing how the components and connectors are hooked toge
* What are the major executing components and how do they interact?
* What are the major shared data stores?
* Which parts of the system are replicated?
* How does data progress through the system?
* What parts of the system can run in parallel?
* How can the systems structure change as it executes?

Process, or communicating processes


* units are processes or threads that are connected with each other by communicat
synchronization, and/or exclusion operations

Concurrency
* The units are components and the connectors are logical threads
* A logical thread is a sequence of computation that can be allocated to a separate
thread

Shared data, or repository


* This structure comprises components and connectors that create, store, and acce
data

Client-server
* The components are the clients and servers, and the connectors are protocols and

Allocation structures
the relationship between the software elements and the elements in one or more external
environments
* What processor does each software element execute on?
* In what files is each element stored during development, testing, and system building?
* What is the assignment of software elements to development teams?

Deployment
* Shows how software (usually a process from a component-and-connector view) is
hardware-processing and communication elements
* Relations are allocated-to and migrates-to if the allocation is dynamic

Implementation
* how software elements (usually modules) are mapped to the file structure(s)

Work assignment
* assigns responsibility for implementing and integrating the modules to developme

RELATING STRUCTURES TO EACH OTHER

Elements of one structure are related to elements of other structures

Often the dominant structure is module decomposition, because it spawns the project stru

Structures represent a powerful separation-of-concerns approach for creating the architect

Structures are basis for architecture documentation

Quality Attributes
This quality attributes section on SoftwareArchitectures.com is the gateway to
resources that address the following areas of the subject:

Guidance on creating quality attribute scenarios

Requirements: how quality attributes fit in the requirement elicitation process

Design: letting quality attributes and the utility tree drive the design

Taxonomy: a comprehensive list of common quality attributes

Sample quality attribute scenarios

Examples of quality attribute scenarios in real architecture documentsE

Introduction
Developing high quality software is hard, especially when the interpretation of term
quality is patchy based on the environment in which it is used. In order to know if
quality has been achieved, or degraded, it has to be measured, but determining
what to measure and how is the difficult part.
Software Quality Attributes are the benchmarks that describe systems intended
behavior within the environment for which it was built. The quality attributes provide
the means for measuring the fitness and suitability of a product. Software

architecture has a profound affect on most qualities in one way or another, and
software quality attributes affect architecture.
Identifying desired system qualities before a system is built allows system designer
to mold a solution (starting with its architecture) to match the desired needs of the
system within the context of constraints (available resources, interface with legacy
systems, etc). When a designer understands the desired qualities before a system is
built, then the likelihood of selecting or creating the right architecture is improved.
Scenarios
Statements like a system will have high performance or a system will be user
friendly are acceptable in the really early stages of requirements elicitation process
(i.e. business concept brainstorming). As more information becomes available, the
above statements become useless as they are meaningless for the purpose of
actually designing a solution. In each of the two examples above an attempt is made
to describe the behavior of a system. Both statements are useless as they provide
no tangible way of measuring the behavior of the system.
The quality attributes must be described in terms of scenarios, such as when 100
users initiate complete payment transition, the payment component, under normal
circumstances, will process the requests with an average latency of three seconds.
This statement, or scenario, allows an architect to make quantifiable arguments
about a system. A scenario defines the source of stimulus (users), the actual
stimulus (initiate transaction), the artifact affected (payment component), the
environment in which it exists (normal operation), the effect of the action (transaction
processed), and the response measure (within three seconds). Writing such detailed
statements is only possible when relevant requirements have been identified and an
idea of components has been proposed.
Writing effective scenarios takes some time to learn. But it's an important skill, as it's
in the scenarios where the desired vague software behaviors are turned into tangible
and measurable goals. Measurable goals tells you what architectural approaches
and tactis to apply as you design the system. It's easiest to learn by looking at

examples. See this resource on how you can download a catalog of over 100 well
defined quality attribute scenarios.
Achieving Qualities
Scenarios help describe the qualities of a system, but they dont describe how they
will be achieved. Architectural tactics describe how a given quality can be achieved.
For each quality there may be a large set of tactics available to an architect. It is the
architects job to select the right tactic in light of the needs of the system and the
environment. For example, a performance tactics may include options to develop
better processing algorithms, develop a system for parallel processing, or revise
event scheduling policy. Whatever tactic is chosen, it must be justified and
documented.
Taxonomy of Software Qualities
Over the past 10 years software architects have devised a list of common software
qualities. It would be nave to claim that the list below is as a complete taxonomy of
all software qualities but its a solid list of general software qualities compiled from
respectable sources. Domain specific systems are likely to have an additional set of
qualities in addition to the list below.
System qualities can be categorized into four parts: runtime qualities, non-runtime
qualities, business qualities, and architecture qualities. Each of the categories and
its associated qualities are briefly described below. Other articles on this site provide
more information about each of the software quality attributes listed below, their
applicable properties, and the conflicts the qualities.
Runtime System Qualities
Runtime System Qualities can be measured as the system executes.
Functionality
Definition: the ability of the system to do the work for which it was intended.
Performance
Definition: the response time, utilization, and throughput behavior of the system. Not

to be confused with human performance or system delivery time.


Security
Definition: a measure of systems ability to resist unauthorized attempts at usage or
behavior modification, while still providing service to legitimate users.
Availability (Reliability quality attributes falls under this category)
Definition: the measure of time that the system is up and running correctly; the
length of time between failures and the length of time needed to resume operation
after a failure.
Usability
Definition: the ease of use and of training the end users of the system. Sub qualities:
learnability, efficiency, affect, helpfulness, control.
Interoperability
Definition: the ability of two or more systems to cooperate at runtime
Non-Runtime System Qualities
Non-Runtime System Qualities cannot be measured as the system executes.
Modifiability
Definition: the ease with which a software system can accommodate changes to its
software
Portability
Definition: the ability of a system to run under different computing environments. The
environment types can be either hardware or software, but is usually a combination
of the two.
Reusability
Definition: the degree to which existing applications can be reused in new
applications.
Integrability
Definition: the ability to make the separately developed components of the system
work correctly together.
Testability
Definition: the ease with which software can be made to demonstrate its faults

Business Qualities
Non-Software System Qualities that influence other quality attributes.
Cost and Schedule
Definition: the cost of the system with respect to time to market, expected project
lifetime, and utilization of legacy and COTS systems.
Marketability
Definition: the use of the system with respect to market competition.
Appropriateness for Organization
Definition: availability of the human input, allocation of expertise, and alignment of
team and software structure. Business process re-engineering
Architecture Qualities
Quality attributes specific to the architecture itself.
Conceptual Integrity
Definition: the integrity of the overall structure that is composed from a number of
small architectural structures.
Correctness
Definition: accountability for satisfying all requirements of the system.
Domain Specific Qualities
Quality attributes found in specific business domains.
Sensitivity
Definition: the degree to which a system component can pick up something being
measured.
Calibrability
Definition: ability of a system to recalibrate itself to some specific working range

Attribute-driven design[1][2] (also called ADD or Attribute-driven design method) is a methodology to create
software architectures that takes into account the quality attributes of the software. I

The Attribute-Driven Design method[edit]

In the book Software architecture in practice[4] the authors describe ADD as an iterative method that, at each
iteration, helps the architect to do the following steps:

Choose a part of the system to design.

Marshal all the architecturally significant requirements for the selected part. This means that you select
all quality attributes and business goals that could affect the architecture of this phase.

Create an architecture for the selected part that meets the selected architecturally significant
requirements and test this design.

Required input[edit]
ADD can only be started successfully when the following resources are already available:

functional requirements

quality requirements

constraints

Of course, we cannot wait until all these requirements are finalized since this can take a while. The ADD
process can start once a set of ASRs (architecturally significant requirements, which are the three resources
listed above) are available.

Process steps[edit]
1. Choose an element of the system to design

Select an element of the system that is not yet designed. In the first iteration this will be the
system itself. Later on, a choice will need to be made between several elements. This choice can
be based on personnel availability, input resources availability, risk mitigation, etc. In case you do
not have any of these limitations, it is suggested to go for a breadth-first strategy.

2. Identify the ASRs for the chosen element

Identify the ASRs that are most important for this selected element. You should prioritize these
requirements to make sure that your design reflects the most important ASRs.

3. Generate a design solution for the chosen element

This step is the heart of ADD since the architecture will be created in this step. The
architecture you create should reflect the selected ASRs. You can do this by making use

of architectural patterns or tactics. Most of the times you will have to make a trade-off between
several tactics and ASRs.
4. Inventory remaining requirements and select the input for the next iteration

Take a look at the listed ASRs and see whether they are already fulfilled with the design you
have at the moment. For each ASR you will have to check whether it is satisfied, delegated to one
of the children, distributed among the children or whether it can not be satisfied. In the last case
you will need to change your architecture.

5. Repeat steps 1-4 until all the ASRs have been satistfied

Repeat!

Output[edit]
A set of sketches of architectural views, NOT a full-blown detailed architecture.

elow are the steps of the QAW.

Business and/or mission drivers for the system (goals and drivers), plan, strategies,
high-level functional requirements, constraints, artifacts and quality attribute
requirements should be presented to the stakeholders. Using Business Scenario in
conjunction with QAWs can be an appropriate approach.
A QAW lends itself to the capture of many architecturally relevant materials:

Software architectural documentation is a collection of view packets plus any


documentation that applies to more than one view
Each view packet contains a primary presentation, a catalogue of the views
elements (including element behaviour), use case diagrams, sequence diagram,
context diagrams, collaboration diagram, a variability guide, architecture
background (rationale, analysis results, and assumptions about the
environment), and other information including mapping to requirements

These elements may also be produced in a Business Scenario or produced later in the
ADM phases A : Architecture Vision, C: Information Systems Architectures
(stakeholders management and taxonomy of artifacts).

The outputs from the QAW can be summarised as:

A list of architectural drivers

Raw scenarios

A prioritized list of raw scenarios

Refined scenarios

Questionnaire

Quality attribute requirements are the means by which a system is intended to meet
its business goals and QAW helps to document them.
Software architectures must be designed so that their quality attributes are met.
The QAWs technique can be utilised as a complementary approach to gather all sort of
requirements including those from Software Architectures when appropriate. - See
more at: http://sergethorn.blogspot.in/2013/09/using-cmusei-quality-attributeworkshop_10.html#sthash.et1oOzWH.dpuf

You might also like