<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-4HHmcQny_Q08Xj_3Q7Sfig" name="new_concept,_mlKb8JyJEdy9brKHb521mQ" guid="-4HHmcQny_Q08Xj_3Q7Sfig" changeDate="2008-08-07T04:56:11.000-0700" version="7.2.0">
  <mainDescription>&lt;h4>&#xD;
    &lt;a id=&quot;Introduction&quot; name=&quot;Introduction&quot;>Introduction&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Design must define enough of the system so that it can be implemented unambiguously. What constitutes enough varies&#xD;
    from project to project and company to company.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In some cases the design resembles a sketch, elaborated only far enough to ensure that the implementer can proceed (a&#xD;
    &quot;sketch and code&quot; approach). The degree of specification varies with the expertise of the implementer, the complexity&#xD;
    of the design, and the risk that the design might be misconstrued.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In other cases, the design is elaborated to the point that the design can be transformed automatically into code. This&#xD;
    typically involves extensions to standard UML to represent language and/or environment specific semantics.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The design may also be hierarchical, such as the following:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        a high level design model which sketches an overview of the overall system&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        a subsystem specification model which precisely specifies the required interfaces and behavior of major subsystems&#xD;
        within the system&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        a detailed design model for the internals of subsystems&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The sections below describe some different options for relating a design and implementation, and discuss benefits and&#xD;
    drawbacks of these approaches.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;sketch&quot; name=&quot;sketch&quot;>Sketch and Code&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    One common approach to design is to sketch out the design at a fairly abstract level, and then move directly to code.&#xD;
    Maintenance of the design model is manual.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In this approach, we let a design class be an abstraction of several code-level classes. We recommend that you map each&#xD;
    design class to one &quot;head&quot; class that, in turn, can use several &quot;helper&quot; classes to perform its behavior. You can use&#xD;
    &quot;helper&quot; classes to implement a complex attribute or to build a data structure that you need for the implementation of&#xD;
    an operation. In design, you don't model the &quot;helper&quot; classes and you only model the key attributes, relationships, and&#xD;
    operations defined by the head class. The purpose of such a model is to abstract away details that can be completed by&#xD;
    the implementer.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This approach is extended to apply to the other design model elements. You may have design interfaces which are more&#xD;
    abstract than the code-level interfaces, and so on.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;round&quot; name=&quot;round&quot;>Round-Trip Engineering&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    In round-trip engineering environments, the design model evolves to a level of detail where it becomes a visual&#xD;
    representation of the code. The code and its visual representation are synchronized (with tool support).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The following are some options for representing a Design Model in a round-trip engineering context.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;b>&lt;a id=&quot;trace&quot; name=&quot;trace&quot;>High Level Design Model and Detailed Design Model&lt;/a>&lt;/b>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In this approach, there are two levels of design model maintained. Each high level design element is an abstraction of&#xD;
    one or more detailed elements in the round-tripped model. For example, a design class may map to one &quot;head&quot; class and&#xD;
    several &quot;helper&quot; classes, just as in the &quot;sketch and code&quot; approach described previously. Traceability from the high&#xD;
    level design model elements to round-trip model elements can help maintain consistency between the two models.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Although this can help abstract away less important details, this benefit must be balanced against the effort required&#xD;
    to maintain consistency between the models.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;b>&lt;a id=&quot;evolves&quot; name=&quot;evolves&quot;>Single Evolving Design Model&lt;/a>&lt;/b>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In this approach, there is a single Design Model. Initial sketches of design elements evolve to the point where they&#xD;
    can be synchronized with code. Diagrams, such as those used to describe design use-case realizations, initially&#xD;
    reference sketched design classes, but eventually reference language-specific classes. High level descriptions of the&#xD;
    design are maintained as needed, such as:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        diagrams of the logical structure of the system,&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        subsystem/component specifications,&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        design patterns / mechanisms.&lt;br />&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Such a model is easier to maintain consistent with the implementation.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;specification&quot; name=&quot;specification&quot;>Specification and Realization Models&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A related approach is to define the design in terms of specifications for major subsystems, detailed to the point where&#xD;
    client implementations can compile against them.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The detailed design of the subsystem realization can be modeled and maintained separately from this specification&#xD;
    model.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Models can be detailed and used to generate an implementation. Both structure (class and package diagrams) and behavior&#xD;
    diagrams (such as collaboration, state, and activity diagrams) can be used to generate executable code. These initial&#xD;
    versions can be further refined as needed.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The design may be platform-independent to varying degrees. Platform-specific design models or even code can be&#xD;
    generated by transformations that apply various rules to map high-level abstractions of platform-specific elements.&#xD;
    This is the focus of the Object Management Group (OMG) Model-Driven Architecture (MDA) &lt;a href=&quot;http://www.omg.org/&quot;&#xD;
    target=&quot;_blank&quot;>(http://www.omg.org&lt;/a>) initiative.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Platform-specific visual models can be used to generate an initial code framework. This framework can be further&#xD;
    elaborated with additional code not specified in the design.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Patterns&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Standard patterns can be applied to generate design and code elements from related design and implementation. For&#xD;
    example, a standard transformation pattern can be applied to a data table to create Java&amp;trade; classes to access the data&#xD;
    table. Another example is using an &lt;a href=&quot;http://www.eclipse.org/emf/&quot; target=&quot;_blank&quot;>Eclipse Modeling Framework&lt;/a>&#xD;
    to generate code for storing data that matches the model and to generate a user interface implementation for populating&#xD;
    data. A pattern or transformation engine can be used to create the implementation, or the implementation can be done by&#xD;
    hand. Pattern engines are easier and more reliable, but handwritten code implementing a defined pattern will have fewer&#xD;
    errors than handwritten code implementing a novel or unique design.&#xD;
&lt;/p>&lt;br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
