| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="_lbGQwMM3EdmSIPI87WLu3g" name="layering,_0gpkAMlgEdmt3adZL5Dmdw" guid="_lbGQwMM3EdmSIPI87WLu3g" changeDate="2007-02-26T12:37:43.312+0000" version="1.0.0"> |
| <mainDescription><p> |
| Layering logically partitions the subsystems into a number of sets, with certain rules regarding how relationships can |
| be formed between the layers. Layering provides a way to restrict inter-subsystem dependencies, with the result that |
| the system is more loosely coupled and, therefore, 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 sufficient. For a complex system, five to seven |
| layers are usually sufficient. For any degree of complexity, more than 10 layers should be viewed with suspicion |
| that increases with the number of layers. The table that follows gives you a few guidelines. |
| </li> |
| </ul> |
| <p align="center"> |
| <strong>Guideline for number of layers according to number of classes</strong> |
| </p> |
| <div align="center"> |
| <table |
| style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid" |
| cellspacing="0" bordercolordark="#808080" cellpadding="4" width="58%" bordercolorlight="#808080" border="1"> |
| <tbody> |
| <tr> |
| <th width="40%"> |
| <p align="center" scope="col"> |
| <b>Number of Classes</b> |
| </p> |
| </th> |
| <th width="60%"> |
| <p align="center" scope="col"> |
| <b>Number of Layers</b> |
| </p> |
| </th> |
| </tr> |
| <tr> |
| <td width="40%"> |
| <p align="center"> |
| 0 - 10 |
| </p> |
| </td> |
| <td width="60%"> |
| <blockquote> |
| <blockquote> |
| <p> |
| No layering needed |
| </p> |
| </blockquote> |
| </blockquote> |
| </td> |
| </tr> |
| <tr> |
| <td width="40%"> |
| <p align="center"> |
| 10 - 50 |
| </p> |
| </td> |
| <td width="60%"> |
| <blockquote> |
| <blockquote> |
| <p> |
| 2 layers |
| </p> |
| </blockquote> |
| </blockquote> |
| </td> |
| </tr> |
| <tr> |
| <td width="40%"> |
| <p align="center"> |
| 25 - 150 |
| </p> |
| </td> |
| <td width="60%"> |
| <blockquote> |
| <blockquote> |
| <p> |
| 3 layers |
| </p> |
| </blockquote> |
| </blockquote> |
| </td> |
| </tr> |
| <tr> |
| <td width="40%"> |
| <p align="center"> |
| 100 - 1000 |
| </p> |
| </td> |
| <td width="60%"> |
| <blockquote> |
| <blockquote> |
| <p> |
| 4 layers |
| </p> |
| </blockquote> |
| </blockquote> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| </div> |
| <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> |
| Exceptions include cases where subsystems need direct access to lower-layer services. 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. |
| </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 lines). This partitioning often |
| occurs early in the design because 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 often |
| disappears 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></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |