| <?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><p>
 |
| Layering&nbsp; is&nbsp;one of the most&nbsp;commonly used&nbsp;approaches for structuring and decomposing systems.
 |
| Layering logically partitions the system into sets of components 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 elements into layers follows a few patterns:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <b>Visibility</b><strong>:</strong> Elements may depend only on components 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 elements tend to be placed in the lower layers. 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 the 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 components 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="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_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> Elements 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> Elements may be organized to partition responsibilities 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 components that are developed and delivered independently from the
 |
| mandatory functionality of the system.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
