| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:TaskDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="_NrC20qeqEdmKDbQuyzCoqQ" |
| name="design_solution,_0fshwMlgEdmt3adZL5Dmdw" guid="_NrC20qeqEdmKDbQuyzCoqQ" |
| changeDate="2007-07-25T12:19:31.752-0700" version="1.0.0"> |
| <mainDescription><p>
 |
| This task is about designing part of the system, not the whole system. It should be applied based upon some small
 |
| subset of the requirements. The requirements driving the <a class="elementLink"
 |
| href="./../../openup/workproducts/design.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a> could be scenario-based
 |
| functional requirements, non-functional requirements, or a combination.
 |
| </p>
 |
| <p>
 |
| This task can be applied in some specific context such as the database access elements required for some scenario. In
 |
| this case the task might be applied again later to deal with a different context on the same requirements. Keep in mind
 |
| that to actually build some functionality of value to the users, all contexts will typically need to be designed and
 |
| implemented. For example, to complete a piece of system capability it must be designed and implemented in all its
 |
| contexts including the user interface, business rules, database access, etc.
 |
| </p>
 |
| <p>
 |
| For cohesion and completeness, this task is described as an end-to-end pass of designing a scenario of system usage. In
 |
| practice, this task will be revisited many times as the design is first considered, portions are implemented, more
 |
| design is performed based on what was learned, etc. The healthiest application of this task is in very close proximity
 |
| to the implementation.
 |
| </p>
 |
| <p>
 |
| If this task is being performed on an architecturally significant element, the results of this design should be
 |
| referenced by the <a class="elementLink" href="./../../openup/workproducts/architecture_notebook.html"
 |
| guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>. See <a class="elementLinkWithType"
 |
| href="./../../openup/guidances/guidelines/determine_architecturally_significant_requirements.html"
 |
| guid="_D3JXMNvKEduv2KOT-Teh6w">Guideline: Determine Architecturally Significant Requirements</a> for more information.
 |
| </p></mainDescription> |
| <sections xmi:id="_4Z7WYKuKEdmhFZtkg1nakg" name="Understand requirement details" |
| guid="_4Z7WYKuKEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| 
 |
| 
 |
| Examine the relevant <a class="elementLink" href="./../../openup/workproducts/use_case_22BE66E2.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>s and <a class="elementLink" href="./../../openup/workproducts/supporting_requirements_spec_7D9DD47C.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements Specification</a>&nbsp;to understand the scope of the design task and the expectations on the Design. Work
 |
| 
 |
| 
 |
| with the&nbsp;<a class="elementLink" href="./../../openup/roles/stakeholder_9FFD4106.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a> and Analyst to clarify ambiguous or missing information. See <a class="elementLinkWithType" href="./../../openup/guidances/guidelines/analyze_the_design_4C4750C0.html" guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>.
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| If the requirements are not represented in some sort of scenario form (for example a non-functional requirement might
 |
| 
 |
| 
 |
| not have a scenario associated with it), a scenario will have to be identified that appropriately exercises the
 |
| 
 |
| 
 |
| requirements under consideration.
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| If the requirements are&nbsp;determined to be incomplete or incorrect, work with an analyst and stakeholder to get the
 |
| 
 |
| 
 |
| requirements improved and possibly submit a change request against the requirements.
 |
| 
 |
| 
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_Ci7aYFixEdusJoWkvSRO9Q" name="Understand the architecture" guid="_Ci7aYFixEdusJoWkvSRO9Q"> |
| <sectionDescription><p>
 |
| Review the Architecture Notebook to identify changes and additions to the architecture. See <a
 |
| class="elementLinkWithType" href="./../../openup/guidances/guidelines/evolve_the_design.html"
 |
| guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a> for more information. Work with the architect if there
 |
| is any uncertainty on the understanding of relevant parts of the architecture or of the conformance of the design
 |
| strategy.
 |
| </p>
 |
| <p>
 |
| This step can be skipped if there were no changes to the&nbsp;architecture in the previous iteration
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_--6tYKuKEdmhFZtkg1nakg" name="Identify design elements" guid="_--6tYKuKEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| Identify the elements that collaborate together to provide the required behavior. This can start with the key
 |
| abstractions identified in the Architecture Notebook, design, domain analysis, and classical analysis of the
 |
| requirements (noun filtering) to derive the elements that would be required to fulfill them. The <a class="elementLink" href="./../../openup/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> provides a good start for identifying elements. Also
 |
| see <a class="elementLinkWithType" href="./../../openup/guidances/guidelines/analyze_the_design_4C4750C0.html" guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>.
 |
| </p>
 |
| <p>
 |
| Existing elements of the design should be examined to see if they should participate in the collaboration. It is a
 |
| mistake to create all new elements in each execution of this task.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_A_LU8KuLEdmhFZtkg1nakg" name="Determine how elements collaborate to realize the scenario" |
| guid="_A_LU8KuLEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| Walk through the scenario distributing responsibilities to the participating elements and ensuring that the elements
 |
| have the relationships required to collaborate.
 |
| </p>
 |
| <p>
 |
| These responsibilities can be simple statements of behavior assigned to elements; they need not be detailed operation
 |
| specifications with parameters, etc. Similarly, the relationships can just be defined at this step. This step is about
 |
| ensuring that a quality model is being created that is robust enough to support the requirements. See <a class="elementLinkWithType" href="./../../openup/guidances/guidelines/analyze_the_design_4C4750C0.html" guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>.
 |
| </p>
 |
| <p>
 |
| Look to the Architecture Notebook and previous design work to create a consistent collaboration. Work with the
 |
| architect to understand the details and motivations of the architecture. Look to reuse existing behavior and relations
 |
| or to apply similar structure to simplify the design of the overall system.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_ENwJwKuLEdmhFZtkg1nakg" name="Refine design decisions" guid="_ENwJwKuLEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| 
 |
| 
 |
| Refine the design to an appropriate level of detail to drive implementation and to ensure that it fits into the
 |
| 
 |
| 
 |
| architecture. In this step the design can take into consideration the actual implementation language and other
 |
| 
 |
| 
 |
| technical decisions. Revisit the identification of the elements and the collaborations that realize the scenarios if
 |
| 
 |
| 
 |
| necessary as this refinement takes into consideration details at a lower level of abstraction. Discuss testability
 |
| 
 |
| 
 |
| issues, such as design elements that are difficult to test or critical performance areas, with the tester and
 |
| 
 |
| 
 |
| architect.
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| Evolve the design by examining recent changes in the larger context of the design and determine if refactoring and
 |
| 
 |
| 
 |
| redesigning techniques will improve the robustness, flexibility, and understandability of the design. See <a class="elementLinkWithType" href="./../../openup/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a> for guidance specific design decisions and on making
 |
| 
 |
| 
 |
| design improvements just when they're needed.
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| Incorporate <a class="elementLink" href="./../../openup/guidances/concepts/arch_mech_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s from the architecture. Apply consistent structure of the
 |
| 
 |
| 
 |
| elements and organization of the behavior as in other areas of the design and use patterns identified in the
 |
| 
 |
| 
 |
| architecture.
 |
| 
 |
| 
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_KNZYAKuLEdmhFZtkg1nakg" name="Design internals (for large or complex elements)" |
| guid="_KNZYAKuLEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| 
 |
| 
 |
| Design large or complex elements or some complex internal behavior in more detail.
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| This might just involve devising an algorithm that could be performed to produce the desired behavior. Add additional
 |
| 
 |
| 
 |
| operations, attributes, and relationships to support the expectations of an element.
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| Design the state of the element over the course of its lifetime to ensure its proper behavior in various circumstances.
 |
| 
 |
| 
 |
| It may be useful to describe a state machine for elements with complex states.
 |
| 
 |
| 
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_mUVt8BfnEduD353bkQ4frw" name="Evaluate the Design" guid="_mUVt8BfnEduD353bkQ4frw"> |
| <sectionDescription><p>
 |
| 
 |
| 
 |
| Evaluate the object design for coupling, cohesion, and other quality design measurements.
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| Consider the design from various angles to ensure that it is a high-quality, communicable design. Work with other
 |
| 
 |
| 
 |
| technical team members; an independent party can provide a fresh perspective. Use the tester and architect to provide
 |
| 
 |
| 
 |
| perspectives on design quality and adherence to the architecture. However, when identifying potential reviewers keep in
 |
| 
 |
| 
 |
| mind that if someone can add value by reviewing the design, then perhaps they could have added even more value by
 |
| 
 |
| 
 |
| actively participating in the design effort itself. If design flaws are identified, improve the design.
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| See <a class="elementLinkWithType" href="./../../openup/guidances/concepts/design_E36137FA.html" guid="_bFjlAPTYEduDKIuqTXQ8SA">Concept: Design</a>, <a class="elementLinkWithType" href="./../../openup/guidances/guidelines/analyze_the_design_4C4750C0.html" guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>, and <a class="elementLinkWithType" href="./../../openup/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a> for more information.
 |
| 
 |
| 
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_OGYbwKuLEdmhFZtkg1nakg" name="Communicate the Design" guid="_OGYbwKuLEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| Communicate&nbsp;the system's design to&nbsp;those who need to understand it. Though this is described here toward the
 |
| end of the task, communication should be going on throughout the steps. Working collaboratively is always better than
 |
| reviewing the work after it is complete.
 |
| </p>
 |
| <p>
 |
| Here are some ways to communicate&nbsp;the design:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Formal models&nbsp;specified in UML.
 |
| </li>
 |
| <li>
 |
| Informal diagrams that render static structure and capture&nbsp;dynamic behavior.
 |
| </li>
 |
| <li>
 |
| Annotated code that communicates information about the static structure. This can be&nbsp;supplemented with textual
 |
| descriptions of collaborative behavior across code modules.
 |
| </li>
 |
| <li>
 |
| Data models to describe the database schema.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Here are some examples of individuals&nbsp;who will need to understand the design of the system:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Developers&nbsp;who will implement a solution based on the design.
 |
| </li>
 |
| <li>
 |
| Architects who can review the design to ensure that it conforms to the architecture or who might examine the design
 |
| for opportunities to improve the architecture.
 |
| </li>
 |
| <li>
 |
| Other designers who can examine the design for applicability to other parts of the system.
 |
| </li>
 |
| <li>
 |
| Developers or other designers who will be working on other parts of the system that will&nbsp;depend on the
 |
| elements designed in this task.
 |
| </li>
 |
| <li>
 |
| Other reviewers&nbsp;who will review the design for quality and adherence to standards.
 |
| </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <keyConsiderations><p>
 |
| 
 |
| 
 |
| 
 |
| 
 |
| Each step in this task can cause all previous steps to be revisited in light of new information and decisions.&nbsp;For
 |
| 
 |
| 
 |
| 
 |
| 
 |
| example, while determining how elements collaborate&nbsp;you might find a gap in the requirements that cause you to go
 |
| 
 |
| 
 |
| 
 |
| 
 |
| back to the beginning after collaborating with the&nbsp;<a class="elementLink" href="./../../openup/roles/analyst_39D7C49B.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a>. Or when evaluating the
 |
| 
 |
| 
 |
| 
 |
| 
 |
| design a reviewer could&nbsp;note that a reusable element doesn't work as expected and that could cause you to identify
 |
| 
 |
| 
 |
| 
 |
| 
 |
| new elements to take its place.
 |
| 
 |
| 
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| 
 |
| 
 |
| Consider the architecture while performing this task.&nbsp;All design work must be done while regarding the
 |
| 
 |
| 
 |
| 
 |
| 
 |
| architecture within which the Design exists.&nbsp;Furthermore, certain design elements will be deemed architecturally
 |
| 
 |
| 
 |
| 
 |
| 
 |
| significant; those elements will require updates to the architecture.
 |
| 
 |
| 
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| 
 |
| 
 |
| This task will be applied numerous times.&nbsp;Design is best performed in small chunks.
 |
| 
 |
| 
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| 
 |
| 
 |
| Even when starting the design for a particular project it&nbsp;is expected that there will be existing frameworks and
 |
| 
 |
| 
 |
| 
 |
| 
 |
| reusable elements.&nbsp;Every step of this task must give attention to the existing Design and existing&nbsp;<a class="elementLink" href="./../../openup/workproducts/implementation_917CA61E.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a>, utilizing existing elements when possible and emulating or improving
 |
| 
 |
| 
 |
| 
 |
| 
 |
| existing elements as appropriate while designing this portion of the solution.
 |
| 
 |
| 
 |
| 
 |
| 
 |
| </p>
 |
| 
 |
| 
 |
| 
 |
| 
 |
| <p>
 |
| 
 |
| 
 |
| 
 |
| 
 |
| Apply patterns throughout this task.&nbsp;Patterns represent proven designs and their usage promotes quality and
 |
| 
 |
| 
 |
| 
 |
| 
 |
| consistency across the Design.
 |
| 
 |
| 
 |
| 
 |
| 
 |
| </p></keyConsiderations> |
| <purpose><p>
 |
| 
 |
| 
 |
| 
 |
| 
 |
| 
 |
| The purpose of&nbsp;this&nbsp;task&nbsp;is to describe the&nbsp;elements of the system so that they support the
 |
| 
 |
| 
 |
| 
 |
| 
 |
| 
 |
| required behavior, are of high quality, and fit within the architecture.
 |
| 
 |
| 
 |
| 
 |
| 
 |
| 
 |
| </p></purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
