OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/concepts/entity_control_boundary_pattern.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?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_basic\guidances\concepts\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: 2125714211 -->This concept introduces a pattern that provides a starting point for the distribution of responsibilities to a set of interacting design elements based on three key perspectives in a collaboration.<!-- END:briefDescription,_uF-QYEAhEdq_UJTvM1DM2Q -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-awaQ_2dwhGyKRoVKQ-esPQ CRC: 2361721321 --><p>
     When identifying the elements for some scenario of system behavior, you can align each participating element with one
     of three key perspectives: Entity, Control, or Boundary.
 </p>
 <p>
     This pattern is similar to the Model View Controller pattern (described here [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] and here [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#WIKP-MVC" guid="_9ToeIB83Edqsvps02rpOOg">WIKP-MVC</a>] among other places), but the Entity Control Boundary pattern is not solely
     appropriate for dealing with user interfaces and it gives the controller a slightly different role to play.
 </p>
 <h5>
     ECB&nbsp;Pattern Example
 </h5>
 <p>
     &nbsp;<img height="233" alt="" src="./resources/EBCDiagram.JPG" width="493" />
 </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&nbsp;design elements&nbsp;are "function". Entities perform behavior organized
     around some cohesive amount of data.
 </p>
 <p>
     An example entity for a customer service application would be a Customer entity that manages all information about a
     customer.&nbsp; A design element for&nbsp;this entity would include data on the customer, behavior to manage the data,
     behavior to validate customer information&nbsp;and 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.&nbsp; 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).&nbsp; Later you could do a
     pass on the same scenario applying an architectural mechanism for database access that breaks the address out into its
     own element, moves the responsibility for storing and retrieving customers to a new control element, and identifies
     some specific database decisions&nbsp;such as&nbsp;the usage 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.&nbsp; Behavior and
     business rules relating to the information relevant to the scenario should be assigned to the entities; the control
     elements are just responsible for the flow of the scenario.
 </p>
 <p>
     An example&nbsp;control element&nbsp;for a customer service application would be CreateMarketingCapmpaign.&nbsp; This
     design element would&nbsp;be responsive to certain front-end boundary elements and would collaborate with other
     entities, control&nbsp;elements, and back-end boundary elements to support the creation of a marketing campaign.
 </p>
 <p>
     As with the entity example above, there might be many passes over the identification of control elements.&nbsp; A first
     pass might be an analysis pass that identifies one control element for a&nbsp;scenario with behavior to make sure 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 the area under design and other elements will be "back-end" managing communication to
     supporting elements outside the system or subsystem.
 </p>
 <p>
     Two example boundary elements for a customer service application might be a front-end MarketingCampaignForm and a
     back-end BugdetSystem element.&nbsp; 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>
 <h3>
     Walking the Scenario
 </h3>
 <p>
     One can walk through a scenario initiated by something outside the bounds 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 above.
 </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.&nbsp; There are certain
     appropriate&nbsp;relations between the participating elements.&nbsp;&nbsp;An element can communicate to other elements
     of the same kind.&nbsp; Control&nbsp;elements can communicate with each of the other two kinds, but entities and
     boundary elements should not directly communicate.&nbsp;
 </p>
 <p>
     The table below shows appropriate links between design elements.
 </p>
 <table cellspacing="2" cellpadding="2" width="400" summary="Appropriate Links" border="1">
     <tbody>
         <tr>
             <th scope="col">
             </th>
             <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&nbsp;applying this pattern, a robust design can be put together that identifies the elements, behavior, and
     relationships&nbsp;necessary to support&nbsp;a scenario.&nbsp;
 </p><!-- END:mainDescription,-awaQ_2dwhGyKRoVKQ-esPQ -->
 </body>
 </html>
	<?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_basic\guidances\concepts\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: 2125714211 -->This concept introduces a pattern that provides a starting point for the distribution of responsibilities to a set of interacting design elements based on three key perspectives in a collaboration.<!-- END:briefDescription,_uF-QYEAhEdq_UJTvM1DM2Q -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-awaQ_2dwhGyKRoVKQ-esPQ CRC: 2361721321 --><p>
	When identifying the elements for some scenario of system behavior, you can align each participating element with one
	of three key perspectives: Entity, Control, or Boundary.
	</p>
	<p>
	This pattern is similar to the Model View Controller pattern (described here [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] and here [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#WIKP-MVC" guid="_9ToeIB83Edqsvps02rpOOg">WIKP-MVC</a>] among other places), but the Entity Control Boundary pattern is not solely
	appropriate for dealing with user interfaces and it gives the controller a slightly different role to play.
	</p>
	<h5>
	ECB Pattern Example
	</h5>
	<p>
	<img height="233" alt="" src="./resources/EBCDiagram.JPG" width="493" />
	</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 entity for a customer service application would be a Customer entity that manages all information about a
	customer.  A design element for this entity would include data on the customer, behavior to manage the data,
	behavior to validate customer information and 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 into its
	own element, moves the responsibility for storing and retrieving customers to a new control element, and identifies
	some specific database decisions such as the usage 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 just responsible for the flow of the scenario.
	</p>
	<p>
	An example control element for a customer service application would be CreateMarketingCapmpaign.  This
	design element would be responsive to certain front-end boundary elements and would collaborate with other
	entities, control elements, and back-end boundary elements to support the creation of a marketing campaign.
	</p>
	<p>
	As with the entity example above, 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 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 the area under design and other elements will be "back-end" managing communication to
	supporting elements outside the system or subsystem.
	</p>
	<p>
	Two example 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 the Scenario
	</h3>
	<p>
	One can walk through a scenario initiated by something outside the bounds 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 above.
	</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 to other elements
	of the same kind.  Control elements can communicate with each of the other two kinds, but entities and
	boundary elements should not directly communicate.
	</p>
	<p>
	The table below shows appropriate links between design elements.
	</p>
	<table cellspacing="2" cellpadding="2" width="400" summary="Appropriate Links" border="1">
	<tbody>
	<tr>
	<th scope="col">
	</th>
	<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, a robust design can be put together that identifies the elements, behavior, and
	relationships necessary to support a scenario.
	</p><!-- END:mainDescription,-awaQ_2dwhGyKRoVKQ-esPQ -->
	</body>
	</html>