Guideline: Refine the Architecture Guidelines
This guideline provides additional information to support the ongoing refinement and development of the architecture.
Relationships
Related Elements
Main Description

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:

  1. availability
  2. modifiability
  3. security
  4. performance
  5. usability
  6. 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

More Information
Concepts