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