| <?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" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-UQ_e8kozIP11Xu008RJd-A" |
| name="new_concept,__O7tAMVvEduLYZUGfgZrkQ" guid="-UQ_e8kozIP11Xu008RJd-A" changeDate="2008-10-15T06:28:05.992-0700" |
| version="7.2.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="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
 |
| 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="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
 |
| 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>
 |
| The architecture focuses on specific aspects of the overall system design, concentrating on structure, essential
 |
| elements, key scenarios and those aspects that have a lasting impact on system qualities such as performance,
 |
| reliability, adaptability and cost. It also defines the set of <a class="elementLink"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
 |
| guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s, <a class="elementLink"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
 |
| guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s and styles that will guide the rest of the design, assuring its integrity.
 |
| </p>
 |
| <h3>
 |
| Purpose of Architecture
 |
| </h3>
 |
| <p>
 |
| The architecture can be used for many things:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>To describe the essential structure of the system and the decisions guiding the structure of the
 |
| system</strong> so the integrity and understandability of the system is assured.
 |
| </li>
 |
| <li>
 |
| <a id="Comment71_" name="Comment71_"><strong>To identify and attack risks to the system</strong> (using the
 |
| architecture as an artifact of governance)</a>
 |
| </li>
 |
| <li>
 |
| <strong>To provide context and guidance for developers</strong> to construct the system by describing the
 |
| motivations behind the architectural decisions so those decisions can be robustly implemented. The architecture
 |
| services as the blueprint for development.&nbsp;For example, the architect may place constraints on how data is
 |
| packaged and communicated between different parts of the system. This may appear to be a burden, but the
 |
| justification in the Architecture Notebook can explain that there is a significant performance bottleneck when
 |
| communicating with a legacy system. The rest of the system must adapt to this bottleneck by following a specific
 |
| data packaging scheme.
 |
| </li>
 |
| <li>
 |
| <strong>To provide an overview of the system to whoever must maintain the architecture</strong>, as well as an
 |
| understanding of the motivation behind the important technical decisions.&nbsp; Team members who were not involved
 |
| in those architectural decisions need to understand the reasoning behind the&nbsp;context of the architecture so
 |
| they can best address the needs of the system.
 |
| </li>
 |
| <li>
 |
| <strong>To define the project structure and team organization.</strong> Architectural elements make excellent units
 |
| of implementation, unit testing, integration, configuration management and&nbsp;documentation.&nbsp;&nbsp; They can
 |
| also be used to define&nbsp; so that managers can plan the project.
 |
| </li>
 |
| </ul>
 |
| <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.
 |
| </p>
 |
| <p>
 |
| The following is some information that is worth capturing as part of the software architecture:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Architectural goals (see <a class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_goals_CB41D8AE.html"
 |
| guid="_HlRqANpbEdyP58ppo1Ieaw">Concept: Architectural Goals</a>)
 |
| </li>
 |
| <li>
 |
| References to architecturally significant requirements and how the architecture addresses those requirements,
 |
| including&nbsp;key scenarios that describe critical behavior of the system (see <a class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html"
 |
| guid="_HrZGIA4MEduibvKwrGxWxA">Concept: Architecturally Significant Requirements</a>)
 |
| </li>
 |
| <li>
 |
| Constraints on the architecture and how the architecture addresses those constraints (see <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_constraints_AE56B662.html"
 |
| guid="_jdKSsNpiEdyP58ppo1Ieaw">Concept: Architectural Constraints</a>)
 |
| </li>
 |
| <li>
 |
| Key abstractions (see <a class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html"
 |
| guid="_pLEGUNqGEdy88NBoQgfGyg">Concept: Key Abstractions</a>)
 |
| </li>
 |
| <li>
 |
| <a class="elementLink"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
 |
| guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a> and where they should be applied (see <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
 |
| guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>).
 |
| </li>
 |
| <li>
 |
| Description of the partitioning approach, as well as a description of the key partitions.&nbsp; For example,
 |
| Layering&nbsp;(see <a class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html"
 |
| guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a>)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 |
| </li>
 |
| <li>
 |
| Description of the deployment approach, as well as how key components are allocated to deployment
 |
| nodes.&nbsp;&nbsp;&nbsp;&nbsp;
 |
| </li>
 |
| <li>
 |
| References to architecturally significant design elements (see <a class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/component_CB167D48.html"
 |
| guid="_0YP18MlgEdmt3adZL5Dmdw">Concept: Component</a>)&nbsp;
 |
| </li>
 |
| <li>
 |
| Critical system interfaces (see <a class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/guidelines/repres_interfaces_to_ext_systems_51A34F6E.html"
 |
| guid="_0gjdYMlgEdmt3adZL5Dmdw">Guideline: Representing Interfaces to External Systems</a>)
 |
| </li>
 |
| <li>
 |
| Assets that have been reused and/or assets that have been developed to be reused (for more information, see <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html"
 |
| guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>)
 |
| </li>
 |
| <li>
 |
| Guidance, decisions, and constraints the developers must follow in building the system, along with justification
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The architecture can contain any information and references that are appropriate in communicating how developers should
 |
| build the system.
 |
| </p>
 |
| <h4>
 |
| Architectural Representation
 |
| </h4>
 |
| <p>
 |
| The architecture can be represented in many forms and from many viewpoints, depending on the needs of the project and
 |
| the preferences of the project team. It need not be a formal document. The essence of the architecture can often be
 |
| communicated through a series of simple diagrams on a whiteboard; or as a list of decisions. The illustration just
 |
| needs to show the nature of the proposed solution, convey the governing ideas, and represent the major building blocks
 |
| to make it easier to communicate the architecture to the project team and stakeholders.
 |
| </p>
 |
| <p>
 |
| If a more complex system is required, then the architecture can be represented as a more comprehensive set
 |
| of&nbsp;views that describe the architecture from a number of viewpoints. For more information, see <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_views_viewpoints_7A6CD31.html"
 |
| guid="_kgtcoNc8Edyd7OybSySFxg">Concept: Architectural Views and Viewpoints</a>.
 |
| </p>
 |
| <p>
 |
| The architecture can be expressed as a simple metaphor or as a comparison to a predefined architectural style or set of
 |
| styles. It may be a precise set of models or documents that describe the various aspects of the system's key elements.
 |
| Expressing it as skeletal implementation is another option - although this may need to be baselined and preserved to
 |
| ensure that the essence of the system can be understood as the system grows. Choose the medium that best meets the
 |
| needs of the project.
 |
| </p>
 |
| <h3>
 |
| Architectural Patterns
 |
| </h3>
 |
| <p>
 |
| Architectural <a class="elementLink"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
 |
| guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s 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>
 |
| <p>
 |
| <a class="elementlinkwithusertext"
 |
| href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
 |
| 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="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
 |
| 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="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
 |
| 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 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>
 |
| <h3>
 |
| Architectural Timing
 |
| </h3>
 |
| <p>
 |
| Teams should expect to spend more time on architectural issues early in the project.&nbsp; This allows the team to
 |
| reduce risk associated to technology early in the project, hence allowing the team to more rapidly reduce the variance
 |
| in their estimate on what they can deliver at what time. Examples of architectural issues that needs to be resolved
 |
| early on include
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Component and their major interfaces
 |
| </li>
 |
| <li>
 |
| Major technology choices (platform, languages, architecture frameworks / reference architectures, etc.)
 |
| </li>
 |
| <li>
 |
| Interfaces to external systems
 |
| </li>
 |
| <li>
 |
| Common services (persistence mechanisms, logging mechanisms, garbage collection, etc.)
 |
| </li>
 |
| <li>
 |
| Key patterns
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Validating the Architecture
 |
| </h3>
 |
| <p>
 |
| The best way to validate the architecture is to actually implement it.&nbsp; For more information, see <a
 |
| class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/executable_arch_D4E68CBD.html"
 |
| guid="_O1kAANvfEduv2KOT-Teh6w">Executable Architecture</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
