| Guideline: Develop the Architecture |
 |
 |
|
| Related Elements |
|---|
Identify architectural drivers and scenariosArchitectural 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:
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 mechanismsConsider 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: :
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]:
Identify reuse opportunitiesAfter 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 elementsConsider 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:
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 architecturesThe development and test architectures may be different from the target production implementation.
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 decisionsYou can document and communicate your decisions as many ways as you wish:
|
| Concepts |
|---|
This program and the accompanying materials are made available under the View copyright information here: OpenUP Copyright |