Model Driven Architecture Interview Questions & Answers

5 avg. rating (100% score) - 1 votes

Model Driven Architecture Interview Questions & Answers

Are you looking for Model Driven Architecture jobs? Finding job interview is tough task and at the same time preparing well for the interviews with right questions and answers will be helpful to get succeed. MDA is most demanding career in the current job market. Having exposure and experience towards MDA concepts will enhance your career growth. If you have an expertise in software design, development and implementation then various job opportunities are available on wisdom jobs. Top companies are searching for the candidates for various experience levels. Find latest jobs such as BI analyst, GIS analyst, simulation developer, CCBD architecture, Business intelligence analyst, data analyst and dashboard analyst etc. Following Model Driven Architecture job Interview Questions and answers are helpful for better interview preparation. Take a look at this page.

Model Driven Architecture Interview Questions

Model Driven Architecture Interview Questions
    1. Question 1. 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.

    2. Question 2. Why Is The Omg Going In A New Direction? What Prompted It?

      Answer :

      It's 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've built, with what you're building, with what you're going to build. Rather than focusing on yet another "next best thing," MDA raises the bar and designs portability and interoperability into the application at the model level.

    3. Question 3. 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.

    4. Question 4. 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.

    5. Question 5. 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 them supporting multiple middleware platforms.

    6. Question 6. 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:

      • Directory Services
      • Transaction Services
      • Security Services
      • Distributed Event and Notification Services

      Additional services, as suggested by the list of CORBAservices already available, will be added as needed to keep the environment complete.

    7. Question 7. 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.

    8. Question 8. 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).

    9. Question 9. 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. (If your company is an OMG member, please come to our meetings and get involved! If it's not, here is information about membership and 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.

    10. Question 10. 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:

      • An architecture based on the MDA is always ready to deal with yesterday's, today's and tomorrow's "next big thing".
      • The MDA makes it easier to integrate applications and facilities across middleware boundaries.
      • 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.

    11. Question 11. 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 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 

      • Interfaces (in OMG IDL and other interface-defining languages)
      • Functionality constrained by a specification (such as the CORBA Component Model, or EJB)
      • Access to MDA-standardized Pervasive Services and Domain Facilities 
      • Cross-platform access to functionality already standardized in the MDA, via an automatically-generated bridge
      • Wrappers for hand-coded execution engines that make access transactional or secure, as long as the basic interfaces to these engines have been defined in the MDA
      • Operations that get and set the values of variables declared in the model.

      The next versions of tools will code execution of simple business rules; future versions will become even more sophisticated.

    12. Question 12. 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 OMGs 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 OMGs twelve year history. 

      Our meetings, which typically attract hundreds of members and guests, regularly host industry workshops and co-host meetings of other organizations.

    13. Question 13. Will Mda Adversely Impact The Corba-based Product I've 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.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Software Architecture and Design Tutorial