<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_lbGQwMM3EdmSIPI87WLu3g" name="layering,_0gpkAMlgEdmt3adZL5Dmdw" guid="_lbGQwMM3EdmSIPI87WLu3g" changeDate="2008-02-11T10:31:51.000-0800" version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    Layering&amp;nbsp; is&amp;nbsp;one of the most&amp;nbsp;commonly used&amp;nbsp;approaches for structuring and decomposing systems.&#xD;
    Layering logically partitions the system into sets of components 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 elements into layers follows a few patterns:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Visibility&lt;/b>&lt;strong>:&lt;/strong> Elements may depend only on components 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 elements tend to be placed in the lower layers. 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 the visibility criteria mentioned above can cause architectural&#xD;
    degradation 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 components 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&#xD;
    class=&quot;elementlinkwithusertext&quot;&#xD;
    href=&quot;./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#BUS96&quot;&#xD;
    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> Elements 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> Elements may be organized to partition responsibilities among different groups&#xD;
    within the development organization. Typically, this occurs in the middle and lower layers of the system, and reflects&#xD;
    the need for specialization in skills during the development and support of an infrastructure based on complex&#xD;
    technology. Examples of such technologies include network and distribution management, database management,&#xD;
    communication management, and process control, among others. Partitioning along competence lines may also occur in&#xD;
    upper layers, where special competency in the problem domain is required to understand and support key business&#xD;
    functionality. Examples include telecommunication call management, securities trading, insurance claims processing, and&#xD;
    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 components that are developed and delivered independently from the&#xD;
    mandatory functionality of the system.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
