| <?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="-YeVRerdEixh4HgHOuw2KRQ" |
| name="analyze_arch_reqs,_42UD4A3tEduibvKwrGxWxA" guid="-YeVRerdEixh4HgHOuw2KRQ" |
| changeDate="2007-06-29T13:28:32.759-0700" version="1.0.0"> |
| <mainDescription><h4>
 |
| Identify architectural goals
 |
| </h4>
 |
| <p>
 |
| Architectural goals provide the motivation and rationale&nbsp;for decisions. These goals are&nbsp;often driven
 |
| by&nbsp;the software requirements, particularly in&nbsp;<a class="elementLink" href="./../../../openup/workproducts/supporting_requirements_spec_7D9DD47C.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements Specification</a>, because they are not always&nbsp;obvious from&nbsp;the use cases alone [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">ALL02</a>].
 |
| </p>
 |
| <p>
 |
| Architectural goals define how the system needs to respond to change over time. Consider these questions when writing
 |
| your goals:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| What is the expected lifespan of the system?
 |
| </li>
 |
| <li>
 |
| Will the system need to respond to technological changes over that time, such as new versions of middleware or
 |
| other products?
 |
| </li>
 |
| <li>
 |
| How&nbsp;frequently is&nbsp;the system&nbsp;expected to adapt to change?
 |
| </li>
 |
| <li>
 |
| What changes can we anticipate in the future, and how can we make them easier to accommodate?
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| These considerations will have a significant effect on the structure of the system.
 |
| </p>
 |
| <h4>
 |
| Identify architecturally significant requirements
 |
| </h4>
 |
| <p>
 |
| Some of the requirements will be more significant than others when considered from an architectural perspective.
 |
| Identifying them will define&nbsp;the subset of requirements that will generally need to be satisfied before the
 |
| architecture can be stabilised. Furthermore, the system will generally be more sensitive to changes&nbsp;against
 |
| architecturally significant requirements&nbsp;than others, so identifying and communicating ths subset will help others
 |
| understand the potential implications of change.
 |
| </p>
 |
| <p>
 |
| Requirements can be explicitly or implicitly architecturally significant. Implicitly significant requirements may
 |
| define the essence of the functional behaviour of the system (for example, making a purchase from an on-line store).
 |
| Explicitly significant requirements are often overtly technical in nature, such as performance targets; the need to
 |
| interface to other systems; the number of users that must be supported; or security requirements.
 |
| </p>
 |
| <p>
 |
| See <a class="elementLink" href="./../../../openup/guidances/guidelines/determine_architecturally_significant_requirements_817DFD9B.html" guid="_D3JXMNvKEduv2KOT-Teh6w">Determine Architecturally Significant Requirements</a>&nbsp;for more information.
 |
| </p>
 |
| <h4>
 |
| Identify constraints on the architecture
 |
| </h4>
 |
| <p>
 |
| Gather information about the existing&nbsp;environment and identify any constraints in the solution. This will ease
 |
| integration with the environment; and may reduce risk, cost and duplication of solution elements.
 |
| </p>
 |
| <p>
 |
| Architectural constraints can arise from various factors:
 |
| </p>
 |
| <div style="MARGIN-LEFT: 2em">
 |
| <ul>
 |
| <li>
 |
| Network topology
 |
| </li>
 |
| <li>
 |
| Use of a given database vendor or an existing database
 |
| </li>
 |
| <li>
 |
| Web environment (server configurations, firewall, DMZs, and so forth)
 |
| </li>
 |
| <li>
 |
| Servers (hardware model, operating system)
 |
| </li>
 |
| <li>
 |
| Use of third-party software or a particular technology
 |
| </li>
 |
| <li>
 |
| Compliance with existing standards
 |
| </li>
 |
| </ul>
 |
| </div>
 |
| <p>
 |
| For example, if the company uses only one type of database, you will probably try to use it as much as possible to
 |
| leverage&nbsp;the existing database administration skills, rather than introducing a new one.
 |
| </p>
 |
| <p>
 |
| These architectural constraints, combined with the requirements, help you define&nbsp;an appropriate&nbsp;candidate for
 |
| the system architecture.
 |
| </p>
 |
| <h4>
 |
| Survey, assess, and select from available assets
 |
| </h4>
 |
| <p>
 |
| To assess and select assets to reuse on your project, you need to understand the requirements of the system's
 |
| environment. You also need to understand the scope and general functionality of the system that the Stakeholders
 |
| require. There are several types of assets to consider, including (but not limited to): reference architectures;
 |
| frameworks; patterns; analysis mechanisms; classes; and experience. You can search asset&nbsp;repositories (internal or
 |
| external to your organization) and industry literature to identify assets or similar projects.
 |
| </p>
 |
| <p>
 |
| You need to assess whether available assets contribute to solving the key challenges of the current project and whether
 |
| they are compatible with the project's architectural constraints. You also need to analyze the extent of the fit
 |
| between assets and requirements, considering whether any of the requirements are negotiable (to enable use of the
 |
| asset). Also, assess whether the asset could be modified or extended to satisfy requirements, as well as what the
 |
| tradeoffs in adopting it are, in terms of cost, risk, and functionality.
 |
| </p>
 |
| <p>
 |
| Finally, decide, in principle, whether to use one or more assets, and record the rationale for this decision.
 |
| </p>
 |
| <h4>
 |
| Define approach for structuring the system
 |
| </h4>
 |
| <p>
 |
| Structuring your system helps you manage its complexity by using the well-known "divide and conquer" strategy. By
 |
| breaking the process into smaller and more manageable pieces, you make development easier.
 |
| </p>
 |
| <p>
 |
| Layering&nbsp; is&nbsp;one of the most&nbsp;commonly used&nbsp;approaches for structuring and decomposing systems. Each
 |
| layer groups similar classes or components, which communicate insofar as possible only with adjacent layers.&nbsp; See
 |
| <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/layering_F169CF07.html" guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a> for more information.
 |
| </p>
 |
| <p>
 |
| You do not define which layers contain which classes or components. Instead, you define how many layers you will need
 |
| and which kinds of layers you will use. For example, if you are developing a new middleware system, you probably do not
 |
| need a business layer. Later, during&nbsp;design activities, you decide which classes and components will populate
 |
| these layers.
 |
| </p>
 |
| <h4>
 |
| Define approach for deploying the system
 |
| </h4>
 |
| <p>
 |
| Develop a high level overview of how the software is deployed. For example, determine if the system needs to be
 |
| accessed remotely, or has requirements that suggest distribution across multiple nodes. Some sources of information to
 |
| consider are:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| users at geographical locations
 |
| </li>
 |
| <li>
 |
| organization of business data
 |
| </li>
 |
| <li>
 |
| service level requirements
 |
| </li>
 |
| <li>
 |
| constraints (such as requirements to interface with legacy systems)
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Validate that the deployment overview supports users (especially those users at remote locations if this is required)
 |
| performing typical&nbsp;usage scenarios&nbsp;while satisfying nonfunctional requirements and constraints. Validate that
 |
| the nodes and connections are adequate to support the interactions between components on different nodes, and between
 |
| components and their stored data.
 |
| </p>
 |
| <h4>
 |
| Identify key abstractions
 |
| </h4>
 |
| <p>
 |
| Requirements and analysis tasks usually uncover key concepts and behaviors that the system must be able to handle.
 |
| </p>
 |
| <p>
 |
| The concepts manifest in design as key abstractions.&nbsp;Key behaviors should correlate with the scenarios identifed
 |
| as part of the architecturally significant requirements and represent the important interactions between key
 |
| abstractions.
 |
| </p>
 |
| <p>
 |
| The <a class="elementLink" href="./../../../openup/workproducts/vision_2E71B03C.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a> and <a class="elementLink" href="./../../../openup/workproducts/glossary_5D300778.html" guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a> work products are
 |
| good sources for key abstractions. These abstractions are often easily identified because they represent things that
 |
| are significant to the business. For example, Customer and Account are typical key abstractions in the banking
 |
| business.
 |
| </p>
 |
| <p>
 |
| The abstractions that&nbsp;are identified at this point will also probably change and evolve during the course of the
 |
| project. The purpose of this step is not to identify&nbsp;the complete&nbsp;set of classes and relationships that will
 |
| survive throughout design.&nbsp;Rather, it is&nbsp;to identify the&nbsp;important&nbsp;concepts that the system must
 |
| handle. The value in calling them out early in the project is that everyone on the team understands the importance of
 |
| these&nbsp;concepts and develops&nbsp;coherant software to handle them consistently.
 |
| </p>
 |
| <p>
 |
| Don't spend too much time describing&nbsp;abstractions in detail at this initial stage, because there is a risk that
 |
| spending too much time will result in identifying classes and relationships that the solution does not actually need.
 |
| When&nbsp;identifying&nbsp;key abstractions, it can be useful to also define any obvious relationships that exist
 |
| between them.&nbsp;These can be captured in a table or&nbsp;in diagrams (in a tool or whiteboard), and create a short
 |
| description for each abstraction.&nbsp;In general, it is not worth agonizing over defining a highly detailed set of
 |
| relationships at this early stage in design. The relationships will become more concrete and detailed later and
 |
| will&nbsp;probably modify&nbsp;these early&nbsp;assumptions.
 |
| </p>
 |
| <h4>
 |
| Identify&nbsp;architecture mechanisms
 |
| </h4>
 |
| <p>
 |
| See&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/concepts/arch_mech_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>.
 |
| </p>
 |
| <h4>
 |
| Capture architectural decisions
 |
| </h4>
 |
| <p>
 |
| It is often useful to record key architectural decisions and working assumptions on an architectural overview diagram
 |
| to make it easier to communicate the architecture to the project team and stakeholders.&nbsp;This information should be
 |
| part of the description of the architecture, but it can vary in format to suit the needs of the project.&nbsp;For
 |
| example, on an agile and low-ceremony project the overview diagram can be an informal picture story board or a graph
 |
| with icons on either a whiteboard or a drawing tool. The illustration needs to show the nature of the proposed
 |
| solution, convey the governing ideas, and represent the major building blocks.
 |
| </p>
 |
| <p>
 |
| Architecture decisions should be captured in the <a class="elementLinkWithType" href="./../../../openup/workproducts/architecture_notebook_9BB92433.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture Notebook</a>.
 |
| </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. See <a class="elementLink" href="./../../../openup/guidances/guidelines/architectural_view_FF6EDA37.html" guid="_T9nygClEEduLGM8dfVsrKg">Architectural View</a>&nbsp;for more information.<br />
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
