<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-CFYVionNDLkMw6SG6runQA" name="uc_realizations,_2uan8NbyEdqu5o2S60g5LA" guid="-CFYVionNDLkMw6SG6runQA" changeDate="2007-07-17T18:54:53.360+0330" version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    A use-case realization represents how a use case will be implemented in terms of collaborating objects. The&#xD;
    realizations reside within the design. By walking through a design exercise of showing how the design elements will&#xD;
    perform the use case, the team gets confirmation that the design is robust enough to perform the required behavior.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The realization can take various forms. It may include, for example, a textual description (a document), class diagrams&#xD;
    of participating classes and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate&#xD;
    the flow of interactions between class and subsystem instances.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The reason for separating the use-case realization from its use case is that doing so allows the requirements, in the&#xD;
    form of use cases, to be managed separately from the design, in the form of realizations. This decoupling will prove&#xD;
    invaluable if the architecture is changed enough that the realization needs to be reworked while the requirements&#xD;
    remain unaffected. Even without such a circumstance, the clear separation of concerns between requirements and design&#xD;
    is valuable.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In a model, a use-case realization is represented as a UML (Unified Modeling Language) collaboration that groups the&#xD;
    diagrams and other information (such as textual descriptions) that form the use-case realization.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Like other aspects of the design, the UML diagrams that support use-case realizations can be produced at various levels&#xD;
    of abstraction. A first pass in creating the realization might produce a diagram at an analysis level of abstraction&#xD;
    where the participants will be high-level elements that are expected to be revisited and detailed down to the design&#xD;
    level in&amp;nbsp;a second pass. If the architecture and design idioms are well-understood, the realization could&#xD;
    immediately be created at a low level of abstraction that specifies more detail on the elements and how they will&#xD;
    collaborate to&amp;nbsp;realize the behavior of the use case. In the latter case, it is valuable to model patterns and&#xD;
    architectural mechanisms to reduce the amount of low-level detail in each realization.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For each use case in the requirements, there can be a use-case realization in the design with a realization&#xD;
    relationship to the use case, as the following figure shows. In UML, this is shown as a dashed arrow with an arrowhead,&#xD;
    like a generalization relationship, indicating that a realization is a kind of inheritance, as well as a dependency&#xD;
    (see the figure that follows).&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;strong>&lt;font face=&quot;Verdana, Arial, Helvetica, sans-serif&quot; size=&quot;2&quot;>The UML notation for use-case&#xD;
    realization&lt;/font>&lt;/strong>&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;img height=&quot;109&quot; alt=&quot;Use Case Realisations&quot; src=&quot;./resources/ucrea1.gif&quot; width=&quot;277&quot; />&#xD;
&lt;/p>&#xD;
&lt;h1>&#xD;
    Class diagrams owned by a use case realization&#xD;
&lt;/h1>For each use-case realization, there may be one or more class diagrams that depict its participating classes. A class&#xD;
and its objects often participate in several use-case realizations. While designing, it is important to coordinate all of&#xD;
the requirements related to a class that different use-case realizations may have. The figure below shows an&#xD;
analysis&amp;nbsp;class diagram for the realization of the Receive Deposit Item use case. Notice the use of&#xD;
boundary-control-entity stereotypes to represent analysis classes (see &lt;a class=&quot;elementLinkWithType&quot;&#xD;
href=&quot;./../../../openup/guidances/guidelines/entity_control_boundary_pattern.html&quot;&#xD;
guid=&quot;_uF-QYEAhEdq_UJTvM1DM2Q&quot;>Guideline: Entity-Control-Boundary Pattern&lt;/a>). &#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;strong>&lt;font face=&quot;Verdana, Arial, Helvetica, sans-serif&quot; size=&quot;2&quot;>The use case Receive Deposit Item and its&#xD;
    analysis-level class diagram&lt;/font>&lt;/strong>&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;img height=&quot;213&quot; alt=&quot;Class diagram for the realization of Receive Deposit Item&quot; src=&quot;./resources/md_ucre3.gif&quot;&#xD;
    width=&quot;328&quot; />&#xD;
&lt;/p>&lt;br align=&quot;center&quot; />&#xD;
&lt;br />&#xD;
&lt;h1>&#xD;
    Sequence and communication diagrams&#xD;
&lt;/h1>&#xD;
&lt;p>&#xD;
    For each use-case realization, there&amp;nbsp;can be&amp;nbsp;one or more interaction diagrams that depict&amp;nbsp;the&#xD;
    participating objects and their interactions. There are two types of interaction diagrams: &lt;i>sequence&lt;/i> diagrams and&#xD;
    &lt;i>communication&lt;/i> diagrams. They express similar information, but show it in different ways.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Sequence diagrams&lt;/b> show the explicit sequence of messages and are better when it is important to visualize&#xD;
        the time order of messages.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Communication diagrams&lt;/b> show the communication links between objects and are better for understanding all of&#xD;
        the effects on a given object and for algorithm design.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Realizing use cases through interaction diagrams helps to keep the design simple and cohesive. Assigning&#xD;
    responsibilities to classes on the basis of what the use-case scenario explicitly requires encourages the design to&#xD;
    contain the following elements:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Only the functionality actually used in support of a use-case scenario&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Functionality that can be tested through an associated test case&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Functionality that is more easily traceable to requirements and changes&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Explicitly declared class dependencies that are easier to manage&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These factors help improve the overall quality of the system.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
