| <?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.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="-QmIvs-rs3Fiyg7PVRx2IvQ" |
| name="new_roadmap,_irQiEOCsEdynptYdmll41Q" guid="-QmIvs-rs3Fiyg7PVRx2IvQ" changeDate="2008-10-15T09:15:06.981-0700" |
| version="7.2.0"> |
| <mainDescription><p>
 |
| <strong>Getting Started</strong>
 |
| </p>
 |
| <p>
 |
| Begin by gaining an understanding of&nbsp;<a class="elementLinkWithUserText"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
 |
| guid="_0YJvUMlgEdmt3adZL5Dmdw">design patterns</a>. There are good references in the Additional&nbsp;Information
 |
| section of the&nbsp;<a class="elementLink"
 |
| href="./../../../practice.tech.evolutionary_design.base/guidances/practices/evolutionary_design_DE27D8D9.html"
 |
| guid="_aSVhIB4qEd2bS8fFOQ7WWA">Evolutionary Design</a>&nbsp;page. Patterns are essential to creating, managing, and
 |
| evolving designs. As the name implies, evolutionary design involves returning to the existing design over and over
 |
| again to refine, change, and improve previous thinking. It can be performed at the beginning of a development cycle
 |
| (before implementation), during a development cycle (while implementing code), after the cycle (when the developer
 |
| tests have&nbsp;successfully executed), or any combination of these. The team should determine where in the development
 |
| cycle the design will be performed. See <a class="elementLinkWithType"
 |
| href="./../../../practice.tech.evolutionary_design.base/tasks/design_solution_A97CE9EA.html"
 |
| guid="_0fshwMlgEdmt3adZL5Dmdw">Task: Design the Solution</a>.
 |
| </p>
 |
| <p>
 |
| Understand <a class="elementLinkWithUserText"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/refactoring_1B63BA3B.html"
 |
| guid="_Poc7IPDzEdqYgerqi84oCA">refactoring</a> and the difference between code refactoring and design refactoring.
 |
| There is no exact boundary separating the two, but there are some clear areas where the developer will wear the "design
 |
| hat" when reworking the design into a better structure. These areas will usually involve identifying where design
 |
| patterns can replace or enhance the existing design, or areas of the design where patterns can be identified and
 |
| harvested for reuse.
 |
| </p>
 |
| <p>
 |
| <strong>Common pitfalls</strong>
 |
| </p>
 |
| <p>
 |
| Evolutionary design emerges from refactoring existing design. This improves the design without changing the behavior of
 |
| the system. Failing to perform developer or unit testing is a high risk activity, as you can not guarantee that:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The original design works correctly
 |
| </li>
 |
| <li>
 |
| The refactored design works correctly
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Therefore, you must perform rigorous <a class="elementLinkWithUserText"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/developer_testing_FEBDAED6.html"
 |
| guid="_ADwlAJRtEdyrdaw_xGakyw">developer testing</a> in order to verify the robustness of the design. Otherwise, you
 |
| may waste a lot of time refactoring something that does not work, or refactoring the correct behavior out of the
 |
| system.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
