| <?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-QmIvs-rs3Fiyg7PVRx2IvQ" |
| name="new_roadmap,_irQiEOCsEdynptYdmll41Q" guid="-QmIvs-rs3Fiyg7PVRx2IvQ" changeDate="2008-06-20T15:07:48.042-0700" |
| version="7.2.0"> |
| <mainDescription><p>
 |
| <strong>Getting Started</strong>
 |
| </p>
 |
| <p>
 |
| Begin by gaining an understanding of design patterns. 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.
 |
| </p>
 |
| <p>
 |
| Understand refactoring and the difference between code refactoring and design refactoring. There's 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't guarantee that:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The original design works correctly
 |
| </li>
 |
| <li>
 |
| The refactored design works correctly
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| So developer testing must be rigorously performed in order to verify the robustness of the design. Otherwise you may
 |
| waste a lot of time refactoring something that doesn't work, or refactoring the correct behavior out of the system.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
