Guideline: Refine the Architecture Guidelines |
This guideline provides additional information to support the ongoing refinement and development of the architecture.
Relationships
Related Elements | Refine the Architecture
Main Description
### Identify architectural drivers and scenarios Architectural drivers are the combination of functional requirements and quality attributes that shape the architecture. Typically, the drivers are a subset of the Supporting Requirements, addressing attributes such as modifiability, performance, safety, reliability and security. The drivers can also address functional aspects of the requirements that provide essential system services. The architectural drivers are often satisified by the development of software that implement Architecture Mechanisms. 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. For example "Logon to Application" is a use case commonly associated with mechanisms related to security but frequently overlooked when users alone specify software requirements. 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, what causes it and what responses are of interest. For example, "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 realise requirements, so that their mapping onto the architecture, their impacts, and their interactions can be understood. ### 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 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 Design Mechanism. 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 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. There may exist a common set of components which provide many of the Architecture 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 architecturally significant design elements Consider each high priority use case in turn, mapping use case scenarios onto the architecture. Walk through the actions that the use case initiates, highlighting the areas of the architecture that participate in realizing the use case. 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 The development and test architectures 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 | Business Pattern
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright