OpenUP/OpenUP_baseline_EN/exported_HTML_1_0/openup/guidances/guidelines/layering.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;layering.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: layering.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_0gpkAMlgEdmt3adZL5Dmdw CRC: 3853959620 -->Layering<!-- END:presentationName,_0gpkAMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_0gpkAMlgEdmt3adZL5Dmdw CRC: 3823084377 -->Guidance on the possible ways for partitioning the system.<!-- END:briefDescription,_0gpkAMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,_lbGQwMM3EdmSIPI87WLu3g CRC: 1894082126 --><p>
     Layering logically partitions the system into sets of subsystems with certain rules regarding how relationships can be
     formed between them. Layering provides a way to restrict inter-subsystem dependencies, with the result that the system
     is more loosely coupled and more easily maintained.
 </p>
 <p>
     Consider the number and purpose of the layers carefully. Do not over-complicate the solution by defining more layers
     than are needed to meet the needs of the solution. More layers can always be added in the future to meet new
     requirements. Removing layers is not always as easy and may introduce risks into the project.
 </p>
 <p>
     The criteria for grouping subsystems follow a few patterns:
 </p>
 <ul>
     <li>
         <b>Visibility</b><strong>:</strong> Subsystems may depend only on subsystems in the same layer and the next-lower
         layer.
     </li>
     <li>
         <b>Volatility</b><strong>:</strong>
         <ul>
             <li>
                 <b>In the highest layers</b>, put elements that vary when user requirements change.
             </li>
             <li>
                 <b>In the lowest layers</b>, put elements that vary when the implementation platform changes (hardware,
                 language, operating system, database, and so forth).
             </li>
             <li>
                 <strong>Sandwiched in the middle</strong>, put elements that are generally applicable across wide ranges of
                 systems and implementation environments.
             </li>
             <li>
                 <strong>Add layers</strong> when additional partitions within these broad categories help to organize the
                 model.
             </li>
         </ul>
     </li>
     <li>
         <b>Generality</b><strong>:</strong> Abstract model elements tend to be placed lower in the model. If not
         implementation-specific, they tend to gravitate toward the middle layers.
     </li>
     <li>
         <b>Number of layers.</b> For a small system, three layers are typically sufficient.&nbsp;A three-layer architecture
         of&nbsp;Presentation, Business, and Data layers is very common in information systems.&nbsp; For a complex system,
         five to seven layers could be appropriate. For any degree of complexity, more than 10 layers should be viewed with
         suspicion that increases with the number of layers.
     </li>
 </ul>
 <p>
     Failure to restrict dependencies according to Visibility criteria mentioned above can cause architectural degradation
     and make the system difficult to extend and maintain.
 </p>
 <p>
     Allowable exceptions to the visibility rule include cases where subsystems need direct access to lower-layer services
     beyond the next-lower layer. Make a decision about how to handle primitive services that are needed throughout the
     system, such as printing, sending messages, and so forth. There is little value in restricting messages to lower layers
     if the solution is to effectively implement call pass-throughs in the intermediate layers.&nbsp;&nbsp;This usage of a
     less strict rule on dependencies down through the layers is sometimes called a Relaxed Layered Architecture (<a class="elementlinkwithusertext" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a>).
 </p>
 <h4>
     <a id="PartitioningPatterns" name="PartitioningPatterns">Partitioning patterns</a>
 </h4>
 <p>
     Within the top layers of the system, additional partitioning may help organize the model. The following guidelines for
     partitioning present different issues to consider:
 </p>
 <p>
     <b>User organization</b><strong>:</strong> Subsystems may be organized along lines that mirror the organization of
     functionality in the business organization (partitioning occurs along departmental or user role lines). This
     partitioning often occurs early in the design&nbsp;due to&nbsp;an existing enterprise model that is strongly
     partitioned according to the structure of the organization. This pattern usually affects only the top few layers of
     application-specific services and can often disappear as the design evolves.
 </p>
 <ul>
     <li>
         <p>
             Partitioning along user-organization lines can be a good starting point for the model.
         </p>
     </li>
     <li>
         <p>
             The structure of the user organization is not stable over a long period of time because business
             reorganizations occur; therefore, it is not a good long-term basis for system partitioning. The internal
             organization of the system should enable the system to evolve and be maintained independently of the
             organization of the business that it supports.
         </p>
     </li>
 </ul>
 <p>
     <b>Areas of competence and skills:</b> Subsystems may be organized to partition responsibilities for parts of the model
     among different groups within the development organization. Typically, this occurs in the middle and lower layers of
     the system, and reflects the need for specialization in skills during the development and support of an infrastructure
     based on complex technology. Examples of such technologies include network and distribution management, database
     management, communication management, and process control, among others. Partitioning along competence lines may also
     occur in upper layers, where special competency in the problem domain is required to understand and support key
     business functionality. Examples include telecommunication call management, securities trading, insurance claims
     processing, and air traffic control, to name a few.
 </p>
 <p>
     <b>System distribution:</b> Within any of the layers of the system, the layers may be further partitioned horizontally,
     so to speak, to reflect the distribution of functionality.
 </p>
 <ul>
     <li>
         <p>
             Partitioning to reflect distribution of functionality can help you visualize the network communication that
             will occur as the system runs.
         </p>
     </li>
     <li>
         <p>
             Partitioning to reflect distribution can also, however, make the system more difficult to change if the
             deployment model changes significantly.
         </p>
     </li>
 </ul>
 <p>
     <b>Secrecy areas</b><strong>:</strong> Some applications, especially those requiring special security clearance to
     develop or support, require additional partitioning according to security access privileges. Software that controls
     access to secrecy areas must be developed and maintained by personnel with appropriate clearance. If the number of
     people with this background on the project is limited, the functionality requiring special clearance must be
     partitioned into subsystems that will be developed independently from other subsystems, with the interfaces to the
     secrecy areas the only visible aspect of these subsystems.
 </p>
 <p>
     <b>Variability areas:</b> Functionality that is likely to be optional, and therefore delivered only in some variants of
     the system, should be organized into independent subsystems that are developed and delivered independently from the
     mandatory functionality of the system.
 </p><!-- END:mainDescription,_lbGQwMM3EdmSIPI87WLu3g -->
 </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;layering.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: layering.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_0gpkAMlgEdmt3adZL5Dmdw CRC: 3853959620 -->Layering<!-- END:presentationName,_0gpkAMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_0gpkAMlgEdmt3adZL5Dmdw CRC: 3823084377 -->Guidance on the possible ways for partitioning the system.<!-- END:briefDescription,_0gpkAMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,_lbGQwMM3EdmSIPI87WLu3g CRC: 1894082126 --><p>
	Layering logically partitions the system into sets of subsystems with certain rules regarding how relationships can be
	formed between them. Layering provides a way to restrict inter-subsystem dependencies, with the result that the system
	is more loosely coupled and more easily maintained.
	</p>
	<p>
	Consider the number and purpose of the layers carefully. Do not over-complicate the solution by defining more layers
	than are needed to meet the needs of the solution. More layers can always be added in the future to meet new
	requirements. Removing layers is not always as easy and may introduce risks into the project.
	</p>
	<p>
	The criteria for grouping subsystems follow a few patterns:
	</p>
	<ul>
	<li>
	<b>Visibility</b><strong>:</strong> Subsystems may depend only on subsystems in the same layer and the next-lower
	layer.
	</li>
	<li>
	<b>Volatility</b><strong>:</strong>
	<ul>
	<li>
	<b>In the highest layers</b>, put elements that vary when user requirements change.
	</li>
	<li>
	<b>In the lowest layers</b>, put elements that vary when the implementation platform changes (hardware,
	language, operating system, database, and so forth).
	</li>
	<li>
	<strong>Sandwiched in the middle</strong>, put elements that are generally applicable across wide ranges of
	systems and implementation environments.
	</li>
	<li>
	<strong>Add layers</strong> when additional partitions within these broad categories help to organize the
	model.
	</li>
	</ul>
	</li>
	<li>
	<b>Generality</b><strong>:</strong> Abstract model elements tend to be placed lower in the model. If not
	implementation-specific, they tend to gravitate toward the middle layers.
	</li>
	<li>
	<b>Number of layers.</b> For a small system, three layers are typically sufficient. A three-layer architecture
	of Presentation, Business, and Data layers is very common in information systems.  For a complex system,
	five to seven layers could be appropriate. For any degree of complexity, more than 10 layers should be viewed with
	suspicion that increases with the number of layers.
	</li>
	</ul>
	<p>
	Failure to restrict dependencies according to Visibility criteria mentioned above can cause architectural degradation
	and make the system difficult to extend and maintain.
	</p>
	<p>
	Allowable exceptions to the visibility rule include cases where subsystems need direct access to lower-layer services
	beyond the next-lower layer. Make a decision about how to handle primitive services that are needed throughout the
	system, such as printing, sending messages, and so forth. There is little value in restricting messages to lower layers
	if the solution is to effectively implement call pass-throughs in the intermediate layers.  This usage of a
	less strict rule on dependencies down through the layers is sometimes called a Relaxed Layered Architecture (<a class="elementlinkwithusertext" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a>).
	</p>
	<h4>
	<a id="PartitioningPatterns" name="PartitioningPatterns">Partitioning patterns</a>
	</h4>
	<p>
	Within the top layers of the system, additional partitioning may help organize the model. The following guidelines for
	partitioning present different issues to consider:
	</p>
	<p>
	<b>User organization</b><strong>:</strong> Subsystems may be organized along lines that mirror the organization of
	functionality in the business organization (partitioning occurs along departmental or user role lines). This
	partitioning often occurs early in the design due to an existing enterprise model that is strongly
	partitioned according to the structure of the organization. This pattern usually affects only the top few layers of
	application-specific services and can often disappear as the design evolves.
	</p>
	<ul>
	<li>
	<p>
	Partitioning along user-organization lines can be a good starting point for the model.
	</p>
	</li>
	<li>
	<p>
	The structure of the user organization is not stable over a long period of time because business
	reorganizations occur; therefore, it is not a good long-term basis for system partitioning. The internal
	organization of the system should enable the system to evolve and be maintained independently of the
	organization of the business that it supports.
	</p>
	</li>
	</ul>
	<p>
	<b>Areas of competence and skills:</b> Subsystems may be organized to partition responsibilities for parts of the model
	among different groups within the development organization. Typically, this occurs in the middle and lower layers of
	the system, and reflects the need for specialization in skills during the development and support of an infrastructure
	based on complex technology. Examples of such technologies include network and distribution management, database
	management, communication management, and process control, among others. Partitioning along competence lines may also
	occur in upper layers, where special competency in the problem domain is required to understand and support key
	business functionality. Examples include telecommunication call management, securities trading, insurance claims
	processing, and air traffic control, to name a few.
	</p>
	<p>
	<b>System distribution:</b> Within any of the layers of the system, the layers may be further partitioned horizontally,
	so to speak, to reflect the distribution of functionality.
	</p>
	<ul>
	<li>
	<p>
	Partitioning to reflect distribution of functionality can help you visualize the network communication that
	will occur as the system runs.
	</p>
	</li>
	<li>
	<p>
	Partitioning to reflect distribution can also, however, make the system more difficult to change if the
	deployment model changes significantly.
	</p>
	</li>
	</ul>
	<p>
	<b>Secrecy areas</b><strong>:</strong> Some applications, especially those requiring special security clearance to
	develop or support, require additional partitioning according to security access privileges. Software that controls
	access to secrecy areas must be developed and maintained by personnel with appropriate clearance. If the number of
	people with this background on the project is limited, the functionality requiring special clearance must be
	partitioned into subsystems that will be developed independently from other subsystems, with the interfaces to the
	secrecy areas the only visible aspect of these subsystems.
	</p>
	<p>
	<b>Variability areas:</b> Functionality that is likely to be optional, and therefore delivered only in some variants of
	the system, should be organized into independent subsystems that are developed and delivered independently from the
	mandatory functionality of the system.
	</p><!-- END:mainDescription,_lbGQwMM3EdmSIPI87WLu3g -->
	</body>
	</html>