| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-awaQ_2dwhGyKRoVKQ-esPQ" |
| name="finding_analysis_classes,_uF-QYEAhEdq_UJTvM1DM2Q" guid="-awaQ_2dwhGyKRoVKQ-esPQ" |
| changeDate="2007-07-18T07:10:37.552-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 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&nbsp;pattern example
 |
| </h4>
 |
| <p>
 |
| &nbsp;<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&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 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&nbsp;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&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 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>
 |
| <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></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
