Guideline: Develop the Architecture |
This guideline provides additional information to support the ongoing refinement and development of the architecture.
Relationships
Related Elements | Develop 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 that address 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 requirements of architectural drivers are often satisfied by the development of software that implements Architectural Mechanism. The features required by these mechanisms can be implicit in the use cases that describe the functionality of the system. These are used to guide the design of each architectural mechanism. It may sometimes be useful to devise additional use cases and scenarios to specifically describe the architectural mechanism. For example Log on 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, specify the types of threats. Quality scenarios are one way to express desired qualities in collaboration with the system stakeholders [KAZ04]. 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 system maintenance staff modifying the system. For each quality attribute (such as usability, reliability, performance, or security), several scenarios may be documented (for instance, security scenarios for denial of service and unauthorized access). A good scenario makes clear what the stimulus is, what causes it, and what responses are appropriate. Example: During peak operation, an unauthorized intruder tries to download prohibited data through the system administrator’s interface. The system detects the attempt, blocks access, and notifies the supervisor within 15 seconds. After you have collected the use cases and scenarios, you need to establish priorities for them. Use scenarios to realize requirements, so that their mapping onto the architecture, their impact, 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 the set of infrastructure services that determine issues to the architectural level. Examples: : 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 well 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, modifiability, or fault tolerance. The Software Engineering Institute (SEI) at Carnegie Mellon University has proposed tactics for six quality attributes [KAZ00]: Availability Modifiability Security Performance Usability Testability #### Identify reuse opportunities After looking for similar behavior and returned values, then look for similarity of parameters. If their interfaces are not an exact match for the component interfaces being proposed, you can modify the proposed signatures to increase the degree of reuse. Some design mechanisms, such as performance or security requirements, may disqualify a component from reuse even when there is a perfect match between operation signatures. A common set of components may exist that provides many of the Architectural Mechanism that you need for the new system. These components may be available either because they were developed or purchased previously for similar systems. Given their suitability and compatibility within the software architecture, there may be a need to reverse-engineer these components to represent them in a design model and reuse them in a project. Similar thinking applies to existing databases. Part of the information to be used by the application under development may already reside in a database. You may be able to get the classes that represent the database structures that hold this information by reverse-engineering the database. #### Identify architecturally significant design elements Consider each high-priority use case in turn while mapping use case scenarios onto the architecture. Walk through the actions that the use case initiates and highlight the areas of the architecture that participate in realizing, or implementing, the use case. Identifying components will help hide the complexity of the system and help you work at a higher level. Components need to be internally cohesive and to provide external services through a limited interface. Component identification can be based on architectural layers, deployment choices, or key abstractions. Ask yourself these questions: What is logically or functionally related (same use case or service, for example)? What entities provide services to multiple others? What entities depend on each other? Strongly or weakly? What entities should you be able to exchange independently from others? What will run on the same processor or 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 components, and interfaces that handle communication with the environment. The interface for each instantiated element is identified. At this point, interfaces do not need to be as detailed as a signature, but they do need to document what the elements need, what they can use, and what they can depend on. Identified patterns define the types of elements, but not a specific number. Apply the chosen patterns to define a new set of elements that conform to the patterns. 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. 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 tests. In each case, you need to specify the architecture. Also, be sure to consider the impact on the quality of the overall architecture. #### Document and communicate decisions You can document and communicate your decisions as many ways as you wish: Publication of reference source code Publication of reference models Publication of software architecture documentation Formal presentations of the material Informal walkthroughs of the architecture
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