OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/guidelines/analyze_arch_reqs.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\guidelines\analyze_arch_reqs.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: analyze_arch_reqs.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_42UD4A3tEduibvKwrGxWxA CRC: 1105243094 -->Analyze the Architectural Requirements<!-- END:presentationName,_42UD4A3tEduibvKwrGxWxA -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_42UD4A3tEduibvKwrGxWxA CRC: 1722712687 -->This guideline provides additional information to support the analysis of architecturally significant requirements and the creation of an outline architecture.<!-- END:briefDescription,_42UD4A3tEduibvKwrGxWxA -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-YeVRerdEixh4HgHOuw2KRQ CRC: 3600285818 --><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><!-- END:mainDescription,-YeVRerdEixh4HgHOuw2KRQ -->
 </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\guidelines\analyze_arch_reqs.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: analyze_arch_reqs.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_42UD4A3tEduibvKwrGxWxA CRC: 1105243094 -->Analyze the Architectural Requirements<!-- END:presentationName,_42UD4A3tEduibvKwrGxWxA -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_42UD4A3tEduibvKwrGxWxA CRC: 1722712687 -->This guideline provides additional information to support the analysis of architecturally significant requirements and the creation of an outline architecture.<!-- END:briefDescription,_42UD4A3tEduibvKwrGxWxA -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-YeVRerdEixh4HgHOuw2KRQ CRC: 3600285818 --><h4>
	Identify architectural goals
	</h4>
	<p>
	Architectural goals provide the motivation and rationale for decisions. These goals are often driven
	by the software requirements, particularly in <a class="elementLink"
	href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
	guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>, because they are not always obvious from 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 frequently is the system 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 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 the existing database administration skills, rather than introducing a new one.
	</p>
	<p>
	These architectural constraints, combined with the requirements, help you define an appropriate 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 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  is one of the most commonly used approaches for structuring and decomposing systems. Each
	layer groups similar classes or components, which communicate insofar as possible only with adjacent layers.  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 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 usage scenarios 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. 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 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 the complete set of classes and relationships that will
	survive throughout design. Rather, it is to identify the important 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 concepts and develops coherant software to handle them consistently.
	</p>
	<p>
	Don't spend too much time describing 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 identifying key abstractions, it can be useful to also define any obvious relationships that exist
	between them. These can be captured in a table or in diagrams (in a tool or whiteboard), and create a short
	description for each abstraction. 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 probably modify these early assumptions.
	</p>
	<h4>
	Identify architecture mechanisms
	</h4>
	<p>
	See <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. This information should be
	part of the description of the architecture, but it can vary in format to suit the needs of the project. 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 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> for more information.<br />
	</p><!-- END:mainDescription,-YeVRerdEixh4HgHOuw2KRQ -->
	</body>
	</html>