| <?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="-QB0WnHnpcK1VJbdJJ5QJ5A" |
| name="new_concept,_kgtcoNc8Edyd7OybSySFxg" guid="-QB0WnHnpcK1VJbdJJ5QJ5A" changeDate="2010-08-24T17:16:41.755-0700" |
| version="7.2.0"> |
| <mainDescription><p>
 |
| Architecture can be represented from a variety of viewpoints, all of which can be combined to create a holistic view of
 |
| the system. 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="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#PW92"
 |
| 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.&nbsp;
 |
| </p>
 |
| <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>
 |
| <p>
 |
| To choose the appropriate set of views,&nbsp;identify the stakeholders who depend on software architecture
 |
| documentation and the information that they need. For an example of a set of views that have been used to represent
 |
| architecture, see <a class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/examples/four_plus_one_view_of_arch_9A93ACE5.html"
 |
| guid="_4bC4cNs_EdyEW4klSH3vRA">Example: 4+1 Views of Software Architecture</a>.&nbsp; A more comprehensive set of views
 |
| can be found in the <a href="http://www.ibm.com/developerworks/rational/library/08/0108_cooks-cripps-spaas/"
 |
| target="_blank">IBM Views and Viewpoints Framework for IT systems</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
