| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-YeVRerdEixh4HgHOuw2KRQ" name="analyze_arch_reqs,_42UD4A3tEduibvKwrGxWxA" guid="-YeVRerdEixh4HgHOuw2KRQ" changeDate="2007-02-26T11:12:32.578+0000" 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_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" |
| guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>, because they are not always&nbsp;obvious from&nbsp;the use |
| cases alone [<a class="elementLinkWithUserText" |
| href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.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 architectural constraints |
| </h4> |
| <p> |
| Ginformation about the existing&nbsp;environment and identify any constraints in the solution. This will ease |
| integration with the environment; and m ay 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_basic/guidances/guidelines/layering,_0gpkAMlgEdmt3adZL5Dmdw.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 that the system must be able to handle. These concepts |
| manifest in design as key abstractions.&nbsp;The <a class="elementLink" |
| href="./../../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" |
| guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a> and <a class="elementLink" |
| href="./../../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.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 arly 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_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.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_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" |
| guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture</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_basic/guidances/guidelines/architectural_view,_T9nygClEEduLGM8dfVsrKg.html" |
| guid="_T9nygClEEduLGM8dfVsrKg">Architectural View</a>&nbsp;for more information.<br /> |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |