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