| <?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.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-awaQ_2dwhGyKRoVKQ-esPQ" |
| name="finding_analysis_classes,_uF-QYEAhEdq_UJTvM1DM2Q" guid="-awaQ_2dwhGyKRoVKQ-esPQ" |
| changeDate="2007-04-24T14:03:24.760-0700" version="1.0.0"> |
| <mainDescription><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&nbsp;will&nbsp;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&nbsp;pattern example </h4>
 |
| <p>
 |
| &nbsp;<img height="233" alt="" src="./resources/EBCDiagram.JPG" width="493" />
 |
| </p>
 |
| <h1> Entity elements </h1>
 |
| <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&nbsp;design 
 |
| elements&nbsp;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.&nbsp; A design element for&nbsp;this 
 |
| entity would include data about the customer, behavior to manage the data, behavior 
 |
| to validate customer information&nbsp;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&nbsp;rate the customer based 
 |
| on some algorithm&nbsp;(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,&nbsp;such as&nbsp;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&nbsp;context.)</p>
 |
| <h1> Control elements </h1>
 |
| <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&nbsp;of a control element&nbsp;for 
 |
| a customer service application. This design element would&nbsp;be responsive 
 |
| to certain frontend boundary elements and would collaborate with other entities, 
 |
| control&nbsp;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&nbsp;scenario, with behavior to make sure that the 
 |
| design can support the flow of events. A&nbsp;subsequent pass might find controllers 
 |
| to manage reusable collaborations of low-level elements that will map to a specific 
 |
| code&nbsp;unit to be written. </p>
 |
| <h1> Boundary elements </h1>
 |
| <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 "frontend" elements that accept 
 |
| input from outside of the area under design, and other elements will be "backend," 
 |
| 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 frontend MarketingCampaignForm and a backend 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&nbsp;small communities made up of collaborating&nbsp;elements&nbsp;of 
 |
| all three stereotypes. </p>
 |
| <h1> Walking through the scenario </h1>
 |
| <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.&nbsp; 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&nbsp;identifies 
 |
| the necessary relationships. There are certain appropriate&nbsp;relations between 
 |
| the participating elements.&nbsp;An element can communicate with other elements 
 |
| of the same kind. Control&nbsp;elements can communicate with each of the other 
 |
| two kinds, but entities and boundary elements should not communicate directly.&nbsp; 
 |
| </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> <center>
 |
| </center></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> <center>
 |
| </center></td>
 |
| <td> <center>
 |
| X </center></td>
 |
| </tr>
 |
| <tr> 
 |
| <th scope="row"> Boundary </th>
 |
| <td> <center>
 |
| </center></td>
 |
| <td> <center>
 |
| </center></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&nbsp;applying this pattern, you can put a robust design together that identifies 
 |
| the elements, behavior, and relationships&nbsp;necessary to support&nbsp;a scenario.&nbsp; 
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
