Definition and Summary: Model-driven development is simply the notion that we can construct a model of a system that we then transform into the real thing... A model is a coherent set of formal elements describing something (for example, a system, bank, phone, or train) built for some purpose that is amenable to a particular form of analysis... Model-driven development automates the transformation of models from one form to another. [Mellor, 2003]

This document defines the practice of capturing artifacts in rigorous model-based notation as being equivalent to Model-Driven Software Engineering (MDSE) ([Mellor, 2003] and [Schmidt, 2006]). Artifacts, in software engineering, are any products of software development and maintenance processes. These include documentation, source code, executables, test data, scripts for installing and executing all or part of a system, and any engineering data produced under such processes. Rigorous model-based notation often involves the adoption of formal methods. Formal methods support precise specification of the syntax and semantics of languages in which models and mathematical proofs about properties of such models are expressed. This document provides an overview of MDSE for managers, without fully specifying technical details.

MDSE is an emerging practice supported by research and commercially-available software tools. The model-based notation used in this practice is machine-readable and used in the automatic derivation or generation of source code for a software-intensive system. The practice of capturing artifacts in rigorous, model-based notation has evolved over the years, from the use of early Computer Aided Software Engineering (CASE) tools to the use of commercially available Model-Driven Software Engineering (MDSE) tools. MDSE is also known as Model-Driven Development (MDD) and Model-Based Development (MBD). Model-Driven Architecture (MDA) is an Object Management Group (OMG) approach, with associated standards. The practice described by this report is MDSE or MDD. "A basic premise of Model-Driven Development (MDD) is to capture all important design information in a set of formal or semiformal models, which are then kept automatically consistent by tools"[Mattsson, 2009]. A recent marketing study divides the analysis, modeling, and design market into business rules management systems and MDSE. MDSE tools consist of tools for data modeling, Unified Modeling Language (UML) process modeling, and business process modeling. The use of MDSE is growing with the use of business process modeling and Service Oriented Architecture [Hendrick, 2008].

Figure 1: MDSE Process

Artifacts in model-based notation are used to record requirements, architecture, or designs. The DACS gold practice on Model-Based Testing describes the construction of models of user behavior, the use of such models in automatically generating test cases, and the tool-based monitoring and execution of testing. This gold practice, on the other hand, focuses on models of software-intensive systems and their architectures, the transformations of such models into designs and implementation, and the maintenance of consistency between models and implementations. Software architecture is "the set of significant decisions about the organization of a software system: selection of the structural elements and their interfaces by which a system is composed, behavior as specified in collaborations among these elements, composition of these structural and behavioral elements into larger subsystems, [and] architectural style that guides this organization. " The architecture includes considerations of "usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and tradeoffs, and aesthetic concerns" (From the Rational Unified Process, as quoted in [Kruchten, 2004]).

Artifacts in model-based notation are particularly useful for:

• Expression of the system and its evolution
• Communication among system stakeholders
• Evaluation and comparison of architectures in a consistent manner
• Planning, managing, and executing the activities of a system development
• Expression of the persistent characteristics and supporting principles of a system to guide acceptable change
• Verification of a system implementation's compliance with an architectural description
• Recording contributions to the body of knowledge of software-intensive systems architecture.

Transformations of one model into another and of models into running code are an important aspect of MDSE. Proponents and researchers using MDSE ([Stahl, 2006] and [Kelly, 2008]) distinguish between a full implementation of MDSE and "round trip engineering". In a full implementation, corrective, adaptive, and perfective modifications are made to the models or mapping information, and the source code is regenerated. That is, models are maintained, and source is never altered by direct human intervention. If one is unhappy with source code, one should alter the mapping information that MDSE tools use in generating code. In round trip engineering, on the other hand, both models and source code are updated, with consistency maintained by the process. Code is regenerated after changes to models, and models are rebuilt after changes to the source code. Code generation tools that support round trip engineering should clearly demarcate generated code and merge newly generated code with existing user modifications, as is done in existing Configuration Management tools such as Concurrent Version Systems (CVS).

MDSE has been instantiated by a number of currently-available approaches:

• Domain specific modeling, as described in [Kelly, 2008] and Section 1.2.2
• MDA, as described in [Miller, 2003] and Section 1.2.2.2
• Software Factories, as being developed by Microsoft in their Oslo project and described in Section 1.2.2.3
• The Rational Unified Process for Systems Engineering (RUP SE), as described in  [Nolan, 2008] and Section 1.2.2.4
• Eclipse modeling projects, as described in Section 1.2.2.5

The adoption of this practice results in changes from traditional software development. More emphasis is placed on tool usage, particularly architecture and design tools. The production of application frameworks, architectures, software product lines, and small Domain-Specific Modeling Languages is stressed. The source code for specific applications on designated target platforms is automatically generated. The effective use of this application may require the use of a specialist in configuring the tools by selecting design patterns, library routines, etc. for generating code.

MDSE has benefits and costs. Increased productivity, increase reuse, and decreased failures are among the benefits. A steep learning curve, including the toolsets that implement it, prevents total development time from being lowered on the first project in an organization to adopt MDSE. MDSE constrains architecture to be specified by component specification. Constraints and other architectural design rules not easily specified in terms of a model are difficult to communicate under MDSE processes. Developers following MDA processes, at least, still need to be aware of details of the target platform, although such knowledge is specified in tool configuration rather than human development of designs and implementations. A number of organizations have completed successful demonstration projects of MDSE. The case studies in Appendix C substantiate this summary of costs and benefits of MDSE.

Not all those implementing a feasibility for MDSE need to be expert in all activities in MDSE. Some can specialize in designing the domain language, while others specialize in specifying applications using that languages. Steven Kelly and Juha-Pekka Tolvanen recommend that both this feasibility study and later modeling be implemented incrementally [Kelly, 2008].

A detailed description of MDSE in this report is organized around supporting technologies and approaches. A brief overview of UML is followed by a brief description of MDSE itself. The possibility of constructing different models for different application domains is central to MDSE, and metamodels allow for such a range of models. The brief description of MDSE is followed by a list of examples of metamodels. The OMG's MDA, Microsoft's software factories, an approach in the Rational Unified Process, and an Eclipse project constitute  approaches to MDSE described in this report. The detailed description of MDSE is concluded by a brief description of some characteristics of the practice. Other sections provide relationships to other Gold Practices and origins of MDSE. Appendices provide background on formal modeling notation, recommending sources, and case studies. This report concludes with some acronyms and resources on the Web for MDSE.

This document defines the practice of capturing artifacts in rigorous model-based notation as being equivalent to Model-Driven Software Engineering (MDSE) ([Mellor, 2003] and [Schmidt, 2006]), an emerging practice supported by research and commercially-available software tools. The model-based notation used in this practice is machine-readable and used in the automatic derivation or generation of source code for a software-intensive system. The Unified Modeling Language (UML) provides one model-based notation widely used in such tools. Some (e.g., [Greenfield, 2004] and [Stahl, 2006]) argue that UML needs a more formal definition, an issue being addressed in UML 2. UML builds on earlier notations, such as Data Flow Diagrams (DFDs), Entity-Relationship (ER) diagrams, and Integration Definition (IDEF) diagrams, used in earlier generations of  Computer-Aided Software Engineering (CASE) tools. UML can be considered as defining a Domain-Specific Modeling Language (DSML) for Object-Oriented systems. MDSE tools, such as MetaEdit+, provide the user with a capability to define their own DSML and then define a model for their application in that DSML.

CASE tools have provided a capacity to generate at least some code for decades. The practice of enhancing, modifying, or maintaining the source code in later life cycle phases, such as implementation, testing, and operations raises the issue of preserving consistency between models and the implementation. In round trip engineering developers update documentation and models after updating the code and vice-versa, thereby preserving consistency. Researchers (e.g., [Stahl, 2006], p. 74) distinguish between round trip engineering and MDSE. Just as in domains outside of some High Performance Computing applications, developers do not manually update the assembly or machine language generated by compilers, so in a mature MDSE approach the generated source code is not manually maintained. Instead, one updates the models and regenerates code with the MDSE tools. Since this approach has a higher payoff in developer productivity and quality, this report concentrates on the MDSE approach.

Artifacts captured in rigorous model-based notation can be used to:

• Document and express a system and its evolution
• Communicate among system stakeholders
• Consistently evaluate and compare architectures
• Derive implementations by successive transformations of models
• Verify a system implementation's compliance with requirements, particularly through Model Based Testing (MBT).

MDSE supports these uses, with experienced developers, more effectively than many processes relying on non-automated notations and traditional human-intensive design, coding, and testing.

Model-based notations are typically displayed graphically by MDSE tools. The models are expressed in a language, where such languages have a formally defined syntax and semantics. MDSE researchers ([Stahl, 2006], p. 85, and [Kelly, 2008], p. 68-70) distinguish between an abstract syntax and a concrete syntax. The abstract syntax specifies the language constructs, their properties, and relations. The concrete syntax specifies the specific representation of language constructs, for example, a rectangle or oval. Only the abstract syntax need be specified in a format such as XML Metadata Interchange (XMI) for storing and sharing models and their associated DSMLs between tools.  Appendix A provides further theoretical background on rigorous model-based notation.

Cognizant of the above background, the following subsection provides an overview of UML. The next subsection defines some key concepts of MDSE. Subsections briefly describe five influential examples of MDSE methodologies, that is,  domain specific modeling, Model Driven Architecture (MDA), Microsoft's software factories, IBM Rational's instantiation, and the Eclipse Modeling Framework (EMF). In MDSE, "architecture" is used to mean both relationships among artifacts and models generated during development and maintenance processes and  the architecture of a software-intensive system documented, analyzed, and derived from a MDSE approach. The term is used in both senses in these explanations of MDSE methodologies.

Various graphical languages were used to specify systems prior to the development of MDA and the recent relative popularization of MDSE. The Unified Modeling Language (UML) is one such language used to describe software systems in a model-based notation. The System Modeling Language (SysML) extends UML for systems engineering. SySML was developed through a collaborative effort between the Internationa Council On Systems Engineering (INCOSE) and the OMG. UML is not specific for an application domain, other than through a connection to Object-Oriented systems. OMG MDA standards are based on UML. Hence, although merely specifying a system in UML is not MDSE, some knowledge of UML is useful in understanding at least the MDA variant of MDSE.

UML provides modelers with twelve diagram types to specify various views of a system. As shown in Table 2, these diagram types can be grouped into depictions of system structure, of system behavior, and of model management. Each diagram type can be expressed in a graphical notation. Many of these diagram types are organized around the notion that a system is composed of interacting classes and objects. An object is an instance of a class, where a class specifies the data and operations possible with a type.

Figure 2: Collage of UML Diagrams (Downloaded from Wikipedia on 11 February 2009)

 Model-Driven Software Engineering (MDSE) predicates that a better software-intensive system can often be more cost-effectively developed and maintained by generating it from a model expressed in a Domain-Specific Modeling Language (DSML). Each DSML focuses on an application or problem domain. Since models developed in DSMLs are specified in concepts closely related to the application domain, MDSE raises the level of abstraction of software development over many current approaches (Figure 3). MDSE implies the need for a technology, a meta-metamodel, to define DSMLs to express one's models. A number of efforts have been on-going for a number of years to define such tecnologies. Among these are Model-Driven Architecture (MDA) [Miller, 2003], MetaObject Facility (MOF) [Anonymous, 2006], and related standards from the Object Management Group (OMG); The Eclipse Modeling Framework (EMF); and technology developed by various tool-vendors, such as MetaEdit+ from MetaCase.

Figure 3: Bridging the Abstraction Gap Between Domain Terms and Their Implementation (Based on [Kelly, 2008])

MDSE applies an approach to requirements, architecture, and high-level design analogous to an implementation approach common among the Unix community. These developers sometimes use Unix commands; such as awk, sed, or yacc; or scripting languages, such as Perl or PHP, to define a mini-language customized for the particular task at hand. The desired implementation is then written in this mini-language. Similarly, in MDSE, one defines a DSML in which to model an application. The implementation is then generated from the model.

For decades, the developers of software-intensive systems have found it useful to raise the level of abstraction embodied in their languages and notations. Early CASE and UML tools allow developers to describe systems in a general model-based notation, not specifically tailored for any specific application domain. MDSE allows developers to specify models in a notation tailored for an application domain, thereby abstracting even further from implementation details influencing Object-Oriented UML models. "The full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts" [Booch, 2004]. For example, an automotive system might include a navigation system, an audio system, a radio, and a CD player, cities, and streets. A point-of-sale system might include Purchase Orders and items. Models from which such systems are derived would then include distinct elements for these components; these models would not consist simply of various UML classes.

Every model is an instance of a metamodel.  [Stahl, 2006] makes a distinction between a metamodel and a DSML. If one views UML as a language for Object-Oriented systems, the corresponding UML meta-model includes the twelve UML diagrams (e.g., a Use Case Diagram), as well as such notions as classes. Figure 4 illustrates the relation between instances of model elements, models, and metamodels. A domain element might be an instantiation of a particular class, such as a specific person with a name, identification number, age, and so on. A model element might be a specific class, such as the class of employees. A metamodel might define the class construct, as in UML, or general notions tailored for the domain, as in a DSML [Kelly, 2008].

Figure 4: Relationships Among Domains, Models, and Metamodels (Based on [Stahl, 2006])

In traditional CASE and UML tools, the meta-model is fixed and predefined. In a sense, the metamodel is hard-coded into the tool. Since a meta-model is a specific kind of model, it too can be viewed as an instance of a higher-level metamodel, that is, a meta-metamodel (Figure 5). In MDSE, the meta-metamodel is fixed, and the metamodel is tailored for the domain. With this approach, UML, at least in version 2.0, is itself defined as a particular instance of the meta-metamodel (Figure 6). For example, the MetaObject Facility (MOF) Classifier is used to specify the concept of a class in UML. A MDSE tool provides a capability to use the built-in meta-metamodel to define a DSML and the corresponding metamodel.

Figure 5: Metamodeling Hierarchy (Based on [Stahl, 2006])

Figure 6: Example of a Metamodeling Hierarchy (Based on [Anonymous, 2003])

A meta-metamodel could be seen as an instance of a meta-meta-metamodel. Theoretically, the number of meta layers could increase without bound. In practice, the number of layers need not increase above the meta-metamodel. Meta-metamodels, such as the MOF, provide the capability to define themselves, just like any other metamodel that they can be used to define. This approach is analogous to defining the syntax of Backus-Naur Form in Backus-Naur Form, as in Section 8 of [Anonymous, 1996].

In MDSE, models expressed are in languages that have a syntax and semantics. MDSE practitioners (e.g., [Kelly, 2008], pp. 68-70) distinguish between the abstract and concrete syntax of a DSML. The abstract syntax specifies how language elements relate to one another, while the concrete syntax specifies, for example, the particular textual or graphical shape of language elements and their relationships. The concrete syntax does not need to be captured in data shared among MDSE tools.

The Eclipse Model Development Tools (MDT) Project provides implementations of metamodels defined by certain standards.

OMG is currently standardizing Model-Driven Architecture (MDA), a model-driven methodology for specifying requirements and deriving applications. The "Architecture" in MDA specifies the relationships among the artifacts and models produced under an MDA approach, not the architecture of the system under development or acquisition. The derivation of a Platform Specific Model from a Platform Independent Model is an example of one such relationship between models. The objective of MDA is "to separate business and application logic from its underlying execution platform technology so that:

1. Changes in the application logic do not affect existing applications, and
2. Business logic can evolve independently from the underlying technology." [Lewis, 2005]

MDA is an example of MDSE. Three models are particularly important for MDA:

• Computational Independent Model (CIM) – a view of a system focusing on the environment of the system and the requirements of a system. The details of the structure and processing are not part of this model. A CIM is also called a Domain model.
• Platform Independent Model (PIM) – a view of a system that focuses on the operation of a system while hiding the details for any particular platform.
• Platform Specific Model (PSM) – A view of a system combining a PIM with details from a specific platform used by a system.

Model-Driven Architecture consists of the following high-level steps:

1. Build the CIM
2. Build the PIM
3. Transform the PIM into the PSM
4. Generate code from the PSM

The third step is performed with an MDA mapping (Figure 7), which provides specifications for transforming a PIM into a PSM. Such a specification could include a map from types in the PIM language to types in the PSM language (model type mapping), a map from elements in the PIM to concepts in the PSM (model instance mapping), or both. In a model-instance mapping implemented by a marking model, the PIM is first marked up, where a mark represents a concept in the PSM and indicates how the marked up element in the PIM is to be transformed. In addition to marks, templates and mapping languages may provide information for transforming a PIM to a PSM. In any case, the MDA approach will result in a record of the transformation, including when the transformation is conducted manually.

Figure 7: A Model Transformation in MDA

A software factory, in this context, is one of a number of Microsoft-sponsored approaches to metamodeling. The Oslo project, is another Microsoft approach now under development. Oslo:

• Provides a visual modeling tool named Quadrant;
• Will store model data within a database repository;
• Includes M, a family of textual languages for metamodeling or meta-metamodeling; and
• Comes with a library of already built domain models and languages.

Oslo allows any number of meta-modeling layers in its architecture. The latest Community Technology Preview (CTP) for the Oslo Software Development Kit (SDK) is dated January 2009. Microsoft describes M as complementary to UML. Microsoft joined OMG on 9 September 2008. Microsoft is now working to ensure its modeling efforts are designed to produce products interoperable with UML. Software factories are more mature than Oslo. Furthermore, a software factory is a software development practice, while Oslo is a combination of tools and languages. Consequently, the remainder of this section describes software factories.

Software factories [Greenfield, 2004] provide one overarching paradigm for MDSE. Software factories:

• Raise the level of abstraction in programming to that of developing DSMLs and models, instead of traditional source code
• Shifts the focus from individual applications to product families
• Dramatically increases the use of automation
• Emphasizes declarative over imperative specifications

 [Greenfield, 2004] defines a software factory:

"A Software Factory is a software product line that configures extensible development tools like Visual Studio Team System with packaged content like [DSMLs], patterns, frameworks and guidance, based on recipes for building specific kinds of applications. For example, we might set up a Software Factory for thin client Customer Relationship Management (CRM) applications using the .NET framework, C#, the Microsoft Business Framework, Microsoft SQL Server and the Microsoft Host Integration Server. Equipped with this factory, we could rapidly punch out an endless variety of CRM applications, each containing unique features based on the unique requirements of specific customers. Better yet, we could use this factory to create an ecosystem, by making it available to third parties, who could extend it to rapidly build CRM applications incorporating their value added extensions." Jack Greenfield, Keith Short, Steve Cook, and Stuart Kent

Implementing software factories requires investments and changes in business processes and organizations to achieve potential benefits, particularly from reuse. Developing families of products mandates new planning processes and management structures. Application development concentrates more on the development of infrastructure, tools, and assets such as patterns and frameworks. ([Greenfield, 2004], p. 591-596) In other words, software factories deliver product families. Design patterns are applied automatically within software factories, and software factories provide systematic reuse.

 [Greenfield, 1996]  compares and contrasts software factories to Rapid Application Development (RAD), MDA, the Rational Unified Process, and agile development. "A Software Factory is essentially a domain specific RAD environment." Software factories differ from a general-purpose RAD in that they use domain-specific models. The concepts captured in such domain-specific models enable more advanced and more extensive automated transformations of models and generation of code. The use of domain-specific models supports the partial automation of design. Automation can use rules governing the selection, configuration, and integration of objects at the level of design. Design-level specification errors can be automatically detected, and domain-specific optimizations and be automatically performed. Visualization, inspection, and debugging of execution at the level of design objects can be made available. Development artifacts are managed with the use of design information.

Unlike MDA, software factories deliver product families from DSMLs. They use design patterns. Software factories use DSMLs, not UML. [Greenfield, 1996] argues effective  use of UML applies it in a lightweight fashion. Software factories also apply small metamodels and DSMLs. Software factories do serialize model-based metadata as XML (chap7 and 8), but do not use MOF and XMI. Expositors of software factories claim not using XMI gives them more independence from the metamodels  of target languages.

According to [Greenfield, 2004], "the least mature aspects of software factories are language technology, tool extensibility, pattern composition, deferred encapsulation, and the development of standard [DSMLs], patterns, frameworks, and tools for popular domains."

The Rational Unified Process for Systems Engineering (RUP SE) "is IBM Rational's instantiation of Model Driven Systems Development" [Nolan, 2008]. RUP SE permits the specification of a system and system elements in either UML or the OMG Systems Modeling Language (SysML). SysML is an extension to UML [Anonymous, 2008]. The RUP SE architecture supports four principles: seperation of concerns, integration, system decomposition, and scalability. Seperation of concerns allows system design to address the concerns of different stakeholders independently. Using common design elements in addressing the different concerns of different stateholders achieves integration. Decomposing the system by structure, not function, allows the for parallel development at any structural level. Using the same framework for systems anywhere from a low-level component to an enterprise system achieves scalability. [Balmelli, 2006] The benefits of MDSE include risk reduction, improved communication among team members, explicit processes for performing trade studies and reasoning about systems issues, early error-detection, incremental integration and improved architecture, traceability ([Nolan, 2008], p. 8)

The process architecture relates the static and dynamic artifacts produced under the process to represent the system to model levels, viewpoints, and views:

• Static artifacts represent the "system in its context" and the components of the system.
• Dynamic  artifacts represent how static components collaborate and interact to fullfill their role in the system.
• A model level is "a subset of the system model that represents a certain level of specificity (abstract to concrete); lower levels capture more specific technology  choices. Model levels are not levels of decomposition; in fact, a model level can contain multiple levels of decomposition."
• A viewpoint is "a subset of the architecture model that addresses a certain set of engineering concerns while maintaining an integrated, consistent representation of the underlying design".
• A view is an intersection of a viewpoint and a model level. "Views contain artifacts (that is, objects used to document engineering data) that describe how the viewpoint's engineering concern is addressed at a particular model level."

A development effort might not require all core viewpoints. The model views shown in Table 6 are samples.

The RUP SE process is ideally an iterative lifecycle, where the capabilities developed in each iteration are chosen based on risk identification and mitigation. At least one build is generally created during an iteration. The RUP SE process permits more than one iteration to be performed during a system phase. Figure 8 shows two iterations in the Elaboration and Transition phases, and three iterations in the Construction phase. The RUP SE does not include a seperate system engineering discipline. System engineers participate in one or more disciplines, such as business modeling, requirements, etc. As shown in Figure 8 each of the disciplines identified in the RUP SE process are emphasized more in some system phases and less in others.

Figure 8: RUP SE Process Framework (from [Nolan, 2008])

Figure 9: Metamodel Representation of a System (based on [Balmelli, 2006])

A system encapsulates resources required to deliver services. RUP SE processes are transformations of models. In the core RUP SE process, systems are decomposed into other systems, and this decomposition process is recurvsive. The root system is at the highest decomposition level, and there is only one root system. Operations analysis, the core RUP SE process and an extension of use case analysis, consists of a recursive pattern:

1. Decompose the system to create a context for system elements
2. Treat the system operations as use case scenarios for the system elements
3. Describe the scenarios in which the system elements, regarded as black boxes, interact to realize the system operations.
4. Derive the operations of the system elements from the scenarios.

As illustrated by Figure 9, operations analysis results in the identification of decomposition levels, system elements at each decomposition level, and the operations of the system element. In applying this pattern recursively, a system element at one level is treated as itself a system at the next lower decomposition level. System elements are grouped together into viewpoints.

Defining the system context is a black-box process in which one identifies actors. As part of this black-box thinking, the system developer specifies use cases, sequence diagrams, and the system context diagram. Understanding the collaboration of system elements and how their elements interact to realize system elements is a white box process in which element context diagrams and lower-level use cases, for example, are specified.

Eclipse is an open source Integrated Development Environment (IDE). In its default configuration, Eclipse supports the development of Java programs. The functionality of Eclipse can be extended through plug-ins. In other words, Eclipse provides a run-time kernel and a capability to integrate additional components implemented as plug-ins. Plug-ins support programming in many languages; configuration management functions such as bug tracking; enterprise applications targeted for middleware such as JBoss; documentation, including UML diagrams; and many more capabilities. Since Elipse provides a Rich Client Platform (RCP), applications can be developed as Eclipse plug-ins. The Eclipse Foundation, a not-for-profit corporation, sustains a community  developing and maintaining Eclipse and related products and services. Many prominent software industry vendors, such as Borland, CA, International Business Machines (IBM) Corporation, Oracle, and SAG AG, are strategic members of the Eclipse Foundation and help set priorities for Eclipse projects.

 Many might think of Eclipse as consisting of the subprojects under the Eclipse project, one of four top-level Eclipse projects (Figure 10). The Eclipse Modeling Project (EMF) "is the focal point for the evolution and promotion of model-based development technologies at Eclipse" [Steinberg, 2009]. [Steinberg, 2009] and [Moore, 2004] also emphasize the Graphical Editing Framework project, which supports the development of graphical editors for application models. Table 7  gives a more complete list of modeling technology being developed for Eclipse, while Table 8 lists subprojects of EMF. MDT subprojects are listed in Section 1.2.2.1.

Figure 10: Eclipse Projects (Based on [Steinberg, 2009])

Table 8: Subprojects of the Eclipse Modeling Framework

Subproject	Short Name	Description
Connected Data Objects	CDO	A technology for distributed shared EMF models and a fast server-based Object/Relational mapping solution.
EMF (Core)	EMF	A modeling framework and code generation facility for building tools and other applications based on a structured data model.
Net4j	Net4j	An extensible client-server system based on the Eclipse Runtime and the Spring Framework
Model Query	Query	Facilitates the process of search and retrieval of model elements in a flexible, contolled, and structured manner.
Service Data Objects	SDO	A framework that simplifies and unifies data application development in a Service Oriented Architecture (SOA).
Teneo	Teneo	A database persistency solution for EMF using Hibernate or Java Persistent Objects/Java Data Objects (JPOX/JDO) 2.0.
Model Transaction	Transaction	Provides a model management layer on top of EMF for managing EMF resources.
Validation Framework	Validation	Provides (1) API for defining constraints for any EMF meta-model, (2) Extensibility API supporting meta-models requiring custom strategies for model traversal, (3) Constraint parsing for specific languages, (4) API support defining "client context" that describe objects needing to be validated and binding them to constraints that need to be enforced on those objects, and (5) support for listening in validation events.

The EMF project developers intend EMF to be a modeling approach that is easy to adopt and that does not require a complete change in development methodology.  As such, EMF makes some compromises with a full MDSE approach. EMF models describe the class modeling aspects of UML, but not non-class modeling aspects of UML diagrams. EMF models are more closely related to generated code (implementations) than the models at the highest level of abstraction created under MDA and some other MDSE approaches. [Steinberg, 2009]

EMF is developed to take advantage of other standards, frameworks, and tools. Experience with the EMF project, especially the EMF metamodel Ecore, influenced the development of the latest OMG standardization of MOF. Models in EMF can be created from annotated Java, class models in Rational Rose, or an XML schema. Model importers are used to create models from these technologies. Other projects, such as the Eclipse UML2 project, have developed other model importers. New model importers can be created by extending org.eclipse.emf.importer.modelImporterDescription. XMI is the default serialization format for instances of EMF models. EMF includes XML Schema Definition (XSD) capabilities,  an implementation of Service Data Objects (SDOs), and an API for handling components of an XML Schema and  the underlying Document Object Model (DOM).

EMF provides powerful code and object generation capabilities consistent with Java programming style and conventions. An EMF model specified with Ecore can be used to generate:

• Java interfaces and classes for modeled objects
• An outline of an adaptor factory class (called an "observer" in other programming frameworks) for creating adaptors for modeled objects. Adaptors are described in the Adptor design pattern and allow changes to modeled objects to be dynamically tracked.
• A switch class for dispatching callbacks to modeled objects based on the type of the objects. (A switch class includes a method with a switch statement in which the case clauses test for the object type to return from the method.)
• Files to implement a model as an Eclipse plug-in, that is, manifest and property files.

Adaptor and switch classes provide a capability for modeled objects to implement a style of Java programming in which listeners are notified of changes to an object. (java.awt.event.MouseListener, which is used to implement interfaces that respond to mouse clicks and movements, is a simple example of a listener in Java.) Java generated with EMF can be modified by the programmer, and regeneration of code will not overwrite the modifications if the @generated tag is properly used. EMF modeling provides a capability for object persistence. Implementations of EMF models can be dynamically generated, and dynamically created model objects can be invoked even though no corresponding Java classes have been generated. The EMF runtime framework extends Eclipse to provide finer-grained and better support for integrating data among applications built on the Eclipse platform.

Figure 11 represents a high-level process architecture for the subject practice, depicting relationships among this practice and the nature of the influences on the practice (describing how other practices might relate to this practice). These relationship statements are based on definitions of specific "best practices" found in the literature and the notion that the successful implementation of practices may "influence" (or are influenced by) the ability to successfully implement other practices. A brief description of these influences is included in the table below.

Figure 11: Process Architecture for the "Capture Artifacts in Rigorous, Model-Based Notation" Gold PracticeTM

The DACS takes its list of Gold Practices from Richard Turner’s 2002 doctoral thesis. Turner states that the practice of capturing artifacts in rigorous, model-based notation has been incorporated into the Model-Based Software Engineering (MBASE) approach. MBASE is a project under the direction of Dr. Barry Boehm at the University of Southern California’s Center for Software Engineering

The models used in this practice are almost always recorded in machine-readable form, are frequently executable (as prototypes), and often can be used to (semi) automatically generate the desired system. The Knowledge-Based Software Assistant (KBSA) project at Rome Laboratory, now part of the Air Force Research Laboratory (AFRL) – Rome Site, is one source for this technology. KBSA project meetings, started in 1986, evolved into an annual conference on Knowledge-Based Software Engineering (KBSE). The IEEE took over sponsorship of this conference in 1997 and changed its name to the IEEE Conference on Automated Software Engineering. Many approaches for automating software development from models have been developed through AFRL sponsorship or presented at these conferences.

Another source of this practice is found in the evolution of Computer-Aided Software Engineering (CASE) tools. These tools are tied to specific methodologies or notations. There was extensive debate over methods and notations during the 1980s and 1990s. Much of this controversy took place within the Object Oriented (OO) community, since many of these notations were tailored for OO programming. In the mid-1990s, Rational hired three leading, competing methodologists (Grady Booch, Ivar Jacobson and James Rumbaugh) who collaborated in developing the Unified Modeling Language (UML). The Object Management Group (OMG), a not-for-profit corporation, acts as a trade association and helps develop standards to foster the creation of a components-based software market. The OMG standardized UML in 1997 and completed a major revision in 2003. UML is a graphical, Object-Oriented specification and design language. UML 2.0 includes improvements for architectural modeling and scalability. Much technology for model-driven development, including the OMG’s Model-Driven Architecture (MDA) emerging standard, is based on UML.

The rigorous, model-based notation used in this practice is taken from formal methods [Vienneau, 1993] in software engineering. Software engineering artifacts are recorded in machine-readable languages, that is, in formally-defined languages. Thus, software tools are capable of processing these artifacts. This section provides tool users with an overview of how to formally define a language. The developers of MDSE  tools used in this practice need a more detailed understanding of the mathematical theory of computability, automata, and formal languages than can be provided here. To some extent, this practice transitions formal methods to more widespread use.

A language has a syntax and a semantics. The syntax or grammar specifies what strings are in the language, while the semantics specifies the meaning of those strings. A string is a sequence of symbols. In a language capable of being represented pictorially, such as a specified UML diagram type, a string might be thought of as a two-dimensional array of symbols or by some other method , known as a serialization syntax, of rigorously expressing a two-dimensional layout as a one-dimensional sequence. The symbols of the language are chosen from an alphabet, where an alphabet is a finite list of symbols. Proponents of MDSE (e.g., [Kelly, 2008], pp. 68-70) distinguish between the abstract and concrete syntax of a DSML. The abstract syntax specifies how language elements relate to one another, while the concrete syntax specifies, for example, the particular textual or graphical shape of language elements and their relationships. In other words, how symbols in the alphabet are represented can vary without changing the abstract syntax. OMG uses a metamodel to define UML's abstract syntax. The concrete syntax does not need to be captured in data shared among MDSE tools.

A language's grammar can be specified by automata that decide if strings are in the grammar or by a generative grammar. More complex types of languages require more computationally powerful automata, as shown in the Chomsky hierarchy. Derivation rules, as written in Backus Naur Form (BNF), provide one way of specifying a context-free generative grammar. As an example, consider the derivation rule shown in Figure 12 for a proposition in propositional logic. The left-hand side of a derivation rule in a context-free grammar consists of a non-terminal symbol. A non-terminal symbol does not appear in any strings in the language. Rather, it is expanded by one of the alternatives shown on the right-hand side of a derivation rule. Assuming an appropriate derivation rule for identifiers, the string ( ( p and q ) or ( not p) ) is a formula in propositional logic formed by recursively applying the derivation rule for a proposition. Notice that the derivation rule ensures that parentheses match in all well-formed formulae in the language. This derivation rule is consistent with no order of precedence being specified for the logical operators.

Figure 12: An (Based on [Gries, 1981])

A model defines the semantics of a language. In logic, a model is roughly a nonempty set, where designated elements of the set correspond to constant symbols in the language. Operations on elements in the set correspond to operations expressed in sentences in the language. Relations among elements in the set correspond to relations expressed in sentences in the language. By determining which predicates over elements, operations, and relations are true in the model, one also establishes which sentences are true in the language under the interpretation provided by the model. Sentences relating elements in the set to expressions in the language for which the semantics is defined are not themselves in that language, but in a metalanguage. This conception of semantics dates to Alfred Tarski's work in the 1930s.

Geometry provides a canonical example of a model in this sense. Nineteenth century mathematicians, in trying to make sense of non-Euclidean geometry, separated the interpretations of the terms in geometric proofs from their formal manipulations. As David Hilbert put it, "One must be able to say at all times - instead of points, straight lines, and planes - tables, chairs, and beer mugs." Non-Euclidean geometries are formed by assuming the negation of the parallel postulate, an axiom in Euclidean geometry. One formulation of the parallel postulate states that for any point off of a given line, exactly one line can be drawn through the point parallel to the given line. In elliptic geometry, one assumes no parallel lines can be drawn. A model of elliptic geometry can be constructed in Euclidean geometry by considering a sphere in an Euclidean space. Interpret a line in elliptic geometry as a great circle on the sphere and a point in elliptic geometry as a pair of points directly opposite one another on the sphere. "The angles of a triangle add up to more than 180 degrees" is a true sentence in the language with the semantics given by  this model. This model establishes that if Euclidean geometry is logically consistent, elliptic geometry is also consistent. Since the other axioms of Euclidean geometry are assumed to hold in elliptic geometry, the parallel posulate is independent of the other postulates of Euclidean geometry and cannot be derived from them. This is a typical structure of a relative consistency proof. For example, Kurt Gödel's proof of the consistency of the axiom of choice and of the continuum hypothesis with the Zermelo-Fraenkel axiomization of set theory has a similar, albeit more abstract, model-theoretic structure.

Figure 13: A Triangle in a Spherical Model of Elliptic Geometry (Downloaded from Wikipedia on 19 March 2009)

The concept of rigorous, model-based notation in MDSE is firmly rooted in mathematics, although models can be used used for other purposes in MDSE. They are used mainly to automatically transform higher-level models of an application domain to lower levels and ultimately to applications written in designated programming languages for specific target platforms. Researchers in formal languages have developed a number of techniques to specify their semantics. [Greenfield, 2004] emphasizes two techniques for use in MDSE. A translational sematics relates the meanings of  the sentences  in one language to the meanings of sentences in another language, called the target language, for which the semantics are already defined. A trace-based semantics relates sentences in the language to the run-time behavior or executions of software systems.

[Royce, 1998] advocates ten "Principles of modern software management", including:

"Capture design artifacts in rigorous, model-based notation. A model-based approach (such as UML) supports the evolution of semantically rich graphical and textual design notations. Visual modeling with rigorous notations and a formal machine-processable language provides for far more objective measures than the traditional approach of human review and inspection of ad hoc design representations in paper documents."

[Turner, 2002] surveyed a sample of 35 software experts from academia, industry and government participating in various software-intensive working groups. The survey partitioned 32 best practices into four focus areas. “Capturing artifacts in rigorous, model-based notation” was grouped into the Change Management focus area. The best practices were ranked based on the 23 survey respondents’ individual rankings; rating of effectiveness; and groupings into the eight best practices, eight worst practices, or otherwise. “Capturing artifacts in rigorous, model-based notation” was ranked 31 out of the 32 best practices.

Many case studies have been performed with Model-Driven Software Engineering, but few include a fully documented, rigorous approach. Some MDSE case studies are catalogued by the Object Management Group (OMG) at MDA Success Stories at OMG. Three studies are selected for presentation here. One, reported in a peer-reviewed journal (IEEE Transactions on Software Engineering), illustrates a case study approach to gain insight and understanding into MDSE. The second and third are selected to illustrate quantifiable results. A 2007 study [Hofer, 2007] found empirical software research focusing on model driven development is "absent." The first Workshop on Empirical Studies of Model Driven Engineering [387828] addresses the need for more quantitative scientific studies on MDSE with papers on frameworks, metrics, and reporting conventions for experiments on MDSE.

In the first case study, Combitech, a Swedish company, was under contract to produce a software platform for a new generation of digital television set-top boxes. The first delivery was scheduled in 18 months, with two more deliveries in the next six months. Development was distributed across five sites, and the size of the effort was more than 100 person-years. Mattson et al. found MDSE does not support architectural design rules, expressed as constraints or conditions on the solution and resulting from decisions that some element will not appear in the design or that the design will exhibit some property [Kruchten, 2004]. Such rules cannot be formally expressed within MDSE. This limitation leads to premature design, where a solution satisfying the rules is expressed instead. The architects communicate the design poorly to design teams and must be heavily involved in reviewing the design team's work. [Mattsson, 2009]

The Software Engineering Institute (SEI) Integration of Software-Intensive Systems (ISIS) Initiative has been analyzing technology for constructing systems with interoperability requirments.  MDA is one such technology that they examined. The SEI researchers developed a Java 2 Enterprise Edition (J2EE)-based Human Resourses military system application using ArcStyler, a MDA tool available from Interactive Objects. The SEI researchers compared development time with data from a previous development. They also analyzed if  the use of the MDA tool freed the developer from having to learn low-level details of the target platform and infrastructure. Because of the learning curve, development time was not reduced on the first implementation of a MDA application, although it may be reduced on future projects targeting the identical platform. Use of a MDA tool requires detailed knowledge of the target platform to configure the tool and define model mappings. [Lewis, 2005]

[Bell, 1996] report the results of a controlled experiment comparing and contrasting the construction of a program generator from a domain-specific specification language and from sets of reusable Ada components. The application domain was the construction of message translation and validation modules for military Command, Control, Communications, and Intelligence (C3I) systems. The productivity of programmers was measured by the number of tasks completed per hour. Reliability was measured by the number of acceptance tests a module failed before a task was completed. Productivity  using a Domain-Specific Modeling Language (DSML) was three times greater than when  using reusable components. The mean number of failures when using a DSML was less than half of the mean number of failures when using reusable components. Both results were statistically significant. Furthermore, the test subjects preferred using the DSML.