Evaluating the Model Driven Architecture Process for Designing, Developing and Deploying Evolving Distributed Applications-- hype or reality that is the question.

ECE1770 Assignment #1 (due Thursday, March 13th, 2003 at the beginning of the lecture.

"Precise definitions of MDA are hard to come by." The objective of this assignment is to evaluate the MDA process by rigorously applying it, as envisioned by its designers, to all stages of the software engineering process of building a distributed application with different middleware platform technologies. A further objective, is to familiarize oneself with different middleware platforms and understand the difference between a "higher-level" middleware platform and a "lower-level" operating systems or network communication abstraction.

This assignment is exploratory and research oriented. There are many right answers (- some wrong ones too.)

The assignment may be carried out in teams of up to four students. The final mark is per team.

Due date is Thursday, March 13th, 2003 (to be handed in at the beginning of the lecture.) Marks decay at the rate of 1% per day handed in late.

All teams should benchmark some of the development process against the use of sockets - not really a middleware abstraction per se. Groups are free to use Java-sockets or C-sockets as found on all standard operating systems.

Teams my chose among the following middleware platforms. Note, the choice of a particular programming language and particular platform implementation is left to the team. The middleware platforms are:

Team structure

Teams of up to four students are allowed. Each group must benchmark some of their development process against the use of sockets (cf. details below.)

  1. A one student team must additionally choose one of the middleware platforms listed above.
  2. A two student team must additionally choose two of the middleware platforms listed above.
  3. A three student team must additionally choose three of the middleware platforms listed above.
  4. A four student team must additionally choose four of the middleware platforms listed above.

Distributed Application Case Study:

The distributed application case study consists of a data dissemination service - essentially, a middleware service in its own right.

A data dissemination service consists of data producers, data consumers, and data mediators.

A data producer is an entity that submits data elements to data consumers via the data dissemination service.

A data consumer is an entity that expresses interest in receiving certain data elements from data producers via the data dissemination service. It should only receive the data elements it has expressed interest in.

The data mediator accepts data elements from data producers and delivers them to data consumers, according to the interests expressed by the data consumer.

An application that is build on top of the data dissemination service creates data producer and/or data consumer objects to exchange data. An application may create any number of such objects and may even create data producers and data consumers all at once.

Data elements exchanged via the data dissemination service are comprised of a unique identifier (unique in the distributed application) and the actual data payload. The payload may be composed of integers, floats, strings, structs, arrays, and unions. All following the typical interpretations of standard programming languages.

Hint: First, try to identify what the operations are that each of the objects support (i.e., their interfaces). You are free to decide how the required functionality is supported. For instance, you need to come up with a scheme that allows a data consumer to express interest in certain data elements, so that the data mediator may filter out irrelevant data elements. However, the overall design is completely left up to you.

Note, if the above specification is not complete (-which it is-), you are free to fill in the gaps, but clearly state your assumptions.

Deliverables:

All deliverables should be presented in a final project report. The report is due in class (cf. deadline above.)

  1. The Platform Independent Model

    1. Provide a PIM (Platform Independent Model) of the application. PIMs are commonly expressed in UML (Unified Modeling Language), however, any concise description will do.

    2. Describe the mapping of the PIM to all PSMs (Platform Specific Models), as envisioned by the MDA process, for your choice of middleware platforms from the above list (you do not have to include a mapping for bare sockets.)

      Note, concrete PIM-PSM mappings are still under development. You may thus define your own mapping for the middleware platform models chosen. Define this mapping carefully and chose an adequate formalism for expressing your mappings. Carefully distinguish between PIM elements that could be mapped automatically and elements that can only be derived manually. You only have to define mappings for the elements of the middleware platform used to build the distributed application case study. (Standardized mappings would define mappings for all middleware elements of a given specific platform model.)

      We don't have any tool that implements mappings, so you are supposed to "simulate" the process of automatically mapping the PIM to the PSM by formalizing, describing, and quantifying the mapping process.

    3. Quantify the amount of the PSM that could indeed be automatically generated and the amount that can only be manually derived for the application case study given - for all specific middleware platforms you chose. Carefully describe your quantification methodology.


  2. Platform Specific Model

    1. Provide all PSMs (Platform Specific Models) of the distributed application case study for each of the specific middleware platforms (excluding sockets) chosen by your team. Note, you may have done this already under the above question; you don't have to repeat yourself.

    2. Describe the mapping of the PSM to the chosen target middleware platform as envisioned by the MDA process.

      Note, concrete mappings depend on the particular middleware platform you have chosen. In CORBA, for instance, interfaces would be generated with the middleware IDL-compiler. Other parts of the implementation may be partially generated with other tools.

      Currently, no concrete recommendations are available on how or what to generate. You may define your own mapping mechanism for your particular choice of target middleware technology. You only need to consider elements of the target middleware platform that you need for the distributed application case study. You may describe the mappings informally, e.g., "...the interfaces of object A and B are processed by a standard IDL compiler to generate stub and skeleton code and ...".

      However, carefully quantify the amount of code that could *NOT* be automatically generated. Even if portions of the code can currently not be generated automatically, if you think they could (e.g., due to their pattern-like nature) do not count them (you may describe the pattern or refer to a common pattern in that case.) You may need to define your own metrics for quantification purposes (e.g., lines of code is a choice, although not the best one.)



  3. Implementation

    1. Partially implement the distributed application case study in all platform technologies (i.e., your choice of sockets and your choice of middleware platforms.)

      For the data producer object, implement the data element submission methods. Implement at least support for submitting one atomic data type (i.e., integer, float etc.) and one composite data type (i.e., array etc.)

      Similarly, for the data consumer object, implement the respective subscription functionality (expression of interest in certain data elements and their transition into the application managing the data consumer object.

      Evaluate the performance of all implementations and comparatively present the results for the exchange of an increasing amount of values of atomic type and an increasing amount of values of composite type. Stretch the limits in your performance studies (i.e., stress test and measure).

      Note, all experiments should be run on the same hardware platform.



  4. Overall assessment and evaluation: Hype or reality ?

    Evaluate the MDA process by critically reflecting on the different stages above. Is it hype or is it reality. Use your "simulated" quantifications to make a point.

References

Document -- ormsc/01-07-01 (Model Driven Architecture (MDA)) This is the description of the MDA adopted as OMG's Technical Architecture by the Platform Technology Committee, Domain Technology Committee and Architecture Board.