| <?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.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-K57GQWwsOy4jkTyqZoWs2A" |
| name="develop_architecture,_mDf2EBapEduSTJywppIxVQ" guid="-K57GQWwsOy4jkTyqZoWs2A" |
| changeDate="2007-02-26T03:44:53.453-0800" version="1.0.0"> |
| <mainDescription><h1> Identify architectural priorities </h1>
 |
| <p> Architecture&nbsp;priorities&nbsp;can take the form of&nbsp;one or more <a class="elementLink" href="./../../../openup/guidances/concepts/arch_mech_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural 
 |
| Mechanism</a>s that are brought into scope by association with 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 
 |
| prototype- to production-quality implementation or to explore certain aspects 
 |
| of the architecture to inform developers of 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/guidances/concepts/arch_mech_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural 
 |
| Mechanism</a>.&nbsp;It is important to specify the qualities of these mechanisms 
 |
| precisely, and this may lead you to supplement the use (or &quot;usage&quot;) 
 |
| scenarios with quality attributes. Because more than one use scenario may place 
 |
| 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/guidances/supportingmaterials/references_6CCF393.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 runtime 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 example: 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>
 |
| <h2> Refine the Architectural Mechanisms </h2>
 |
| <p> Consider each high-priority quality scenario, and map each of these onto the 
 |
| Architectural Mechanisms. Refine the mechanisms to identify the specific technology 
 |
| that will handle each mechanism in scope. For example, for the Persistence mechanism, 
 |
| 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/guidances/concepts/arch_mech_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a> for more information.
 |
| </p>
 |
| <h2> Identify Business Patterns </h2>
 |
| <p> The&nbsp;architecture of&nbsp;a software system can often be characterized 
 |
| by a small number of essential scenarios. For example, for an online bookstore, 
 |
| 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>
 |
| <h2> Identify reuse opportunities </h2>
 |
| <p> After looking for similar behavior and returned values, look for similarity 
 |
| of parameters. If the 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/guidances/concepts/arch_mech_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural 
 |
| Mechanisms</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>
 |
| <h2 align="left"> Identify architecturally significant design elements </h2>
 |
| <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>
 |
| <h2> Define development and test architectures </h2>
 |
| <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>
 |
| <h2> Validate the architecture </h2>
 |
| <p> The surest way to validate the architecture is through software. The software 
 |
| developed up to the end of the Elaboration 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 substitute for building some software. </p>
 |
| <h2> Communicate decisions </h2>
 |
| <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> |
