| <?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="_d2aMwKrMEdmqUqi7YGiSxw" |
| name="implement_solution,_0hyzgMlgEdmt3adZL5Dmdw" guid="_d2aMwKrMEdmqUqi7YGiSxw" |
| authors="Jim Ruehlin, Brian Lyons" changeDate="2007-07-25T12:31:18.594-0700" version="1.0"> |
| <mainDescription><p>
 |
| Usually, this task is focused on a specific element, such as a class or component, but it does not need to be.
 |
| </p>
 |
| <p>
 |
| A portion of the design is implemented by performing this task. This task can be performed any number of times during
 |
| an iteration. In fact it is best to do this task in as small a scope as possible to tighten the loop between it and
 |
| related tasks involving developer testing and consideration of the design.
 |
| </p></mainDescription> |
| <sections xmi:id="_2sxisE2iEduU655MA_3VXg" name="Determine a strategy" guid="_2sxisE2iEduU655MA_3VXg"> |
| <sectionDescription><p>
 |
| Determine a strategy based on the design and developer tests for how you are going to implement the solution. The
 |
| fundamental options are:
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| Apply existing, reusable assets.
 |
| </li>
 |
| <li>
 |
| Model the design in detail and generate the source code (by model transformation).
 |
| </li>
 |
| <li>
 |
| Write the source code.
 |
| </li>
 |
| <li>
 |
| Any combination of the above.
 |
| </li>
 |
| </ol></sectionDescription> |
| </sections> |
| <sections xmi:id="_iMMWoKuPEdmhFZtkg1nakg" name="Identify opportunities for reuse" |
| guid="_iMMWoKuPEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| Identify existing code or other implementation elements that can be reused in the portion of the <a class="elementLink" href="./../../openup/workproducts/implementation_917CA61E.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a> that you
 |
| are creating or changing. A comprehensive understanding of the overall design is helpful, because it is best to
 |
| leverage reuse opportunities when you have a thorough understanding of the proposed solution.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_pjehkNb7Edq_LtLvi4w2yw" name="Transform Design into Implementation" |
| guid="_pjehkNb7Edq_LtLvi4w2yw"> |
| <sectionDescription><p>
 |
| If you are using sophisticated modeling tools, you should be able to generate a portion of the required source code
 |
| from the model. Note that programming is&nbsp;commonly required to complete the implementation after the design model
 |
| has been transformed into code.
 |
| </p>
 |
| <p>
 |
| Even without tools, there is&nbsp;typically some amount of code that can be created by rote by examining the design and
 |
| developer tests.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_mFQ58KuPEdmhFZtkg1nakg" name="Write source code" guid="_mFQ58KuPEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| Write the source code to make the implementation conform to the design and expected behavior. You should strive to
 |
| reuse and/or generate code wherever possible, but you will still need to do some programming. To do so, consider the
 |
| following:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Examine the&nbsp;requirements. Because some requirements information does not translate directly into your design
 |
| you should examine the requirement(s) to ensure that they are fully realized in the implementation.
 |
| </li>
 |
| <li>
 |
| Refactor your code to improve its design. <a class="elementLink"
 |
| href="./../../openup/guidances/concepts/refactoring.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> is a
 |
| technique where you improve the quality of your code via small, safe changes.
 |
| </li>
 |
| <li>
 |
| Tune the results of the existing implementation by improving performance, the user interface, security, and other
 |
| nonfunctional areas.
 |
| </li>
 |
| <li>
 |
| Add missing details, such as completing the logic of operations or adding supporting classes and data structures
 |
| </li>
 |
| <li>
 |
| Handle boundary conditions.
 |
| </li>
 |
| <li>
 |
| Deal with unusual circumstances or error states.
 |
| </li>
 |
| <li>
 |
| Restrict behavior (preventing users or client code from executing illegal flows, scenarios, or combinations of
 |
| options).
 |
| </li>
 |
| <li>
 |
| Add critical sections for multi-threaded or re-entrant code.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Though many different considerations are listed here, there is one clear way to know when the source code is done. The
 |
| solution has been implemented when it passes the developer tests. Any other considerations can be taken care of in a
 |
| refactoring pass over the code to improve it once it is complete and correct.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_ni25UKuPEdmhFZtkg1nakg" name="Evaluate the Implementation" guid="_ni25UKuPEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| Verify that the implementation is fit for its purpose. Examine the code for its suitability to perform its intended
 |
| function. This is a quality assurance step that you perform in addition to testing which is described in other tasks.
 |
| Consider these strategies:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Pair programming. By pairing to implement the code in the first place, you effectively evaluate the code as its
 |
| being written.
 |
| </li>
 |
| <li>
 |
| Read through the code for common mistakes. Consider keeping a checklist of common mistakes that you make, as a
 |
| reminder reference.
 |
| </li>
 |
| <li>
 |
| Use tools to check for implementation errors and inappropriate code. For example, use a static code rule checker or
 |
| set the compiler to the most detailed warning level.
 |
| </li>
 |
| <li>
 |
| Use tools that can visualize the code. Code visualization, such as the UML visualizations in the Eclipse IDE, help
 |
| developers identify issues such as excessive coupling or circular dependencies.
 |
| </li>
 |
| <li>
 |
| Perform informal, targeted code inspections. Ask colleagues to review small critical sections of code and code with
 |
| significant churn. Avoid reviewing large sections of code.
 |
| </li>
 |
| <li>
 |
| Use&nbsp;a tester to ensure the implementation is testable and understandable to testing resources.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Improve the implementation based on the results of these evaluations.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_q5XiIKuPEdmhFZtkg1nakg" name="Communicate significant decisions" |
| guid="_q5XiIKuPEdmhFZtkg1nakg"> |
| <sectionDescription><p>
 |
| Communicate the impact of unexpected changes to the design and requirements.
 |
| </p>
 |
| <p>
 |
| The issues and constraints that you uncover when you implement the system must be communicated to the team. The impact
 |
| of issues discovered during implementation must be incorporated into future decisions. If appropriate, update
 |
| requirements to reflect ambiguities that you identified and resolved in the implementation so they can be tested and
 |
| you can manage the <a class="elementLink" href="./../../openup/roles/stakeholder.html"
 |
| guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a> expectations appropriately. Similarly, update the design to reflect new
 |
| constraints and issues uncovered during implementation to be sure that the new information is communicated to other
 |
| developers.
 |
| </p>
 |
| <p>
 |
| Usually, there is no need for a change request if the required change is small and the same person is designing and
 |
| implementing the code element. That individual can make the design change directly. If the required change has a broad
 |
| impact, it may be necessary to communicate that change to the other team members through a change request.
 |
| </p></sectionDescription> |
| </sections> |
| <keyConsiderations><p>
 |
| It is best when developer tests already exist so there is an unambiguous definition of what behavior is considered
 |
| correct. The implementation should be immediately tested.
 |
| </p></keyConsiderations> |
| <purpose><p>
 |
| The purpose of this task is to produce an implementation for part of the solution (such as a class or component), or to
 |
| fix one or more defects. The result is typically new or modified source code, which is&nbsp;referred to the
 |
| implementation.
 |
| </p></purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
