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