OpenUP/OpenUP_baseline_EN/exported_HTML_1_0/openup/guidances/guidelines/architectural_mechanisms.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&amp;#92;guidances&amp;#92;guidelines&amp;#92;&amp;#92;architectural_mechanisms.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: architectural_mechanisms.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_J6BKgNvIEduv2KOT-Teh6w CRC: 2367463022 -->Architectural Mechanisms<!-- END:presentationName,_J6BKgNvIEduv2KOT-Teh6w -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_J6BKgNvIEduv2KOT-Teh6w CRC: 2090701943 -->This guideline describes how to evolve architectural mechanisms from definition to implementation.<!-- END:briefDescription,_J6BKgNvIEduv2KOT-Teh6w -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-bP4wJKW0CrR9pL0yz20r3Q CRC: 3388224263 --><p>
     Architectural mechanisms represent key technical concepts that&nbsp;will be standardized across the solution. They are
     refined&nbsp;during the project through three states, represented by the three categories of Architectural Mechanisms:
 </p>
 <ul>
     <li>
         <strong>Analysis Mechanisms</strong>, which give the mechanism a name, brief description and some basic
         attributes&nbsp;derived from&nbsp;the project requirements
     </li>
     <li>
         <strong>Design Mechanisms</strong>, which are more concrete and assume some details of the implementation
         environment
     </li>
     <li>
         <strong>Implementation Mechanisms</strong>, which specify the&nbsp;exact implementation of&nbsp;each mechanism
     </li>
 </ul>
 <p>
     When the <a class="elementLink" href="./../../../openup/roles/architect_E7A12309.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> initially identifies an&nbsp;architectural mechanism they are putting down
     a marker that says to the team, "We are going to handle this aspect of the system in a standard way. We'll figure out
     the details later." As the project proceeds, the architectural mechanisms are gradually refined until they become part
     of the software.
 </p>
 <h4>
     Analysis Mechanisms
 </h4>
 <p>
     Analysis mechanisms&nbsp;are the initial state for an architectural mechanism. They are identified early in the project
     and represent&nbsp;bookmarks for future software development. They allow the&nbsp;team to focus on understanding the
     requirements without getting distracted by the specifics of a complex implementation. Analysis mechanisms are
     discovered by surveying the requirements and looking for recurrent technical concepts.&nbsp;Security, persistence and
     legacy interface are some examples of these. In effect, the <a class="elementLink" href="./../../../openup/roles/architect_E7A12309.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> is collating the
     requirements that describe&nbsp;architecturally significant topics bringing them together in a single list. This makes
     them easier to manage.
 </p>
 <p>
     Analysis mechanisms are described in simple terms:
 </p>
 <ul>
     <li>
         <strong>Name:</strong> Identifies the mechanism.
     </li>
     <li>
         <strong>Basic attributes:</strong> Define the requirements of the mechanism. These attributes can vary depending
         upon the mechanism being analyzed. Refer to <a class="elementLinkWithType" href="./../../../openup/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html" guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>&nbsp;for more guidance.
     </li>
 </ul>
 <p>
     Once the list of analysis mechanisms has been defined it can be prioritized and the mechanisms refined in line
     with&nbsp;iteration&nbsp;objectives. It is not necessary to develop the entire set of architecture mechanisms into
     working software in a single pass. It is often more sensible to develop only those mechanisms required to support the
     functionality to be delivered in the current iteration.
 </p>
 <h4>
     Design Mechanisms
 </h4>
 <p>
     Design mechanisms&nbsp;represent decisions about the concrete technologies that are going to be used to&nbsp;develop
     architectural mechanisms. For example, the decision to use an RDBMS for persistence. It's often no more complicated
     than that (though of course, the effort involved in making the decision can sometimes be quite complex).
 </p>
 <p>
     The decision on when to refine an architectural mechanism from an analysis state to a design state is largely
     arbitrary. Often there will be constraints on the project that&nbsp;force the decision on some of these issues. For
     example, there may be a corporate standard for databases which mean that the decision&nbsp;for the&nbsp;persistence
     mechanism can be made on day 1 of the project.
 </p>
 <p>
     On other occasions the decision may point to products that the project team has not yet acquired.&nbsp;If so,&nbsp;the
     decision needs to be made in time to enable the required products to be made available to the team.
 </p>
 <p>
     It can often be useful to develop some prototype code to prove that these decisions are sound. The <a class="elementLink" href="./../../../openup/roles/architect_E7A12309.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> should
     be confident that the technologies being selected are able to fulfill the requirements. The attributes captured against
     the corresponding analysis mechanisms should be used as criteria to prove the validity of the decisions.
 </p>
 <h4>
     Implementation Mechanism
 </h4>
 <p>
     An implementation mechanism&nbsp;specifies the actual implementation for the architectural mechanism (hence the
     name).&nbsp;It can be modeled as a design pattern or presented as&nbsp;example code.
 </p>
 <p>
     The best time to&nbsp;produce the&nbsp;implementation mechanism is usually when the first piece of functionality that
     needs it is scheduled for development. The <a class="elementLink" href="./../../../openup/roles/architect_E7A12309.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> and <a class="elementLink" href="./../../../openup/roles/developer_C633AB7.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Developer</a> work together to develop this.
 </p><!-- END:mainDescription,-bP4wJKW0CrR9pL0yz20r3Q -->
 </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&#92;guidances&#92;guidelines&#92;&#92;architectural_mechanisms.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: architectural_mechanisms.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_J6BKgNvIEduv2KOT-Teh6w CRC: 2367463022 -->Architectural Mechanisms<!-- END:presentationName,_J6BKgNvIEduv2KOT-Teh6w -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_J6BKgNvIEduv2KOT-Teh6w CRC: 2090701943 -->This guideline describes how to evolve architectural mechanisms from definition to implementation.<!-- END:briefDescription,_J6BKgNvIEduv2KOT-Teh6w -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-bP4wJKW0CrR9pL0yz20r3Q CRC: 3388224263 --><p>
	Architectural mechanisms represent key technical concepts that will be standardized across the solution. They are
	refined during the project through three states, represented by the three categories of Architectural Mechanisms:
	</p>
	<ul>
	<li>
	<strong>Analysis Mechanisms</strong>, which give the mechanism a name, brief description and some basic
	attributes derived from the project requirements
	</li>
	<li>
	<strong>Design Mechanisms</strong>, which are more concrete and assume some details of the implementation
	environment
	</li>
	<li>
	<strong>Implementation Mechanisms</strong>, which specify the exact implementation of each mechanism
	</li>
	</ul>
	<p>
	When the <a class="elementLink" href="./../../../openup/roles/architect_E7A12309.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> initially identifies an architectural mechanism they are putting down
	a marker that says to the team, "We are going to handle this aspect of the system in a standard way. We'll figure out
	the details later." As the project proceeds, the architectural mechanisms are gradually refined until they become part
	of the software.
	</p>
	<h4>
	Analysis Mechanisms
	</h4>
	<p>
	Analysis mechanisms are the initial state for an architectural mechanism. They are identified early in the project
	and represent bookmarks for future software development. They allow the team to focus on understanding the
	requirements without getting distracted by the specifics of a complex implementation. Analysis mechanisms are
	discovered by surveying the requirements and looking for recurrent technical concepts. Security, persistence and
	legacy interface are some examples of these. In effect, the <a class="elementLink" href="./../../../openup/roles/architect_E7A12309.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> is collating the
	requirements that describe architecturally significant topics bringing them together in a single list. This makes
	them easier to manage.
	</p>
	<p>
	Analysis mechanisms are described in simple terms:
	</p>
	<ul>
	<li>
	<strong>Name:</strong> Identifies the mechanism.
	</li>
	<li>
	<strong>Basic attributes:</strong> Define the requirements of the mechanism. These attributes can vary depending
	upon the mechanism being analyzed. Refer to <a class="elementLinkWithType" href="./../../../openup/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html" guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a> for more guidance.
	</li>
	</ul>
	<p>
	Once the list of analysis mechanisms has been defined it can be prioritized and the mechanisms refined in line
	with iteration objectives. It is not necessary to develop the entire set of architecture mechanisms into
	working software in a single pass. It is often more sensible to develop only those mechanisms required to support the
	functionality to be delivered in the current iteration.
	</p>
	<h4>
	Design Mechanisms
	</h4>
	<p>
	Design mechanisms represent decisions about the concrete technologies that are going to be used to develop
	architectural mechanisms. For example, the decision to use an RDBMS for persistence. It's often no more complicated
	than that (though of course, the effort involved in making the decision can sometimes be quite complex).
	</p>
	<p>
	The decision on when to refine an architectural mechanism from an analysis state to a design state is largely
	arbitrary. Often there will be constraints on the project that force the decision on some of these issues. For
	example, there may be a corporate standard for databases which mean that the decision for the persistence
	mechanism can be made on day 1 of the project.
	</p>
	<p>
	On other occasions the decision may point to products that the project team has not yet acquired. If so, the
	decision needs to be made in time to enable the required products to be made available to the team.
	</p>
	<p>
	It can often be useful to develop some prototype code to prove that these decisions are sound. The <a class="elementLink" href="./../../../openup/roles/architect_E7A12309.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> should
	be confident that the technologies being selected are able to fulfill the requirements. The attributes captured against
	the corresponding analysis mechanisms should be used as criteria to prove the validity of the decisions.
	</p>
	<h4>
	Implementation Mechanism
	</h4>
	<p>
	An implementation mechanism specifies the actual implementation for the architectural mechanism (hence the
	name). It can be modeled as a design pattern or presented as example code.
	</p>
	<p>
	The best time to produce the implementation mechanism is usually when the first piece of functionality that
	needs it is scheduled for development. The <a class="elementLink" href="./../../../openup/roles/architect_E7A12309.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> and <a class="elementLink" href="./../../../openup/roles/developer_C633AB7.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Developer</a> work together to develop this.
	</p><!-- END:mainDescription,-bP4wJKW0CrR9pL0yz20r3Q -->
	</body>
	</html>