| <?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="-4HHmcQny_Q08Xj_3Q7Sfig" |
| name="new_concept,_mlKb8JyJEdy9brKHb521mQ" guid="-4HHmcQny_Q08Xj_3Q7Sfig" changeDate="2008-08-07T16:56:11.960-0700" |
| version="7.2.0"> |
| <mainDescription><h4>
 |
| <a id="Introduction" name="Introduction">Introduction</a>
 |
| </h4>
 |
| <p>
 |
| Design must define enough of the system so that it can be implemented unambiguously. What constitutes enough varies
 |
| from project to project and company to company.
 |
| </p>
 |
| <p>
 |
| In some cases the design resembles a sketch, elaborated only far enough to ensure that the implementer can proceed (a
 |
| "sketch and code" approach). The degree of specification varies with the expertise of the implementer, the complexity
 |
| of the design, and the risk that the design might be misconstrued.
 |
| </p>
 |
| <p>
 |
| In other cases, the design is elaborated to the point that the design can be transformed automatically into code. This
 |
| typically involves extensions to standard UML to represent language and/or environment specific semantics.
 |
| </p>
 |
| <p>
 |
| The design may also be hierarchical, such as the following:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| a high level design model which sketches an overview of the overall system
 |
| </li>
 |
| <li>
 |
| a subsystem specification model which precisely specifies the required interfaces and behavior of major subsystems
 |
| within the system
 |
| </li>
 |
| <li>
 |
| a detailed design model for the internals of subsystems
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The sections below describe some different options for relating a design and implementation, and discuss benefits and
 |
| drawbacks of these approaches.
 |
| </p>
 |
| <h4>
 |
| <a id="sketch" name="sketch">Sketch and Code</a>
 |
| </h4>
 |
| <p>
 |
| One common approach to design is to sketch out the design at a fairly abstract level, and then move directly to code.
 |
| Maintenance of the design model is manual.
 |
| </p>
 |
| <p>
 |
| In this approach, we let a design class be an abstraction of several code-level classes. We recommend that you map each
 |
| design class to one "head" class that, in turn, can use several "helper" classes to perform its behavior. You can use
 |
| "helper" classes to implement a complex attribute or to build a data structure that you need for the implementation of
 |
| an operation. In design, you don't model the "helper" classes and you only model the key attributes, relationships, and
 |
| operations defined by the head class. The purpose of such a model is to abstract away details that can be completed by
 |
| the implementer.
 |
| </p>
 |
| <p>
 |
| This approach is extended to apply to the other design model elements. You may have design interfaces which are more
 |
| abstract than the code-level interfaces, and so on.
 |
| </p>
 |
| <h4>
 |
| <a id="round" name="round">Round-Trip Engineering</a>
 |
| </h4>
 |
| <p>
 |
| In round-trip engineering environments, the design model evolves to a level of detail where it becomes a visual
 |
| representation of the code. The code and its visual representation are synchronized (with tool support).
 |
| </p>
 |
| <p>
 |
| The following are some options for representing a Design Model in a round-trip engineering context.
 |
| </p>
 |
| <p>
 |
| <b><a id="trace" name="trace">High Level Design Model and Detailed Design Model</a></b>
 |
| </p>
 |
| <p>
 |
| In this approach, there are two levels of design model maintained. Each high level design element is an abstraction of
 |
| one or more detailed elements in the round-tripped model. For example, a design class may map to one "head" class and
 |
| several "helper" classes, just as in the "sketch and code" approach described previously. Traceability from the high
 |
| level design model elements to round-trip model elements can help maintain consistency between the two models.
 |
| </p>
 |
| <p>
 |
| Although this can help abstract away less important details, this benefit must be balanced against the effort required
 |
| to maintain consistency between the models.
 |
| </p>
 |
| <p>
 |
| <b><a id="evolves" name="evolves">Single Evolving Design Model</a></b>
 |
| </p>
 |
| <p>
 |
| In this approach, there is a single Design Model. Initial sketches of design elements evolve to the point where they
 |
| can be synchronized with code. Diagrams, such as those used to describe design use-case realizations, initially
 |
| reference sketched design classes, but eventually reference language-specific classes. High level descriptions of the
 |
| design are maintained as needed, such as:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| diagrams of the logical structure of the system,
 |
| </li>
 |
| <li>
 |
| subsystem/component specifications,
 |
| </li>
 |
| <li>
 |
| design patterns / mechanisms.<br />
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Such a model is easier to maintain consistent with the implementation.
 |
| </p>
 |
| <h4>
 |
| <a id="specification" name="specification">Specification and Realization Models</a>
 |
| </h4>
 |
| <p>
 |
| A related approach is to define the design in terms of specifications for major subsystems, detailed to the point where
 |
| client implementations can compile against them.
 |
| </p>
 |
| <p>
 |
| The detailed design of the subsystem realization can be modeled and maintained separately from this specification
 |
| model.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h4>
 |
| Patterns
 |
| </h4>
 |
| <p>
 |
| 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.
 |
| </p><br /></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
