<?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.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-UQ_e8kozIP11Xu008RJd-A"
    name="new_concept,__O7tAMVvEduLYZUGfgZrkQ" guid="-UQ_e8kozIP11Xu008RJd-A" changeDate="2007-04-07T05:49:37.411-0700"
    version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Introduction&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Software architecture is a concept that is easy to understand, and that most engineers intuitively feel, especially&#xD;
    with a little experience, but it is hard to precisely define. In particular, it is difficult to draw a sharp line&#xD;
    between design and architecture -- architecture is one aspect of design that concentrates on some specific features.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In &lt;i>An Introduction to Software Architecture&lt;/i>, David Garlan and Mary Shaw suggest that software architecture is a level&#xD;
    of design concerned with issues: &quot;Beyond the algorithms and data structures of the computation; designing and&#xD;
    specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization&#xD;
    and global control structure; protocols for communication, synchronization, and data access; assignment of&#xD;
    functionality to design elements; physical distribution; composition of design elements; scaling and performance; and&#xD;
    selection among design alternatives.&quot; &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#GAR93&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[GAR93]&lt;/a>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    But there is more to architecture than just structure; the IEEE Working Group on Architecture defines it as &quot;the&#xD;
    highest-level concept of a system in its environment&quot; &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#IEP1471&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[IEP1471]&lt;/a>. It also encompasses the &quot;fit&quot; with system integrity, with economical&#xD;
    constraints, with aesthetic concerns, and with style. It is not limited to an inward focus, but takes into&#xD;
    consideration the system as a whole in its user environment and its development environment -- an outward focus.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In this process, the architecture of a software system (at a given point) is the organization or structure of the&#xD;
    system's significant components interacting through interfaces, with components composed of successively smaller&#xD;
    components and interfaces.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Architecture Description&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    To speak and reason about software architecture, you must first define an architectural representation, a way of&#xD;
    describing important aspects of an architecture. This description is captured in the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/workproducts/architecture_notebook_9BB92433.html&quot; guid=&quot;_0XAf0MlgEdmt3adZL5Dmdw&quot;>Artifact: Architecture Notebook&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Architectural views&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The software architecture can be represented in multiple architectural views. Each architectural view addresses&#xD;
    some specific set of concerns, specific to stakeholders in the development process: users, designers, managers, system&#xD;
    engineers, maintainers, and so on.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The views capture the major structural design decisions by showing how the software architecture is decomposed into&#xD;
    components, and how components are connected by connectors to produce useful forms &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#DEW92&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[DEW92]&lt;/a>. These design choices must be tied to the requirements -- functional and&#xD;
    supplementary -- and other constraints. But these choices in turn put further constraints on the requirements, and&#xD;
    on future design decisions at a lower level.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Architectural Focus&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Although the views above could represent the whole design of a system, the architecture concerns itself only with some&#xD;
    specific aspects:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>The structure of the model:&lt;/b> the organizational patterns, for example, Layering&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>The essential elements:&lt;/b> critical use cases, main classes, common mechanisms, and so on, as opposed to all the&#xD;
        elements present in the model&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>A few key scenarios&lt;/b> showing the main control flows throughout the system&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>The services&lt;/b>, to capture modularity, optional features, product-line aspects&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    In essence, architectural views are abstractions (or simplifications) of the entire design, in which important&#xD;
    characteristics are made more visible by leaving details aside. These characteristics are important when reasoning&#xD;
    about:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        System evolution: going to the next development cycle&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Reuse of the architecture, or parts of it, in the context of a product line&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Assessing supplementary qualities, such as performance, availability, portability, and safety&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Assigning development work to teams or subcontractors&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Decisions about including off-the-shelf components&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Insertion in a wider system&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Architectural Patterns&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Architectural patterns are ready-made forms that solve recurring architectural problems. An architectural framework or&#xD;
    an architectural infrastructure (middleware) is a set of components on which you can build a certain kind of&#xD;
    architecture. Many of the major architectural difficulties should be resolved in the framework or in the&#xD;
    infrastructure, usually targeted to a specific domain: command and control, MIS, control system, and so on.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Examples of Architectural Patterns&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#BUS96&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[BUS96]&lt;/a> groups architectural patterns according to the characteristics of the&#xD;
    systems in which they are most applicable, with one category dealing with more general structuring issues. The following table&#xD;
    shows the categories presented in &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#BUS96&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[BUS96]&lt;/a> and the patterns they contain.&#xD;
&lt;/p>&#xD;
&lt;div align=&quot;center&quot;>&#xD;
    &lt;table     style=&quot;BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid&quot;      cellspacing=&quot;0&quot; bordercolordark=&quot;#808080&quot; cellpadding=&quot;4&quot; width=&quot;85%&quot; bordercolorlight=&quot;#808080&quot; border=&quot;1&quot;>&#xD;
        &lt;tbody>&#xD;
            &lt;tr>&#xD;
                &lt;th id=&quot;col1&quot; width=&quot;50%&quot;>&#xD;
                    Category&#xD;
                &lt;/th>&#xD;
                &lt;th id=&quot;col2&quot; width=&quot;50%&quot;>&#xD;
                    Pattern&#xD;
                &lt;/th>&#xD;
            &lt;/tr>&#xD;
            &lt;tr>&#xD;
                &lt;th id=&quot;row2&quot; align=&quot;left&quot; headers=&quot;col1&quot; width=&quot;50%&quot; rowspan=&quot;3&quot;>&#xD;
                    Structure&#xD;
                &lt;/th>&#xD;
                &lt;td headers=&quot;row2 col2&quot; width=&quot;50%&quot;>&#xD;
                    Layers&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
            &lt;tr>&#xD;
                &lt;td headers=&quot;row2 col2&quot; width=&quot;50%&quot;>&#xD;
                    Pipes and Filters&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
            &lt;tr>&#xD;
                &lt;td headers=&quot;row2 col2&quot; width=&quot;50%&quot;>&#xD;
                    Blackboard&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
            &lt;tr>&#xD;
                &lt;th id=&quot;row3&quot; align=&quot;left&quot; headers=&quot;col1&quot; width=&quot;50%&quot;>&#xD;
                    Distributed Systems&#xD;
                &lt;/th>&#xD;
                &lt;td headers=&quot;row3 col2&quot; width=&quot;50%&quot;>&#xD;
                    Broker&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
            &lt;tr>&#xD;
                &lt;th id=&quot;row4&quot; align=&quot;left&quot; headers=&quot;col1&quot; width=&quot;50%&quot; rowspan=&quot;2&quot;>&#xD;
                    Interactive Systems&#xD;
                &lt;/th>&#xD;
                &lt;td headers=&quot;row4 col2&quot; width=&quot;50%&quot;>&#xD;
                    Model-View-Controller&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
            &lt;tr>&#xD;
                &lt;td headers=&quot;row4 col2&quot; width=&quot;50%&quot;>&#xD;
                    Presentation-Abstraction-Control&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
            &lt;tr>&#xD;
                &lt;th id=&quot;row5&quot; align=&quot;left&quot; headers=&quot;col1&quot; width=&quot;50%&quot; rowspan=&quot;2&quot;>&#xD;
                    Adaptable Systems&#xD;
                &lt;/th>&#xD;
                &lt;td headers=&quot;row5 col2&quot; width=&quot;50%&quot;>&#xD;
                    Reflection&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
            &lt;tr>&#xD;
                &lt;td headers=&quot;row5 col2&quot; width=&quot;50%&quot;>&#xD;
                    Microkernel&#xD;
                &lt;/td>&#xD;
            &lt;/tr>&#xD;
        &lt;/tbody>&#xD;
    &lt;/table>&lt;br />&#xD;
&lt;/div>&#xD;
&lt;p>&#xD;
    Refer to &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#BUS96&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[BUS96]&lt;/a> for a complete description of these patterns.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Architectural Style&quot; name=&quot;Architectural Style&quot;>Architectural Style&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    A software architecture, or simply an architectural view, may have an attribute called &lt;b>architectural style&lt;/b>, which&#xD;
    reduces the set of possible forms to choose from, and imposes a certain degree of uniformity to the architecture. The&#xD;
    style may be defined by a set of patterns, or by the choice of specific components or connectors as the basic building&#xD;
    blocks.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>