| <?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" xmi:id="_4wqaMMPaEdmbOvqy4O0adg" |
| name="transforming_design_into_implementation,_0Y0dsMlgEdmt3adZL5Dmdw" guid="_4wqaMMPaEdmbOvqy4O0adg" |
| authors="Jim Ruehlin" changeDate="2007-07-20T08:43:58.859-0700" version="1.0"> |
| <mainDescription><p>
 |
| <b>Transforming</b> the design into code implements the system structure in the chosen source language. It also
 |
| implements the system behavior defined in the functional requirements. <b>Implementing</b> 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>
 |
| 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&trade; classes to access the
 |
| data table. Another example is using an <a href="http://www.eclipse.org/emf/" target="_blank">Eclipse Modeling
 |
| Framework</a> 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 handwritten code
 |
| implementing a defined pattern will have fewer errors than handwritten code implementing a novel or unique design.
 |
| </li>
 |
| <li>
 |
| Models can be detailed and used to generate an implementation. Both structure (class and package diagrams) and
 |
| behavior diagrams (such as collaboration, state, and activity diagrams) can be used to generate executable code.
 |
| These initial versions can be further refined as needed.
 |
| </li>
 |
| <li>
 |
| The design may be platform-independent to varying degrees. Platform-specific design models or even code can be
 |
| generated by transformations that apply various rules to map high-level abstractions of 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.
 |
| </li>
 |
| <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.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| In all cases, however, some design abstraction (classes, components, and so on) is detailed to become the
 |
| implementation.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
