OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/concepts/software_architecture.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\guidances\concepts\software_architecture.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: software_architecture.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,__O7tAMVvEduLYZUGfgZrkQ CRC: 867985127 -->Software Architecture<!-- END:presentationName,__O7tAMVvEduLYZUGfgZrkQ -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,__O7tAMVvEduLYZUGfgZrkQ CRC: 3599034556 -->The software architecture represents the structure or structures of the system, which consists of software components, the externally visible properties of those components, and the relationships among them.<!-- END:briefDescription,__O7tAMVvEduLYZUGfgZrkQ -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-UQ_e8kozIP11Xu008RJd-A CRC: 3617722195 --><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_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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>
     In OpenUP, 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. In OpenUP, this description is captured in the <a
     class="elementLinkWithType" href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
     guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture</a>.
 </p>
 <h3>
     Architectural Views
 </h3>
 <p>
     We have chosen to represent software architecture 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_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
     guid="_9ToeIB83Edqsvps02rpOOg">[PW92]</a>. These design choices must be tied to the Requirements, functional, and
     supplementary, 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_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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 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><!-- END:mainDescription,-UQ_e8kozIP11Xu008RJd-A -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\guidances\concepts\software_architecture.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: software_architecture.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,__O7tAMVvEduLYZUGfgZrkQ CRC: 867985127 -->Software Architecture<!-- END:presentationName,__O7tAMVvEduLYZUGfgZrkQ -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,__O7tAMVvEduLYZUGfgZrkQ CRC: 3599034556 -->The software architecture represents the structure or structures of the system, which consists of software components, the externally visible properties of those components, and the relationships among them.<!-- END:briefDescription,__O7tAMVvEduLYZUGfgZrkQ -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-UQ_e8kozIP11Xu008RJd-A CRC: 3617722195 --><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_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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>
	In OpenUP, 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. In OpenUP, this description is captured in the <a
	class="elementLinkWithType" href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
	guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture</a>.
	</p>
	<h3>
	Architectural Views
	</h3>
	<p>
	We have chosen to represent software architecture 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_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
	guid="_9ToeIB83Edqsvps02rpOOg">[PW92]</a>. These design choices must be tied to the Requirements, functional, and
	supplementary, 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.
	</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_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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 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><!-- END:mainDescription,-UQ_e8kozIP11Xu008RJd-A -->
	</body>
	</html>