| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="_4wqaMMPaEdmbOvqy4O0adg" name="implementation,_0Y0dsMlgEdmt3adZL5Dmdw" guid="_4wqaMMPaEdmbOvqy4O0adg" authors="Jim Ruehlin" changeDate="2006-12-01T16:13:39.278-0800" version="1.0"> |
| <mainDescription><h5> |
| Code Reuse&nbsp; |
| </h5> |
| <p> |
| Code reuse and code generation tools produce more robust code and are preferable to writing code by hand. Existing code |
| has often already been tested and even deployed, making it more stable and well understood than new code. Source code |
| created from a code generation tool (such as a visual modeling tool) automates dreary coding tasks such as creating |
| getters and setters. |
| </p> |
| <p> |
| There are many places to harvest code for reuse: |
| </p> |
| <ul> |
| <li> |
| Internal (corporate) code libraries. |
| </li> |
| <li> |
| 3rd party libraries. |
| </li> |
| <li> |
| Built-in language libraries. |
| </li> |
| <li> |
| Code samples from tutuorials, examples, books, etc. |
| </li> |
| <li> |
| Local code guru or knowledgable colleague |
| </li> |
| <li> |
| Existing system code |
| </li> |
| <li> |
| Open source products (be sure to follow any licensing agreements)&nbsp; |
| </li> |
| </ul> |
| <h5> |
| Transforming the Design into the&nbsp;Implementation |
| </h5> |
| <p> |
| Transforming the design into code implements the system structure in the chosen source language. It also implements the |
| system behavior defined in the functional requirements. Implementing the system behavior means writing the code that |
| allows different parts of the application (classes or components) to collaborate in realizing the behavior of the |
| system. |
| </p> |
| <p> |
| There are various techniques for automatically transforming design to implementation. Here are some examples: |
| </p> |
| <ul> |
| <li> |
| Platform-specific visual models can be used to generate an initial code framework. This framework can be further |
| elaborated with additional code not specified in the design.<br /> |
| </li> |
| <li> |
| Models can be detailed and used to generate an implementation. Both structure (class and package diagrams) and |
| behavior diagrams (such as state and activity diagram) can be used to generate executable code. These prototypes |
| can be further refined as needed.<br /> |
| </li> |
| <li> |
| The design may be platform independent to varying degrees. Platform specific design models or even code can be |
| generated via transformations that apply various rules to map high level abstractions platform specific elements. |
| This is the focus of the Object Management Group (OMG) Model Driven Architecture (MDA) <a href="http://www.omg.org/" target="_blank">(http://www.omg.org</a>) initiative.<br /> |
| </li> |
| <li> |
| Standard patterns can be applied to generate design and code elements from related design and implementation. For |
| example, a standard transformation pattern can be applied to a data table to create java classes to access the data |
| table. Another example is using an Eclipse Modeling Framework (<a href="http://www.eclipse.org/emf/" target="_blank">http://www.eclipse.org/emf/</a>) model to generate code for storing data that matches the model and |
| to generate a user interface implementation for populating data. A pattern or transformation engine can be used to |
| create the implementation, or the implementation can be done by hand. Pattern engines are easier and more reliable, |
| but hand-written code implementing a defined pattern will have fewer errors than hand-written code implementing a |
| novel or unique design. |
| </li> |
| </ul> |
| <p> |
| In all cases, however, some design abstraction (classes, components, etc)&nbsp;is detailed to become the |
| implementation. |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |