| <?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.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-CFYVionNDLkMw6SG6runQA" |
| name="uc_realizations,_2uan8NbyEdqu5o2S60g5LA" guid="-CFYVionNDLkMw6SG6runQA" |
| changeDate="2007-06-29T08:45:40.595-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 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 size="2" face="Verdana, Arial, Helvetica, sans-serif">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>
 |
| <h1>Class diagrams owned by a use case realization</h1>
 |
| 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 size="2" face="Verdana, Arial, Helvetica, sans-serif">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>
 |
| <p align="center">&nbsp; </p>
 |
| <h1> Sequence and communication diagrams</h1>
 |
| <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> |
