3.2 UML as PIM Language

As seen in section 1.3.1 the level of completeness, consistency, and unambiguity of a PIM must be very high. Otherwise, it is not possible to generate a PSM from a PIM. Let's investigate to what extent UML is a good language for building PIMs.

3.2.1 Plain UML

The strongest point in UML is the modeling of the structural aspects of a system. This is mainly done through the use of class models, which enables us to generate a PSM with all structural features in place. The example in Chapter 4 shows how this is done.

UML has some weak points that stop us from generating a complete PSM from a PIM. The weak area in UML is in the behavioral or dynamic part. UML includes many different diagrams to model dynamics, but their definition is not formal and complete enough to enable the generation of a PSM. For example, what code (for any platform) would you generate from an interaction diagram, or from a use case?

Plain UML is suitable to build PIMs in which the structural aspects are important. When a PSM is generated, a lot of the work still remains to be done on the resulting model, to define the dynamic aspects of the system.

3.2.2 Executable UML

Executable UML (Mellor 2002) is defined as plain UML combined with the dynamic behavior of the Action Semantics (AS). The concrete syntax used in Executable UML has not been standardized.

The strength of plain UML, modeling the structural aspect, is present in Executable UML as well. Executable UML to some extent mends the weak point in plain UML, the modeling of behavior. In Executable UML the state machine becomes the anchor point for defining behavior. Each state is enhanced with a procedure written in the AS.

In principle, Executable UML is capable of specifying a PIM and generating a complete PSM, but there are a few problems:

  • Relying on state machines to specify complete behavior is only useful in specific domains, especially embedded software development. In other, more administrative, domains the use of state machines to define all behavior is too cumbersome to be used in practice.

  • The AS language is not a very high-level language. In fact, the concepts used are at the same abstraction level as a PSM. Therefore, using Executable UML has little advantage over writing the dynamics of the system in the PSM directly. You will have to write the same amount of code, at the same level of abstraction.

  • The AS language does not have a standardized concrete syntax or notation; therefore, you cannot write anything in a standard way.

Executable UML is suitable within specialized domains, but even there the benefits might be less than you would expect, because of the low abstraction level of the action language.

3.2.3 UML “OCL Combination

Using the combination of UML with OCL to build a PIM allows for PIMs that have a high quality; that is, they are consistent, full of information, and precise. The strong structural aspect of UML can be utilized and made fully complete and consistent. Query operations can be defined completely by writing the body of the operation as an OCL expression. Business rules can be specified using OCL, including dynamic triggers.

The dynamics of the system can be expressed by pre- and post-conditions on operations. For relatively simple operations the body of the corresponding operation might be generated from the post-condition, but most of the time the body of the operation must be written in the PSM. In that case, generating code for the pre- and post-condition ensures that the code written in the PSM conforms to the required specification in the PIM.

Although the dynamics of the systems still cannot be fully specified in the UML “OCL combination, the combination of UML class models with OCL allows for a much more complete generation of PSMs and code than does plain UML. The use of the combination of UML and OCL is at the moment of this writing probably the best way to develop a high quality and high level PIM, because this results in precise, unambiguous, and consistent models that contain much information about the system to be implemented.



MDA Explained. The Model Driven Architecture(c) Practice and Promise 2003
Project Leadership (The Project Management Essential Library)
ISBN: N/A
EAN: 2147483647
Year: 2004
Pages: 118

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net