https://bugs.eclipse.org/bugs/show_bug.cgi?id=196243
diff --git a/OpenUP/configurations/OpenUP.xmi b/OpenUP/configurations/OpenUP.xmi
index 03ab537..e3cbdf8 100644
--- a/OpenUP/configurations/OpenUP.xmi
+++ b/OpenUP/configurations/OpenUP.xmi
@@ -22,12 +22,10 @@
<methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0aQBEMlgEdmt3adZL5Dmdw"/>
<methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_kB42IDRiEduU7vV49F9N0A"/>
<methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8MlgEdmt3adZL5Dmdw"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_h15dULCxEdujaOuld2kPdg"/>
<methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_douywISSEdu8NaFPL8nS_w"/>
<methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8clgEdmt3adZL5Dmdw"/>
<methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_-KUSIAInEdyLh7vsrHZ4YA"/>
<methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YcDMMlgEdmt3adZL5Dmdw"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_XIwYQPTYEduDKIuqTXQ8SA"/>
<methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_PGDx8PisEdmjyaJMRcPDWA"/>
<methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MMlgEdmt3adZL5Dmdw"/>
<methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0cQzQMlgEdmt3adZL5Dmdw"/>
diff --git a/OpenUP/openup/guidances/guidelines/continuous_integration.xmi b/OpenUP/openup/guidances/guidelines/continuous_integration.xmi
index 54ed18f..e36c684 100644
--- a/OpenUP/openup/guidances/guidelines/continuous_integration.xmi
+++ b/OpenUP/openup/guidances/guidelines/continuous_integration.xmi
@@ -1,60 +1,90 @@
<?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="-DlaqJu4sEqMPk84qhJ6IEA"
+ xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-DlaqJu4sEqMPk84qhJ6IEA"
name="continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ" guid="-DlaqJu4sEqMPk84qhJ6IEA"
- changeDate="2007-06-15T06:39:25.578-0700">
- <mainDescription><p> Continuous integration is a software development practice that completely 
- rebuilds and tests the application frequently -- ideally, every time a change 
- is introduced. This approach provides many benefits as outlined in <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/continuous_integration_87682D06.html" guid="_B3xkEPD0EdqYgerqi84oCA">Concept: 
- Continuous Integration</a> and in <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#WIKP-CI" guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>. 
+ changeDate="2007-07-13T14:47:43.207-0700">
+ <mainDescription><p>
+ Continuous integration is a software development practice that completely rebuilds and tests the application frequently
+ -- ideally, every time a change is introduced. This approach provides many benefits as outlined in <a
+ class="elementLinkWithType" href="./../../../openup/guidances/concepts/continuous_integration.html"
+ guid="_B3xkEPD0EdqYgerqi84oCA">Concept: Continuous Integration</a> and in <a class="elementLinkWithUserText"
+ href="./../../../openup/guidances/supportingmaterials/references.html#WIKP-CI"
+ guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
</p>
-<h1>Basic steps</h1>
-<p> The detailed application of continuous integration depends on which tools 
- you use (content management system, automated build tool, automated test tool, 
- and so forth). However, these are the basic steps: </p>
+<h1>
+ Basic steps
+</h1>
+<p>
+ The detailed application of continuous integration depends on which tools you use (content management system, automated
+ build tool, automated test tool, and so forth). However, these are the basic steps:
+</p>
<ol>
- <li> A developer, let’s call her Jane, selects an to work on. </li>
- <li> Jane updates her <a class="elementLink" href="./../../../openup/guidances/concepts/workspace_722BBA90.html" guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a> 
- to include the most recent <a class="elementLink" href="./../../../openup/workproducts/implementation_917CA61E.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a> 
- from the integration workspace. </li>
- <li> Jane makes her changes in her workspace to both her developer tests and 
- to the implementation, and then she tests the changes. </li>
- <li> Before committing the changes, Jane updates her workspace again (because 
- other developers may have introduced conflicting changes) and reruns her developer 
- tests. </li>
- <li> If these tests are successful, the changes are promoted (see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/promoting_changes_9087B764.html" guid="_SM4YIL6dEdqti4GwqTkbsQ">Guideline: 
- Promoting Changes</a>) to&nbsp;the&nbsp;integration workspace. </li>
- <li> A complete <a class="elementLink" href="./../../../openup/workproducts/build_95D7D8FD.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a> 
- of the application is performed by using the implementation from the integration 
- workspace, and the entire suite of developer tests is run on this build. </li>
- <li> If any of these tests fail, the team is notified, and the failed test should 
- be addressed as soon as possible. </li>
- <li> This process repeats as the team develops and continuously integrates and 
- tests functionality in small increments. </li>
+ <li>
+ A developer, let’s call her Jane, selects an to work on.
+ </li>
+ <li>
+ Jane updates her <a class="elementLink" href="./../../../openup/guidances/concepts/workspace.html"
+ guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a> to include the most recent <a class="elementLink"
+ href="./../../../openup/workproducts/implementation-3.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a> from
+ the integration workspace.
+ </li>
+ <li>
+ Jane makes her changes in her workspace to both her developer tests and to the implementation, and then she tests
+ the changes.
+ </li>
+ <li>
+ Before committing the changes, Jane updates her workspace again (because other developers may have introduced
+ conflicting changes) and reruns her developer tests.
+ </li>
+ <li>
+ If these tests are successful, the changes are promoted (see <a class="elementLinkWithType"
+ href="./../../../openup/guidances/guidelines/promoting_changes.html" guid="_SM4YIL6dEdqti4GwqTkbsQ">Guideline:
+ Promoting Changes</a>) to&nbsp;the&nbsp;integration workspace.
+ </li>
+ <li>
+ A complete <a class="elementLink" href="./../../../openup/workproducts/build.html"
+ guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a> of the application is performed by using the implementation from the
+ integration workspace, and the entire suite of developer tests is run on this build.
+ </li>
+ <li>
+ If any of these tests fail, the team is notified, and the failed test should be addressed as soon as possible.
+ </li>
+ <li>
+ This process repeats as the team develops and continuously integrates and tests functionality in small increments.
+ </li>
</ol>
-<h1>Constraints</h1>
-<p> Conceptually, continuous integration can be performed manually (see <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#SHO06" guid="_9ToeIB83Edqsvps02rpOOg">[SHO06]</a> 
- for example). However, in practice, there are several constraints that must 
- be respected for it to be effective: </p>
+<h1>
+ Constraints
+</h1>
+<p>
+ Conceptually, continuous integration can be performed manually (see <a class="elementLinkWithUserText"
+ href="./../../../openup/guidances/supportingmaterials/references.html#SHO06" guid="_9ToeIB83Edqsvps02rpOOg">[SHO06]</a>
+ for example). However, in practice, there are several constraints that must be respected for it to be effective:
+</p>
<ol>
- <li> All changes must be introduced into a tested configuration that you know 
- to be good. </li>
- <li> The integrate-build-test cycle must be fast enough so that it can be completed 
- quickly and the team notified of the results. Many published guidelines promote 
- a 10-minute cycle. </li>
- <li><a href="./../../../openup/guidances/concepts/change_set_430BF233.html">Change 
- Sets</a> must be kept small enough so that the work can be completed and integration 
- performed several times per day. Many published guidelines promote a 2- to 
- 4-hour cycle between integrations. </li>
+ <li>
+ All changes must be introduced into a tested configuration that you know to be good.
+ </li>
+ <li>
+ The integrate-build-test cycle must be fast enough so that it can be completed quickly and the team notified of the
+ results. Many published guidelines promote a 10-minute cycle.
+ </li>
+ <li>
+ Keep the <a class="elementLink" href="./../../../openup/guidances/concepts/change_set.html"
+ guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s&nbsp;small enough so that the work can be completed and integration
+ performed several times per day. Many published guidelines promote a 2- to 4-hour cycle between integrations.
+ </li>
</ol>
-<p> These constraints imply the need for a content management (CM) repository 
- to maintain configuration information (Item 1 listed previously), automated 
- build and test tools to meet the turnaround constraints (Item 2), and proper 
- planning and discipline by developers to ensure that their work items and change 
- sets are small enough to complete quickly (Item 3). </p>
-<p> For a more detailed description of continuous integration, see <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#FOW06" guid="_9ToeIB83Edqsvps02rpOOg">[FOW06]</a> 
- or <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#WIKP-CI" guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>. 
+<p>
+ These constraints imply the need for a content management (CM) repository to maintain configuration information (Item 1
+ listed previously), automated build and test tools to meet the turnaround constraints (Item 2), and proper planning and
+ discipline by developers to ensure that their work items and change sets are small enough to complete quickly (Item 3).
+</p>
+<p>
+ For a more detailed description of continuous integration, see <a class="elementLinkWithUserText"
+ href="./../../../openup/guidances/supportingmaterials/references.html#FOW06" guid="_9ToeIB83Edqsvps02rpOOg">[FOW06]</a>
+ or <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references.html#WIKP-CI"
+ guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/openup/guidances/guidelines/detail_ucs_and_scenarios.xmi b/OpenUP/openup/guidances/guidelines/detail_ucs_and_scenarios.xmi
index 4675b74..0704f72 100644
--- a/OpenUP/openup/guidances/guidelines/detail_ucs_and_scenarios.xmi
+++ b/OpenUP/openup/guidances/guidelines/detail_ucs_and_scenarios.xmi
@@ -1,54 +1,69 @@
<?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="-78ko4CuOJERKJF9ZvwMUBQ"
+ xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-78ko4CuOJERKJF9ZvwMUBQ"
name="detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q" guid="-78ko4CuOJERKJF9ZvwMUBQ"
- changeDate="2007-03-30T13:16:38.898-0700" version="1.0.0">
- <mainDescription><h1> Most efficient way to write use cases </h1>
-<p> Because use cases model requirements, they are highly dynamic by nature. The 
- more we examine a scenario, the more we learn and the more things change. To 
- further complicate the issue, changes to one use case can lead to changes in 
- others. Therefore, we want a flexible, highly efficient method for writing use 
- cases that maximizes stakeholder value and minimizes risk early in the project 
- and minimizes costly rework later. </p>
-<p> An iterative, breadth-before-depth approach is best. This breadth-first approach 
- involves two aspects: finding and outlining use cases and detailing individual 
- use cases. </p>
-<h2> Finding and outlining&nbsp;use cases </h2>
-<p> Use cases exist in sets, and the relationships between the various use cases 
- and Actors are important. As you learn more about the Actors, you also learn 
- more about the system's boundaries and transactions. Likewise, as you learn 
- more about the system's transactions, you learn more about its Actors. Therefore, 
- it is more efficient to capture and outline the primary use cases before detailing 
- individual use cases. This way, you can identify and understand the importance 
- and risk associated with each use case before committing time to detailing them.&nbsp; 
- This aspect of the breadth-before-depth approach is embodied in the process 
- by the explicit separation of two tasks <a class="elementLink" href="./../../../openup/tasks/find_and_outline_requirements_90D272B9.html" guid="_P9cMUPV_EdmdHa9MmVPgqQ">Find 
- and Outline Requirements</a>&nbsp;and <a class="elementLink" href="./../../../openup/tasks/detail_requirements_9747F71E.html" guid="_0e1mIMlgEdmt3adZL5Dmdw">Detail 
- Requirements</a>.&nbsp; </p>
-<h2> Detailing individual use cases </h2>
-<p> Similarly, it makes sense to write each individual use case iteratively. Start 
- by detailing the main scenario.&nbsp; As you do this, you can identify various 
- alternative and error flows that the use case might follow, and then evaluate, 
- rearrange, or eliminate them and prioritize them before detailing the surviving 
- scenarios, so you can focus your effort in the right place. </p>
-<p> The level of detail that you capture depends on several factors. See <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/use_case_formats_FF4AE425.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: 
- Use Case Formats</a> for guidance on selecting the correct format for your use 
- cases. </p>
-<h3> Detail the basic flow of events (main scenario) </h3>
+ changeDate="2007-07-13T14:50:34.560-0700" version="1.0.0">
+ <mainDescription><h1>
+ Most efficient way to write use cases
+</h1>
<p>
- As a starting point, use the step-by-step description of the main scenario that you created during <a class="elementLinkWithType" href="./../../../openup/tasks/find_and_outline_requirements_90D272B9.html" guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>. Then, gradually add details to this scenario,
+ Because use cases model requirements, they are highly dynamic by nature. The more we examine a scenario, the more we
+ learn and the more things change. To further complicate the issue, changes to one use case can lead to changes in
+ others. Therefore, we want a flexible, highly efficient method for writing use cases that maximizes stakeholder value
+ and minimizes risk early in the project and minimizes costly rework later.
+</p>
+<p>
+ An iterative, breadth-before-depth approach is best. This breadth-first approach involves two aspects: finding and
+ outlining use cases and detailing individual use cases.
+</p>
+<h2>
+ Finding and outlining&nbsp;use cases
+</h2>
+<p>
+ Use cases exist in sets, and the relationships between the various use cases and Actors are important. As you learn
+ more about the Actors, you also learn more about the system's boundaries and transactions. Likewise, as you learn more
+ about the system's transactions, you learn more about its Actors. Therefore, it is more efficient to capture and
+ outline the primary use cases before detailing individual use cases. This way, you can identify and understand the
+ importance and risk associated with each use case before committing time to detailing them.&nbsp; This aspect of the
+ breadth-before-depth approach is embodied in the process by the explicit separation of two tasks <a class="elementLink"
+ href="./../../../openup/tasks/find_and_outline_requirements.html" guid="_P9cMUPV_EdmdHa9MmVPgqQ">Find and Outline
+ Requirements</a>&nbsp;and <a class="elementLink" href="./../../../openup/tasks/detail_requirements.html"
+ guid="_0e1mIMlgEdmt3adZL5Dmdw">Detail Requirements</a>.&nbsp;
+</p>
+<h2>
+ Detailing individual use cases
+</h2>
+<p>
+ Similarly, it makes sense to write each individual use case iteratively. Start by detailing the main scenario.&nbsp; As
+ you do this, you can identify various alternative and error flows that the use case might follow, and then evaluate,
+ rearrange, or eliminate them and prioritize them before detailing the surviving scenarios, so you can focus your effort
+ in the right place.
+</p>
+<p>
+ The level of detail that you capture depends on several factors. See <a class="elementLinkWithType"
+ href="./../../../openup/guidances/guidelines/use_case_formats.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case
+ Formats</a> for guidance on selecting the correct format for your use cases.
+</p>
+<h3>
+ Detail the basic flow of events (main scenario)
+</h3>
+<p>
+ As a starting point, use the step-by-step description of the main scenario that you created during <a
+ class="elementLinkWithType" href="./../../../openup/tasks/find_and_outline_requirements.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>. Then, gradually add details to this scenario,
describing <strong>what</strong> the use case does, <strong>not how</strong> to solve problems internal to the system.
</p>
-<p> A flow of events description covers: </p>
+<p>
+ A flow of events description covers:
+</p>
<ul>
<li>
How and when the use case starts
</li>
- 
- <li> When the use case interacts with the Actors and what data they exchange 
- </li>
+ <li>
+ When the use case interacts with the Actors and what data they exchange
+ </li>
<li>
When the use case uses data stored in the system or stores data in the system
</li>
@@ -74,142 +89,198 @@
Describe the flow of events for the main scenario in the form:
</p>
<ol>
- <li> The use case starts when &lt;&lt;Actor name&gt;&gt; &lt;&lt;does something&gt;&gt;.</li>
- <li> The system &lt;&lt;does something in response&gt;&gt;.</li>
- <li> The &lt;&lt;Actor name&gt;&gt; does something else.</li>
+ <li>
+ The use case starts when &lt;&lt;Actor name&gt;&gt; &lt;&lt;does something&gt;&gt;.
+ </li>
+ <li>
+ The system &lt;&lt;does something in response&gt;&gt;.
+ </li>
+ <li>
+ The &lt;&lt;Actor name&gt;&gt; does something else.
+ </li>
</ol>
-<p> See Section 4 of&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_spec_CD5DD9B1.html" guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: 
- Use-Case Specification</a> for a sample completed basic flow. </p>
-<h3> Detail alternate flows </h3>
-<p> A use case consists of a number of scenarios, each representing specific instances 
- of the use case that correspond to specific inputs from the Actor or to specific 
- conditions in the environment. Each scenario describes alternate ways that the 
- system behaves, or it may describe failure or exception cases. </p>
<p>
- Review the list of alternative flows that you captured during <a class="elementLinkWithType" href="./../../../openup/tasks/find_and_outline_requirements_90D272B9.html" guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>. As you detail the main scenario, you may
- identify additional alternate flows by asking these questions:
+ See Section 4 of&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_spec.html"
+ guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: Use-Case Specification</a> for a sample completed basic flow.
+</p>
+<h3>
+ Detail alternate flows
+</h3>
+<p>
+ A use case consists of a number of scenarios, each representing specific instances of the use case that correspond to
+ specific inputs from the Actor or to specific conditions in the environment. Each scenario describes alternate ways
+ that the system behaves, or it may describe failure or exception cases.
+</p>
+<p>
+ Review the list of alternative flows that you captured during <a class="elementLinkWithType"
+ href="./../../../openup/tasks/find_and_outline_requirements.html" guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline
+ Requirements</a>. As you detail the main scenario, you may identify additional alternate flows by asking these
+ questions:
</p>
<ul>
- 
- <li> Are there different options available, depending on input from the Actor? 
- (Example: If the Actor enters an invalid PIN number while accessing an ATM.) 
- </li>
- 
- <li> What business rules may come into play? (Example: The Actor requests more 
- money from the ATM than is available in her account.) </li>
- 
- <li> What could go wrong? (Example: No network connection available when required 
- to perform a transaction.) </li>
+ <li>
+ Are there different options available, depending on input from the Actor? (Example: If the Actor enters an invalid
+ PIN number while accessing an ATM.)
+ </li>
+ <li>
+ What business rules may come into play? (Example: The Actor requests more money from the ATM than is available in
+ her account.)
+ </li>
+ <li>
+ What could go wrong? (Example: No network connection available when required to perform a transaction.)
+ </li>
</ul>
-<p> It is best to develop these scenarios iteratively, as well. </p>
+<p>
+ It is best to develop these scenarios iteratively, as well.
+</p>
<ol>
- <li>Begin by identifying them. </li>
- <li>Examine each possible scenario to determine whether it is relevant, that 
- it can actually happen, and that it is distinct from other scenarios. </li>
- <li>Eliminate redundant or unnecessary scenarios. </li>
- <li>Prioritize the remaining scenarios and start detailing the more important 
- ones. </li>
+ <li>
+ Begin by identifying them.
+ </li>
+ <li>
+ Examine each possible scenario to determine whether it is relevant, that it can actually happen, and that it is
+ distinct from other scenarios.
+ </li>
+ <li>
+ Eliminate redundant or unnecessary scenarios.
+ </li>
+ <li>
+ Prioritize the remaining scenarios and start detailing the more important ones.
+ </li>
</ol>
-<p> In addition to the detailing the flow of events of each alternative flow in 
- the form described above, each alternative flow should describe: </p>
+<p>
+ In addition to the detailing the flow of events of each alternative flow in the form described above, each alternative
+ flow should describe:
+</p>
<ul>
- 
- <li> Where the alternative flow can be inserted in the basic flow of events</li>
- 
- <li> The condition that needs to be fulfilled for the alternative behavior to 
- start</li>
- 
- <li> How and where the basic flow of events is resumed, or how the use case 
- ends</li>
+ <li>
+ Where the alternative flow can be inserted in the basic flow of events
+ </li>
+ <li>
+ The condition that needs to be fulfilled for the alternative behavior to start
+ </li>
+ <li>
+ How and where the basic flow of events is resumed, or how the use case ends
+ </li>
</ul>
-<p> See Section 5 of&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_spec_CD5DD9B1.html" guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: 
- Use-Case Specification</a> for examples of completed alternative flows. </p>
-<h2> Structure the use case </h2>
-<p> It is useful to structure the use case according to scenarios. This helps 
- both to simplify communication and maintenance and to permit the use cases to 
- be implemented iteratively. Name and describe each key scenario so that these 
- may be prioritized, assigned to an iteration and an individual, and referenced 
- from the&nbsp;<a class="elementLink" href="./../../../openup/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work 
- Items List</a> for implementation. </p>
-<p> In addition to structuring the use cases according to scenarios, it is often 
- useful to structure the scenarios themselves into subflows. This provides an 
- additional level of granularity for planning work and tracking progress. Unless 
- a subflow involves only a minor part of the complete flow of events (which can 
- be described in the body of the text), describe each subflow in a separate section 
- of the Flow of Events section. Subflows that should be in a separate section 
- include these examples: </p>
+<p>
+ See Section 5 of&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_spec.html"
+ guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: Use-Case Specification</a> for examples of completed alternative flows.
+</p>
+<h2>
+ Structure the use case
+</h2>
+<p>
+ It is useful to structure the use case according to scenarios. This helps both to simplify communication and
+ maintenance and to permit the use cases to be implemented iteratively. Name and describe each key scenario so that
+ these may be prioritized, assigned to an iteration and an individual, and referenced from the&nbsp;<a
+ class="elementLink" href="./../../../openup/workproducts/work_items_list-3.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work
+ Items List</a> for implementation.
+</p>
+<p>
+ In addition to structuring the use cases according to scenarios, it is often useful to structure the scenarios
+ themselves into subflows. This provides an additional level of granularity for planning work and tracking progress.
+ Unless a subflow involves only a minor part of the complete flow of events (which can be described in the body of the
+ text), describe each subflow in a separate section of the Flow of Events section. Subflows that should be in a separate
+ section include these examples:
+</p>
<ul>
<li>
Subflows that occupy a large segment of a given flow of events.
</li>
- 
- <li> Exceptional and alternative flows of events. This helps the use case's 
- basic flow of events to stand out more clearly. </li>
- 
- <li> Any subflow that can be run at several intervals in the same flow of events. 
- </li>
+ <li>
+ Exceptional and alternative flows of events. This helps the use case's basic flow of events to stand out more
+ clearly.
+ </li>
+ <li>
+ Any subflow that can be run at several intervals in the same flow of events.
+ </li>
</ul>
-<p> If there are subflows identified that are common to multiple use cases, you 
- can re-factor your use-case model to include these. See&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/concepts/use_case_model_CD178AF9.html" guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: 
- Use-Case Model</a> for more information on the &lt;&lt;include&gt;&gt; dependency. 
+<p>
+ If there are subflows identified that are common to multiple use cases, you can re-factor your use-case model to
+ include these. See&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/concepts/use_case_model.html"
+ guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a> for more information on the &lt;&lt;include&gt;&gt;
+ dependency.
</p>
<p>
- For more information on structuring the use case, see the "Flow of Events - Structure" section&nbsp;in <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/use_case_BB199D1B.html" guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+ For more information on structuring the use case, see the "Flow of Events - Structure" section&nbsp;in <a
+ class="elementLinkWithType" href="./../../../openup/guidances/concepts/use_case-2.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
</p>
-<p> The&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/templates/uc_specification_E97E98B0.html" guid="_0cpNwMlgEdmt3adZL5Dmdw">Template: 
- Use-Case Specification</a> provides a suggested structure for the use case specification. 
- See&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/uc_model_evolve_960F136B.html" guid="_t4QdAMNqEdu2IdAIaWZyAw">Example: 
- Evolution of the Use-Case Model</a> and&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_spec_CD5DD9B1.html" guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: 
- Use-Case Specification</a> for examples of structuring the use-case model and 
- use case specifications, respectively. </p>
-<h2> Detail special requirements </h2>
-<p> Be sure to also capture any requirements that are related to the use case 
- but are not taken into consideration in the flow of events of the use case.&nbsp;These 
- requirements include business rules, design constraints, usability requirements, 
- performance requirements, reliability requirements, supportability requirements, 
- and interface requirements. These requirements all influence the implementation 
- and associated cost as much as the flow of events. Therefore, they must be agreed 
- upon and prioritized. </p>
-<p> Typically, nonfunctional requirements that refer to a specific use case are 
- captured in the Special Requirements section of the use case. For more information, 
- see the "Special Requirements" section in <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/use_case_BB199D1B.html" guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: 
- Use Case</a>. </p>
-<p> If there are nonfunctional requirements that apply to more than one use case, 
- capture these in the <a class="elementLinkWithType" href="./../../../openup/workproducts/supporting_requirements_spec_7D9DD47C.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: 
- Supporting Requirements Specification</a>. For more information on supporting 
- requirements, see <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/supporting_requirements_B2C4D610.html" guid="_VXZ5wO0IEdqHTdbLTmC5IQ">Concept: 
- Supporting Requirements</a>. </p>
-<p> For guidance in writing clear, concise, unambiguous special and supporting 
- requirements, see <a href="./../../../openup/guidances/guidelines/writing_good_requirements_48248536.html">Guidelines:&nbsp;Writing 
- Good Requirements</a> and <a class="elementLink" href="./../../../openup/guidances/guidelines/requirement_pitfalls_14EE9652.html" guid="_1AOsMO0JEdqHTdbLTmC5IQ">Requirement 
- Pitfalls</a>. </p>
<p>
- See Section 8 of&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_spec_CD5DD9B1.html" guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: Use-Case Specification</a> for examples of special requirements.
+ The&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/templates/uc_specification.html"
+ guid="_0cpNwMlgEdmt3adZL5Dmdw">Template: Use-Case Specification</a> provides a suggested structure for the use case
+ specification. See&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/uc_model_evolve.html"
+ guid="_t4QdAMNqEdu2IdAIaWZyAw">Example: Evolution of the Use-Case Model</a> and&nbsp;<a class="elementLinkWithType"
+ href="./../../../openup/guidances/examples/use_case_spec.html" guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: Use-Case
+ Specification</a> for examples of structuring the use-case model and use case specifications, respectively.
</p>
-<h2> Describe preconditions and post-conditions </h2>
-<p> A <strong>precondition</strong> of a use case explains the state that the system must 
- be in for the use case to be able to start. Be careful in describing the system 
- state. Avoid describing the detail of other, incidental activities that may 
- already have taken place. </p>
-<p> A <strong>post-condition</strong> of a use case lists possible states that the system can 
- be in after the use case runs. The system must be in one of those states. A 
- post-condition also states actions that the system performs at the end of the 
- use case, regardless of what occurred in the use case. Post-conditions may be 
- categorized as Minimal Guarantees&nbsp;or Success Guarantees:</p>
+<h2>
+ Detail special requirements
+</h2>
+<p>
+ Be sure to also capture any requirements that are related to the use case but are not taken into consideration in the
+ flow of events of the use case.&nbsp;These requirements include business rules, design constraints, usability
+ requirements, performance requirements, reliability requirements, supportability requirements, and interface
+ requirements. These requirements all influence the implementation and associated cost as much as the flow of events.
+ Therefore, they must be agreed upon and prioritized.
+</p>
+<p>
+ Typically, nonfunctional requirements that refer to a specific use case are captured in the Special Requirements
+ section of the use case. For more information, see the "Special Requirements" section in <a class="elementLinkWithType"
+ href="./../../../openup/guidances/concepts/use_case-2.html" guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+</p>
+<p>
+ If there are nonfunctional requirements that apply to more than one use case, capture these in the <a
+ class="elementLinkWithType" href="./../../../openup/workproducts/supporting_requirements_spec.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements Specification</a>. For more information on supporting
+ requirements, see <a class="elementLinkWithType"
+ href="./../../../openup/guidances/concepts/supporting_requirements-2.html" guid="_VXZ5wO0IEdqHTdbLTmC5IQ">Concept:
+ Supporting Requirements</a>.
+</p>
+<p>
+ For guidance in writing clear, concise, unambiguous special and supporting requirements, see&nbsp;guidelines <a
+ class="elementLink" href="./../../../openup/guidances/guidelines/writing_good_requirements.html"
+ guid="_6jXzYNcKEdqz_d2XWoVt6Q">Writing Good Requirements</a>&nbsp;and <a class="elementLink"
+ href="./../../../openup/guidances/guidelines/requirement_pitfalls.html" guid="_1AOsMO0JEdqHTdbLTmC5IQ">Requirement
+ Pitfalls</a>.
+</p>
+<p>
+ See Section 8 of&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_spec.html"
+ guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: Use-Case Specification</a> for examples of special requirements.
+</p>
+<h2>
+ Describe preconditions and post-conditions
+</h2>
+<p>
+ A <strong>precondition</strong> of a use case explains the state that the system must be in for the use case to be able
+ to start. Be careful in describing the system state. Avoid describing the detail of other, incidental activities that
+ may already have taken place.
+</p>
+<p>
+ A <strong>post-condition</strong> of a use case lists possible states that the system can be in after the use case
+ runs. The system must be in one of those states. A post-condition also states actions that the system performs at the
+ end of the use case, regardless of what occurred in the use case. Post-conditions may be categorized as Minimal
+ Guarantees&nbsp;or Success Guarantees:
+</p>
<ul>
- <li><b>Minimal Guarantees</b> represent conditions that will be true when the 
- use cases end, regardless of how they terminate. </li>
- <li><b>Success Guarantees </b>represent condition that will be true when the 
- use cases end successfully, regardless of which paths they took. </li>
+ <li>
+ <b>Minimal Guarantees</b> represent conditions that will be true when the use cases end, regardless of how they
+ terminate.
+ </li>
+ <li>
+ <b>Success Guarantees</b> represent condition that will be true when the use cases end successfully, regardless of
+ which paths they took.
+ </li>
</ul>
<p>
Consider the following when specifying preconditions and post-condition:
</p>
<ul>
- 
- <li> The states described by pre- or post-conditions should be states that the 
- user can observe. "The user has logged on to the system" or "The user has 
- opened the document" are examples of observable states. </li>
+ <li>
+ The states described by pre- or post-conditions should be states that the user can observe. "The user has logged on
+ to the system" or "The user has opened the document" are examples of observable states.
+ </li>
<li>
A precondition is a constraint on when a use case can start. It is not the event that starts the use case.
</li>
@@ -217,17 +288,19 @@
A precondition for a use case is not a precondition for only one subflow, although you can define preconditions and
post-conditions at the subflow level.
</li>
- 
- <li> A post-condition for a use case should be true regardless of which alternative 
- flows were executed; it should not be true only for the main flow. If something 
- could fail, you would cover that in the post-condition by saying "The action 
- has completed,&quot; or if something failed, &quot;The action was not performed," 
- rather than just "The action is completed."&nbsp; </li>
+ <li>
+ A post-condition for a use case should be true regardless of which alternative flows were executed; it should not
+ be true only for the main flow. If something could fail, you would cover that in the post-condition by saying "The
+ action has completed," or if something failed, "The action was not performed," rather than just "The action is
+ completed."&nbsp;
+ </li>
</ul>
<p>
- For more information, see the "Preconditions Post-conditions" section in <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/use_case_BB199D1B.html" guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+ For more information, see the "Preconditions Post-conditions" section in <a class="elementLinkWithType"
+ href="./../../../openup/guidances/concepts/use_case-2.html" guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
</p>
<p>
- See Section 7 of&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_spec_CD5DD9B1.html" guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: Use-Case Specification</a> for example pre- and post-conditions.
+ See Section 7 of&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_spec.html"
+ guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: Use-Case Specification</a> for example pre- and post-conditions.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/openup/guidances/guidelines/develop_architecture 2.xmi b/OpenUP/openup/guidances/guidelines/develop_architecture 2.xmi
deleted file mode 100644
index 353cbc9..0000000
--- a/OpenUP/openup/guidances/guidelines/develop_architecture 2.xmi
+++ /dev/null
@@ -1,167 +0,0 @@
-<?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="-K57GQWwsOy4jkTyqZoWs2A"
- name="develop_architecture,_mDf2EBapEduSTJywppIxVQ" guid="-K57GQWwsOy4jkTyqZoWs2A"
- changeDate="2007-02-26T03:44:53.453-0800" version="1.0.0">
- <mainDescription><h1> Identify architectural priorities </h1>
-<p> Architecture&nbsp;priorities&nbsp;can take the form of&nbsp;one or more <a class="elementLink" href="./../../../openup/guidances/concepts/arch_mech_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural 
- Mechanism</a>s that are brought into scope by association with the scenarios 
- prioritized for the current iteration. Other drivers may also be apparent. For 
- example, it may be necessary to move certain aspects of the architecture from 
- prototype- to production-quality implementation or to explore certain aspects 
- of the architecture to inform developers of future iterations. </p>
-<p> The architectural&nbsp;priorities are often&nbsp;driven by&nbsp;the development 
- of software that implements an&nbsp;<a class="elementLink" href="./../../../openup/guidances/concepts/arch_mech_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural 
- Mechanism</a>.&nbsp;It is important to specify the qualities of these mechanisms 
- precisely, and this may lead you to supplement the use (or &quot;usage&quot;) 
- scenarios with quality attributes. Because more than one use scenario may place 
- demands on the same mechanisms, it may be helpful to consolidate these into 
- quality scenarios. </p>
-<p> For example, if you want a system to be secure, specify the types of threats. 
- Quality scenarios are one way to express desired qualities in collaboration 
- with the system stakeholders [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">KAZ04</a>]. 
- Walk through things that could happen to the system and how it would respond. 
- <strong>Use-case scenarios</strong> focus on runtime behavior where the stakeholder is the user. 
- <strong>Quality scenarios</strong> encompass other interactions with the system as well, such 
- as system maintenance staff modifying the system. </p>
-<p> Several scenarios may be devised for each quality attribute (such as usability, 
- reliability, performance, or&nbsp;security). For example: security scenarios 
- for denial of service and unauthorized access. A good scenario makes clear what 
- the stimulus is, what causes it, and what responses are appropriate. </p>
-<p>
- Example:
-</p>
-<blockquote>
- <p>
- During peak operation, an unauthorized intruder tries to download prohibited data through the system
- administrator’s interface. The system detects the attempt, blocks access, and notifies the supervisor within 15
- seconds.
- </p>
-</blockquote>
-<p>
- After you have collected the scenarios, you need to establish priorities for them. Use scenarios to realize
- requirements, so that their mapping onto the architecture, their impact, and their interactions can be understood.
-</p>
-<h2> Refine the Architectural Mechanisms </h2>
-<p> Consider each high-priority quality scenario, and map each of these onto the 
- Architectural Mechanisms. Refine the mechanisms to identify the specific technology 
- that will handle each mechanism in scope. For example, for the Persistence mechanism, 
- it may be appropriate to&nbsp;use a relational database management system, such 
- as MySQL.&nbsp;Consider the selection of technology in the context of the requirements 
- and constraints. </p>
-<p>
- See <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/arch_mech_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a> for more information.
-</p>
-<h2> Identify Business Patterns </h2>
-<p> The&nbsp;architecture of&nbsp;a software system can often be characterized 
- by a small number of essential scenarios. For example, for an online bookstore, 
- describing the way the software handles the scenarios for ordering a book and 
- checking out the shopping cart are often enough to communicate the essence of 
- the architecture. Such business patterns also provide a useful blueprint for 
- similar functionality throughout the system. </p>
-<h2> Identify reuse opportunities </h2>
-<p> After looking for similar behavior and returned values, look for similarity 
- of parameters. If the interfaces&nbsp;are not an exact match for the component 
- interfaces being proposed, you can modify the proposed&nbsp;signatures to increase 
- the degree of reuse. Some design mechanisms, such as performance or security 
- requirements, may disqualify a component from reuse even when there is&nbsp;a 
- perfect match between operation signatures. </p>
-<p align="left"> A common set of components may exist that provides many of the 
- <a class="elementLink" href="./../../../openup/guidances/concepts/arch_mech_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural 
- Mechanisms</a> that you need&nbsp;for the new system. These components may be 
- available either because they were developed or purchased previously for&nbsp;similar 
- systems. Given their suitability and compatibility within the software architecture, 
- there may be a need to reverse-engineer these components to represent them in 
- a design model and reuse them in a project. </p>
-<p align="left">
- Similar thinking applies to&nbsp;existing databases. Part of the information to be used by the application under
- development may already reside in a database. You may be able to get the classes that represent the database structures
- that hold this information by reverse-engineering the database.
-</p>
-<h2 align="left"> Identify architecturally significant design elements </h2>
-<p align="left"> Consider&nbsp;each high-priority&nbsp;scenario in scope. Walk 
- through the actions that the&nbsp;scenario initiates, and highlight the areas 
- of the architecture that participate in realizing, or implementing, the requirements. 
-</p>
-<p>
- Identifying components will help hide the complexity of the system and help you work at a higher level. Components need
- to be internally cohesive and to provide external services through a limited interface. Component identification can
- be&nbsp;based on architectural layers, deployment choices, or key abstractions. Ask yourself these questions:
-</p>
-<ul>
- <li>
- What is logically or functionally related (same use case or service, for example)?
- </li>
- <li>
- What entities provide services to multiple others?
- </li>
- <li>
- What entities depend on each other? Strongly or weakly?
- </li>
- <li>
- What entities should you be able to exchange independently from others?
- </li>
- <li>
- What will run on the same processor or network node?
- </li>
- <li>
- What parts are constrained by similar performance requirements?
- </li>
-</ul>
-<p>
- Each component includes entities from the problem domain, control classes that coordinate complex tasks within
- components, and interfaces that handle communication with the environment. The interface for each instantiated element
- is identified. At this point, interfaces do not need to be as detailed as a signature, but they do need to document
- what the elements need, what they can use, and what they can depend on.
-</p>
-<p> Identified patterns define the types of elements but not a specific number. 
- Apply the chosen patterns to define a new set of elements that conform to the 
- patterns. Functionality will be allocated to the instantiated elements. </p>
-<h2> Define development and test architectures </h2>
-<p>
- The development and test architectures may be different from the target production implementation.
-</p>
-<ul>
- <li>
- Additional software may need to be developed to support testing.
- </li>
- <li>
- Alternative deployment configurations may need to be defined in response to constraints on development hardware.
- </li>
- <li>
- Multiple environments may be required to support different categories of tests.
- </li>
-</ul>
-<p>
- In each case, you need to specify the architecture. Also, be sure to consider the impact on the quality of the overall
- architecture.
-</p>
-<h2> Validate the architecture </h2>
-<p> The surest way to validate the architecture is through software. The software 
- developed up to the end of the Elaboration phase is largely aiming to validate 
- the architecture, to the point where it can be baselined, thereby providing 
- some level of stability during the Construction phase. </p>
-<p> It can also be useful to perform simple validation by walking through the 
- main design concepts and models, perhaps around a whiteboard or through other 
- collaborative techniques. This can help refine thinking but will not act as 
- a substitute for building some software. </p>
-<h2> Communicate decisions </h2>
-<p>
- You can document and communicate your decisions as many ways as you wish:
-</p>
-<ul>
- 
- <li> Publication of&nbsp;reference source code</li>
- 
- <li> Publication of&nbsp;reference models</li>
- 
- <li> Publication of&nbsp;software architecture documentation</li>
- 
- <li> Formal&nbsp;presentations of the material</li>
- <li>
- Informal walkthroughs of the architecture
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/openup/guidances/guidelines/repres_interfaces_to_ext_systems.xmi b/OpenUP/openup/guidances/guidelines/repres_interfaces_to_ext_systems.xmi
deleted file mode 100644
index f5075d3..0000000
--- a/OpenUP/openup/guidances/guidelines/repres_interfaces_to_ext_systems.xmi
+++ /dev/null
@@ -1,46 +0,0 @@
-<?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:rmc="http://www.ibm.com/rmc" xmlns:epf="http://www.eclipse.org/epf"
- epf:version="1.2.0" xmi:id="_iCwb8MM3EdmSIPI87WLu3g"
- name="repres_interfaces_to_ext_systems,_0gjdYMlgEdmt3adZL5Dmdw" guid="_iCwb8MM3EdmSIPI87WLu3g"
- changeDate="2007-02-26T04:05:55.921-0800" version="1.0.0">
- <mainDescription><p>
- Interfaces with external systems should be consistently handled throughout the system, so markers need to be identified
- in the architecture to make sure that the team develop the coherant software. The architecture need not include a
- specific, detailed design for each system interface. It is often enough to simply identify the existence of the
- interfacre as a significant part of the architecture and create a subsystem to encapsulate the detail, so that it can
- be developed later.
-</p>
-<p>
- The <a class="elementLink" href="./../../../openup/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;provides the basis for a useful technique to
- support this.
-</p>
-<p>
- If the system communicates with another system, define one or more boundary classes to describe the communication
- protocol. An external system may be anything from software to hardware units that the current system will use, such as
- printers, terminals, alarm devices, and sensors. In each case, a boundary class that mediates the communication with
- the external system will be identified.
-</p>
-<p>
- Example:
-</p>
-<blockquote>
- <p>
- An automated teller machine (ATM) must communicate with the ATM network to ascertain whether a customer's bank
- number and PIN are correct, and whether the customer has sufficient funds to withdrawal the requested amount. The
- ATM network is an external system (from the perspective of the ATM); therefore, you would use a
- <strong>boundary</strong> class to represent it in a use-case analysis.
- </p>
-</blockquote>
-<p>
- If the interfaces with the system are simple and well-defined, a single class may be sufficient to represent the
- external system. Often, however, these interfaces are too complex to be represented by using a single class; they often
- require complex collaborations of many classes. Moreover, interfaces between systems are often highly reusable across
- applications. As a result, in many cases, a subsystem models the system interfaces more appropriately.
-</p>
-<p>
- The use of a subsystem allows the interface to the external system to be defined and stabilized, while leaving the
- design details of the system interface hidden as the system evolves.<br />
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/openup/guidances/guidelines/using_patterns.xmi b/OpenUP/openup/guidances/guidelines/using_patterns.xmi
deleted file mode 100644
index 4d6ed9d..0000000
--- a/OpenUP/openup/guidances/guidelines/using_patterns.xmi
+++ /dev/null
@@ -1,42 +0,0 @@
-<?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:rmc="http://www.ibm.com/rmc" xmlns:epf="http://www.eclipse.org/epf"
- epf:version="1.2.0" xmi:id="-U-5cLUk-mdaO518lh5CxTQ"
- name="using_patterns,_0cr7cACrEdu8m4dIntu6jA" guid="-U-5cLUk-mdaO518lh5CxTQ" changeDate="2006-09-21T15:38:16.868-0700"
- version="1.0.0">
- <mainDescription><p>
- In software design, it is primarily the development method and not the pattern and its pattern language that influences
- the process of pattern selection and use. As discussed in <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/pattern_10BE6D96.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a>, Alexander developed the concept of generative pattern languages
- to guide a designer’s application of individual patterns to the entire design. In software design, however, as
- Alexander observed [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">OOP96</a>] there is little evidence of using generative pattern languages.
-</p>
-<p>
- For iterative development methods, software patterns and pattern languages support the development method through their
- ability to be applied incrementally, or by piecemeal growth, and by providing extensible structures. From an
- architectural perspective, these two qualities allow software architecture to be designed and refactored incrementally,
- thus so avoid the need for a so-called "big, up-front design."
-</p>
-<h4>
- Piecemeal growth
-</h4>
-<p>
- The term <strong>piecemeal growth</strong>, as it applies to patterns, originates in Alexander's work. It refers to a
- top-down design process in which a design starts from a high-level structure that is embellished or refined through the
- implementation of lower-level patterns. For software development, this corresponds to using hierarchies of
- architectural and design patterns and idioms like those proposed by Buschmann et. al. [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>]. Using the idea of piecemeal growth, an architect can start with one or more
- architectural patterns to provide an architectural vision for the design, and then progressively extend the design
- using design patterns. For example, an interactive application may use the Model-View-Controller pattern as its
- architectural vision, then during implementation the Command pattern may be selected to implement the Controller
- component.
-</p>
-<h4>
- Extensibility
-</h4>
-<p>
- A key aspect of object oriented design patterns is their ability to support extension without causing the rewriting of
- existing code. This feature allows a bottom up approach to the design process through code refactoring. When a problem
- is encountered during coding such as duplicate code, the developer can weighed up various patterns and their tradeoffs
- and select the appropriate solution in the context of the application.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/openup/plugin.xmi b/OpenUP/openup/plugin.xmi
index 3a22930..ea0ce5f 100644
--- a/OpenUP/openup/plugin.xmi
+++ b/OpenUP/openup/plugin.xmi
@@ -2,8 +2,7 @@
<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.4/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.2.0">
+ xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0">
<org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nHk9MPL5Edm6Nvont3uinw"
guid="_nHk9MPL5Edm6Nvont3uinw">
<subManagers xmi:id="_nI06YvL5Edm6Nvont3uinw" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_nI06YvL5Edm6Nvont3uinw"/>
@@ -191,8 +190,6 @@
uri="guidances/guidelines/test_suite.xmi"/>
<resourceDescriptors xmi:id="_nuo9MPL5Edm6Nvont3uinw" id="_On0agNSAEdmLhZ9H5Plxyw"
uri="guidances/guidelines/req_gathering_techniques.xmi"/>
- <resourceDescriptors xmi:id="_nuo9MvL5Edm6Nvont3uinw" id="_iCwb8MM3EdmSIPI87WLu3g"
- uri="guidances/guidelines/repres_interfaces_to_ext_systems.xmi"/>
<resourceDescriptors xmi:id="_nuo9M_L5Edm6Nvont3uinw" id="_lbGQwMM3EdmSIPI87WLu3g"
uri="guidances/guidelines/layering.xmi"/>
<resourceDescriptors xmi:id="_nu1KcPL5Edm6Nvont3uinw" id="_qS8JcMM3EdmSIPI87WLu3g"
@@ -357,8 +354,6 @@
uri="guidances/concepts/phase_milestones.xmi"/>
<resourceDescriptors xmi:id="_ZXEuAClFEduLGM8dfVsrKg" id="-cnGBBA4NXmhTIjHjlHx4Mw"
uri="guidances/guidelines/architectural_view.xmi"/>
- <resourceDescriptors xmi:id="_2hWugClTEduLGM8dfVsrKg" id="-U-5cLUk-mdaO518lh5CxTQ"
- uri="guidances/guidelines/using_patterns.xmi"/>
<resourceDescriptors xmi:id="_DLM38ColEduK2emCyq5fBw" id="-X7QSjItNBz7w8603yBCv0Q"
uri="guidances/guidelines/abstract_away_complexity.xmi"/>
<resourceDescriptors xmi:id="_XQS1oC5REduVhuZHT5jKZQ" id="-VGT8iHGtQSiOUGitq1qmow"
@@ -555,8 +550,6 @@
uri="guidances/termdefinitions/attribute.xmi"/>
<resourceDescriptors xmi:id="_brXFwOX7Edu8VZPtlaU33g" id="-g0jWGmg-E0rCQEmnibTDIA"
uri="guidances/guidelines/refactoring.xmi"/>
- <resourceDescriptors xmi:id="_zAzLkOmzEdupia_tZIXEqg" id="-K57GQWwsOy4jkTyqZoWs2A"
- uri="guidances/guidelines/develop_architecture%202.xmi"/>
<resourceDescriptors xmi:id="_En710Om-Edupia_tZIXEqg" id="-8LfKJab2khAUjdmnImaXPA"
uri="guidances/examples/architectural_mechanism_attributes.xmi"/>
<resourceDescriptors xmi:id="_AtgW0O0PEduUpsu85bVhiQ" id="-Vp61zQMUoP-Icm5jgDar7A"
@@ -682,7 +675,7 @@
<contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TX9AMlgEdmt3adZL5Dmdw"
name="architecture" guid="_0TX9AMlgEdmt3adZL5Dmdw" briefDescription="This discipline explains how to create an architecture from architecturally significant requirements. The architecture is built in the Development discipline."
presentationName="Architecture" conceptsAndPapers="_mzxI0A4LEduibvKwrGxWxA _HrZGIA4MEduibvKwrGxWxA _Z53x0BapEduSTJywppIxVQ _0YP18MlgEdmt3adZL5Dmdw _0YJvUMlgEdmt3adZL5Dmdw _0XY6UMlgEdmt3adZL5Dmdw _O1kAANvfEduv2KOT-Teh6w __O7tAMVvEduLYZUGfgZrkQ"
- checklists="_17PYUNd6EdmIm-bsRSNCgw" guidelines="_we3F4ACpEdu8m4dIntu6jA _T9nygClEEduLGM8dfVsrKg _mDf2EBapEduSTJywppIxVQ _0gpkAMlgEdmt3adZL5Dmdw _0gjdYMlgEdmt3adZL5Dmdw _42UD4A3tEduibvKwrGxWxA _J6BKgNvIEduv2KOT-Teh6w _D3JXMNvKEduv2KOT-Teh6w _uF-QYEAhEdq_UJTvM1DM2Q"
+ checklists="_17PYUNd6EdmIm-bsRSNCgw" guidelines="_we3F4ACpEdu8m4dIntu6jA _T9nygClEEduLGM8dfVsrKg _mDf2EBapEduSTJywppIxVQ _0gpkAMlgEdmt3adZL5Dmdw _42UD4A3tEduibvKwrGxWxA _J6BKgNvIEduv2KOT-Teh6w _D3JXMNvKEduv2KOT-Teh6w _uF-QYEAhEdq_UJTvM1DM2Q"
tasks="_0f-1oMlgEdmt3adZL5Dmdw _0gRJgMlgEdmt3adZL5Dmdw">
<presentation xmi:id="_Bbq2MLv-EdmmUvZAZjqE3g" href="uma://_Bbq2MLv-EdmmUvZAZjqE3g#_Bbq2MLv-EdmmUvZAZjqE3g"/>
<referenceWorkflows href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7islgEdmt3adZL5Dmdw"/>
@@ -845,7 +838,7 @@
</contentElements>
<contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_2l8U4K4sEdudp4CB-AFxtw"
name="architectural_mechanisms" guid="_2l8U4K4sEdudp4CB-AFxtw" briefDescription="Information about how to use use architectural mechansims to create a robust architecture."
- presentationName="Architectural mechanisms" categorizedElements="_mzxI0A4LEduibvKwrGxWxA _HrZGIA4MEduibvKwrGxWxA _0YJvUMlgEdmt3adZL5Dmdw _0cr7cACrEdu8m4dIntu6jA _O39h0O9pEdu635i_iQ5Jag _eQ_s8Om5Edupia_tZIXEqg"/>
+ presentationName="Architectural mechanisms" categorizedElements="_mzxI0A4LEduibvKwrGxWxA _HrZGIA4MEduibvKwrGxWxA _0YJvUMlgEdmt3adZL5Dmdw _O39h0O9pEdu635i_iQ5Jag _eQ_s8Om5Edupia_tZIXEqg"/>
<contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_RdM7MMXnEduywMSzPTUUwA"
name="openup_treebrowser" guid="_RdM7MMXnEduywMSzPTUUwA" presentationName="OpenUP">
<categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_BTJ_YMXwEduywMSzPTUUwA"/>
@@ -953,7 +946,7 @@
<contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_2plxwBOMEduCNqgZdt_OaA"
name="elaboration_phase" guid="_2plxwBOMEduCNqgZdt_OaA" briefDescription="This is the second phase in the project lifecycle, where major technical and non-technical risks are addressed, allowing us to produce more accurate schedules and cost estimates. "
presentationName="Elaboration Phase" conceptsAndPapers="_0bsLgMlgEdmt3adZL5Dmdw _9gocwMvoEdqukPpotm3DYg _KkTIsMp7EdqC_NfSivunjA"
- guidelines="_y-Q08OmzEdupia_tZIXEqg _42UD4A3tEduibvKwrGxWxA">
+ guidelines="_42UD4A3tEduibvKwrGxWxA _mDf2EBapEduSTJywppIxVQ">
<presentation xmi:id="-F-eWIBzxEXE1jygbN3nrrQ" href="uma://-F-eWIBzxEXE1jygbN3nrrQ#-F-eWIBzxEXE1jygbN3nrrQ"/>
</contentElements>
<contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_48EKsBOMEduCNqgZdt_OaA"
@@ -1604,26 +1597,6 @@
name="analyze_arch_reqs_ucm" guid="_YdaogAI9Edu5WetVoS7Gvw" variabilityType="contributes"
variabilityBasedOnElement="_0f-1oMlgEdmt3adZL5Dmdw" mandatoryInput="_W2SgEDR5EdutE_HNDTJk5Q"/>
</childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_h15dULCxEdujaOuld2kPdg"
- name="deprecated" guid="_h15dULCxEdujaOuld2kPdg" briefDescription="This is a temporary content package to hold old copies of elements while they are refactored for release 1.0 It should be deleted before final release. This package should not be published.">
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0cr7cACrEdu8m4dIntu6jA"
- name="using_patterns" guid="_0cr7cACrEdu8m4dIntu6jA" briefDescription="This guidance discusses the practical application of patterns in a project."
- presentationName="Using Patterns">
- <presentation xmi:id="-U-5cLUk-mdaO518lh5CxTQ" href="uma://-U-5cLUk-mdaO518lh5CxTQ#-U-5cLUk-mdaO518lh5CxTQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0gjdYMlgEdmt3adZL5Dmdw"
- name="repres_interfaces_to_ext_systems" guid="_0gjdYMlgEdmt3adZL5Dmdw"
- briefDescription="This guideline introduces system level interfaces."
- presentationName="Representing Interfaces to External Systems" guidelines="_uF-QYEAhEdq_UJTvM1DM2Q">
- <presentation xmi:id="_iCwb8MM3EdmSIPI87WLu3g" href="uma://_iCwb8MM3EdmSIPI87WLu3g#_iCwb8MM3EdmSIPI87WLu3g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_y-Q08OmzEdupia_tZIXEqg"
- name="develop_architecture" guid="_y-Q08OmzEdupia_tZIXEqg" briefDescription="This guideline provides additional information to support the ongoing refinement and development of the architecture."
- presentationName="Develop the Architecture" conceptsAndPapers="_Z53x0BapEduSTJywppIxVQ"
- guidelines="_T9nygClEEduLGM8dfVsrKg">
- <presentation xmi:id="-K57GQWwsOy4jkTyqZoWs2A" href="uma://-K57GQWwsOy4jkTyqZoWs2A#-K57GQWwsOy4jkTyqZoWs2A"/>
- </contentElements>
- </childPackages>
<contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0YJvUMlgEdmt3adZL5Dmdw"
name="pattern" guid="_0YJvUMlgEdmt3adZL5Dmdw" briefDescription="A generalized solution that can be implemented and applied in a problem situation (a context) and thereby eliminate one or more of the inherent problems."
presentationName="Pattern">
@@ -1665,8 +1638,7 @@
</contentElements>
<contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0gpkAMlgEdmt3adZL5Dmdw"
name="layering" guid="_0gpkAMlgEdmt3adZL5Dmdw" briefDescription="Guidance on the possible ways for partitioning the system."
- presentationName="Layering" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw"
- guidelines="_0cr7cACrEdu8m4dIntu6jA">
+ presentationName="Layering" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw">
<presentation xmi:id="_lbGQwMM3EdmSIPI87WLu3g" href="uma://_lbGQwMM3EdmSIPI87WLu3g#_lbGQwMM3EdmSIPI87WLu3g"/>
</contentElements>
<contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_42UD4A3tEduibvKwrGxWxA"
@@ -1801,8 +1773,6 @@
name="analyze_the_design_vm" guid="_m42lMPTeEduDKIuqTXQ8SA" variabilityType="contributes"
variabilityBasedOnElement="__MnggPTdEduDKIuqTXQ8SA" guidelines="_1fM3AC9_EduW5uTjiIcspQ"/>
</childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_XIwYQPTYEduDKIuqTXQ8SA"
- name="deprecated" guid="_XIwYQPTYEduDKIuqTXQ8SA"/>
<contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0YoQcMlgEdmt3adZL5Dmdw"
name="implementation" guid="_0YoQcMlgEdmt3adZL5Dmdw" briefDescription="Software code files, data files, and supporting files such as online help files that represent the raw parts of a system that can be built."
presentationName="Implementation" conceptsAndPapers="_0lnRMMqOEduwrYVlQ9zp3w"
