Anda di halaman 1dari 49


Pudukkottai to Aranthangi road, Kaikkurichi, Pudukkottai - 622003

Department of Information Technology



Prepared by,
Mrs. M.Abinaya B.Tech., (M.E)., MISTE,
(Lect. / IT)



3 0 0 3
Introduction What is software architecture? Standard Definitions Architectural structures
Influence of software architecture on organization-both business and technical Architecture
Business Cycle- Introduction Functional requirements Technical constraints Quality
Quality Attribute Workshop Documenting Quality Attributes Six part scenarios Case
Introduction Standard Definitions for views Structures and views - Representing viewsavailable notations Standard views 4+1 view of RUP, Siemens 4 views, SEI's perspectives
and views Case studies
Introduction Data flow styles Call-return styles Shared Information styles - Event styles
Case studies for each style.
Good practices Documenting the Views using UML Merits and Demerits of using visual
languages Need for formal languages - Architectural Description Languages ACME Case
studies. Special topics: SOA and Web services Cloud Computing Adaptive structures.
1. Len Bass, Paul Clements, and Rick Kazman, Software Architectures Principles and
Practices,2nd Edition, Addison-Wesley, 2003.
2. Anthony J Lattanze, Architecting Software Intensive System. A Practitioner's Guide,
Auerbach Publications, 2010.
1. Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo
Merson, Robert Nord, and Judith Stafford, Documenting Software Architectures. Views and
Beyond, 2nd Edition, Addison-Wesley, 2010.
2. Paul Clements, Rick Kazman, and Mark Klein, Evaluating software architectures: Methods
and case studies. Addison-Wesley, 2001.
3. Rajkumar Buyya, James Broberg, and Andrzej Goscinski, Cloud Computing. Principles and
Paradigms, John Wiley & Sons, 2011
4. Mark Hansen, SOA Using Java Web Services, Prentice Hall, 2007
5. David Garlan, Bradley Schmerl, and Shang-Wen Cheng, Software Architecture-Based
SelfAdaptation,31-56.MiesoK Denko, Laurence Tianruo Yang, and Yan Zang (eds.),
Autonomic Computing and Networking. Springer Verlag, 2009.


Typical, but uninformative, presentation of software architecture

Figure taken from a system description for an underwater acoustic simulation, purports
to describe that system's "top-level architecture" and is precisely the kind of diagram most often
displayed to help explain architecture. Exactly what can we tell from it?
The system consists of four elements.
Three of the elements Prop Loss Model (MODP), Reverb Model (MODR), and
Noise Model (MODN) might have more in common with each other than with
the fourthControl Process (CP)because they are positioned next to each
All of the elements apparently have some sort of relationship with each other,
since the diagram is fully connected.
Is this an architecture? What can we not tell from the diagram?
What is the nature of the elements?
What is the significance of their separation? Do they run on separate processors? Do they
run at separate times? Do the elements consist of processes, programs, or both? Do they
represent ways in which the project labor will be divided, or do they convey a sense of runtime
separation? Are they objects, tasks, functions, processes, distributed programs, or something
What are the responsibilities of the elements?
What is it they do? What is their function in the system?
What is the significance of the connections?
Do the connections mean that the elements communicate with each other, control each
other, send data to each other, use each other, invoke each other, synchronize with each other,
share some information-hiding secret with each other, or some combination of these or other
relations? What are the mechanisms for the communication? What information flows across the
mechanisms, whatever they may be?

What is the significance of the layout?

Why is CP on a separate level? Does it call the other three elements, and are the others
not allowed to call it? Does it contain the other three in an implementation unit sense? Or is there
simply no room to put all four elements on the same row in the diagram?
This diagram does not show a software architecture. We now define what does constitute
software architecture:
The software architecture of a program or computing system is the structure or structures
of the system, which comprise software elements, the externally visible properties of those
elements, and the relationships among them.
Let's look at some of the implications of this definition in more detail.
Architecture defines software elements
The definition makes clear that systems can and do comprise more than one structure and
that no one structure can irrefutably claim to be the architecture.
The definition implies that every computing system with software has a software
architecture because every system can be shown to comprise elements and the relations
among them.
The behavior of each element is part of the architecture insofar as that behavior can be
observed or discerned from the point of view of another element. Such behavior is what
allows elements to interact with each other, which is clearly part of the architecture.
The definition is indifferent as to whether the architecture for a system is a good one or a
bad one, meaning that it will allow or prevent the system from meeting its behavioral,
performance, and lifecycle requirements.
The study of software architecture is an attempt to abstract the commonalities inherent in system
design, and as such it must account for a wide range of activities, concepts, methods, approaches,
and results.
Architecture is high-level design. Other tasks associated with design are not
architectural, such as deciding on important data structures that will be encapsulated.
Architecture is the overall structure of the system. The different structures provide the
critical engineering leverage points to imbue a system with the quality attributes that will
render it a success or failure. The multiplicity of structures in an architecture lies at the
heart of the concept.
Architecture is the structure of the components of a program or system, their
interrelationships, and the principles and guidelines governing their design and
evolution over time. Any system has an architecture that can be discovered and analyzed
independently of any knowledge of the process by which the architecture was designed or

Architecture is components and connectors. Connectors imply a runtime mechanism for

transferring control and data around a system. When we speak of "relationships" among
elements, we intend to capture both runtime and non-runtime relationships.


Architectural structures can by and large be divided into three groups, depending on the broad
nature of the elements they show.
Module structures.
Here the elements are modules, which are units of implementation. Modules
represent a code-basedway of considering the system. They are assigned areas of
functional responsibility. There is less emphasis on how the resulting software manifests
itself at runtime. Module structures allow us to answer questions such as 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? What modules are
related to other modules by generalization or specialization (i.e., inheritance)
Component-and-connector structures.
Here the elements are runtime components (which are the principal units of
computation) and connectors (which are the communication vehicles among
components). Component-and-connector structures help answer questions such as 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 system's structure
change as it executes?

Allocation structures.
Allocation structures show the relationship between the software elements and the
elements in one or more external environments in which the software is created and
executed. They answer questions such as 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?
Module-based structures include the following structures.
Decomposition: The units are modules related to each other by the "is a submodule of "
relation, showing how larger modules are decomposed into smaller ones recursively until
they are small enough to be easily understood.
Uses: The units are related by the uses relation. One unit uses another if the correctness
of the first requires the presence of a correct version (as opposed to a stub) of the second.
Layered: Layers are often designed as abstractions (virtual machines) that hide
implementation specifics below from the layers above, engendering portability.
Class or generalization: The class structure allows us to reason about re-use and the
incremental addition of functionality.
Component-and-connector structures include the following structures
Process or communicating processes: The units here are processes or threads that are
connected with each other by communication, synchronization, and/or exclusion
Concurrency: The concurrency structure is used early in design to identify the
requirements for managing the issues associated with concurrent execution.
Shared data or repository: This structure comprises components and connectors that
create, store, and access persistent data

Client-server: This is useful for separation of concerns (supporting modifiability), for

physical distribution, and for load balancing (supporting runtime performance).
Allocation structures include the following structures
Deployment: This view allows an engineer to reason about performance, data integrity,
availability, and security
Implementation: This is critical for the management of development activities and builds
Work assignment: This structure assigns responsibility for implementing and integrating
the modules to the appropriate development teams.


Each of these structures provides a different perspective and design handle on a system, and each
is valid and useful in its own right. In general, mappings between structures are many to many.
Individual structures bring with them the power to manipulate one or more quality attributes.
They represent a powerful separation-of concerns approach for creating the architecture.
Kruchten's four views follow:
Logical. The elements are "key abstractions," which are manifested in the object-oriented
world as objects or object classes. This is a module view.
Process. This view addresses concurrency and distribution of functionality. It is a
component-and connector view.
Development. This view shows the organization of software modules, libraries,
subsystems, and units of development. It is an allocation view, mapping software to the
development environment.
Physical. This view maps other elements onto processing and communication nodes and
is also an allocation view.
An architecture is the result of a set of business and technical decisions. There are many
influences at work in its design, and the realization of these influences will change depending on
the environment in which the architecture is required to perform. Even with the same
requirements, hardware, support software, and human resources available, an architect designing
a system today is likely to design a different system than might have been designed five years
Many people and organizations interested in the construction of a software system are
referred to as stakeholders. E.g. customers, end users, developers, project manager etc.
Having an acceptable system involves properties such as performance, reliability,
availability, platform compatibility, memory utilization, network usage, security,
modifiability, usability, and interoperability with other systems as well as behavior.
The underlying problem, of course, is that each stakeholder has different concerns and
goals, some of which may be contradictory.
The reality is that the architect often has to fill in the blanks and mediate the conflicts.
Architecture is influenced by the structure or nature of the development organization.
There are three classes of influence that come from the developing organizations:
immediate business, long-term business and organizational structure.

An organization may have an immediate business investment in certain assets, such as

existing architectures and the products based on them.
An organization may wish to make a long-term business investment in an infrastructure
to pursue strategic goals and may review the proposed system as one means of financing
and extending that infrastructure.
The organizational structure can shape the software architecture.
If the architects for a system have had good results using a particular architectural
approach, such as distributed objects or implicit invocation, chances are that they will try
that same approach on a new development effort.
Conversely, if their prior experience with this approach was disastrous, the architects may
be reluctant to try it again.
Architectural choices may also come from an architects education and training, exposure
to successful architectural patterns, or exposure to systems that have worked particularly
poorly or particularly well.
The architects may also wish to experiment with an architectural pattern or technique
learned from a book or a course.
A special case of the architects background and experience is reflected by the technical
The environment that is current when an architecture is designed will influence that
architecture. It might include standard industry practices or software engineering
prevalent in the architects professional community.
The influences on the architect, and hence on the architecture, are shown in Figure 1.3.

Influences on an architecture come from a wide variety of sources. Some are only implied, while
others are explicitly in conflict.
Architects need to know and understand the nature, source, and priority of constraints on
the project as early as possible.
Therefore, they must identify and actively engage the stakeholders to solicit their needs
and expectations.
Architects are influenced by the requirements for the product as derived from its
stakeholders, the structure and goals of the developing organization, the available
technical environment, and their own background and experience.
Relationships among business goals, product requirements, architects experience,
architectures and fielded systems form a cycle with feedback loops that a business can
A business manages this cycle to handle growth, to expand its enterprise area, and to take
advantage of previous investments in architecture and system building.
The software architecture of a program or computing system is the structure or structures
of the system, which comprise software elements, the externally visible properties of those
elements, and the relationships among them.

Figure shows the feedback loops. Some of the feedback comes from the architecture
itself, and some comes from the system built from it.
Software architecture is a result of technical, business and social influences. Its existence
in turn affects the technical, business and social environments that subsequently influence
future architectures.
This cycle of influences, from environment to the architecture and back to the environment, the
Architecture Business Cycle (ABC).
How organizational goals influence requirements and development strategy.
How requirements lead to architecture.
How architectures are analyzed.
How architectures yield systems that suggest new organizational capabilities and
Working of architecture business cycle:
1. The architecture affects the structure of the developing organization. An architecture
prescribes a structure for a system it particularly prescribes the units of software that must
be implemented and integrated to form the system. Teams are formed for individual
software units; and the development, test, and integration activities around the units.
Likewise, schedules and budgets allocate resources in chunks corresponding to the units.
Teams become embedded in the organizations structure. This is feedback from the
architecture to the developing organization.
2. The architecture can affect the goals of the developing organization. A successful system
built from it can enable a company to establish a foothold in a particular market area. The
architecture can provide opportunities for the efficient production and deployment of the
similar systems, and the organization may adjust its goals to take advantage of its

newfound expertise to plumb the market. This is feedback from the system to the
developing organization and the systems it builds.
3. The architecture can affect customer requirements for the next system by giving the
customer the opportunity to receive a system in a more reliable, timely and economical
manner than if the subsequent system were to be built from scratch.
4. The process of system building will affect the architects experience with subsequent
systems by adding to the corporate experience base.
5. A few systems will influence and actually change the software engineering culture. i.e,
The technical environment in which system builders operate and learn.
Software process is the term given to the organization, reutilization, and management of
software development activities.
The various activities involved in creating software architecture are:
Creating the business case for the system
It is an important step in creating and constraining any future requirements.
How much should the product cost?
What is its targeted market?
What is its targeted time to market?
Will it need to interface with other systems?
Are there system limitations that it must work within?
These are all the questions that must involve the systems architects.
They cannot be decided solely by an architect, but if an architect is not consulted in the
creation of the business case, it may be impossible to achieve the business goals.
Understanding the requirements
There are a variety of techniques for eliciting requirements from the stakeholders.
For ex:
1. Object oriented analysis uses scenarios, or use cases to embody requirements.
2. Safety-critical systems use more rigorous approaches, such as finite-state-machine
models or formal specification languages.
Another technique that helps us understand requirements is the creation of prototypes.
Regardless of the technique used to elicit the requirements, the desired qualities of the
system to be constructed determine the shape of its structure.
Creating or selecting the architecture
In the landmark book The Mythical Man-Month, Fred Brooks argues forcefully and
eloquently that conceptual integrity is the key to sound system design and that conceptual
integrity can only be had by a small number of minds coming together to design the system's
Documenting and communicating the architecture
For the architecture to be effective as the backbone of the projects design, it must be
communicated clearly and unambiguously to all of the stakeholders.

Developers must understand the work assignments it requires of them, testers must
understand the task structure it imposes on them, management must understand the
scheduling implications it suggests, and so forth.
Analyzing or evaluating the architecture
Choosing among multiple competing designs in a rational way is one of the architects
greatest challenges.
Evaluating an architecture for the qualities that it supports is essential to ensuring that the
system constructed from that architecture satisfies its stakeholders needs.
Use scenario-based techniques or architecture tradeoff analysis method (ATAM) or cost
benefit analysis method (CBAM).
Implementing the system based on the architecture
This activity is concerned with keeping the developers faithful to the structures and
interaction protocols constrained by the architecture.
Having an explicit and well-communicated architecture is the first step toward ensuring
architectural conformance.
Ensuring that the implementation conforms to the architecture
Finally, when an architecture is created and used, it goes into a maintenance phase.
Constant vigilance is required to ensure that the actual architecture and its representation
remain to each other during this phase.
Given the same technical requirements for a system, two different architects in different
organizations will produce different architectures, how can we determine if either one of them is
the right one?
We divide our observations into two clusters: process recommendations and product (or
structural) recommendations.
Process recommendations are as follows:
The architecture should be the product of a single architect or a small group of architects
with an identified leader.
The architect (or architecture team) should have the functional requirements for the
system and an articulated, prioritized list of quality attributes that the architecture is
expected to satisfy.
The architecture should be well documented, with at least one static view and one
dynamic view, using an agreed-on notation that all stakeholders can understand with a
minimum of effort.
The architecture should be circulated to the systems stakeholders, who should be
actively involved in its review.
The architecture should be analyzed for applicable quantitative measures (such as
maximum throughput) and formally evaluated for quality attributes before it is too late to
make changes to it.

The architecture should lend itself to incremental implementation via the creation of a
skeletal system in which the communication paths are exercised but which at first has
minimal functionality. This skeletal system can then be used to grow the system
incrementally, easing the integration and testing efforts.
The architecture should result in a specific (and small) set of resource contention areas,
the resolution of which is clearly specified, circulated and maintained.
Product (structural) recommendations are as follows:
The architecture should feature well-defined modules whose functional responsibilities
are allocated on the principles of information hiding and separation of concerns.
Each module should have a well-defined interface that encapsulates or hides
changeable aspects from other software that uses its facilities. These interfaces should
allow their respective development teams to work largely independent of each other.
Quality attributes should be achieved using well-known architectural tactics specific to
each attribute.
The architecture should never depend on a particular version of a commercial product or
Modules that produce data should be separate from modules that consume data. This
tends to increase modifiability.
For parallel processing systems, the architecture should feature well-defined processors
or tasks that do not necessarily mirror the module decomposition structure.
Every task or process should be written so that its assignment to a specific processor can
be easily changed, perhaps even at runtime.
The architecture should feature a small number of simple interaction patterns.
Functional requirements
Each child module has responsibilities that derive partially from considering
decomposition of the functional requirements. Those responsibilities can be translated into use
cases for the module. Another way of defining use cases is to split and refine the parent use
cases. For example, a use case that initializes the whole system is broken into the initializations
of subsystems. This approach has traceability because an analyst can follow the refinement.
In our example, the initial responsibilities for the garage door opener were to open and close
the door on request, either locally or remotely; to stop the door within 0.1 second when an
obstacle is detected; and to interact with the home information system and support remote
diagnostics. The responsibilities are decomposed into the following functional groups
corresponding to the modules:
User interface. Recognize user requests and translate them into the form expected by the
raising/lowering door module.

Raising/lowering door module. Control actuators to raise or lower the door. Stop the door
when it reaches either fully open or fully closed.
Obstacle detection. Recognize when an obstacle is detected and either stop the descent of
the door or reverse it.
Communication virtual machine. Manage all communication with the home information
Sensor/actuator virtual machine. Manage all interactions with the sensors and actuators.
Scheduler. Guarantee that the obstacle detector will meet its deadlines.
Diagnosis. Manage the interactions with the home information system devoted to

Constraints of the parent module can be satisfied in one of the following ways:
The decomposition satisfies the constraint. For example, the constraint of using a certain
operating system can be satisfied by defining the operating system as a child module. The
constraint has been satisfied and nothing more needs to be done.
The constraint is satisfied by a single child module. For example, the constraint of using a
special protocol can be satisfied by defining an encapsulation child module for the
protocol. The constraint has been designated a child. Whether it is satisfied or not
depends on what happens with the decomposition of the child.
The constraint is satisfied by multiple child modules. For example, using the Web
requires two modules (client and server) to implement the necessary protocols. Whether
the constraint is satisfied depends on the decomposition and coordination of the children
to which the constraint has been assigned.
In our example, one constraint is that the communication with the home information system
is maintained. The communication virtual machine will recognize if this communication is
unavailable, so the constraint is satisfied by a single child.

To be meaningful, quality attribute requirements must be specic about how an
application should achieve a given need. A common problem I regularly encounter in
architectural documents is a general statement such as The application must be scalable.
A performance quality requirement denes a metric that states the amount of work an
application must perform in a given time, and/or deadlines that must be met for correct
Throughput is a measure of the amount of work an application must perform in unit time.
Work is typically measured in transactions per second (tps), or messages processed per second
(mps). For example, an on-line banking application might have to guarantee it can execute 1,000

tps from Internet banking customers. An inventory management system for a large warehouse
might need to process 50 messages per second from trading partners requesting orders.
Response Time
This is a measure of the latency an application exhibits in processing a business
transaction. Response time is most often (but not exclusively) associated with the time an
application takes to respond to some input. A rapid response time allows users to work more
effectively, and consequently is good for business.
An excellent example is a point-of-sale application supporting a large store. When an
item is scanned at the checkout, a fast, second or less response from the system with the items
price means a customer can be served quickly. This makes the customer and the store happy, and
thats a good thing for all involved stakeholders.
How well a solution to some problem will work when the size of the problem increases.
This is useful in an architectural context. It tells us that scalability is about how a design can
cope with some aspect of the applications requirements increasing in size.

Request Load
In the perfect world and without additional hardware capacity, as the load increases,
application throughput should remain constant (i.e., 100 tps), and response time per request
should increase only linearly (i.e., 10 s).
A scalable solution will then permit additional processing capacity to be deployed to
increase throughput and decrease response time. This additional capacity may be deployed in
two different ways, one by adding more CPUs (and likely memory) to the machine the
applications runs on (scale up), the other from distributing the application on multiple machines
(scale out).
The modiability quality attribute is a measure of how easy it may be to change an
application to cater for new functional and nonfunctional requirements. Note the use of may in
the previous sentence. Predicting modiability requires an estimate of effort and/or cost to make
a change. You only know for sure what a change will cost after it has been made. Then you nd
out how good your estimate was.
Modiability measures are only relevant in the context of a given architectural solution.
This solution must be expressed at least structurally as a collection of components, the
component relationships and a description of how the components interact with the environment.
Then, assessing Modiability requires the architect to assert likely change scenarios that capture
how the requirements may evolve.
Change scenarios are:

Provide access to the application through rewalls in addition to existing behind the
rewall access.
Incorporate new features for self-service check-out kiosks.
The COTS speech recognition software vendor goes out of business and we need to
replace this component.
The application needs to be ported from Linux to the Microsoft Windows platform.

Security is a complex technical topic that can only be treated somewhat supercially
here. At the architectural level, security boils down to understanding the precise security
requirements for an application, and devising mechanisms to support them.
The most common security-related requirements are:
Authentication: Applications can verify the identity of their users and other
applications with which they communicate.
Authorization: Authenticated users and applications have dened access rights to the
resources of the system. For example, some users may have read-only access to the
applications data, while others have readwrite.
Encryption: The messages sent to/from the application are encrypted.
Integrity: This ensures the contents of a message are not altered in transit.
Nonrepudiation: The sender of a message has proof of delivery and the receiver is
assured of the senders identity. This means neither can subsequently refute their
participation in the message exchange.
Availability is related to an applications reliability. If an application isnt available for
use when needed, then its unlikely to be fullling its functional requirements. Availability is
relatively easy to specify and measure.
Failures in applications cause them to be unavailable. Failures impact on an applications
reliability, which is usually measured by the mean time between failures. The length of time any
period of unavailability lasts is determined by the amount of time it takes to detect failure and
restart the system. Consequently, applications that require high availability minimize or
preferably eliminate single points of failure, and institute mechanisms that automatically detect
failure and restart the failed components.
Other Quality Attributes
There are numerous other quality attributes that are important in various application
contexts. Some of these are:
Portability: Can an application be easily executed on a different software/ hardware
platform to the one it has been developed for? Portability depends on the choices of
software technology used to implement the application, and the characteristics of the
platforms that it needs to execute on. Easily portable code bases will have their platform

dependencies isolated and encapsulated in a small set of components that can be replaced
without affecting the rest of the application.
Testability: How easy or difcult is an application to test? Early design decisions can
greatly affect the amount of test cases that are required. As a rule of thumb, the more
complex a design, the more difcult it is to thoroughly test. Simplicity tends to promote
ease of testing. Likewise, writing less of your own code by incorporating pretested
components reduces test effort.
Supportability: This is a measure of how easy an application is to support once it is
deployed. Support typically involves diagnosing and xing problems that occur during
application use. Supportable systems tend to provide explicit facilities for diagnosis, such
as application error logs that record the causes of failures. They are also built in a
modular fashion so that code xes can be deployed without severely inconveniencing
application use.

The QAW is one way to discover, document, and prioritize a systems quality attributes
early in its life cycle. This is the third edition of a technical report describing the QAW. We have
narrowed the scope of a QAW to the creation of prioritized and refined scenarios. This report
describes the newly revised QAW and describes potential uses of the refined scenarios generated
during it.
The Quality Attribute Workshop (QAW) is a facilitated method that engages system
stakeholders early in the system development life cycle to discover the driving quality attributes
of a software-intensive system. The QAW is system-centric and stakeholder focused; it is used
before the software architecture has been created. The QAW provides an opportunity to gather
stakeholders together to provide input about their needs and expectations with respect to key
quality attributes that are of particular concern to them

Both the system and software architectures are key to realizing quality attribute requirements in
the implementation. Although architecture cannot guarantee that an implementation will meet its
quality attribute goals, the wrong architecture will surely spell disaster. As an example, consider
security. It is difficult, maybe even impossible, to add effective security to a system as an
afterthought. Components as well as communication mechanisms and paths must be designed or
selected early in the life cycle to satisfy security requirements. The critical quality attributes must
be well understood and articulated early in the development of a system, so the architect can
design an architecture that will satisfy them. The QAW is one way to discover, document, and
prioritize a systems quality attributes early in its life cycle.

It is important to point out that we do not aim at an absolute measure of quality; rather
our purpose is to identify scenarios from the point of view of a diverse group of stakeholders
(e.g., architects, developers, users, sponsors). These scenarios can then be used by the system
engineers to analyze the systems architecture and identify concerns (e.g., inadequate
performance, successful denial-of-service attacks) and possible mitigation strategies (e.g.,
prototyping, modeling, and simulation).
QAW Method
The QAW is a facilitated, early intervention method used to generate, prioritize, and
refine quality attribute scenarios before the software architecture is completed. The QAW is
focused on system-level concerns and specifically the role that software will play in the system.
The QAW is dependent on the participation of system stakeholdersindividuals on whom the
system has significant impact, such as end users, installers, administrators (of database
management systems [DBMS], networks, help desks, etc.), trainers, architects, acquirers, system
and software engineers, and others. The group of stakeholders present during any one QAW
should number at least 5 and no more than 30 for a single workshop. In preparation for the
workshop, stakeholders receive a participants handbook providing example quality attribute
taxonomies, questions, and scenarios. If time allows, the handbook should be customized to the
domain of the system and contain the quality attributes, questions, and scenarios that are
appropriate to the domain and the level of architectural detail available.
The contribution of each stakeholder is essential during a QAW; all participants are expected to
be fully engaged and present throughout the workshop. Participants are encouraged to comment
and ask questions at any time during the workshop. However, it is important to recognize that
facilitators may occasionally have to cut discussions short in the interest of time or when it is
clear that the discussion is not focused on the required QAW outcomes. The QAW is an intense
and demanding activity. It is very important that all participants stay focused, are one time, and
limit side discussions throughout the day.
The QAW involves the following steps:
1. QAW Presentation and Introductions
2. Business/Mission Presentation
3. Architectural Plan Presentation
4. Identification of Architectural Drivers
5. Scenario Brainstorming
6. Scenario Consolidation
7. Scenario Prioritization
8. Scenario Refinement

The following sections describe each step of the QAW in detail.

Step 1: QAW Presentation and Introductions
In this step, QAW facilitators describe the motivation for the QAW and explain each step
of the method. We recommend using a standard slide presentation that can be customized
depending on the needs of the sponsor. Next, the facilitators introduce themselves and the
stakeholders do likewise, briefly stating their background, their role in the organization, and their
relationship to the system being built.
Step 2: Business/Mission Presentation
After Step 1, a representative of the stakeholder community presents the business and/or
mission drivers for the system. The term business and/or mission drivers is used carefully here.
Some organizations are clearly motivated by business concerns such as profitability, while
others, such as governmental organizations, are motivated by mission concerns and find
profitability meaningless. The stakeholder representing the business and/or mission concerns
(typically a manager or management representative) spends about one hour presenting
the systems business/mission context
high-level functional requirements, constraints, and quality attribute requirements
During the presentation, the facilitators listen carefully and capture any relevant information
that may shed light on the quality attribute drivers. The quality attributes that will be refined in
later steps will be derived largely from the business/mission needs presented in this step.
Step 3: Architectural Plan Presentation
While detailed system architecture might not exist, it is possible that high-level system
description, context drawings, or other artifacts have been created that describe some of the
systems technical details. At this point in the workshop, a technical stakeholder will present the
system architectural plans as they stand with respect to these early documents. Information in
this presentation may include
plans and strategies for how key business/mission requirements will be satisfied
key technical requirements and constraintssuch as mandated operating systems,
hardware, middleware, and standardsthat will drive architectural decisions
presentation of existing context diagrams, high-level system diagrams, and other written
Step 4: Identification of Architectural Drivers
During steps 2 and 3, the facilitators capture information regarding architectural drivers
that are key to realizing quality attribute goals in the system. These drivers often include highlevel requirements, business/mission concerns, goals and objectives, and various quality
attributes. Before undertaking this step, the facilitators should excuse the group for a 15-minute
break, during which they will caucus to compare and consolidate notes taken during steps 2 and
3. When the stakeholders reconvene, the facilitators will share their list of key architectural

drivers and ask the stakeholders for clarifications, additions, deletions, and corrections. The idea
is to reach a consensus on a distilled list of architectural drivers that include high-level
requirements, business drivers, constraints, and quality attributes. The final list of architectural
drivers will help focus the stakeholders during scenario brainstorming to ensure that these
concerns are represented by the scenarios collected.
Step 5: Scenario Brainstorming
After the architectural drivers have been identified, the facilitators initiate the
brainstorming process in which stakeholders generate scenarios. The facilitators review the parts
of a good scenario (stimulus, environment, and response) and ensure that each scenario is well
formed during the workshop.
Each stakeholder expresses a scenario representing his or her concerns with respect to the
system in round-robin fashion. During a nominal QAW, at least two round-robin passes are made
so that each stakeholder can contribute at least two scenarios. The facilitators ensure that atleast
one representative scenario exists for each architectural driver listed in Step 4.Scenario
generation is a key step in the QAW method and must be carried out with care.
We suggest the following guidance to help QAW facilitators during this step:
1. Facilitators should help stakeholders create well-formed scenarios. It is tempting for
stakeholders to recite requirements such as The system shall produce reports for
users.While this is an important requirement, facilitators need to ensure that the quality
attribute aspects of this requirement are explored further. For example, the following
scenario sheds more light on the performance aspect of this requirement: A remote user
requests a database report via the Web during peak usage and receives the report within
five seconds.Note that the initial requirement hasnt been lost, but the scenario further
explores the performance aspect of this requirement. Facilitators should note that quality
attribute names by themselves are not enough. Rather than say the system shall be
modifiable, the scenario should describe what it means to be modifiable by providing a
specific example of a modification to the system vis--vis a scenario.
2. The vocabulary used to describe quality attributes varies widely. Heated debates often
revolve around to which quality attribute a particular system property belongs. It doesnt
matter what we call a particular quality attribute, as long as theres a scenario that
describes what it means.
3. Facilitators need to remember that there are three general types of scenarios and to ensure
that each type is covered during the QAW:
a. use case scenarios - involving anticipated uses of the system
b. growth scenarios - involving anticipated changes to the system
c. exploratory scenarios - involving unanticipated stresses to the system that can
include uses and/or changes

4. Facilitators should refer to the list of architectural drivers generated in Step 4 from
time to time during scenario brainstorming to ensure that representative scenarios exist
for each one.
Step 6: Scenario Consolidation
After the scenario brainstorming, similar scenarios are consolidated when reasonable. To
do that, facilitators ask stakeholders to identify those scenarios that are very similar in content.
Scenarios that are similar are merged, as long as the people who proposed them agree and feels
that their scenarios will not be diluted in the process. Consolidation is an important step because
it helps to prevent a dilution of votes during the prioritization of scenarios (Step 7).Such a
dilution occurs when stakeholders split their votes between two very similar scenarios .As a
result, neither scenario rises to importance and is therefore never refined (Step 8). However, if
the two scenarios are similar enough to be merged into one, the votes might be concentrated, and
the merged scenario may then rise to the appropriate level of importance and be refined further.
Facilitators should make every attempt to reach a majority consensus with the stakeholders
before merging scenarios. Though stakeholders may be tempted to merge scenarios with
abandon, they should not do so. In actuality, very few scenarios are merged.
Step 7: Scenario Prioritization
Prioritization of the scenarios is accomplished by allocating each stakeholder a number of
votes equal to 30% of the total number of scenarios generated after consolidation. The actual
number of votes allocated to stakeholders is rounded to an even number of votes at the discretion
of the facilitators. For example, if 30 scenarios were generated, each stakeholder gets 30 x0.3, or
9, votes rounded up to 10. Voting is done in round-robin fashion, in two passes. . Stakeholders
can allocate any number of their votes to any scenario or combination of scenarios. The votes are
counted, and the scenarios are prioritized accordingly.
Step 8: Scenario Refinement
After the prioritization, depending on the amount of time remaining, the top four or five
scenarios are refined in more detail. Facilitators further elaborate each one, documenting the
Further clarify the scenario by clearly describing the following six things:
1. stimulus - the condition that affects the system
2. response - the activity that results from the stimulus
3. source of stimulus - the entity that generated the stimulus
4. environment - the condition under which the stimulus occurred
5. artifact stimulated - the artifact that was stimulated
6. response measure - the measure by which the systems response will be evaluated
Describe the business/mission goals that are affected by the scenario.
Describe the relevant quality attributes associated with the scenario.

Allow the stakeholders to pose questions and raise any issues regarding the scenario. Such
questions should concentrate on the quality attribute aspects of the scenario and any concerns
that the stakeholders might have in achieving the response called for in the scenario. See the
example template for scenario refinement in Appendix A. This step continues until time runs out
or the highest priority scenarios have been refined. Typically, time runs out first.
QAW Benefits
The QAW provides a forum for a wide variety of stakeholders to gather in one room at onetime
very early in the development process. It is often the first time such a meeting takes place and
generally leads to the identification of conflicting assumptions about system requirements. In
addition to clarifying quality attribute requirements, the QAW provides increased stakeholder
communication, an informed basis for architectural decisions, improved architectural
documentation, and support for analysis and testing throughout the life of the system.
The results of a QAW include
a list of architectural drivers
the raw scenarios
the prioritized list of raw scenarios
the refined scenarios
This information can be used to
update the organizations architectural vision
refine system and software requirements
guide the development of prototypes
exercise simulations
understand and clarify the systems architectural drivers
influence the order in which the architecture is developed
describe the operation of a system
In short, the architect can use this information to design the architecture. In addition, after the
architecture is created, the scenarios can be used as part of a software architecture evaluation. If
the Architecture Tradeoff Analysis MethodSM (ATAMSM)4 is selected as the software
architecture evaluation method, the scenarios generated during the QAW can be incorporated as
seed scenarios in that evaluation .
The QAW lends itself well 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 [Clements 02b]. Each view packet contains a primary presentation, a
catalog of the views elements (including element behavior), a context diagram, a variability

guide, architecture background (rationale, analysis results, and assumptions about the
environment), and other information including mapping to requirements.
Several pieces of this information will be gleaned directly from the QAW. For example,
scenario generation can lead to the creation of use case diagrams, context diagrams, or their
equivalent. Refined scenarios can be documented as sequence diagrams or collaboration
diagrams. Stakeholders concerns and any other rationale information that is captured should be
recorded individually in a form that can be included in the appropriate view packet or overview
documentation. Details that explain how to transition these artifacts into architectural
documentation is the subject of ongoing research. In addition to the more immediate benefits
cited above, the scenarios continue to provide benefits during later phases of development. They
provide input for analysis throughout the life of the system and can be used to drive test case
development during implementation testing.
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.
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 tell 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
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
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.
Definition: the ability of the system to do the work for which it was intended.
Definition: the response time, utilization, and throughput behavior of the system. Not to
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.
Definition: the ease of use and of training the end users of the system. Sub qualities:
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.
Definition: the ease with which a software system can accommodate changes to its
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.
Definition: the degree to which existing applications can be reused in new applications.
Definition: the ability to make the separately developed components of the system work
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
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
Definition: accountability for satisfying all requirements of the system.
Domain Specific Qualities
Quality attributes found in specific business domains.

Definition: the degree to which a system component can pick up something being
Definition: ability of a system to recalibrate itself to some specific working range.
A quality attribute scenario is a quality-attribute-specific requirement. It consists of six
1. Source of stimulus. This is some entity (a human, a computer system, or any other
actuator) that generated the stimulus.
2. Stimulus. The stimulus is a condition that needs to be considered when it arrives at a
3. Environment. The stimulus occurs within certain conditions. The system may be in an
overload condition or may be running when the stimulus occurs, or some other condition
may be true.
4. Artifact. Some artifact is stimulated. This may be the whole system or some pieces of it.
5. Response. The response is the activity undertaken after the arrival of the stimulus.
6. Response measure. When the response occurs, it should be measurable in some fashion
so that the requirement can be tested.



A general scenario is "A request arrives for a change in functionality, and the change must
be made at a particular time within the development process within a specified period." A
system-specific version might be "A request arrives to add support for a new browser to a Webbased system, and the change must be made within two weeks."

Availability scenario

Availability is concerned with system failure and its associated consequences. A system
failure occurs when the system no longer delivers a service consistent with its specification. Such
a failure is observable by the system's userseither humans or other systems.
Once a system fails, an important related concept becomes the time it takes to repair it.
Since a system failure is observable by users, the time to repair is the time until the failure is no
longer observable. This may be a brief delay in the response time.
The availability of a system is the probability that it will be operational when it is needed.
This is typically defined as
mean time
mean time

= failure failure+ meantime repair

From this come terms like 99.9% availability, or a 0.1% probability that the system will
not be operational when needed.
Availability General Scenarios
From these considerations the portions of availability scenario is shown in Figure 2.2.
1. Source of stimulus. We differentiate between internal and external indications of faults or
failure since the desired system response may be different. In our example, the
unexpected message arrives from outside the system.

fig 2.2 availability general scenario

2. Stimulus. A fault of one of the following classes occurs.
omission. A component fails to respond to an input.
crash. The component repeatedly suffers omission faults.
timing. A component responds but the response is early or late.
response. A component responds with an incorrect value.
3. Artifact. This specifies the resource that is required to be highly available, such as a
processor, communication channel, process, or storage.

4. Environment. The state of the system when the fault or failure occurs may also affect the
desired system response. For example, if the system has already seen some faults and is
operating in other than normal mode, it may be desirable to shut it down totally.
5. Response. There are a number of possible reactions to a system failure. These include
logging the failure, notifying selected users or other systems, switching to a degraded
mode with either less capacity or less function, shutting down external systems, or
becoming unavailable during repair. In our example, the system should notify the
operator of the unexpected message and continue to operate normally.
6. Response measure. The response measure can specify an availability percentage, or it can
specify a time to repair, times during which the system must be available, or the duration
for which the system must be available.
Modifiability is about the cost of change. It brings up two concerns.
1. What can change (the artifact)? A change can occur to any aspect of a system, most
commonly the functions that the system computes, the platform the system exists on (the
hardware, operating system, middleware, etc.), the environment within which the system
operates (the systems with which it must interoperate, the protocols it uses to
communicate with the rest of the world, etc.), the qualities the system exhibits (its
performance, its reliability, and even its future modifications), and its capacity (number
of users supported, number of simultaneous operations, etc.). The category of platform
changes is also called portability. Those changes may be to add, delete, or modify any
one of these aspects.
2. When is the change made and who makes it (the environment)? Most commonly in the
past, a change was made to source code. That is, a developer had to make the change,
which was tested and then deployed in a new release. Changes can be made to the
implementation (by modifying the source code), during compile (using compile-time
switches), during build (by choice of libraries), during configuration setup (by a range of
techniques, including parameter setting) or during execution (by parameter setting). A
change can also be made by a developer, an end user, or a system administrator.
3. Once a change has been specified, the new implementation must be designed,
implemented, tested, and deployed. All of these actions take time and money, both of
which can be measured.
Modifiability General Scenarios
From these considerations we can see the portions of the modifiability general scenarios.
Figure 2.3 gives an example:

2.3 modifiability general scenario
"A developer wishes to change the user interface. This change will be made to the code at
design time, it will take less than three hours to make and test the change, and no side-effect
changes will occur in the behavior."
1. Source of stimulus. This portion specifies who makes the changesthe developer, a
system administrator, or an end user. Clearly, there must be machinery in place to allow
the system administrator or end user to modify a system, but this is a common
2. Stimulus. This portion specifies the changes to be made. A change can be the addition of
a function, the modification of an existing function, or the deletion of a function. It can
also be made to the qualities of the systemmaking it more responsive, increasing its
availability, and so forth. The capacity of the system may also change. Increasing the
number of simultaneous users is a frequent requirement.
3. Artifact. This portion specifies what is to be changedthe functionality of a system, its
platform, its user interface, its environment, or another system with which it
4. Environment. This portion specifies when the change can be madedesign time, compile
time, build time, initiation time, or runtime. In our example, the modification is to occur
at design time.
5. Response. Whoever makes the change must understand how to make it, and then make it,
test it and deploy it. In our example, the modification is made with no side effects.
6. Response measure. All of the possible responses take time and cost money, and so time
and cost are the most desirable measures. Time is not always possible to predict,
however, and so less ideal measures are frequently used, such as the extent of the change
(number of modules affected).
Performance is about timing. Events (interrupts, messages, requests from users, or the
passage of time) occur, and the system must respond to them. There are a variety of
characterizations of event arrival and the response but basically performance is concerned with
how long it takes the system to respond when an event occurs.

A performance scenario begins with a request for some service arriving at the system.
Satisfying the request requires resources to be consumed. While this is happening the system
may be simultaneously servicing other requests.
Performance General Scenarios
From these considerations we can see the portions of the performance general scenario,
an example of which is shown in Figure 2.4: "Users initiate 1,000 transactions per minute
stochastically under normal operations, and these transactions are processed with an average
latency of two seconds.

Fig 2.4 performance general scenario

1. Source of stimulus. The stimuli arrive either from external (possibly multiple) or internal
sources. In our example, the source of the stimulus is a collection of users.
2. Stimulus. The stimuli are the event arrivals. The arrival pattern can be characterized as
periodic, stochastic, or sporadic. In our example, the stimulus is the stochastic initiation
of 1,000 transactions per minute.
3. Artifact. The artifact is always the system's services, as it is in our example.
4. Environment. The system can be in various operational modes, such as normal,
emergency, or overload. In our example, the system is in normal mode.
5. Response. The system must process the arriving events. This may cause a change in the
system environment (e.g., from normal to overload mode). In our example, the
transactions are processed.
6. Response measure. The response measures are the time it takes to process the arriving
events (latency or a deadline by which the event must be processed), the variation in this
time (jitter), the number of events that can be processed within a particular time interval
(throughput), or a characterization of the events that cannot be processed (miss rate, data
loss). In our example, the transactions should be processed with an average latency of
two seconds.

Security is a measure of the system's ability to resist unauthorized usage while still
providing its services to legitimate users. An attempt to breach security is called an attack and
can take a number of forms. It may be an unauthorized attempt to access data or services or to
modify data, or it may be intended to deny services to legitimate users.
Security can be characterized as a system providing nonrepudiation, confidentiality,
integrity, assurance, availability, and auditing.
1. Nonrepudiation is the property that a transaction (access to or modification of data or
services) cannot be denied by any of the parties to it. This means you cannot deny that
you ordered that item over the Internet.
2. Confidentiality is the property that data or services are protected from unauthorized
access. This means that a hacker cannot access your income tax returns on a government
3. Integrity is the property that data or services are being delivered as intended. This means
that your grade has not been changed since your instructor assigned it.
4. Assurance is the property that the parties to a transaction are who they purport to be. This
means that, when a customer sends a credit card number to an Internet merchant, the
merchant is who the customer thinks they are.
5. Availability is the property that the system will be available for legitimate use. This
means that a denial-of-service attack won't prevent your ordering this book.
6. Auditing is the property that the system tracks activities within it at levels sufficient to
reconstruct them. This means that, if you transfer money out of one account to another
account, in Switzerland, the system will maintain a record of that transfer.
Security General Scenarios
The portions of a security general scenario are given below. Figure 2.5 presents an
example. A correctly identified individual tries to modify system data from an external site;
system maintains an audit trail and the correct data is restored within one day.

Fig 2.5 security general scenario

1. Source of stimulus. The source of the attack may be either a human or another system. It
may have been previously identified (either correctly or incorrectly) or may be currently
unknown. The difficulty with security is allowing access to legitimate users and
determining legitimacy. If the only goal were to prevent access to a system, disallowing
all access would be an effective defensive measure.
2. Stimulus. The stimulus is an attack or an attempt to break security. This as an
unauthorized person or system trying to display information, change and/or delete
information, access services of the system, or reduce availability of system services. In
Figure 2.5, the stimulus is an attempt to modify data.
3. Artifact. The target of the attack can be either the services of the system or the data
within it. In our example, the target is data within the system.
4. Environment. The attack can come when the system is either online or offline, either
connected to or disconnected from a network, either behind a firewall or open to the
5. Response. Using services without authorization or preventing legitimate users from using
services is a different goal from seeing sensitive data or modifying it. Thus, the system
must authorize legitimate users and grant them access to data and services, at the same
time rejecting unauthorized users, denying them access, and reporting unauthorized
access. Not only does the system need to provide access to legitimate users, but it needs
to support the granting or withdrawing of access. One technique to prevent attacks is to
cause fear of punishment by maintaining an audit trail of modifications or attempted
accesses. An audit trail is also useful in correcting from a successful attack. In Figure 2.5,
an audit trail is maintained.
6. Response measure. Measures of a system's response include the difficulty of mounting
various attacks and the difficulty of recovering from and surviving attacks. In our
example, the audit trail allows the accounts from which money was embezzled to be
restored to their original state. Of course, the embezzler still has the money, and he must
be tracked down and the money regained, but this is outside of the realm of the computer
Usability is concerned with how easy it is for the user to accomplish a desired task and
the kind of user support the system provides. It can be broken down into the following areas:
1. Learning system features. If the user is unfamiliar with a particular system or a particular
aspect of it, what can the system do to make the task of learning easier?
2. Using a system efficiently. What can the system do to make the user more efficient in its
3. Minimizing the impact of errors. What can the system do so that a user error has minimal
4. Adapting the system to user needs. How can the user (or the system itself) adapt to make
the user's task easier?
5. Increasing confidence and satisfaction. What does the system do to give the user
confidence that the correct action is being taken?

In the last five years, our understanding of the relation between usability and software
architecture has deepened (see the sidebar Usability Mea Culpa). The normal development
process detects usability problems through building prototypes and user testing. The later a
problem is discovered and the deeper into the architecture its repair must be made, the more the
repair is threatened by time and budget pressures. In our scenarios we focus on aspects of
usability that have a major impact on the architecture. Consequently, these scenarios must be
correct prior to the architectural design so that they will not be discovered during user testing or
Usability General Scenarios
Figure 2.5 gives an example of a usability scenario: A user, wanting to minimize the
impact of an error, wishes to cancel a system operation at runtime; cancellation takes place in
less than one second. The portions of the usability general scenarios are:
1. Source of stimulus. The end user is always the source of the stimulus.
2. Stimulus. The stimulus is that the end user wishes to use a system efficiently, learn to use
the system, minimize the impact of errors, adapt the system, or feel comfortable with the
system. In our example, the user wishes to cancel an operation, which is an example of
minimizing the impact of errors.

3. Artifact. The artifact is always the system.

4. Environment. The user actions with which usability is concerned always occur at runtime
or at system configuration time. Any action that occurs before then is performed by
developers and, although a user may also be the developer, we distinguish between these
roles even if performed by the same person. In Figure 4.8, the cancellation occurs at
5. Response. The system should either provide the user with the features needed or
anticipate the user's needs. In our example, the cancellation occurs as the user wishes and
the system is restored to its prior state.
6. Response measure. The response is measured by task time, number of errors, number of
problems solved, user satisfaction, gain of user knowledge, ratio of successful operations
to total operations, or amount of time/data lost when an error occurs. In Figure 2.5, the
cancellation should occur in less than one second.

1. Architecture documentation is both prescriptive and descriptive. That is, for some
audiences it prescribes what should be true by placing constraints on decisions to be
made. For other audiences it describes what is true by recounting decisions already made
about a system's design.
2. All of this tells us that different stakeholders for the documentation have different needs
different kinds of information, different levels of information, and different treatments
of information.
3. One of the most fundamental rules for technical documentation in general, and software
architecture documentation in particular, is to write from the point of view of the reader.
Documentation that was easy to write but is not easy to read will not be used, and "easy
to read" is in the eye of the beholderor in this case, the stakeholder.
4. Documentation facilitates that communication. Some examples of architectural
stakeholders and the information they might expect to find in the documentation are
given in Table 9.1.
5. In addition, each stakeholder comes in two varieties: seasoned and new. A new
stakeholder will want information similar in content to what his seasoned counterpart
wants, but in smaller and more introductory doses. Architecture documentation is a key
means for educating people who need an overview: new developers, funding sponsors,
visitors to the project, and so forth.
Stakeholders and the communication needs served by architecture

The concept of a view, which you can think of as capturing a structure, provides us with the
basic principle of documenting software architecture Documenting an architecture is a matter of
documenting the relevant views and then adding documentation that applies to more than one
view. This principle is useful because it breaks the problem of architecture documentation into
more tractable parts, which provide the structure for the remainder of this chapter:
Choosing the relevant views
Documenting view
Documenting information that applies to more than one view
Choosing The Relevant Views
A view simply represents a set of system elements and relationships among them, so
whatever elements and relationships you deem useful to a segment of the stakeholder community
constitute a valid view. Here is a simple 3 step procedure for choosing the views for your project.
Produce a candidate view list:
Begin by building a stakeholder/view table. Your stakeholder list is likely to be different
from the one in the table as shown below, but be as comprehensive as you can. For the columns,
enumerate the views that apply to your system. Some views apply to every system, while others
only apply to systems designed that way. Once you have rows and columns defined, fill in each
cell to describe how much information the stakeholder requires from the view: none, overview
only, moderate detail, or high detail.
Stakeholders and the architecture documentation

2. Combine views:
The candidate view list from step 1 is likely to yield an impractically large number of
views. To reduce the list to a manageable size, first look for views in the table that require only
overview depth or that serve very few stakeholders. See if the stakeholders could be equally well
served by another view having a stronger consistency. Next, look for the views that are good
candidates to be combined- that is, a view that gives information from two or more views at
once. For small and medium projects, the implementation view is often easily overlaid with the
module decomposition view. The module decomposition view also pairs well with users or
layered views. Finally, the deployment view usually combines well with whatever componentand-connector view shows the components that are allocated to hardware elements.
3. Prioritize:
After step 2 you should have an appropriate set of views to serve your stakeholder
community. At this point you need to decide what to do first. How you decide depends on the
details specific project. But, remember that you dont have to complete one view before starting
another. People can make progress with overview-level information, so a breadth-first approach
is often the best. Also, some stakeholders interests supersede others.

Primary presentation- elements and their relationships, contains main information about
these system , usually graphical or tabular.
Element catalog- details of those elements and relations in the picture,
Context diagram- how the system relates to its environment
Variability guide- how to exercise any variation points a variability guide should include
documentation about each point of variation in the architecture, including
1. The options among which a choice is to be made
2. The binding time of the option. Some choices are made at design time, some at
build time, and others at runtime.
Architecture background why the design reflected in the view came to be? an
architecture background includes
1. rationale, explaining why the decisions reflected in the view were made and why
alternatives were rejected
2. analysis results, which justify the design or explain what would have to change in
the face of a modification
3. assumptions reflected in the design
Glossary of terms used in the views, with a brief description of each.
Other information includes management information such as authorship, configuration
control data, and change histories. Or the architect might record references to specific
sections of a requirements document to establish traceability.


Architecture in some sense expresses what is essential about a software system, and that
essence is independent of languages and notations to capture it. Nevertheless, today the Unified
Modeling Language (UML) has emerged as the de facto standard notation for documenting a
software architecture.
However, it must be said that UML makes its main contribution in a view's primary
presentation, and its secondary contribution in the behavior of an element or group of elements.
It is up to the architect to augment the UML pictures with the necessary supporting
documentation (the element catalog, the rationale, and so forth) that a responsible job requires.
UML provides no direct support for components, connectors, layers, interface semantics,
or many other aspects of a system that are supremely architectural.
Recall that a module is a code or implementation unit and a module view is an
enumeration of modules together with their interfaces and their relations.

Interfaces in UML
Figure shows how module interfaces can be represented in UML. UML uses a "lollipop"
to denote an interface, which can be appended to classes and subsystems, among other things.
UML also allows a class symbol (box) to be stereotyped as an interface; the open-headed
dashed arrow shows that an element realizes an interface. The bottom of the class symbol can be
annotated with the interface's signature information: method names, arguments, argument types,
and so forth. The lollipop notation is normally used to show dependencies from elements to the
interface, while the box notation allows a more detailed description of the interface's syntax, such
as the operations it provides.
UML provides a variety of constructs to represent different kinds of modules. Figure 9
shows some examples. UML has a class construct, which is the object-oriented specialization of
a module. Packages can be used in cases where grouping of functionality is important, such as to
represent layers and classes. The subsystem construct can be used if a specification of interface
and behavior is required.

Examples of module notation in UML

In UML, the subsystem construct can be used to represent modules that contain other modules;
the class box is normally used for the leaves of the decomposition. Subsystems are used both as
packages and asclassifiers. As packages, they can be decomposed and hence are suitable for
module aggregation. Asclassifiers, they encapsulate their contents and can provide an explicit
interface. Aggregation is depicted in one of three ways in UML
Modules may be nested

Decomposition in UML with nesting. The aggregate module is shown as a package (left);
decomposition in UML with arcs (right).

A succession of two diagrams (possibly linked) can be shown, where the second is
a depiction of the contents of a module shown in the first.
An arc denoting composition is drawn between the parent and the children.
Expressing generalization is at the heart of UML in which modules are shown as classes
(although they may also be shown as subsystems). Figure 9.8 shows the basic notation available
in UML.

Documenting generalization in UML with two line styles

The two diagrams in Figure are semantically identical. UML allows an ellipsis () in
place of a sub module, indicating that a module can have more children than shown and that
additional ones are likely. Module Shape is the parent of modules Polygon, Circle, and Spline,
each of which is a subclass, child, or descendant of Shape. Shape is more general, while its
children are specialized versions.
There is no single preferred strategy to document component-and-connector (C&C)
views in UML, but a number of alternatives. Each alternative has its advantages and
disadvantages. One natural candidate for representing component-and-connector types begins
with the UML class concept. Figure illustrates the general idea using a simple pipe-and-filter
system. Here, the filter architectural type is represented as the UML class Filter. Instances of
filters, such as Splitter, are represented as corresponding objects in an object instance diagram.
To provide a namespace boundary, enclose the descriptions in packages.

Types as classes, and instances as objects, exemplified with a simple pipe and filter

The type/instance relationship in architectural descriptions is a close match to the
class/object relationship in a UML model. UML classes, like component types in
architectural descriptions, are firstclass entities and are rich structures for capturing
software abstractions. The full set of UML descriptive mechanisms is available to describe
the structure, properties, and behavior of a class, making this a good choice for depicting
detail and using UML-based analysis tools. Properties of architectural components can be
represented as class attributes or with associations; behavior can be described using UML
behavioral models; and generalization can be used to relate a set of component types. The
semantics of an instance or type can also be elaborated by attaching one of the standard
stereotypes; for example, the process stereotype can be attached to a component to
indicate that it runs as a separate process.
Interfaces to components, sometimes called ports, can be shown in five ways, as
shown in Figure 9.11,
described in increasing order of expressiveness. However, as expressiveness rises so does
so you should pick the first strategy that will serve your purposes.
Option 1: No explicit representation. Leaving out interfaces leads to the simplest diagrams
suffers from the obvious problem that there is no way to characterize the names or the
properties of
the interfaces in the primary presentation. Still, this choice might be reasonable if the
have only one interface, if the interfaces can be inferred from the system topology, or if the
is refined elsewhere.
This PDF file was converted by Atop CHM to PDF Converter free version!
Addison Wesley : Software Architecture in Practice, Second Edition
220 / 463
Option 2: Interfaces as annotations. Representing interfaces as annotations provides a
home for
information about them, although annotations have no semantic value in UML so cannot
be used as
a basis for analysis. Again, if the detailed properties of an interface are not of concern, this
might be reasonable.
Option 3: Interfaces as class/object attributes. Treating interfaces as attributes of a

makes them part of the formal structural model, but they can have only a simple
representation in a
class diagramessentially, a name and a type. This restriction limits the expressiveness of
Option 4: Interfaces as UML interfaces. The UML lollipop notation provides a compact
of an interface in a class diagram depicting a component type. In an instance diagram, a
association role, corresponding to an interface instance and qualified by the interface type
provides a compact way to show that a component instance is interacting through a
interface instance. This approach provides visually distinct depictions of components and
in which interfaces can clearly be seen as subservient.
However, this strategy provides no means to depict the services required from a
environment, often a key part of an interface. Furthermore, it is meaningful for a
component type to
have several instances of the same interface type, but it is not meaningful to say that a class
several versions of one UML interface. For example, there is no easy way to define a
filter type that has two output ports of the same "type" using this technique. Finally, unlike
UML interfaces do not have attributes or substructure.
Option 5: Interfaces as classes. Describing interfaces as classes contained by a component
overcomes the lack of expressiveness of the previous alternatives: We can now represent
substructure and indicate that a component type has several interfaces of the same type. A
component instance is modeled as an object containing a set of interface objects. However,
representing interfaces as classes, we not only clutter the diagram but also lose clear visual
discrimination between interfaces and components. We could use a notational variation in
which the
interfaces are contained classes, as shown in the lower part of option 5 in Figure 9.11.
points of interaction is counterintuitive, however, as containment usually indicates that a
class owns

other classes whose instances may or may not be accessible through instances of the parent
Figure 9.11. Five ways to represent interfaces to components (ports)
There are three reasonable options for representing connectors. Again, the choice is
expressiveness and semantic match on the one hand and complexity on the other.
Option 1: Connector types as associations and connector instances as links. In an
box-and-line diagram of a system, the lines between components are connectors. One
tempting way
This PDF file was converted by Atop CHM to PDF Converter free version!
Addison Wesley : Software Architecture in Practice, Second Edition
221 / 463
to represent connectors in UML is as associations between classes or links between objects.
approach is visually simple, provides a clear distinction between components and
connectors, and
uses the most familiar relationship in UML class diagrams: association. Moreover,
associations can
be labeled, and a direction associated with the connector can be indicated with an arrow.
Unfortunately, connectors and associations have different meanings. A system in an
description is built up by choosing components with behavior exposed through their
interfaces and
connecting them with connectors that coordinate their behaviors. A system's behavior is
defined as
the collective behavior of a set of components whose interaction is defined and limited by
connections between them.
In contrast, although an association, or link, in UML represents a potential for interaction
the elements it relates, the association mechanism is primarily a way of describing a
relationship between two elements. In addition, an association is a relationship between
elements, so it cannot stand on its own in a UML model. Consequently, a connector type
cannot be
represented in isolation. Instead, you must resort to naming conventions or to stereotypes

meanings are captured by description in UML's object constraint language. Further, the
does not allow you to specify a connector's interfaces.
Option 2: Connector types as association classes. One solution to the lack of expressiveness
is to
qualify the association with a class that represents the connector type. In this way, the
type or connector attributes can be captured as attributes of a class or object.
Unfortunately, this
technique still does not provide any way of explicitly representing connector interfaces.
Option 3: Connector types as classes and connector instances as objects. One way to give
connectors first-class status in UML is to represent connector types as classes and
instances as objects. Using classes and objects, we have the same four options for
roles as we had for interfaces: not at all, as annotations, as interfaces realized by a class, or
as child
classes contained by a connector class. Given a scheme for representing interfaces, an
between a component's interface and a connector's interface may be represented as an
or a dependency.
In addition to representing individual components and connectors and their types, we also
need to
encapsulate graphs of components and connectors: systems. Three options are available.
Option 1: Systems as UML subsystems. The primary UML mechanism for grouping related
elements is the package. In fact, UML defines a standard package stereotype, called
subsystem, to group UML models that represent a logical part of a system. The choice of
subsystems is appropriate for any mapping of components and connectors, and it works
well for grouping classes. One of the problems with using subsystems, as defined in UML
1.4, is
that, although they are both a classifier and a package, the meaning is not entirely clear.
Some have
argued that we should be able to treat a subsystem as an atomic class-like entity at certain
stages in
the development process and later be able to refine it in terms of a more detailed
Having the ability to do this would make the subsystem construct more appropriate for

architectural components.
Option 2: Systems as contained objects. Object containment can be used to represent
Components are represented as instances of contained classes, and connectors are modeled
one of the options outlined earlier. Objects provide a strong encapsulation boundary and
carry with
them the notion that each instance of the class has the associated "substructure." However,
approach has problems, the most serious being that associations, used to model connectors,
between contained classes are not scoped by the class. That is, it is not possible to say that a
of classes interacts via a particular connector, modeled as an association, only in the context
of a
particular system. So, for example, indicating that two contained classes interact via an
is valid for instances of classes used anywhere else in the model.
Option 3: Systems as collaborations. A set of communicating objects connected by links is
This PDF file was converted by Atop CHM to PDF Converter free version!
Addison Wesley : Software Architecture in Practice, Second Edition
222 / 463
described in UML using a collaboration. If we represent components as objects, we can use
collaborations to represent systems. A collaboration defines a set of participants and
that are meaningful for a given purpose, which in this case is to describe the runtime
structure of the
system. The participants define classifier roles that objects play, or conform to, when
Similarly, the relationships define association roles that links must conform to.
Collaboration diagrams can be used to present collaborations at either the specification or
instance level. A specification-level collaboration diagram shows the roles, defined within
collaboration, arranged in a pattern to describe the system substructure. An instance-level
collaboration diagram shows the objects and links conforming to the roles at the
specification level
and interacting to achieve the purpose. Therefore, a collaboration presented at the instance
level is
best used to represent the runtime structure of the system.

Figure 9.12 illustrates this approach. The Filter architectural type is represented as
Instances of filters and pipes are represented as corresponding classifier rolesfor
/Splitter indicates the Splitter roleand association roles. The objects and links
to those roles are shown in the collaboration diagram at the instance level, indicated by
Figure 9.12. Systems as collaborations
Although this is a natural way to describe runtime structures, it leaves no way to explicitly
system-level properties. There is also a semantic mismatch; a collaboration describes a
representative interaction between objects and provides a partial description, whereas an
architectural configuration is meant to capture a complete description.
In UML, a deployment diagram is a graph of nodes connected by communication
associations. Figure
9.13 provides an example. Nodes may contain component instances, which indicates that
the component
lives or runs on the node. Components may contain objects, which indicates that the object
is part of the
component. Components are connected to other components by dashed-arrow
dependencies (possibly
through interfaces). This indicates that one component uses the services of another; a
stereotype may be
used to indicate the precise dependency if needed. The deployment type diagram may also
be used to
show which components may run on which nodes, by using dashed arrows with the
This PDF file was converted by Atop CHM to PDF Converter free version!
Addison Wesley : Software Architecture in Practice, Second Edition
223 / 463
Figure 9.13. A deployment view in UML
A node is a runtime physical object that represents a processing resource, generally having
at least a
memory and often processing capability as well. Nodes include computing devices but also
human or

mechanical processing resources. Nodes may represent types of instances. Runtime

instances, both objects and components, may reside on node instances.
Nodes may be connected by associations to other nodes. An association indicates a
communication path
between them. The association may have a stereotype to indicate the nature of the
communication path
(for example, the kind of channel or network).
The nesting of symbols within the node symbol signifies a composition association between
a node class
and constituent classes or a composition link between a node object and constituent