Channels ▼
RSS

Design

Application Lifecycle Management Meets Model-Driven Development


Model-Driven Development

MDD lets you manage complexity by providing a way to make big picture decisions first, only adding details as needed. This solves the typical development conundrum of relying on implementation experts to create the architecture because they are the only ones who know how the pieces fit together. By letting architects focus on intended high-level functionality, MDD bridges the sizeable gap between the project requirements and the final implementation, and helps you realize a more manageable and practical application lifecycle platform (see Figure 2).

MDD provides a graphical language to define and develop systems and software. Based on industry-standards—for example, the Unified Modeling Language (UML 2.1) or Systems Modeling Language (SysML 1.0)—MDD lets requirements be assembled into a representative model that includes a complete use case and depiction of the application's functionality. Serving as a computer-based prototype, this model can then be "executed" in a manner similar to the way source code is compiled and run in order to simulate the system and validate and verify its completeness and intended behavior.

The results from the simulation are analyzed and used as the basis for developing more detailed specifications and requirements, iteratively extending the requirements into a complete application design. During each stage, the updated systems model can be executed to provide additional validation, verification, and detailed development. This iterative approach lets the application be constructed from high-level to detailed deployment, with continual validation of proper functionality and behavior at each step.

[Click image to view at full size]

Figure 2: Model-driven development workflow.

Once the application's systems architecture is fully specified, the model becomes the basis for all future activities, including application software development, testing, and implementation/deployment. The model can be used to specify and even generate application software, unit and integration tests, and published documentation. Because MDD is fully compatible with software development environments like Eclipse and Visual Studio, developers can debug and edit the application at any level—model or code—with their changes automatically synchronized throughout. For example, edits to code will automatically update the model and then be used to determine their impact on the entire architecture.

MDD provides a number of additional benefits. It lets you visualize system requirements and trace these requirements to design, code and test cases, formally extending requirements engineering through the entire development lifecycle. Because the requirements form portions of the model, they become an integral part of the design itself. Design validation allows you to catch defects early in the development process, as well as highlight flaws of logic in the project requirements. Common design models eliminate the hand-off gaps between systems, software, and test teams. And, with the option of automated code generation from the design model, you improve developer productivity and quality while providing more time for design optimization and innovation.

With MDD, traceability is established throughout development. Each feature can be traced back through the model to its originating requirement, while extraneous features (those "thrown in" by well-intentioned developers) are quickly exposed, eliminating the expense and bloat of unintended feature-creep. You can also simulate and validate system behavior, which adds a whole new dimension to constructing complex applications like those based on service-oriented architectures (SOA). MDD improves development productivity, product quality, and the organization's overall competitiveness while reducing development cost and time to market.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video