Identify architectural drivers and scenarios (for current iteration)
Architectural drivers are the combination of functional requirements and quality attributes that shape the
architecture. Typically, the drivers are a subset of the Artifact: Supporting Requirements, addressing attributes such as
modifiability,performance, safety, reliability, and security but they can also cover funcional aspects that provide
essencial services of the system.
The architectural drivers are often satisified by the development of software that implements the Concept: Architecture Mechanism(s). The features required by these mechanisms can be
implicit in the use cases that describe the functionality of the system. These are used to drive the design of
each architecture mechanism. It may sometimes be useful to devise additional use cases and/or scenarios to
specifically describe the architecture mechanism.
It is important to specify qualities precisely: for example, if you want a system to be secure, you should specify the
types of threats. Quality scenarios are one way to express desired qualities in collaboration with the system
stakeholders [CMU/SEI-2004-TR-011]. One should walk through things that could happen to the system, and how it would
respond. Use case scenarios focus on run-time behavior where the stakeholder is the user. Quality Scenarios
encompass other interactions with the system as well, such as a maintainer carrying out a modification.
For each quality attribute (such as usability, reliability, performance or security) several scenarios may be
captured. For instance, security scenarios for Denial of Service, Unauthorized access and Non-repudiatability. A good
scenario makes clear what the stimulus is, wthat causes it and what responses are of interest: "During peak operation,
an unauthorized intruder tries to download prohibited data via the system administrator’s interface. The system detects
the attempt, blocks access, and notifies the supervisor within 15 seconds".
Once the use cases and scenarios have been collected, they must be prioritized. Use scenarios to operationalize
requirements, so that their mapping onto the architecture, their impacts, and their interactions can be understood.
Identify common solutions across scenarios
Identify Design Mechanisms
Consider each high priority quality scenario and map each of these onto the architecture. This step raises to the
architectural level the set of infrastructure services that determine issues such as:
-
how system activities are scheduled and coordinated
-
how data moves through the system
-
how faults are propagated and handled
-
how security is achieved
-
how performance goals are measured and met
-
how new components are integrated
-
and how the system scales.
It is this set of infrastructure services, far more than the functional goals of the system,that determine the form of
the architecture. Propose mechanisms or tactics for responding to quality scenarios. These are represented by the Concept: Design Mechanisms. There are, for example, sets of engineering design
principles and patterns for dealing with performance constraints, or modifiability, or fault tolerance. The Software
Engineering Institute (SEI) at Carnegie Mellon University has proposed tactics for six quality attributes:
-
availability
-
modifiability
-
security
-
performance
-
usability
-
testability
( Bass, L., ClementsEngineering, Vol. 9, 2000, 5-33. )
Identify Components from existing assets
Identify reuse opportunities
After looking for similar behavior and returned values, then look for parameters similarity. If their
interfaces are not an exact match to the component interfaces being proposed, you can modify the
proposed signatures in order to increase the degree of reuse. Some design mechanisms like performance or security
requirements may disqualify a component from reuse even when there is a perfect match between operation
signatures.
Identify how to interface to existing components
There may exist a common set of components which provide many of the architectural mechanisms needed for a new
system. These components may be available either because they were developed or purchased for previous similar
systems. Given their suitability and compatibility within the software architecture, there may be a need to
reverse-engineer these components in order to represent them in a design model and reuse them in a project.
Similarly, thinking applies to existing databases. Part of the information to be used by the application
under development may already reside in a database, so the classes that represent the database structures that hold
this information may be obtained from reverse-engineering the database.
Identify Components from the problem space
Identifying Components will help to hide the complexity of the system and work at a higher level. Components should be
internally cohesive and provide external services via a limited interface. Component identification can be based
on Architectural Layers, on Deployment Choices or on Key abstractions. Reason about:
-
What is logically/functionally related (same use case/service etc.)?
-
What entities provide services to multiple others?
-
What entities depend on each other strongly/weakly?
-
What entities should be exchangeable independently from others?
-
What is going to run on the same processor/network node?
-
What parts are constrained by similar performance requirements?
Each component includes entities from the problem domain, control classes that coordinate complex tasks within
component and interfaces that handle comunication with the environment. The interface for each instantiated element is
identified. At this point, interfaces need not be as detailed as a signature, but they document what elements
need, what they can use, and on what they can depend.
Identified patterns define the types of elements but not a specific number. Apply the chosen pattern(s) to define a new
set of elements that conform to it. Functionality will be allocated to the instantiated elements.
Define development and test architectures
These may be different from the target production implementation. For example,
-
Additional software may need to be developed to support testing.
-
Alternative deployment configurations may need to be defined in response to constraints on development hardware.
-
Multiple environments may be required to support different categories of test activity.
In each case, the specification of these architectures will need to be performed and the impact on the quality of the
overall solution architecture will need to be taken into account.
Communicate and document decisions
This can be achieved through a variety of techniques. For example
-
Publication of reference source code
-
Publication of reference models
-
Publication of software architecture documentation
-
Formal presentations of the material
-
Informal walkthroughs of the architecture products
|