An Example Model-Driven Process

As an example of a model-driven process with simple source and target models, consider our banking application with J2EE as its implementation platform. In this case, you will have to formalize the knowledge of the bank in a model, and then build a bridge from the Bank model to J2EE.

In general, of course, it's not quite as simple as having a single source model and a single preselected target implementation model. Rather, a typical system will comprise several platforms, and this means that there will be potentially several utilizations of the pair of high-level activities described above, not just one.

With these easily identified platforms on hand, you may also require other platforms for modeling at higher levels of abstraction. For this banking system, for example, you may identify the need for a platform on which the bank relies to ensure that certain operations can be carried out, and certain data accessed only by people playing certain authorized roles. If this behavior is formalized in a model of Security, then you will have to do the following:

• Formalize the knowledge of the bank in a model.

• Build a bridge from the Bank model to the Security model.

• Build bridges from the Bank and Security models to J2EE.

Each definition of the work to be done is the specification of a model-driven process for your particular project, given a particular set of platforms.

This model-driven process assumes the prior existence of the Security platform as a model. If, however, the Security platform doesn't exist, you'll have to build it by formalizing the knowledge of that subject matter. In that case, your process will be as follows:

• Formalize the knowledge of the bank in a model.

• Formalize the knowledge of security in a model.

• Build a bridge from the Bank model to the Security model.

• Build bridges from the Bank and Security models to J2EE.

The result of identifying these platforms and the bridges between them constitutes a specific model-driven process, the workflow if you like, for your project.

The overall structure of the process, then, is not only iterative and incremental, but also recursive. We formalize the knowledge for one platform and attempt to build a bridge to our platform's implementing abstractions. If that platform already exists, the mapping can proceed. If it doesn't, we must formalize the knowledge of the target platform before the mapping can be specified and executed.

Normally, of course, we plan ahead by searching out existing platforms and only build our own platforms from scratch when we have no choice. Many platforms near to the implementation will also already be realized. Examples include the Java platform; CORBA; .NET; operating systems like Linux, Solaris, and Windows; and specific real-time platforms.