| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-t7mQSRPYITkMoYRVNz7jQg" name="develop_architecture,_mDf2EBapEduSTJywppIxVQ" guid="-t7mQSRPYITkMoYRVNz7jQg" changeDate="2007-02-26T03:44:53.453-0800" version="1.0.0"> |
| <mainDescription><h4> |
| Identify architectural priorities |
| </h4> |
| <p> |
| Architecture&nbsp;priorities&nbsp;can take the form of&nbsp;one or more <a class="elementLink" |
| href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html" |
| guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s brought into scope by association to the scenarios |
| prioritized for the current iteration. Other drivers may also be apparent. For example, it may be necessary to move |
| certain aspects of the architecture from prototypical to production quality implementation; or explore certain aspects |
| of the architecture to inform future iterations. |
| </p> |
| <p> |
| The architectural&nbsp;priorities are often&nbsp;driven by&nbsp;the development of software that implements an&nbsp;<a |
| class="elementLink" href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html" |
| guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>.&nbsp;It is important to specify the qualities of these |
| mechasnisms precisely and this may lead you to supplement the usage scenarios with quality attributes. As more than one |
| usage scenario may plkace demands on the same mechanisms, it may be helpful to consolidate these into quality |
| scenarios. |
| </p> |
| <p> |
| 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 [<a class="elementLinkWithUserText" |
| href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" |
| guid="_9ToeIB83Edqsvps02rpOOg">KAZ04</a>]. Walk through things that could happen to the system and How it would |
| respond. <strong>Use-case scenarios</strong> focus on run-time behavior where the stakeholder is the user. |
| <strong>Quality scenarios</strong> encompass other interactions with the system as well, such as system maintenance |
| staff modifying the system. |
| </p> |
| <p> |
| Several scenarios may be devised for each quality attribute (such as usability, reliability, performance, |
| or&nbsp;security). 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. |
| </p> |
| <p> |
| Example: |
| </p> |
| <blockquote> |
| <p> |
| 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. |
| </p> |
| </blockquote> |
| <p> |
| After you have collected the 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. |
| </p> |
| <h4> |
| Refine &nbsp;the architecture mechanisms |
| </h4> |
| <p> |
| Consider each high-priority quality scenario, and map each of these onto the architecture mechanisms. Refine the |
| mechanisms to identify the specific technology&nbsp;to be used&nbsp;to handle each mechanism in scope. For example, for |
| the Persistence mechasnism, it may be appropriate to&nbsp;use a relational database management system such as |
| MySQL.&nbsp;Consider the selection of technology in the context of the requirements and constraints. |
| </p> |
| <p> |
| See <a class="elementLinkWithType" |
| href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html" |
| guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a> for more information. |
| </p> |
| <h4> |
| Identify Business Patterns |
| </h4> |
| <p> |
| The&nbsp;architecture of&nbsp;a software system can often be characterised by a small number of essential scenarios. |
| For example, for an on-line book store describing the way the software handles the scenarios for ordering a book and |
| checking out the shopping cart are often enough to communicate the essence of the architecture. Such business patterns |
| also provide a useful blueprint for similar functionality throughout the system. |
| </p> |
| <h4> |
| Identify reuse opportunities |
| </h4> |
| <p> |
| After looking for similar behavior and returned values, then look for similarity of parameters. If their |
| interfaces&nbsp;are not an exact match for the component interfaces being proposed, you can modify the |
| proposed&nbsp;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&nbsp;a perfect match between operation |
| signatures. |
| </p> |
| <p align="left"> |
| A common set of components may exist that provides many of the <a class="elementLink" |
| href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html" |
| guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a> that you need&nbsp;for the new system. These components may |
| be available either because they were developed or purchased previously for&nbsp;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. |
| </p> |
| <p align="left"> |
| Similar thinking applies to&nbsp;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. |
| </p> |
| <h4 align="left"> |
| Identify architecturally significant design elements |
| </h4> |
| <p align="left"> |
| Consider&nbsp;each high-priority&nbsp;scenario in scope. Walk through the actions that the&nbsp;scenario initiates and |
| highlight the areas of the architecture that participate in realizing, or implementing, the requirements. |
| </p> |
| <p> |
| 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&nbsp;based on architectural layers, deployment choices, or key abstractions. Ask yourself these questions: |
| </p> |
| <ul> |
| <li> |
| What is logically or functionally related (same use case or service, for example)? |
| </li> |
| <li> |
| What entities provide services to multiple others? |
| </li> |
| <li> |
| What entities depend on each other? Strongly or weakly? |
| </li> |
| <li> |
| What entities should you be able to exchange independently from others? |
| </li> |
| <li> |
| What will run on the same processor or network node? |
| </li> |
| <li> |
| What parts are constrained by similar performance requirements? |
| </li> |
| </ul> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h4> |
| Define development and test architectures |
| </h4> |
| <p> |
| The development and test architectures may be different from the target production implementation. |
| </p> |
| <ul> |
| <li> |
| Additional software may need to be developed to support testing. |
| </li> |
| <li> |
| Alternative deployment configurations may need to be defined in response to constraints on development hardware. |
| </li> |
| <li> |
| Multiple environments may be required to support different categories of tests. |
| </li> |
| </ul> |
| <p> |
| In each case, you need to specify the architecture. Also, be sure to consider the impact on the quality of the overall |
| architecture. |
| </p> |
| <h4> |
| Validate the architecture |
| </h4> |
| <p> |
| The surest way to validate the architecture is through software. The software developed up to the end of the |
| Elbaoration Phase is largely aiming to validate the architecture, to the point where it can be baselined, thereby |
| providing some level of stability during the Construction phase. |
| </p> |
| <p> |
| It can also be useful to perform simple validation by walking through the main design concepts and models, perhaps |
| around a whiteboard or through other collaborative techniques. This can help refine thinking but will not act as a |
| subsitute for building some software. |
| </p> |
| <h4> |
| Communicate decisions |
| </h4> |
| <p> |
| You can document and communicate your decisions as many ways as you wish: |
| </p> |
| <ul> |
| <li> |
| Publication of&nbsp;reference source code. |
| </li> |
| <li> |
| Publication of&nbsp;reference models. |
| </li> |
| <li> |
| Publication of&nbsp;software architecture documentation. |
| </li> |
| <li> |
| Formal&nbsp;presentations of the material. |
| </li> |
| <li> |
| Informal walkthroughs of the architecture |
| </li> |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |