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