Professional Documents
Culture Documents
structures, and the documentation of these structures. These structures are needed to reason about the
software system.
Characteristics
Multitude of stakeholders:
Separation of concerns:
Quality-driven:
Recurring styles:
Conceptual integrity:
Architectural Synthesis or design is the process of creating an architecture. Given the architecturally
significant requirements determined by the analysis, the current state of the design and the results of any
evaluation activities, the design is created and improved. See
[3]:pp.311326[23]
Frameworks for comparing the techniques are discussed in frameworks such as SARA Report
[15]
and
[28]
Architecture Evolution is the process of maintaining and adapting an existing software architecture to meet
requirement and environmental changes. As software architecture provides a fundamental structure of a
software system, its evolution and maintenance would necessarily impact its fundamental structure. As such,
architecture evolution is concerned with adding new functionality as well as maintaining existing functionality
and system behaviour.
Architecture requires critical supporting activities. These supporting activities take place throughout the core
software architecture process. They include knowledge management and communication, design reasoning
and decision making, and documentation.
Definition
View
A representation of a set of elements and the relations among them.
Structure
The set of elements itself, as they exist in software or hardware
Restrict our attention at any one moment to one (or a small number) of the software syste
structures.
SOFTWARE STRUCTURES
Module structures
Elements are modules, which are units of implementation.
* What is the primary functional responsibility assigned to each module?
* What other software elements is a module allowed to use?
* What other software does it actually use?
Decomposition
* shows how larger modules are decomposed into smaller ones recursively
Uses
* The units are: modules, procedures or resources on the interfaces of modules
* The units are related by the uses relation
Layered
* "uses relations" structured into layers
Class, or generalization
Component-and-connector structures
Elements are runtime components (units of computation) and connectors (communication
among components)
The relation is attachment, showing how the components and connectors are hooked toge
* What are the major executing components and how do they interact?
* What are the major shared data stores?
* Which parts of the system are replicated?
* How does data progress through the system?
* What parts of the system can run in parallel?
* How can the systems structure change as it executes?
Concurrency
* The units are components and the connectors are logical threads
* A logical thread is a sequence of computation that can be allocated to a separate
thread
Client-server
* The components are the clients and servers, and the connectors are protocols and
Allocation structures
the relationship between the software elements and the elements in one or more external
environments
* What processor does each software element execute on?
* In what files is each element stored during development, testing, and system building?
* What is the assignment of software elements to development teams?
Deployment
* Shows how software (usually a process from a component-and-connector view) is
hardware-processing and communication elements
* Relations are allocated-to and migrates-to if the allocation is dynamic
Implementation
* how software elements (usually modules) are mapped to the file structure(s)
Work assignment
* assigns responsibility for implementing and integrating the modules to developme
Often the dominant structure is module decomposition, because it spawns the project stru
Quality Attributes
This quality attributes section on SoftwareArchitectures.com is the gateway to
resources that address the following areas of the subject:
Design: letting quality attributes and the utility tree drive the design
Introduction
Developing high quality software is hard, especially when the interpretation of term
quality is patchy based on the environment in which it is used. In order to know if
quality has been achieved, or degraded, it has to be measured, but determining
what to measure and how is the difficult part.
Software Quality Attributes are the benchmarks that describe systems intended
behavior within the environment for which it was built. The quality attributes provide
the means for measuring the fitness and suitability of a product. Software
architecture has a profound affect on most qualities in one way or another, and
software quality attributes affect architecture.
Identifying desired system qualities before a system is built allows system designer
to mold a solution (starting with its architecture) to match the desired needs of the
system within the context of constraints (available resources, interface with legacy
systems, etc). When a designer understands the desired qualities before a system is
built, then the likelihood of selecting or creating the right architecture is improved.
Scenarios
Statements like a system will have high performance or a system will be user
friendly are acceptable in the really early stages of requirements elicitation process
(i.e. business concept brainstorming). As more information becomes available, the
above statements become useless as they are meaningless for the purpose of
actually designing a solution. In each of the two examples above an attempt is made
to describe the behavior of a system. Both statements are useless as they provide
no tangible way of measuring the behavior of the system.
The quality attributes must be described in terms of scenarios, such as when 100
users initiate complete payment transition, the payment component, under normal
circumstances, will process the requests with an average latency of three seconds.
This statement, or scenario, allows an architect to make quantifiable arguments
about a system. A scenario defines the source of stimulus (users), the actual
stimulus (initiate transaction), the artifact affected (payment component), the
environment in which it exists (normal operation), the effect of the action (transaction
processed), and the response measure (within three seconds). Writing such detailed
statements is only possible when relevant requirements have been identified and an
idea of components has been proposed.
Writing effective scenarios takes some time to learn. But it's an important skill, as it's
in the scenarios where the desired vague software behaviors are turned into tangible
and measurable goals. Measurable goals tells you what architectural approaches
and tactis to apply as you design the system. It's easiest to learn by looking at
examples. See this resource on how you can download a catalog of over 100 well
defined quality attribute scenarios.
Achieving Qualities
Scenarios help describe the qualities of a system, but they dont describe how they
will be achieved. Architectural tactics describe how a given quality can be achieved.
For each quality there may be a large set of tactics available to an architect. It is the
architects job to select the right tactic in light of the needs of the system and the
environment. For example, a performance tactics may include options to develop
better processing algorithms, develop a system for parallel processing, or revise
event scheduling policy. Whatever tactic is chosen, it must be justified and
documented.
Taxonomy of Software Qualities
Over the past 10 years software architects have devised a list of common software
qualities. It would be nave to claim that the list below is as a complete taxonomy of
all software qualities but its a solid list of general software qualities compiled from
respectable sources. Domain specific systems are likely to have an additional set of
qualities in addition to the list below.
System qualities can be categorized into four parts: runtime qualities, non-runtime
qualities, business qualities, and architecture qualities. Each of the categories and
its associated qualities are briefly described below. Other articles on this site provide
more information about each of the software quality attributes listed below, their
applicable properties, and the conflicts the qualities.
Runtime System Qualities
Runtime System Qualities can be measured as the system executes.
Functionality
Definition: the ability of the system to do the work for which it was intended.
Performance
Definition: the response time, utilization, and throughput behavior of the system. Not
Business Qualities
Non-Software System Qualities that influence other quality attributes.
Cost and Schedule
Definition: the cost of the system with respect to time to market, expected project
lifetime, and utilization of legacy and COTS systems.
Marketability
Definition: the use of the system with respect to market competition.
Appropriateness for Organization
Definition: availability of the human input, allocation of expertise, and alignment of
team and software structure. Business process re-engineering
Architecture Qualities
Quality attributes specific to the architecture itself.
Conceptual Integrity
Definition: the integrity of the overall structure that is composed from a number of
small architectural structures.
Correctness
Definition: accountability for satisfying all requirements of the system.
Domain Specific Qualities
Quality attributes found in specific business domains.
Sensitivity
Definition: the degree to which a system component can pick up something being
measured.
Calibrability
Definition: ability of a system to recalibrate itself to some specific working range
Attribute-driven design[1][2] (also called ADD or Attribute-driven design method) is a methodology to create
software architectures that takes into account the quality attributes of the software. I
In the book Software architecture in practice[4] the authors describe ADD as an iterative method that, at each
iteration, helps the architect to do the following steps:
Marshal all the architecturally significant requirements for the selected part. This means that you select
all quality attributes and business goals that could affect the architecture of this phase.
Create an architecture for the selected part that meets the selected architecturally significant
requirements and test this design.
Required input[edit]
ADD can only be started successfully when the following resources are already available:
functional requirements
quality requirements
constraints
Of course, we cannot wait until all these requirements are finalized since this can take a while. The ADD
process can start once a set of ASRs (architecturally significant requirements, which are the three resources
listed above) are available.
Process steps[edit]
1. Choose an element of the system to design
Select an element of the system that is not yet designed. In the first iteration this will be the
system itself. Later on, a choice will need to be made between several elements. This choice can
be based on personnel availability, input resources availability, risk mitigation, etc. In case you do
not have any of these limitations, it is suggested to go for a breadth-first strategy.
Identify the ASRs that are most important for this selected element. You should prioritize these
requirements to make sure that your design reflects the most important ASRs.
This step is the heart of ADD since the architecture will be created in this step. The
architecture you create should reflect the selected ASRs. You can do this by making use
of architectural patterns or tactics. Most of the times you will have to make a trade-off between
several tactics and ASRs.
4. Inventory remaining requirements and select the input for the next iteration
Take a look at the listed ASRs and see whether they are already fulfilled with the design you
have at the moment. For each ASR you will have to check whether it is satisfied, delegated to one
of the children, distributed among the children or whether it can not be satisfied. In the last case
you will need to change your architecture.
5. Repeat steps 1-4 until all the ASRs have been satistfied
Repeat!
Output[edit]
A set of sketches of architectural views, NOT a full-blown detailed architecture.
Business and/or mission drivers for the system (goals and drivers), plan, strategies,
high-level functional requirements, constraints, artifacts and quality attribute
requirements should be presented to the stakeholders. Using Business Scenario in
conjunction with QAWs can be an appropriate approach.
A QAW lends itself to the capture of many architecturally relevant materials:
These elements may also be produced in a Business Scenario or produced later in the
ADM phases A : Architecture Vision, C: Information Systems Architectures
(stakeholders management and taxonomy of artifacts).
Raw scenarios
Refined scenarios
Questionnaire
Quality attribute requirements are the means by which a system is intended to meet
its business goals and QAW helps to document them.
Software architectures must be designed so that their quality attributes are met.
The QAWs technique can be utilised as a complementary approach to gather all sort of
requirements including those from Software Architectures when appropriate. - See
more at: http://sergethorn.blogspot.in/2013/09/using-cmusei-quality-attributeworkshop_10.html#sthash.et1oOzWH.dpuf