fixed broken references
diff --git a/epf_prac_151/core.tech.common.base/guidances/supportingmaterials/references.tech.xmi b/epf_prac_151/core.tech.common.base/guidances/supportingmaterials/references.tech.xmi index 8aae0fb..0acfdc0 100644 --- a/epf_prac_151/core.tech.common.base/guidances/supportingmaterials/references.tech.xmi +++ b/epf_prac_151/core.tech.common.base/guidances/supportingmaterials/references.tech.xmi
@@ -1,5 +1,5 @@ <?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="-aCI9T-9TIe8D35yXBU6qvg" name="references,_9ToeIB83Edqsvps02rpOOg" guid="-aCI9T-9TIe8D35yXBU6qvg" changeDate="2008-07-24T05:24:18.000-0700" version="1.0.0"> +<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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-aCI9T-9TIe8D35yXBU6qvg" name="references,_9ToeIB83Edqsvps02rpOOg" guid="-aCI9T-9TIe8D35yXBU6qvg" changeDate="2010-11-23T11:06:53.544-0800" version="1.0.0"> <mainDescription><h3>
 Technical
 </h3>
 @@ -265,7 +265,7 @@ <tbody>
 <tr>
 <td valign="top" width="12%">
 - <a id="COH05" name="COH05">COH05</a> 
 + <a id="COH05" name="COH05">COH05</a>
 </td>
 <td colspan="2">
 <p>
 @@ -317,7 +317,7 @@ <tbody>
 <tr>
 <td valign="top" width="12%">
 - <a id="GAM95" name="GAM95">GAM95</a> 
 + <a id="GAM95" name="GAM95">GAM95</a>
 </td>
 <td colspan="2">
 Gamma, E., Helm, R., Johnson, R., Vlissides, J., <em>Design Patterns: Elements of Reusable Object-Oriented
 @@ -452,8 +452,7 @@ MAR03&nbsp;
 </td>
 <td colspan="2">
 - Marick, B., <em>Exploration Through Example</em>, <a
 - href="http://www.exampler.com/blog/">http://www.exampler.com/blog/</a> 
 + Marick, B., <em>Exploration Through Example.</em>
 </td>
 </tr>
 </tbody>
 @@ -504,7 +503,7 @@ </td>
 <td colspan="2">
 The 1996 ACM Conference on Object-Oriented Programs, Systems, Languages, and Applications (OOPSLA), <em>The
 - Origins of Pattern Theory, the Future of the Theory, and The Generation of a Living World.</em> 
 + Origins of Pattern Theory, the Future of the Theory, and The Generation of a Living World.</em>
 </td>
 </tr>
 <tr>
 @@ -515,7 +514,6 @@ <td style="PADDING-BOTTOM: 10px" width="78%">
 See <a
 href="http://www.patternlanguage.com/archive/ieee/ieeetext.htm">http://www.patternlanguage.com/archive/ieee/ieeetext.htm</a>
 - 
 </td>
 </tr>
 </tbody>
 @@ -524,7 +522,7 @@ <tbody>
 <tr>
 <td valign="top" width="12%">
 - <a id="PW29" name="PW92">PW92</a> 
 + <a id="PW29" name="PW92">PW92</a>
 </td>
 <td colspan="2">
 Dewayne E. Perry and Alexander L. Wolf. <em>Foundations for the Study of Software Architecture</em>. ACM
 @@ -562,7 +560,7 @@ <tbody>
 <tr>
 <td valign="top" width="12%">
 - <a id="SHA05" name="SHA05">SHA05</a> 
 + <a id="SHA05" name="SHA05">SHA05</a>
 </td>
 <td colspan="2">
 Shalloway, J., Trott, J. <em>Design Patterns Explained</em> A New Perspective on Object-Oriented Design,
 @@ -578,7 +576,7 @@ TEL06
 </td>
 <td colspan="2">
 - Telelogic, 2006. <em>Get It Right the First Time: Writing Better Requirements.</em> 
 + Telelogic, 2006. <em>Get It Right the First Time: Writing Better Requirements.</em>
 </td>
 </tr>
 </tbody>
 @@ -620,7 +618,6 @@ Whitepaper, 2004<br />
 <a
 href="http://www.telelogic.com/download/index.cfm?id=4423">http://www.telelogic.com/download/index.cfm?id=4423</a>
 - 
 </td>
 </tr>
 </tbody>
 @@ -633,7 +630,6 @@ Wikipedia <em>Model-view-controller</em><br />
 <a
 href="http://en.wikipedia.org/wiki/Model-view-controller">http://en.wikipedia.org/wiki/Model-view-controller</a>
 - 
 </td>
 </tr>
 </tbody>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/use_case_model.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/use_case_model.xmi index 7bb410e..9982f57 100644 --- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/use_case_model.xmi +++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/use_case_model.xmi
@@ -1,167 +1,166 @@ <?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" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-yEWkrWZ3VUcjZPhq6bvScg" name="new_concept,_2jyfUAhVEduRe8TeoBmuGg" guid="-yEWkrWZ3VUcjZPhq6bvScg" changeDate="2008-09-03T05:28:20.000-0700" version="1.0.0"> - <mainDescription><h3> - Explanation -</h3> -<p> - A use-case model is a model of how different types of users interact with the system to solve a problem.&nbsp; As such, - it describes the goals of the users, the interactions between the users and the system, and the required behavior of - the system in satisfying these goals. -</p> -<p> - A use-case model consists of a number of model elements.&nbsp; The most important model elements are: use cases, actors - and the relationships between them.&nbsp; -</p> -<p> - A use-case diagram is used to graphically depict a subset of the model to simplify communications.&nbsp; There will - typically be several use-case diagrams associated with a given model, each showing a subset of the model elements - relevant for a particular purpose.&nbsp; The same model element may be shown on several use-case diagrams, but each - instance must be consistent.&nbsp; If tools are used to maintain the use-case model, this consistency constraint is - automated so that any changes to the model element (changing the name for example) will be automatically reflected on - every use-case diagram that shows that element. -</p> -<p> - The use-case model may contain packages that are used to structure the model to simplify analysis, communications, - navigation, development, maintenance and planning. -</p> -<p> - Much of the use-case model is in fact textual, with the text captured in the&nbsp;use-case specifications&nbsp;that are - associated with each use-case model element.&nbsp;These specifications describe the flow of events of the use case. -</p> -<p> - The use-case model serves as a unifying thread throughout system development. It is used as the primary specification - of the functional requirements for the system, as the basis for analysis and design, as an input to iteration planning, - as the basis of defining test cases and as the basis for user documentation&nbsp;&nbsp; -</p> -<h3> - Basic model elements -</h3> -<p> - The use-case model contains, as a minimum, the following basic model elements. -</p> -<h4> - Actor -</h4> -<p> - A model element representing&nbsp;each actor. Properties include the actors name and brief description. See&nbsp;<a - class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/actor_411726C.html" - guid="_zGqO0MDpEduTGJ8i4u8TMw">Concept: Actor</a> for more information. -</p> -<h4> - Use Case -</h4> -<p> - A model element representing&nbsp;each use case. Properties include the use case name and use case specification. See - <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/workproducts/use_case_22BE66E2.html" - guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a> and <a class="elementLinkWithType" - href="./../../../core.tech.common.extend_supp/guidances/concepts/use_case_BB199D1B.html" - guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a> for more information. -</p> -<h4> - Associations -</h4> -<p> - Associations are used to describe the relationships between actors and the use cases they participate in. This - relationship is commonly known as a "communicates-association". -</p> -<h3> - Advanced model elements -</h3> -<p> - The use-case model may also contain the following advanced model elements. -</p> -<h4> - Subject -</h4> -<p> - A model element that represents the boundary of the system of interest.&nbsp;&nbsp; -</p> -<h4> - Use-Case Package -</h4> -<p> - A model element used to structure the use case model to simplify analysis, communications, navigation, and - planning.&nbsp; If there are many use cases or actors, you can use use-case packages to further structure the use-case - model in much the same manner you use folders or directories to structure the information on your hard-disk. -</p> -<p> - You can partition a use-case model into use-case packages for several reasons, including: -</p> -<ul> - <li> - To reflect the order, configuration, or delivery units in the finished system thus supporting iteration planning. - </li> - <li> - To support parallel development by dividing the problem into bite-sized pieces. - </li> - <li> - To simplify communication with different stakeholders by creating packages for containing use cases and actors - relevant to a particular stakeholder. - </li> -</ul> -<h4> - Generalizations -</h4> -<p> - A relationship&nbsp;between actors to support re-use of common properties. -</p> -<h4> - Dependencies -</h4> -<p> - A number of dependency types between use cases are defined in UML. In particular, &lt;&lt;extend&gt;&gt; and - &lt;&lt;include&gt;&gt;. -</p> -<p> - &lt;&lt;extend&gt;&gt; is used to include optional behavior from an extending use case in an extended use case. -</p> -<p> - &lt;&lt;include&gt;&gt; is used to include common behavior from an included use case into a base use case in order to - support re-use of common behavior. -</p> -<p> - The latter is the most widely used dependency and is useful for: -</p> -<ul> - <li> - Factoring out behavior from the base use case that is not necessary for the understanding of the primary purpose of - the use case to simplify communications. - </li> - <li> - Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and - ensure consistency. - </li> -</ul> -<h3> - Example Use-Case Diagram -</h3> -<p> - Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model. -</p> -<p> - &nbsp;<img alt="Figure 1: ATM Use-Case Diagram" src="resources/atm_uc_diagram.gif" /> -</p> -<p> - Figure 1: ATM Use-Case Diagram -</p> -<p> - This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cashier and Maintenance Person), five use - cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill Machine and Validate User), three &lt;&lt;includes&gt;&gt; - dependencies, and the associations between the performing actors and the use cases. -</p> -<p> - The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the customer is identified to - the system. This behavior can be extracted to a new inclusion use case called Validate User, which the three base use - cases &lt;&lt;include&gt;&gt;. The base use cases are independent of the method used for identification, and it is - therefore encapsulated in the inclusion use case. From the perspective of the base use cases, it does not matter - whether the method for identification is to read a magnetic bank card, or perform a retinal scan. They only depend on - the result of Validate Customer. -</p> -<p> - Note that Figure 1 is only a partial view of the use-case model. The complete use-case model also includes descriptions - of each actor, descriptions of each use case, and use-case specifications for each use case.&nbsp; For a more complete - example of this use case model see&nbsp;<a class="elementLink" - href="./../../../core.tech.common.extend_supp/guidances/examples/uc_model_evolve_960F136B.html" - guid="_t4QdAMNqEdu2IdAIaWZyAw">Evolution of the Use-Case Model</a>.<br /> +<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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-yEWkrWZ3VUcjZPhq6bvScg" name="new_concept,_2jyfUAhVEduRe8TeoBmuGg" guid="-yEWkrWZ3VUcjZPhq6bvScg" changeDate="2010-11-23T11:24:10.272-0800" version="1.0.0"> + <mainDescription><h3>
 + Explanation
 +</h3>
 +<p>
 + A use-case model is a model of how different types of users interact with the system to solve a problem.&nbsp; As such,
 + it describes the goals of the users, the interactions between the users and the system, and the required behavior of
 + the system in satisfying these goals.
 +</p>
 +<p>
 + A use-case model consists of a number of model elements.&nbsp; The most important model elements are: use cases, actors
 + and the relationships between them.&nbsp;
 +</p>
 +<p>
 + A use-case diagram is used to graphically depict a subset of the model to simplify communications.&nbsp; There will
 + typically be several use-case diagrams associated with a given model, each showing a subset of the model elements
 + relevant for a particular purpose.&nbsp; The same model element may be shown on several use-case diagrams, but each
 + instance must be consistent.&nbsp; If tools are used to maintain the use-case model, this consistency constraint is
 + automated so that any changes to the model element (changing the name for example) will be automatically reflected on
 + every use-case diagram that shows that element.
 +</p>
 +<p>
 + The use-case model may contain packages that are used to structure the model to simplify analysis, communications,
 + navigation, development, maintenance and planning.
 +</p>
 +<p>
 + Much of the use-case model is in fact textual, with the text captured in the&nbsp;use-case specifications&nbsp;that are
 + associated with each use-case model element.&nbsp;These specifications describe the flow of events of the use case.
 +</p>
 +<p>
 + The use-case model serves as a unifying thread throughout system development. It is used as the primary specification
 + of the functional requirements for the system, as the basis for analysis and design, as an input to iteration planning,
 + as the basis of defining test cases and as the basis for user documentation&nbsp;&nbsp;
 +</p>
 +<h3>
 + Basic model elements
 +</h3>
 +<p>
 + The use-case model contains, as a minimum, the following basic model elements.
 +</p>
 +<h4>
 + Actor
 +</h4>
 +<p>
 + A model element representing&nbsp;each actor. Properties include the actors name and brief description. See&nbsp;<a
 + class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/actor_411726C.html"
 + guid="_zGqO0MDpEduTGJ8i4u8TMw">Concept: Actor</a> for more information.
 +</p>
 +<h4>
 + Use Case
 +</h4>
 +<p>
 + A model element representing&nbsp;each use case. Properties include the use case name and use case specification.
 + See&nbsp;Use Case artifact and <a class="elementLinkWithType"
 + href="./../../../core.tech.common.extend_supp/guidances/concepts/use_case_BB199D1B.html"
 + guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a> for more information.
 +</p>
 +<h4>
 + Associations
 +</h4>
 +<p>
 + Associations are used to describe the relationships between actors and the use cases they participate in. This
 + relationship is commonly known as a "communicates-association".
 +</p>
 +<h3>
 + Advanced model elements
 +</h3>
 +<p>
 + The use-case model may also contain the following advanced model elements.
 +</p>
 +<h4>
 + Subject
 +</h4>
 +<p>
 + A model element that represents the boundary of the system of interest.&nbsp;&nbsp;
 +</p>
 +<h4>
 + Use-Case Package
 +</h4>
 +<p>
 + A model element used to structure the use case model to simplify analysis, communications, navigation, and
 + planning.&nbsp; If there are many use cases or actors, you can use use-case packages to further structure the use-case
 + model in much the same manner you use folders or directories to structure the information on your hard-disk.
 +</p>
 +<p>
 + You can partition a use-case model into use-case packages for several reasons, including:
 +</p>
 +<ul>
 + <li>
 + To reflect the order, configuration, or delivery units in the finished system thus supporting iteration planning.
 + </li>
 + <li>
 + To support parallel development by dividing the problem into bite-sized pieces.
 + </li>
 + <li>
 + To simplify communication with different stakeholders by creating packages for containing use cases and actors
 + relevant to a particular stakeholder.
 + </li>
 +</ul>
 +<h4>
 + Generalizations
 +</h4>
 +<p>
 + A relationship&nbsp;between actors to support re-use of common properties.
 +</p>
 +<h4>
 + Dependencies
 +</h4>
 +<p>
 + A number of dependency types between use cases are defined in UML. In particular, &lt;&lt;extend&gt;&gt; and
 + &lt;&lt;include&gt;&gt;.
 +</p>
 +<p>
 + &lt;&lt;extend&gt;&gt; is used to include optional behavior from an extending use case in an extended use case.
 +</p>
 +<p>
 + &lt;&lt;include&gt;&gt; is used to include common behavior from an included use case into a base use case in order to
 + support re-use of common behavior.
 +</p>
 +<p>
 + The latter is the most widely used dependency and is useful for:
 +</p>
 +<ul>
 + <li>
 + Factoring out behavior from the base use case that is not necessary for the understanding of the primary purpose of
 + the use case to simplify communications.
 + </li>
 + <li>
 + Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and
 + ensure consistency.
 + </li>
 +</ul>
 +<h3>
 + Example Use-Case Diagram
 +</h3>
 +<p>
 + Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.
 +</p>
 +<p>
 + &nbsp;<img alt="Figure 1: ATM Use-Case Diagram" src="resources/atm_uc_diagram.gif" />
 +</p>
 +<p>
 + Figure 1: ATM Use-Case Diagram
 +</p>
 +<p>
 + This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cashier and Maintenance Person), five use
 + cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill Machine and Validate User), three &lt;&lt;includes&gt;&gt;
 + dependencies, and the associations between the performing actors and the use cases.
 +</p>
 +<p>
 + The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the customer is identified to
 + the system. This behavior can be extracted to a new inclusion use case called Validate User, which the three base use
 + cases &lt;&lt;include&gt;&gt;. The base use cases are independent of the method used for identification, and it is
 + therefore encapsulated in the inclusion use case. From the perspective of the base use cases, it does not matter
 + whether the method for identification is to read a magnetic bank card, or perform a retinal scan. They only depend on
 + the result of Validate Customer.
 +</p>
 +<p>
 + Note that Figure 1 is only a partial view of the use-case model. The complete use-case model also includes descriptions
 + of each actor, descriptions of each use case, and use-case specifications for each use case.&nbsp; For a more complete
 + example of this use case model see&nbsp;<a class="elementLink"
 + href="./../../../core.tech.common.extend_supp/guidances/examples/uc_model_evolve_960F136B.html"
 + guid="_t4QdAMNqEdu2IdAIaWZyAw">Evolution of the Use-Case Model</a>.<br />
 </p></mainDescription> </org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/plugin.xmi b/epf_prac_151/core.tech.common.extend_supp/plugin.xmi index 4a8e848..de38729 100644 --- a/epf_prac_151/core.tech.common.extend_supp/plugin.xmi +++ b/epf_prac_151/core.tech.common.extend_supp/plugin.xmi
@@ -1,5 +1,5 @@ <?xml version="1.0" encoding="UTF-8"?> -<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1"> +<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1"> <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_9S-U4LekEd-D7YZN9NgldQ" guid="_9S-U4LekEd-D7YZN9NgldQ"> <resourceDescriptors xmi:id="_-ypX4LekEd-D7YZN9NgldQ" id="_zHTQUKYSEdmvhNXG0Oc2uA" uri="workproducts/vision.xmi"/> <resourceDescriptors xmi:id="_-y8S0LekEd-D7YZN9NgldQ" id="-_dNuyh-0q5vpCiIiLfbj6w" uri="workproducts/system_wide_requirements.xmi"/> @@ -124,7 +124,7 @@ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_W2SgEDR5EdutE_HNDTJk5Q" name="use_case_model" guid="_W2SgEDR5EdutE_HNDTJk5Q" presentationName="Use-Case Model" briefDescription="This artifact captures a model of the intended functions and environment of the system and serves as a contract between the customer and the team." conceptsAndPapers="_KudM0NcJEdqz_d2XWoVt6Q _2jyfUAhVEduRe8TeoBmuGg _zGqO0MDpEduTGJ8i4u8TMw" checklists="_0U6OEMlgEdmt3adZL5Dmdw" examples="_t4QdAMNqEdu2IdAIaWZyAw"> <presentation xmi:id="-kQg7MSGPB3RPjrplyxwimQ" href="uma://-kQg7MSGPB3RPjrplyxwimQ#-kQg7MSGPB3RPjrplyxwimQ"/> </contentElements> - <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_KudM0NcJEdqz_d2XWoVt6Q" name="use_case" guid="_KudM0NcJEdqz_d2XWoVt6Q" presentationName="Use Case" briefDescription="A use case describes what the system must do to provide value to the stakeholders."> + <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_KudM0NcJEdqz_d2XWoVt6Q" name="use_case" guid="_KudM0NcJEdqz_d2XWoVt6Q" presentationName="Use Case" briefDescription="A use case describes what the system must do to provide value to the stakeholders." conceptsAndPapers="_0Wh-sMlgEdmt3adZL5Dmdw"> <presentation xmi:id="-BQLZ5GRUNrMdU6XeZAfe9Q" href="uma://-BQLZ5GRUNrMdU6XeZAfe9Q#-BQLZ5GRUNrMdU6XeZAfe9Q"/> </contentElements> <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0WoFUMlgEdmt3adZL5Dmdw" name="vision" guid="_0WoFUMlgEdmt3adZL5Dmdw" presentationName="Vision" briefDescription="This check list provides questions to verify that the Vision is described in a consistent and complete manner."> @@ -181,7 +181,7 @@ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0kNwINk1Edq2Q8qZoWbvGA" name="use_case" guid="_0kNwINk1Edq2Q8qZoWbvGA" presentationName="Use Case" briefDescription="This checklist provides questions to verify that use cases are described in a consistent and complete manner." variabilityType="replaces"> <presentation xmi:id="-T2IeqdOunweffIDgL-aM0w" href="uma://-T2IeqdOunweffIDgL-aM0w#-T2IeqdOunweffIDgL-aM0w"/> </contentElements> - <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0U6OEMlgEdmt3adZL5Dmdw" name="use_case_model" guid="_0U6OEMlgEdmt3adZL5Dmdw" presentationName="Use-Case Model" briefDescription="This checklist provides questions to verify that the use-case model is described in a consistent and complete manner."> + <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0U6OEMlgEdmt3adZL5Dmdw" name="use_case_model" guid="_0U6OEMlgEdmt3adZL5Dmdw" presentationName="Use-Case Model" briefDescription="This checklist provides questions to verify that the use-case model is described in a consistent and complete manner." checklists="_0kNwINk1Edq2Q8qZoWbvGA"> <presentation xmi:id="_MqODAMM1EdmSIPI87WLu3g" href="uma://_MqODAMM1EdmSIPI87WLu3g#_MqODAMM1EdmSIPI87WLu3g"/> </contentElements> <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_VXZ5wO0IEdqHTdbLTmC5IQ" name="system_wide_requirements" guid="_VXZ5wO0IEdqHTdbLTmC5IQ" presentationName="System-Wide Requirements" briefDescription="This concept describes the system-wide requirements.">