Interview Questions  «Prev  Next»
  • Interview Questions
  • MDA Faq
  • RUP Faq1
  • RUP Faq2
  • UML Questions

    • Model Driven Architecture (MDA) FAQ

    Model Driven Architecture (MDA) is a software design approach that might be particularly beneficial in systems design due to its focus on abstracting and automating the development process. Essentially, MDA separates the specification of the functionality of a system from its implementation on any specific technology platform. In the context of systems design, MDA could potentially be used to first define a system-independent model, often known as a Platform Independent Model (PIM). This model aims to specify the system's operations and functionalities without being bound to any particular technology or platform. The advantage here might be the ability to maintain a clear focus on the business logic and requirements without getting entangled in technical complexities at the initial stages.
    Subsequently, this PIM can be transformed into one or more Platform Specific Models (PSMs). These PSMs are tailored to specific platforms or technologies, such as a particular programming language or database system. The transformation process, which can often be automated to a significant extent, leverages mappings defined between the platform-independent and platform-specific layers. This approach could potentially lead to increased efficiency, as it allows for the generation of code and other system components for different platforms from a single model. Moreover, MDA might also facilitate better adaptability and scalability in systems design. Since the core functionality is defined at an abstract level, adapting the system to new technologies or platforms may simply involve creating new mappings and generating new PSMs, without the need to alter the fundamental business logic.
    It's also worth noting that MDA's reliance on formal specifications and models could enhance communication among stakeholders, including developers, architects, and business analysts. By providing a clear and technology-agnostic view of the system, it might aid in ensuring that all parties have a common understanding of what is being built. However, it's important to consider the potential challenges and limitations of MDA. The approach requires significant upfront investment in creating detailed models and mappings, and it demands a high level of expertise in model-driven development tools and methodologies. Furthermore, the success of MDA heavily depends on the quality and expressiveness of the models, and there may be scenarios where the abstraction provided by MDA doesn't align well with complex, specific business requirements or technical constraints. In summary, while Model Driven Architecture could offer several advantages in systems design, such as improved efficiency, adaptability, and communication, its effectiveness may largely depend on the specific context of the project and the skill sets of the development team.

    MDA Technology Briefing Questions:

    1. What is the Model Driven Architecture (MDA) and how is it different from other architectures?
    2. Why is the OMG going in a new direction? What prompted it?
    3. What is the role of UML in the MDA?
    4. What is the role of middleware platforms in the MDA?
    5. What about CORBA, then?
    6. How does MDA enable cross-platform interoperability?
    7. What Services will be available in the MDA?
    8. How will Domain-Specific Software and Standards take advantage of the MDA?
    9. How does MDA compare or compete with Microsoft's .NET or Sun's ONE?
    10. Who is responsible for the MDA?
    11. What are the top three benefits of the MDA to enterprises trying to cope with today's computing environment?
    12. How will the MDA be delivered? In what kind of tools? And when?
    13. How is OMG doing, anyways?
    14. Will MDA adversely impact the CORBA-based product I've installed or plan to install in the near future?
    Question: What is the Model Driven Architecture® (MDA®) and how is it different from other architectures?
    Answer:
    The MDA is a new way of writing specifications and developing applications, based on a platform-independent model (PIM). A complete MDA specification consists of a definitive platform-independent base UML® model, plus one or more platform-specific models (PSM) and interface definition sets, each describing how the base model is implemented on a different middleware platform.
    A complete MDA application consists of a definitive PIM, plus one or more PSMs and complete implementations, one on each platform that the application developer decides to support.
    MDA development focuses first on the functionality and behavior of a distributed application or system, undistorted by idiosyncrasies of the technology or technologies in which it will be implemented. MDA divorces implementation details from business functions.
    Thus, it is not necessary to repeat the process of modeling an application or system's functionality and behavior each time a new technology (e.g., XML/SOAP) comes along. Other architectures are generally tied to a particular technology.
    With MDA, functionality and behavior are modeled once and only once. Mapping from a PIM through a PSM to the supported MDA platforms will be implemented by tools, easing the task of supporting new or different technologies.

    Question: Why is the OMG™ going in a new direction? What prompted it?
    Anwser:
    It is not really a new direction, when you take OMG's history into account. In 1997, OMG expanded its scope to include modeling with the adoption of the Unified Modeling Language (UML) and Meta-Object Facility(MOF™).
    Although it has always been true that UML models can be implemented on any platform, the continuing proliferation of middleware "silver bullets" suggested that a platform-independent UML model is the secret to software stability and ROI, a stake that remains fixed in the ground while the infrastructure around it shifts over time.
    The MDA unites OMG's well-established modeling standards with not only CORBA but also every other middleware technology (past, present, and future) to integrate what you have built with what you are building, with what you are going to build. MDA raises the bar and designs portability and interoperability into the application at the model level.

    MDA Distilled
    Question: What is the role of UML in the MDA?
    Answer:
    UML is the key enabling technology for the Model Driven Architecture: Every application using the MDA is based on a normative, platform-independent UML model. By leveraging OMG's universally accepted modeling standard, the MDA allows creation of applications that are portable across, and interoperate naturally across, a broad spectrum of systems from embedded, to desktop, to server, to mainframe, and across the Internet.

    Question: What is the role of middleware platforms in the MDA?
    Answer:
    In the MDA, a specification's PIM is used to define one or more PSMs and interface definition sets, each defining how the base model is implemented on a different middleware platform. Because the PIM, PSMs, and interface definitions will all be part of an MDA specification, OMG will adopt specifications in multiple middleware platforms under the MDA.
    While CORBA's platform and language independence and proven, deployed transactional and secure nature continue to make it the best choice for systems from embedded to desktop to Internet, MDA makes porting to, and interoperating with, other middleware platforms easier and cheaper.
    Question: What about CORBA®, then?
    Answer:OMG continues to promote and develop CORBA, and the CORBA market continues to expand, particularly in real-time & embedded systems, and the large, mission-critical, fault tolerant systems essential to enterprise computing.
    Because CORBA is the only multi-platform, multi-language solution for systems integration, many enterprises will use CORBA to build and integrate applications defined in the MDA.
    OMG and its member companies have always recognized the value of interoperating with other standards as well as proprietary platforms & languages. OMG created the COM/CORBA interoperability specification in 1995 (for connections to Microsoft's proprietary desktop systems) and expanded it in 1997, and designed and constructed the many ways that CORBA works with Java and XML.
    Among its other benefits, MDA continues this work of defining cross-middleware interoperability, and will provide tool support to speed and automate the process. This will be a great benefit to users who find themselves supporting multiple middleware platforms.
    Question: How does MDA enable cross-platform interoperability?
    Answer: As every new MDA specification or application is built, interoperability with other specifications and services is designed into it. In the MDA, the base specification of every service, facility, and application is a platform-independent model. In the platform-independent modeling environment, architects can specify links from an application to needed services and facilities, and to other applications, as part of its model. Working with this structure of linked models, MDA tools automatically build bridges connecting implementations on their various middleware platforms.
      Question: What services will be available in the MDA environment?
    Answer: OMG members are well aware of the extensive services necessary to support distributed computing, both within an enterprise and among many over the Internet. In CORBA, OMG's answer to this need was originally the CORBAservices, already defined and available here. In the MDA, these have been renamed the Pervasive Services because a single implementation of each, regardless of the platform on which it runs, can service every application or client that needs its capabilities via MDA-generated cross-platform bridges. Enterprises struggling to maintain and synchronize large directory services replicated on multiple platforms will surely appreciate the opportunity to trim down to a single instance!  In the MDA, OMG will define four Pervasive Services quickly: Additional services, as suggested by the list of CORBAservices already available, will be added as needed to keep the environment complete.
    Question:
    How will Domain-Specific Software and Standards take advantage of the MDA?
    Answer: The MDA has so many advantages for industry-specific software that some of OMG's Domain Task Forces started writing specifications in the MDA before it became an official part of our architecture!
    In order to benefit an industry, a standard must be used by a critical mass of companies. Technology-specific standards will have trouble getting established where platform incompatibility prevents achieving this critical mass. Sometimes the problem is even deeper than this: In some industries, architecturally excellent standards have been adopted in the formal sense but failed to gain hold because they were written for a platform that few companies were willing to support. 
    MDA completely removes these roadblocks. Under MDA, the functional description of every standard is technology independent, and the architecture is capable of producing interoperating implementations on multiple platforms. This allows an industry to define the business functionality and behavior of their standards as a PIM, and then produce PSMs and implementations on whatever platforms the participants require. 
    Bottom line: The industry gets a standard, every company uses it, and none are forced to switch platforms in order to benefit. Everybody wins! 
    Question: How does MDA compare or compete with Microsoft's .NET or Sun's ONE?
    Answer: MDA works at a different level than .NET and ONE. These are individual platforms, aimed at specific albeit broad application targets, while the MDA is (as its name declares) a Model Driven Architecture that works above the level of every middleware platform, .NET and ONE included. A middleware platform is incorporated into the MDA as a platform-specific profile. As .NET and ONE  establish market share, OMG members will define platform-specific profiles for them, allowing them to participate in the MDA along with the other platforms which will almost certainly include Java/EJB, XML and additional protocols and platforms dictated by the industry or the marketplace (SOAP or XP, for example).
    Question: Who is responsible for the MDA?

    Answer: Although the original impetus for the MDA came from OMG staff, it is now supported by the membership as demonstrated by unanimous votes of the technical representatives attending the organization's meeting in late February, 2001. Like all the other work of the OMG, MDA was defined and will be developed by the OMG membership which includes a diverse cross-section of computer vendors, software suppliers, and many end-users.
    1. If your company is an OMG member, please
    2. come to our Events
    3. If it is not, here is information about membership and
    4. an invitation to join us.
    The wealth of experience contributed by these hundreds of organizations is one of the great strengths of OMG's process, and has been put to good use in defining and refining the MDA. The initial vision was drafted in late 2000 in this OMG white paper, and subsequently refined with the help of many individual contributors into this technical perspective.
    Question: What are the top three benefits of the MDA to enterprises trying to cope with today's computing environment?

    Answer: There are many benefits to using the MDA approach, with the most important being:
    1. An architecture based on the MDA is always ready to deal with yesterday's, today's and tomorrow's "next big thing".
    2. The MDA makes it easier to integrate applications and facilities across middleware boundaries.
    3. Domain facilities defined in the MDA by OMG's Domain Task Forces will provide much wider interoperability by always being available on a domain's preferred platform, and on multiple platforms whenever there is a need.

    Question: How will the MDA be delivered? In what kind of tools? And when?
    Answer: Several key parts of the MDA vision have already been standardized, including not only the UML, MOF, XMI and CWM, but also the first middleware mapping (to OMG's own CORBA). Several other major MDA foundation specifications are "in the chute," including a middleware-independent mapping for enterprise systems (called "UML Profile for Enterprise Distributed Object Computing"). In terms of products, MDA will be implemented by tools - or suites of tools - that integrate modeling and development into a single environment that carries an application from the PIM, through the PSM, and then via code generation to a set of language and configuration files implementing interfaces, bridges to services and facilities, and possibly even business functionality. Several vendors already provide tools that support integration at about this level, including substantial code generation. Although these tools were not built explicitly to OMG's MDA standard (which wasn't complete when they were created), we're pleased to see this level of support for MDA so early in its development, and have collected links to MDA products and vendors that we know about here. 
    Many other vendors are hard at work on MDA-based development tools, so we expect the first generation of tools built explicitly to OMG's standard to emerge in late 2001. Additional vendors' products will join these soon after, so that almost all OMG vendor members (and many non-members) will be represented in the marketplace by products by around the middle of 2002. 
    The the generation of application code from an MDA PIM through an automated or semi-automated series of steps will be biggest benefit of MDA. We've pointed to examples (some more limited in scope than the generally-applicable MDA architecture itself), running today, that demonstrate the practicality of this vision. Generally-applicable MDA tools will initially move beyond modeling with the generation of code for  The next versions of tools will code execution of simple business rules; future versions will become even more sophisticated.  Question: How is OMG doing, anyways?

    Answer: OMG is bigger than ever, and doing well. With hundreds of member companies, OMG continues to be the largest software standards organization of its kind. There are more systems deployed using OMG's standards than ever, with new success stories appearing daily. Some recent examples include major design wins at a large airline reservation system and two of the world's biggest multinational automobile manufacturers.
    In terms of the OMG standards process, there are now more adoptions in process than at any other time in OMG's twelve year history. Our meetings, which typically attract hundreds of  members and guests, regularly host industry workshops and co-host meetings of other organizations.
    Question:
    Will MDA adversely impact the CORBA-based product I have installed or plan to install in the near future?
    Answer: Absolutely not. First, OMG plans to continue support for CORBA at current levels at least; demand from CORBA users in realtime, embedded, fault-tolerant, and enterprise systems will actually increase the tempo of CORBA standardization. CORBA will also be one of the most prominent platform-specific models in the MDA. MDA will make it practical to either keep all of your CORBA applications and bridge to other platforms, or port to them, basing this decision on business factors instead of technological pressure.