Workshop on Model-Driven Architecture and Program Generation

Abstract : This technical note summarizes the results of a workshop held on June 2,2006, at the Software Engineering Institute in Pittsburgh, Pennsylvania (USA). The workshop explored business and technical aspects of program generation in the context of the Object Management Group's model-driven architecture development approach. The workshop was structured around consideration of the perspectives of five different communities: standards body, vendor, acquisition, development, and research. This note recapitulates these individual perspectives and highlights important themes.


List of Figures
MDA is a well-known approach to the development and maintenance of systems.MDA is produced and maintained by OMG, an open-membership, not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications.The goal of MDA is one that is often sought: to separate business and application logic from its underlying execution platform technology so that (1) changes in the underlying platform do not affect existing applications and (2) business logic can evolve independently from the underlying technology [Lewis 04, OMG 03].
A tool that implements the MDA concept would allow developers to produce models of the application and business logic and generate code for a target platform by means of transformations.Instead of writing platform-specific code in some high-level language, developers focus on developing models that are specific to the application domain but independent of the platform.In this way, MDA raises the level of abstraction in software development.
MDA has been endorsed by various entities of the U.S. Department of Defense (DoD).For example, in a recent Defense Science Board report on the Joint Integrated Fire Support Systems (JIFSS), a large distributed system, it was stated that JIFSS ... should employ the Model-Driven Architecture (MDA) development approach for designing the JIFSS architecture and in implementing its component systems.The MDA approach ensures adherence to standards across the components and has been shown to substantially reduce costs in the development of large-scale systems-of-systems [ATL 04].
Statements such as the one above are predicated on the expected benefits of using MDA on large systems.Will MDA satisfy these expectations?Which elements of MDA are robust today, and which will require further development?How will MDA change DoD 1 For more information about the OMG, go to http://www.omg.org.Carnegie Mellon is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. CMU/SEI-2006-TN-031 procurement practice?These are important (if only representative) questions to ask, but they are difficult to answer-for any new technology, but more so because of the complexity of MDA itself.To make progress toward finding answers, we necessarily restricted the scope of our inquiry in our workshop.For this workshop we selected program generation (or model transformation in MDA terms) as our scope.
We elicited perspectives on the state of MDA technology in our workshop, specifically those views relating to automated model transformation and automated program generation.We sought the perspectives of five particular MDA-related communities: 1. standards body 2. vendor 3. acquisition 4. development

research
Each of these communities has different desires and expectations for what MDA can provide.
Bringing them together in a small forum was expected to provide interactions that not only focused on the individual perspectives but also afforded the opportunity for integration of these perspectives.
The workshop was organized as a small, invitation-only event.Each of the invited participants is expert in the OMG MDA development approach and could plausibly play the role of perspective representative.
Several important observations emerged during the course of the workshop: • MDA is best thought of as a software engineering approach that is supported by a set of dujour standards.The benefits of MDA will emanate primarily from the approach and secondarily from the technical details of the standards themselves.
• MDA tools today are exhibiting increasing capabilities to generate code from models.On the other hand, support for model-based analysis is lagging, at least in part because it introduces challenges beyond the state-of-the-research.
• The use of MDA in DoD acquisition processes has been motivated primarily by anticipated technology benefits.How the acquisition of models of systems instead of their implementations will change acquisition remains to be determined.
These observations are elaborated in the main text of this note.The remainder of this note is organized as follows: • Section 2 provides some background on MDA.
Section 3 discusses the workshop approach, including purpose, scope, attendees, and conduct of the workshop.
Section 4 presents a discussion of the role-based perspectives represented by attendees.
The perspectives, based on the five communities mentioned above, were standards body, vendor, acquirer, developer, and researcher.
Section 5 discusses a thematic perspective of material discussed in the workshop.

Background
MDA is a broad conceptual framework that describes an overall approach to software development.In general, in tools that implement the MDA concept, a platform-independent model (PIM) that contains only business and application logic is developed using the tool's modeling component.The code generation component is a series of transformation rules that map elements in the PIM to elements in a platform-specific model (PSM) that contains details that are specific to the target platform.
In this way, all code that depends on the middleware, for example, will be generated and not written by hand as is usually the case today.Code is considered a form of the PSM, and a PIM can go through several levels of transformation before becoming code.This model transformation process is illustrated in Figure 1. 3 Workshop Approach

Attendees
The attendees, invited by the SEI, represented a broad range of depth and experience in dealing with various aspects related to MDA development approach.Each attendee represented a particular area of expertise and represented one of the following communities: • standards body (Mr. Fred Waskiewicz, OMG) • vendor (Mr. Michael Jungmann, Interactive Objects) • acquisition (Mr. Pat Kohli, Naval Air Systems Command-NAVAIR) • development (Mr. Ben Watson, Lockheed-Martin Corporation) • research (Dr.Douglas C. Schmidt, Vanderbilt University) In addition to the authors of this report, several other SEI technical staff members participated in the workshop.

Conduct of the Workshop
The agenda for the workshop is summarized below:

Introduction
This segment introduced the workshop and set the expectations of the attendees.

Overview of MDA
A brief overview of MDA was given to set a common theme.

SEI Interest in MDA
A brief discussion of why the SEI was interested in MDA was presented.

Presentation of Role-Based Perspectives
Assuming the five roles, attendees were asked to present their perspectives on MDA.The questions that each perspective was expected to address are presented in Table 1.It should be noted that having various perspectives presented was a significant factor in the success of the workshop.

Development of Thematic Perspectives
The perspectives of the roles represented by the attendees were integrated to provide thematic perspectives.

Summary
The SEI and attendees presented summaries of the workshop content.

Role-Based Perspectives
This section describes the perspectives presented by the attendees based on their roles and summarizes the material they presented.The summaries that follow should not be taken to represent positions of the participants but rather the positions of the roles they were asked to represent.The authors have taken some liberties in emphasizing some aspects of presentations at the expense of others.

Standards Body Role-Based Perspective
The primary standards organization involved in MDA work is the OMG.Although the OMG has an architecture steering board, its standards are member-defined.This emphasis on user preferences results in a varied set of standards that address the needs and concerns of the organization's members.The work of OMG is broadly accepted and used in enterprise systems (e.g., The Walt Disney Company, Deutsche Bank AG, transportation organizations, and healthcare organizations), as well as by the real-time and embedded communities (notably the DoD).
The following definition was proposed initially model-driven architecture: a model-based, standards-driven, and toolsupported software engineering approach to application and system development The goal of MDA is achieved through abstraction, automation, and the use of open (industrybased) standards.An implementation of the MDA development approach is realized through the use of a PIM and various possible PSMs, as was shown in Figure 1 on page 4. Transforming a PIM to a PSM accounts for the platform-specific characteristics, including distribution, middleware, and operating system dependencies.Thus, the same PIM can be applied to a single-process, single-processor model or to a multithreaded, multiprocessor model.
In OMG's MDA, models are represented using UML.Some elements of the UML have welldefined execution semantics 3 (e.g., state machine specifications and sequence diagrams).The UML Object Constraint Language (OCL) permits specification of pre-and postconditions, invariants, and other conditions on various UML model elements.
There is invariably some controversy about how rigorous this definition is.For the purpose of this report, we assume that the current definition is sufficiently rigorous for some but not all purposes.There is ongoing work at the OMG to provide a fully formal (execution) semantics for a subset of the UML.This difficult undertaking will likely never be extended to the full suite of UML notations.

CMU/SEI-2006-TN-031
Other MDA-related standards include: • Knowledge Discovery Metamodel that provides a common repository facilitating discovery and exchange of data • Abstract Syntax Tree Metamodel that is used to specify the structure of application code • Business Process Management that includes process definition, modeling and representation of production rules • metadata management that includes -a framework and services to enable development and interoperability of models and metadata systems (an MOF) -Query, View, Transformation (QVT) -Information Management Metamodel based on UML profiles The development of standards by OMG continues, along with that of specifications related to MDA tool interoperability.Since OMG standards are defined by its members, the MDA portfolio of standards will continue to change to reflect the interests of the membership.On the one hand, this method can enable the standards to adapt to changing needs; on the other hand, it can also result in an unwieldy portfolio of standards.

Vendor Role-Based Perspective
For an MDA-based tool vendor, it is important to understand the problem that MDA and its users are trying to solve.It is common to see different interpretations, because perceptions of these problems have evolved over time.Is the problem more than just code generation?It probably is, as can be seen from this unordered list of potential answers: Achieve platform independence and interoperability.
Simplify and streamline system development.
Protect investments by turning knowledge into accessible and reusable assets.
Help the business people understand what the system does.
Industrialize the software development process by separating roles and supporting workflow.
• Plan, create, and maintain holistic enterprise information technology (IT) landscapes.
Given this varied list of answers, it is no surprise that adding a feature to a product seems like research for a vendor.The feature corresponds either to an aspect of MDA that is not fullydeveloped or to user expectations that stem from the evolving answer to the problem that MDA should solve.
A common question from potential customers to vendors is "What can your product do for me?"This question is hard to answer, because an appropriate response will always depend on the context.It follows, then, that a key aspect for closing a deal is working with the customer to identify the right problem that the product will solve.As part of that process, a vendor needs to identify MDA as a solution for a seemingly unsolvable problem.Other generic critical factors for the vendor are • efficient customization of a solution to customer's needs • efficient support of target technology • efficient integration with development environment

• minimization of risk
Once the product is acquired, customers require more assistance at first, probably due to the immaturity of the technology and the need to overcome a steep learning curve.A main area of vendor assistance is the development of metamodels, transformations, and chains of transformations.
From a vendor perspective, there are some interrelated potential areas of research associated with MDA that would help develop a better product.Some of these are • domain-specific modeling and scalable modeling environments • end-to-end software development life-cycle support and integrated workflow management as a form of development process control • round-trip (generation and transformation) support that goes beyond trivial mappings or incremental transformations and automated generation of artifacts other than code and infrastructure4 • clearer relationships between MDA and software reuse • specification, notation, and integration of metamodels • industry-specific metamodels, modeling environments, and transformations • clearer relationship between MDA and service-oriented architecture (SOA) as a response to a growing software development trend • further evolution and clarification of OMG specifications and initiatives

Acquirer Role-Based Perspective
In this perspective, the acquirer role is concerned with the ability to specify, in a contract, products or services that can be used to create, maintain, and field operational systems.Some current systems take an MDA approach, notably Single Integrated Air Picture (SIAP) and Joint Strike Fighter (JSF) [Jacobs 04].
Of special interest is the issue of what it means to acquire a model.For example, a contract could be awarded for development of a model, and subsequent implementations of that model could be separately awarded.One concern in that example would be the ownership of intellectual property rights.There are also acquisition strategy questions such as maturity and risk of the technology, as well as the ability to integrate the model with other models that were possibly obtained through different contract vehicles.
The use of MDA is reminiscent of the transition to an object-oriented approach or to the use of computer-aided software engineering (CASE) tools.As with those techniques, there are concerns regarding cost, training, and the maturity of the technology with MDA.Furthermore, it is necessary to consider re-architecting legacy systems to foster integration with the capabilities provided by MDA technologies [Jacobs 04].Thus, the transition to the use of an MDA approach can have broad effects on both an acquisition organization and a development organization.
Some of the perceived benefits to the acquirer regarding MDA include the following: • It is easier to port software to a new computing environment or to defer the selection of hardware, middleware, and the operating system.
• The comprehensibility provided through the use of a model can foster competition in maintenance by soliciting a separate contract for maintenance, thereby reducing the lifecycle cost.
Some particular comments regarding the generator capability include the following: • Some tools are able to generate code for popular operating systems, such as POSIX.
VxWorks, or Win32.Tools can also provide extensibility to account for distribution middleware, such as common object request broker architecture (CORBA) or Java message service (JMS).
• The capability provided by some tools is rather basic.As a result, the acquirer must obtain code generation capabilities that are extensively tailored beyond those used for development of the PIM.This need for specialization reflects the immaturity of some code generators.
• There are challenges in porting the dynamic and nonfunctional aspects of PIMs from one tool to another.

Developer Role-Based Perspective
The most effective aspects of MDA in practice are the improved semantics for UML.There is also potential for the Systems Modeling Language (SysML) to solve a current problem with most UML-based tools-limited traceability between requirements and implementation.
From a developer perspective, there is potential for MDA in application and service development, but there should be caution: The current market hype may have overpromised what MDA can deliver. CMU/SEI-2006-TN-031 From the developer's experience, there are aspects of MDA that are not as effective as might otherwise have been expected: • OMG has done a good job of selling MDA, but not its interpretation, which has caused a proliferation of tools with their own interpretation of MDA, as well as multiple user expectations about what an MDA-based tool should do.
• Model transformation tools are slow to market.
• There are not enough automatic validation test generators.
• There is much confusion regarding the definition of computer-independent model (CIM), PIM, and PSM.
• Current tools generate code for a limited number of target platforms.
• Diagram interchange is difficult between tools from different vendors, let alone model interchange.Perhaps if MDA would have proposed MOF and not UML as the modeling tool, this difficulty would not occur.
• There is little tool support for domain-specific modeling.
• The MDA-based tool market is "business as usual" where many UML tools are being marketed as MDA tools.
There are also aspects that MDA does not address, but that some community should address, to make the use of MDA more effective.
• tool interoperability Even though the available tools claim to offer import and export capabilities, they provide only limited functionality beyond the exchange of diagrams that can be just a small portion of the complete model.
• integration with complex analysis tools It is not easy to make complex analysis tools work with UML-based tools to evaluate aspects such as schedulability and security or to do a dependency analysis.

• theoretically sound operational semantics
There is considerable effort underway in OMG to develop a sound semantics of executable elements of UML.Progress has been slow, and the gains have been hard won.But these gains address only functional concerns-and only in an abstract (platformindependent) computational setting.
• composition of models Models must be transformed for multiple purposes-not just to generate code, but also to generate input to various analysis tools.Each such transformation must be backed by sound semantics.If multiple transformations are to be valid simultaneously (e.g., performance, functional, and security views), their semantics must be coherent.
Current MDA tools also (in general) lack capabilities to model and reason about nonfunctional attributes such as performance, security, and reliability-a limitation that is further explained in Section 5.5.In one example discussed in the workshop, the developer is using the Vanderbilt Generic Modeling Environment (GME)" to model nonfunctional aspects such as timing and schedulability, deployment, and memory allocation.Basically, the developer has implemented the equivalent of a UML profile as GME metamodels.This solution works reasonably well, but there is no real support for transforming UML representations to specific analysis models.Therefore, this analysis occurs outside of the MDA-based tool.
Two recent experiences with code generators were described.In the first experience, a code generator was employed more as an "advanced build tool."Class and state diagrams were used to generate code to a real-time operating system (RTOS)/middleware isolation layer.C++ snippets were then assembled into compilation components.This solution was workable, but difficult to characterize as MDA-like.In the second experience, an MDAbased tool was used.The benefits of using that tool were the (1) easy access to model metadata for validation checks and documentation and (2) freedom it gave developers to focus on the problem space rather than the runtime mechanics.
Some lessons learned from the developer's experiences with code generators are • Ensure that the tool is well suited to your problem domain.The tool used a very limited abstract language to represent actions that were then translated to code.For the developers, the language was not adequate for the complex mathematics required in some algorithms.
• Ensure that the tool vendor has a track record in your problem domain.For example, if the solution to the problem requires distribution and threading, the vendor should have experience using the tool in similar projects.
• Resist the urge to raise the abstraction level too high.The consequence of choosing the wrong level of abstraction is that the transformations may become unnecessarily complex.
• Ensure that the tool suite can scale up to industrial-size development teams.Some tools work well in a stand-alone environment but do not adapt well to distributed development and deployment environments.
MDA development is evolving and will evolve further-based on factors such as SOA, business process modeling, and model-driven development in general-into a yet unknown model architecture that may have its roots in OMG's MDA but be quite different.This path of development will require a paradigm shift that gives business users the power to define their processes and expected performance.By contrast, in current practice IT and business users seem to go in different directions.By empowering users, IT will be the "behind the scenes" provider of automated code generation that is platform independent and can be ported to specific platforms with ease.For more information, see http://www.isis.vanderbilt.edu/projects/gme/. CMU/SEI-2006-TN-031

Researcher Role-Based Perspective
Generative programming is not a new idea: program generation has long been an intrinsic element of software development, even before the advent of FORTRAN.Indeed, the practice of software engineering would be inconceivable without technology to transform input specification to output object automatically.In this context, compiler technology (especially for conventional programming languages) is only the most mature and widely used, and therefore most familiar, example in this class of technology.
The search for more effective specification languages and processors continues, as seen by the long history of research in specification languages that pushes beyond the boundaries of conventional programming languages-including (but certainly not limited to) widespectrum languages, application-specific languages, 6 "4 lh -generation" languages, moduleinterconnection languages, architecture description languages, and composition languages.
It is difficult to assess the impact of this earlier research, at least when judged from its influence on the day-to-day activities of software developers.On the one hand, modern programming languages strongly reflect improved formal foundations, especially in type systems and module systems.On the other hand, software developers have stubbornly resisted any substantial shift from their fundamental reliance on imperative programming to higher-level specifications as a primary vehicle for implementation.
It is possible that changing factors in the research environments-including economic incentives, hardware capabilities, and social needs-may make some previously explored approaches more attractive.It is also possible that new forms of specification may be developed to address new classes of engineering problems.There is likely to be some degree of reinvention.Of course, it is not easy to draw the line between useful recapitulation and not-so-useful reinvention, and perhaps no line need be drawn.
What is indisputable is that the science, technology, and art of language design compose a significant body of knowledge.Figure 2 offers a research perspective on the evolution of program generation technology.This view is not offered as definitive or comprehensive, but instead as a reflection of du jour sensibilities about the subject.It adopts aspect-orientation as its organizing precept, implying an evolution from conventional to aspect-oriented programming and from aspect-oriented programming to model-based something-where the lack of an explicit compile step suggests a something that is qualitatively different from the conventional meaning of programming.
Application-specific languages are also known as domain-specific or problem-oriented languages.MDA provides one interpretation of this something.Although it is not overtly "aspectoriented," MDA, in its prescribed notations, does address distinct specification concerns (aspects).MDA also emphasizes metamodeling and imposes an organizational scheme (CIM, PIM, and PSM) to rationalize integration and transformation of concerns (weaving).
For a user, the ability to apply mature tools will lead to benefits expected of an MDA approach.Perhaps MDA, and model-generation tools in general, might exploit the technology to provide model-driven product lines or a model-based tool integration framework.Thus, although difficult problems remain in the application of MDA to largescale systems, the experience provided by the research community will help industry to realize the expected benefits of MDA and other model-driven approaches to software development. CMU/SEI-2006-TN-031

Thematic Perspectives
In the workshop, following presentations of the role-based perspectives, the group sought to identify themes that were relevant.These thematic perspectives are described below.

Understanding MDA
There is a lack of agreement concerning the term MDA.
It was recognized that the term MDA is used in several contexts, often simultaneously, and perhaps with different meaning!The term has been used to denote: • a philosophy of development, stressing the use of models • standards sponsored by the OMG that support a specific approach • products developed by a vendor (that could relate to either of the above points) MDA is sometimes viewed as a collection of standards, skills, tools, and processes that implement a particular approach to software development.It was pointed out, however, that there are no MDA tools per se.There are tools that implement a particular concept associated with MDA.In this sense, the concern of a philosophical approach is important to visionaries in the business communities.There are also implications regarding how to accomplish the practice of software engineering amid competing perspectives of the same term.Unfortunately, the lack of understanding around MDA percolates through various communities and causes further confusion.

Role of MDA in the Software Life Cycle
The role of MDA in the software life cycle could be greater, but current tools that support MDA do not make it easy.
Most current tools that support MDA focus on its code generation aspects: Models are developed using UML, and code is generated from these models.Even though this contribution is important and can potentially reduce development cycles, MDA could have a large impact on many other elements of the life cycle as well.For example, consider areas of the software life cycle that developers do not want to deal with, such as documentation, test cases, quality assurance, configuration management, and generation of "glue code."Given that a tool supporting MDA use throughout the software life cycle will probably never become a reality, there will be a need for more interoperability between tools at the model level.
Other tool features that would increase the role of MDA in the software life cycle include • code generation for a greater variety of platforms • debugging at the model level • configuration management at the model level as opposed to the "XMI level" • more modeling support for "upper stream" activities that provide traceability all the way to the generated code (This traceability would allow one to understand, for example, the impact of change to a business rule.) • easier integration with analysis and validation tools But more than anything else, there needs to be greater guidance in the use of MDA.How do you use MDA correctly?What does good modeling look like?What are design best practices?The answers to these questions are fundamental to extending the use of MDA further in the software life cycle.

Role of Transformations and Generator Technologies
The role of transformation and generator technologies is crucial to MDA.
A key aspect in the process of applying MDA is the transformation of a PIM to a PSM.The transformation is achieved through the use of some generator technology, the most common of which turns the model specification into executable code for a particular platform.
There are a number of aspects to consider regarding the generator technology.For example, an overriding issue is the amount of support that should be present in the model for nonfunctional attributes, as opposed to their specification in the context of a model's implementation.
It must also be recognized that generators can be developed for many purposes.For example, one could use output from a generator as input to a tool that performs an analysis of a model (independent of any implementation).Or, one could have a generator that creates test scenarios for a model.Perhaps, such generators can also be ported to the implementation context to obtain consistency between the PIM and PSM for various types of analysis.
A transformation, expressed through some generator technology, must address many aspects.Some are localized to the context of the domain defined by the model.For example, how does one demonstrate the correctness of a particular transformation?However, other considerations also apply.Most notably, these other aspects relate to interoperability concerns.For example, the integration with results produced by legacy systems or o:ier model approaches is of importance-in particular, the ability to achieve semantic interoperability.Interoperability also becomes significant when one seeks interoperability among tools for possibly different purposes where different vendors have provided the tools.
Another constellation of issues arises when considering interoperation of language semantics, as opposed to interoperation of system semantics.Defining language semantics is difficult enough when there is only one intended target transformation.When there are multiple transformations (i.e., transform one model into many views), multiple semantic views must be mutually consistent.Questions of shared observational semantics and modular semantics, to name just two, pose challenges to state-of-the-research language specification technology.
In general, the efficiency of using MDA-based tools for code generation will depend on the amount of the programmer's effort that is automated by the tool.The level of automation is directly proportional to the sophistication of the transformations and to the amount of information that is present in the models and used by the transformations.As a result, transformations and generators will have to evolve beyond generating infrastructure code and code "skeletons," which most current MDA-based tools accomplish.

Present State of MDA Capabilities
The real-world application of MDA is still limited to certain problem domains.
MDA works well in business applications, which provide a well-understood problem domain dominated by functional requirements and standard platforms.MDA also works well in datacentric applications, because the underlying data models are very structured.For other types of problem domains, however, MDA has not performed as well.Even though there have been case studies on the use of MDA in real-time systems and other domains, these are situations that require large amounts of tailoring and vendor support-requirements that seem contradictory to the MDA philosophy.
At a different level of abstraction, MDA deals well with functional properties; it is less capable of dealing with nonfunctional attributes.There is debate about whether the specification of nonfunctional attributes is within the scope of MDA.Regardless of the resolution of that debate, there is a need for semantics that will allow the specification of nonfunctional attributes.This topic is further discussed in the next section.

Nonfunctional Attributes in a Model Context
There exists a need to represent, analyze, and verify nonfunctional attributes using models.
The term nonfunctional attributes refers to characteristics such as performance, reliability, maintainability, availability, and interoperability.The nature of this thematic perspective is directly related to the MDA approach.
In the context of a PIM, the emphasis is on functional attributes of the system being modeled.
For example, suppose one has developed a PIM for some application.It may be possible to simulate the PIM, but that simulation would be in the context of a single process on a single processor.At that level of abstraction, it is not possible to address such characteristics as timing properties.This example illustrates, simply, the concept that a PIM abstracts implementation-level details.Unfortunately, there are cases where such details are important.
The transformation from PIM to PSM is determined, at least in part, by the ability to satisfy nonfunctional attributes.Consider the case where there is a requirement about timing (such as the amount of time required to transmit a message): • A timing requirement could be represented in the context of a model.Such an expression would be one of intent, in effect a somewhat refined statement of the requirement.
• Analysis of a timing requirement in the context of a PIM could be performed qualitatively.For example, one may assess the temporal ordering of a sequence of events.
• Verification of the timing requirement requires consideration of the execution context of the code-generated form of the model.Thus, verification is not possible until one enters the context of platform-specific considerations.This verification includes quantitative analysis of the requirement as well.For example, the value of a temporal interval is influenced by implementation concerns, notably the operating system.
This separation of perspectives (model versus implementation) for nonfunctional attributes has limited the utility of MDA in certain environments.More can be done to abstract such discussion to the context of a model; in the end, however, it is the implementation context that is most important.

Validation
MDA could play a larger role in system validation.
In an ideal model-driven development scenario, there are a number of models of a system, interrelated in a way that provides traceability (e.g., from use cases to code).In this ideal scenario, it should be possible to A potential solution to this problem is to have a metamodel for DSLs.There is currently a great amount of discussion on the creation of a UML Profile for DSLs, which would be a step in this direction.On the other hand, this entire subject may be more suitable for research than for standards development.

SEI Role
An additional perspective discussed was the role the SEI could play in the technology associated with MDA.The topics discussed in this area include • education Throughout the workshop, it was recognized that there is confusion about how the term MDA is used.The SEI could help to "separate fact from fiction."It was pointed out, for example, that MDA in itself is not a solution to the interoperability problem.The means by which the SEI can clarify use of the term might include an integrated glossary and courses intended for executives.
• experimentation There would be value in performing experiments that would provide knowledge to the community.
• transition A main function of the SEI is to transition technology, and several ideas were brought forward.One was for the SEI to interact with DoD programs using MDA, as well as with vendors and researchers.Bringing these groups together would help develop a shared understanding of problems and approaches.It was also suggested that the SEI could expand its participation with OMG.
• research A research agenda relating to MDA technologies would be of value.As part of this subject, participants perceived that consideration of technology readiness levels (TRLs) and a technology maturity model would be useful.There are also research questions that apply to the acquisition community (e.g., what does it mean to acquire a model?) CMU/SEI-2006-TN-031

Summary
This technical note has addressed various aspects related to MDA, which is suggested as a means to develop and maintain large systems.Along with the touted advantages of using MDA, there are a number of concerns.The workshop attendees represented perspectives of the standards body, vendor, acquisition, development, and research communities.In addition to considering these perspectives, workshop attendees developed several integrated perspectives.
Three conclusions stand out from this workshop: 1. OMG's MDA is an approach to software development and not just a set of standards.
The standards exist to support the realization of this approach, especially as they relate to the transformations of a PIM to one or more PSMs and the capability for tools to support these transformations.
2. MDA tools available today exhibit useful capabilities for generating software from models.Nonetheless, the technical challenges posed by the MDA vision push beyond the reach of what can be achieved with today's language specification technology, especially with respect to nonfunctional semantics (behavior).There is great risk that consumer expectations will not be satisfied.
3. The question of acquisition of a model is problematic.It runs the gamut from high-level acquisition strategy to the language of a contract.To the extent that MDA represents an abstraction of a PSM to a PIM, there may be a corresponding abstraction required from the perspective of an acquisition.
In summary, while the principles underlying MDA are sound, there remain issues that must be solved for MDA to realize its full potential.

Figure 2 :
Figure 2: Three Contemporary Forms of Program Generation For a pattern that MDA tool development might follow, we can look at the CASE experience.CMU/SEI-2006-TN-031 Some of the expected benefits of MDA, as identified by OMG include: CMU/SEI-2006-TN-031 XMI stands for XML Model Interchange.It is an OMG specification used for model exchange between most tools that have an XML model feature.CMU/SEI-2006-TN-031

Table 1 :
MDA Preparation Questions to be Addressed by Each Role-Based Perspective Can MDA be a conduit for commercial exploitation of software engineering technology research?• What can tool vendors and the OMG do to facilitate this outcome?
• When an acquisition organization says that it wants to acquire models, what does that mean exactly?Development Developer • What are the most effective aspects of MDA in practice?• What aspects of MDA are not as effective as you had hoped or expected?• What aspects not currently addressed by MDA do you think are needed or would be most desirable?• How do developers deal with nonfunctional aspects, like performance or deadlines?• What are your experiences with MDA code generator tools?Research Researcher • How does MDA fit in the context of past and current research in specification, analysis, and program generation?It is "ok" to address both natural strengths and limitations inherent to the MDA approach.• CMU/SEI-2006-TN-031