| <?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;entity_control_boundary_pattern.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: entity_control_boundary_pattern.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_uF-QYEAhEdq_UJTvM1DM2Q CRC: 3808310074 -->Entity-Control-Boundary Pattern<!-- END:presentationName,_uF-QYEAhEdq_UJTvM1DM2Q --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_uF-QYEAhEdq_UJTvM1DM2Q CRC: 1547844432 -->This guideline describes a rapid way to build a design that is robust enough to realize the functional requirements.<!-- END:briefDescription,_uF-QYEAhEdq_UJTvM1DM2Q --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-awaQ_2dwhGyKRoVKQ-esPQ CRC: 3490029770 --><p> |
| When identifying the elements for a scenario of system behavior, you can align each participating element with one of |
| three key perspectives: <b>Entity</b>, <b>Control</b>, or <b>Boundary</b>. Although specifics of languages, frameworks, |
| and heuristics of quality design will drive the final design, a first cut that covers required system behavior can |
| always be assembled with elements of these three perspectives. |
| </p> |
| <p> |
| This pattern is similar to the Model View Controller pattern (described here [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] |
| and here [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#WIKP-MVC" guid="_9ToeIB83Edqsvps02rpOOg">WIKP-MVC</a>], among other places), but the Entity Control Boundary (ECB) pattern is not |
| solely appropriate for dealing with user interfaces, and it gives the controller a slightly different role to play. |
| </p> |
| <h4 align="left"> |
| ECB pattern example |
| </h4> |
| <p> |
| <img alt="" src="./resources/ebc_diagram.JPG" /> |
| </p> |
| <h3> |
| Entity elements |
| </h3> |
| <p> |
| An entity is a long-lived, passive element that is responsible for some meaningful chunk of information. This is not to |
| say that entities are "data," while other design elements are "function." Entities perform behavior organized around |
| some cohesive amount of data. |
| </p> |
| <p> |
| An example of an entity for a customer service application is a Customer entity that manages all information about a |
| customer. A design element for this entity would include data about the customer, behavior to manage the data, |
| behavior to validate customer information and to perform other business calculations, such as "Is this customer |
| allowed to purchase product X?" |
| </p> |
| <p> |
| The identification of the entities as part of this pattern can be done many times at different levels of abstraction |
| from the code, at different levels of granularity in size, and from the perspectives of different contexts. For |
| example, you could do an analysis pass on a scenario of creating a marketing campaign and identify the customer element |
| with various customer data elements, such as name and address, plus various required behaviors, such as the management |
| of the name and address data and the ability to rate the customer based on some algorithm (such an application of this |
| pattern would be abstract from code, coarse-grained, and have no specific context). Later, you could do a pass on the |
| same scenario applying an architectural mechanism for database access that breaks the address out as its own element, |
| moves the responsibility for storing and retrieving customers to a new control element, and identifies specific |
| database decisions, such as the use of primary keys in the entities. (Such an application of this pattern would be |
| closer to the code, finer-grained, and aligned with a database context.) |
| </p> |
| <h3> |
| Control elements |
| </h3> |
| <p> |
| A control element manages the flow of interaction of the scenario. A control element could manage the end-to-end |
| behavior of a scenario. or it could manage the interactions between a subset of the elements. Behavior and business |
| rules relating to the information relevant to the scenario should be assigned to the entities; the control elements are |
| responsible only for the flow of the scenario. |
| </p> |
| <p> |
| CreateMarketingCapmpaign is an example of a control element for a customer service application. This design element |
| would be responsive to certain frontend boundary elements and would collaborate with other entities, |
| control elements, and backend boundary elements to support the creation of a marketing campaign. |
| </p> |
| <p> |
| As with the entity example here, there might be many passes over the identification of control elements. A first pass |
| might be an analysis pass that identifies one control element for a scenario, with behavior to make sure that the |
| design can support the flow of events. A subsequent pass might find controllers to manage reusable collaborations |
| of low-level elements that will map to a specific code unit to be written. |
| </p> |
| <h3> |
| Boundary elements |
| </h3> |
| <p> |
| A boundary element lies on the periphery of a system or subsystem, but within it. For any scenario being considered |
| either across the whole system or within some subsystem, some boundary elements will be "front end" elements that |
| accept input from outside of the area under design, and other elements will be "back end," managing communication to |
| supporting elements outside of the system or subsystem. |
| </p> |
| <p> |
| Two examples of boundary elements for a customer service application might be a front end MarketingCampaignForm and a |
| back end BugdetSystem element. The MarketingCampaignForm would manage the exchange of information between a user and |
| the system, and the BugdetSystem would manage the exchange of information between the system and an external system |
| that manages budgets. |
| </p> |
| <p> |
| An analysis pass could identify one boundary element for each external relevant to a scenario. Subsequently, these |
| could be broken down into multiple boundary elements or small communities made up of collaborating elements of all |
| three stereotypes. |
| </p> |
| <h3> |
| Walking through the scenario |
| </h3> |
| <p> |
| You can walk through a scenario initiated by something outside of the boundaries of the system or subsystem being |
| designed and distribute the responsibility to perform behavior supporting the scenario to the elements identified of |
| each type. The appropriate design element responsible for each action in the scenario will be as described in the |
| definition of each of the element types described here previously. |
| </p> |
| <p> |
| In addition to identifying the behavior necessary to perform the scenario, the initiation of this behavior from design |
| element to design element identifies the necessary relationships. There are certain appropriate relations between the |
| participating elements. An element can communicate with other elements of the same kind. Control elements can |
| communicate with each of the other two kinds, but entities and boundary elements should not communicate directly. |
| </p> |
| <p> |
| This table shows appropriate links between design elements. |
| </p> |
| <table cellspacing="2" cellpadding="2" width="400" summary="Appropriate Links" border="1"> |
| <tbody> |
| <tr> |
| <td> |
| </td> |
| <th scope="col"> |
| <center> |
| Entity |
| </center> |
| </th> |
| <th scope="col"> |
| <center> |
| Boundary |
| </center> |
| </th> |
| <th scope="col"> |
| <center> |
| Control |
| </center> |
| </th> |
| </tr> |
| <tr> |
| <th scope="row"> |
| Entity |
| </th> |
| <td> |
| <center> |
| X |
| </center> |
| </td> |
| <td> |
| </td> |
| <td> |
| <center> |
| X |
| </center> |
| </td> |
| </tr> |
| <tr> |
| <th scope="row"> |
| Boundary |
| </th> |
| <td> |
| </td> |
| <td> |
| </td> |
| <td> |
| <center> |
| X |
| </center> |
| </td> |
| </tr> |
| <tr> |
| <th scope="row"> |
| Control |
| </th> |
| <td> |
| <center> |
| X |
| </center> |
| </td> |
| <td> |
| <center> |
| X |
| </center> |
| </td> |
| <td> |
| <center> |
| X |
| </center> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <p> |
| By applying this pattern, you can put a robust design together that identifies the elements, behavior, and |
| relationships necessary to support a scenario. |
| </p><!-- END:mainDescription,-awaQ_2dwhGyKRoVKQ-esPQ --> |
| </body> |
| </html> |