| <?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" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-UaDGd7K2rQIFMwCrDuqQKQ" |
| name=",_Ht-z8JfJEdyZkIR-s-Y8wQ" guid="-UaDGd7K2rQIFMwCrDuqQKQ" changeDate="2008-02-01T10:28:08.249-0800" |
| version="7.2.0"> |
| <mainDescription><p>
 |
| Usually, this task is focused on a specific implementation&nbsp;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> |
| <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>The <a class="elementLink" href="./../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project Work]</a>&nbsp; is implicitly used in implementation tasks to manage which
 |
| requirements or change requests are being realized in the code.<br /></keyConsiderations> |
| <sections xmi:id="_RiBg4JfJEdyZkIR-s-Y8wQ" name="Determine a strategy" guid="_RiBg4JfJEdyZkIR-s-Y8wQ"> |
| <sectionDescription><p>
 |
| Determine a strategy based on the software design and developer tests&nbsp;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="_SW1pAJfJEdyZkIR-s-Y8wQ" name="Identify opportunities for reuse" |
| guid="_SW1pAJfJEdyZkIR-s-Y8wQ"> |
| <sectionDescription><p>
 |
| Identify existing code or other implementation elements that can be reused in the portion of the implementation 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="_IVaTAJ-uEdyHNcWzRYqQMg" name="Transform design into implementation" |
| guid="_IVaTAJ-uEdyHNcWzRYqQMg"> |
| <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="_TadCIJfJEdyZkIR-s-Y8wQ" name="Write source code" guid="_TadCIJfJEdyZkIR-s-Y8wQ"> |
| <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 technical requirements. Because some requirement 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. Refactoring 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="_WpB28JfJEdyZkIR-s-Y8wQ" name="Evaluate the implementation" guid="_WpB28JfJEdyZkIR-s-Y8wQ"> |
| <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="_XjAL4JfJEdyZkIR-s-Y8wQ" name="Communicate significant decisions" |
| guid="_XjAL4JfJEdyZkIR-s-Y8wQ"> |
| <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, use&nbsp; the
 |
| change management process to reflect ambiguities that you identified and resolved in the implementation so they can be
 |
| tested and you can manage&nbsp;stakeholder expectations appropriately. Similarly,&nbsp;leverage the design process to
 |
| 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> |
| <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> |
