| <?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.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="_NrC20qeqEdmKDbQuyzCoqQ" name="design_solution,_0fshwMlgEdmt3adZL5Dmdw" guid="_NrC20qeqEdmKDbQuyzCoqQ" changeDate="2008-01-25T09:58:59.000-0800" version="1.0.0"> |
| <mainDescription><p>
 |
| This task is about designing part of the system, not the whole system.&nbsp; It should be applied based upon some small
 |
| subset of requirements.&nbsp; The requirements driving the design 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.&nbsp; In this case the task might be applied&nbsp;again later&nbsp;to deal with a different context on the
 |
| same requirements.&nbsp; Keep in mind that to actually build some functionality of value&nbsp;to the users, all
 |
| contexts will typically need to be designed and implemented. For example, to actually utilize some system capability it
 |
| will have to have been designed and implemented all its context such as 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="./../../core.tech.slot.base/workproducts/technical_architecture_slot_FF074CDD.html"
 |
| guid="_8OD-cLPTEduocbW-TPTq7A">[Technical Architecture]</a>.
 |
| </p></mainDescription> |
| <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 causes you
 |
| to go back to the beginning after collaborating with the analyst, or when evaluating the design a reviewer
 |
| could&nbsp;note that a reusable element being used 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
 |
| implementation, 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> |
| <sections xmi:id="_4Z7WYKuKEdmhFZtkg1nakg" name="Understand requirement details" guid="_4Z7WYKuKEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| Examine the relevant&nbsp;<a class="elementLink"
 |
| href="./../../core.tech.slot.base/workproducts/technical_specification_slot_2812F7EF.html"
 |
| guid="_i3vkoLS-EduDY8LNbMCDBA">[Technical Specification]</a>&nbsp;to understand the scope of the design task and the
 |
| expectations on the <a class="elementLink"
 |
| href="./../../practice.tech.evolutionary_design.base/workproducts/design_D677D182.html"
 |
| guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Work with the stakeholder and Analyst to clarify ambiguous or missing
 |
| information.
 |
| </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&nbsp;incomplete or incorrect, work with the analyst 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&nbsp;<a
 |
| class="elementLinkWithType"
 |
| href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html"
 |
| guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a>&nbsp;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="./../../core.tech.common.extend_supp/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="./../../practice.tech.evolutionary_design.base/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="./../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html"
 |
| guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>.
 |
| </p>
 |
| <p>
 |
| Look to the architecture 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.&nbsp; For more information, see&nbsp; <a
 |
| class="elementLinkWithType"
 |
| href="./../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html"
 |
| guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>.
 |
| </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&nbsp;<a
 |
| class="elementLinkWithType"
 |
| href="./../../practice.tech.evolutionary_design.base/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="./../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_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="_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> |
| <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="./../../practice.tech.evolutionary_design.base/guidances/concepts/design_E36137FA.html"
 |
| guid="_bFjlAPTYEduDKIuqTXQ8SA">Concept: Design</a>, <a class="elementLinkWithType"
 |
| href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html"
 |
| guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>, and <a class="elementLinkWithType"
 |
| href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html"
 |
| guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a>&nbsp;for more information.
 |
| </p></sectionDescription> |
| </sections> |
| <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> |