OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/develop_architecture.xmi

<?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>&lt;h4&gt;
    Identify architectural priorities
&lt;/h4&gt;
&lt;p&gt;
    Architecture&amp;nbsp;priorities&amp;nbsp;can take the form of&amp;nbsp;one or more &lt;a class=&quot;elementLink&quot;
    href=&quot;./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html&quot;
    guid=&quot;_mzxI0A4LEduibvKwrGxWxA&quot;&gt;Architectural Mechanism&lt;/a&gt;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.
&lt;/p&gt;
&lt;p&gt;
    The architectural&amp;nbsp;priorities are often&amp;nbsp;driven by&amp;nbsp;the development of software that implements an&amp;nbsp;&lt;a
    class=&quot;elementLink&quot; href=&quot;./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html&quot;
    guid=&quot;_mzxI0A4LEduibvKwrGxWxA&quot;&gt;Architectural Mechanism&lt;/a&gt;.&amp;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.
&lt;/p&gt;
&lt;p&gt;
    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 [&lt;a class=&quot;elementLinkWithUserText&quot;
    href=&quot;./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html&quot;
    guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;&gt;KAZ04&lt;/a&gt;]. Walk through things that could happen to the system and How it would
    respond. &lt;strong&gt;Use-case scenarios&lt;/strong&gt; focus on run-time behavior where the stakeholder is the user.
    &lt;strong&gt;Quality scenarios&lt;/strong&gt; encompass other interactions with the system as well, such as system maintenance
    staff modifying the system.
&lt;/p&gt;
&lt;p&gt;
    Several scenarios may be devised for each quality attribute (such as usability, reliability, performance,
    or&amp;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.
&lt;/p&gt;
&lt;p&gt;
    Example:
&lt;/p&gt;
&lt;blockquote&gt;
    &lt;p&gt;
        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.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;h4&gt;
    Refine &amp;nbsp;the architecture mechanisms
&lt;/h4&gt;
&lt;p&gt;
    Consider each high-priority quality scenario, and map each of these onto the architecture mechanisms. Refine the
    mechanisms to identify the specific technology&amp;nbsp;to be used&amp;nbsp;to handle each mechanism in scope. For example, for
    the Persistence mechasnism, it may be appropriate to&amp;nbsp;use a relational database management system such as
    MySQL.&amp;nbsp;Consider the selection of technology in the context of the requirements and constraints.
&lt;/p&gt;
&lt;p&gt;
    See &lt;a class=&quot;elementLinkWithType&quot;
    href=&quot;./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html&quot;
    guid=&quot;_mzxI0A4LEduibvKwrGxWxA&quot;&gt;Concept: Architectural Mechanism&lt;/a&gt; for more information.
&lt;/p&gt;
&lt;h4&gt;
    Identify Business Patterns
&lt;/h4&gt;
&lt;p&gt;
    The&amp;nbsp;architecture of&amp;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.
&lt;/p&gt;
&lt;h4&gt;
    Identify reuse opportunities
&lt;/h4&gt;
&lt;p&gt;
    After looking for similar behavior and returned values, then look for similarity of parameters. If their
    interfaces&amp;nbsp;are not an exact match for the component interfaces being proposed, you can modify the
    proposed&amp;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&amp;nbsp;a perfect match between operation
    signatures.
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt;
    A common set of components may exist that provides many of the &lt;a class=&quot;elementLink&quot;
    href=&quot;./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html&quot;
    guid=&quot;_mzxI0A4LEduibvKwrGxWxA&quot;&gt;Architectural Mechanism&lt;/a&gt; that you need&amp;nbsp;for the new system. These components may
    be available either because they were developed or purchased previously for&amp;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.
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt;
    Similar thinking applies to&amp;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.
&lt;/p&gt;
&lt;h4 align=&quot;left&quot;&gt;
    Identify architecturally significant design elements
&lt;/h4&gt;
&lt;p align=&quot;left&quot;&gt;
    Consider&amp;nbsp;each high-priority&amp;nbsp;scenario in scope. Walk through the actions that the&amp;nbsp;scenario initiates and
    highlight the areas of the architecture that participate in realizing, or implementing, the requirements.
&lt;/p&gt;
&lt;p&gt;
    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&amp;nbsp;based on architectural layers, deployment choices, or key abstractions. Ask yourself these questions:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        What is logically or functionally related (same use case or service, for example)?
    &lt;/li&gt;
    &lt;li&gt;
        What entities provide services to multiple others?
    &lt;/li&gt;
    &lt;li&gt;
        What entities depend on each other? Strongly or weakly?
    &lt;/li&gt;
    &lt;li&gt;
        What entities should you be able to exchange independently from others?
    &lt;/li&gt;
    &lt;li&gt;
        What will run on the same processor or network node?
    &lt;/li&gt;
    &lt;li&gt;
        What parts are constrained by similar performance requirements?
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;h4&gt;
    Define development and test architectures
&lt;/h4&gt;
&lt;p&gt;
    The development and test architectures may be different from the target production implementation.
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Additional software may need to be developed to support testing.
    &lt;/li&gt;
    &lt;li&gt;
        Alternative deployment configurations may need to be defined in response to constraints on development hardware.
    &lt;/li&gt;
    &lt;li&gt;
        Multiple environments may be required to support different categories of tests.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    In each case, you need to specify the architecture. Also, be sure to consider the impact on the quality of the overall
    architecture.
&lt;/p&gt;
&lt;h4&gt;
    Validate the architecture
&lt;/h4&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;h4&gt;
    Communicate decisions
&lt;/h4&gt;
&lt;p&gt;
    You can document and communicate your decisions as many ways as you wish:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Publication of&amp;nbsp;reference source code.
    &lt;/li&gt;
    &lt;li&gt;
        Publication of&amp;nbsp;reference models.
    &lt;/li&gt;
    &lt;li&gt;
        Publication of&amp;nbsp;software architecture documentation.
    &lt;/li&gt;
    &lt;li&gt;
        Formal&amp;nbsp;presentations of the material.
    &lt;/li&gt;
    &lt;li&gt;
        Informal walkthroughs of the architecture
    &lt;/li&gt;
&lt;/ul&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>