What is MDD? (Part 3)

Executable Models is one of the approaches for MDD. This post concentrates specifically on UML-based models. The idea is to use the minimum but necessary set of models to capture the domain logic, and make it immediately executable without further coding, compilation, and deployment.

As a quick background to set the context, developing a piece of software (whether done formally or informally) starts with capturing the functional requirements, analyzing it to better understand the problem and identify wholes and contradictions, then developing the abstract design to prescribe a solution to the problem independent of the underlying technologies and target architecture. The non-functional requirements are used for developing the target architecture including specifying the involved technologies, approach, patterns, etc. The marriage between abstract design and architecture results in the detailed design that can be coded, compiled and executed.

Accordingly, if you specify the target architecture upfront, then you’re able to automate the process of going from the abstract design to details design, coding and compilation. And, with a little of dynamic loading techniques, you can also eliminate deployment and blur the line between development and runtime.

So this takes care of the executable part. Now for the minimum but necessary set of models, a close study of any object-oriented programming language would reveal that it offers three constructs for development: static constructs like a class definition, dynamic constructs like the implementation of an operation with various flow-of-control statements (e.g. if-then-else, looping, etc.), and an expression syntax. Accordingly, if we identify the equivalent models in UML then we’re equally able to develop any application.

For the static construct, the UML Class Diagram is a great substitute for the text-based class definition code. You’re able to define one or more classes with their attributes, relationships to other classes, and operations (the declaration part only). For example, with a single line from one class to another, you’re able to specify the class member and type (including a typed-collection if it’s one to many), ownership (if any), the directionality (i.e. uni- vs. bi-directional), and visibility. And with a little bit of rule annotation, and you’re able to have a semantically complete model, that is ready to execute. A simple diagram that takes minutes to draw and comprehend can easily replace pages of code.

As far as the dynamic model to provide the implementation of operations, the UML Activity Diagram has all of the elements necessary to capture the flow-of-control similar to code statements. The Activity element is used to capture simple expressions, and you’re ready to execute the model. The operation declaration provides the signature including in/out parameters, and the Activity Diagram captures activities to traverse and manipulate the state of instances of the object model including by calling operations on other objects. Granted that the Activity Diagram might get crowded, but if the developer is experienced, your operation implementations should have no more than two to six activities (common metrics for quality of OO code).

Finally, expression syntax is very important. UML includes the Object Constraint Language (OCL), yet doesn’t prescribe a specific syntax. Regardless, pick your favorite expression syntax, say Java for example, add higher level operators that assist in the navigation and traversal of your object model, and you’re in compliance with OCL.

Now if you strip out all interface (specifically user interface) and persistence logic and focus on the domain logic, your models using the above can be readily executable. This changes the development paradigm altogether, where you’re able to use very small increments to model different parts (use cases) of the application and execute it for a quick validation. If you don’t like the results, quickly change the model and hit execute! This has a huge productivity gain that go far beyond even Smalltalk with its ability to immediately execute the logic by highlighting it and clicking Run It.

Going back to the interface logic, since it’s an important part of any application, the static model has the semantics necessary to render an instance of any class to a target client device (e.g. a web browser). If you limit the communication of an external entity (an actor) on the system to the execution of operations and the interchange of objects, you’re able to directly interact with instances of your model and validate the behavior of the system without any further coding. As far as personalizing the look and feel, there are many WYSIWYG approaches that can be used to control the rendering of an object instance to a specific look with a fraction of the time compared to normal development since you always start with the model (hence, no tedious wiring code).

As far as persistence, the static model (Class Diagram) also has all the necessary semantics to drive the generation of the data model (that can be automatically deployed to a live database instance), along with the SQL statements and the Object-Relational Mapping to transform the data back and forth. OR-Mapping is mainstream today even for hand coded applications.

This is getting to be a long post, so Part 4 will discuss the advantages and disadvantages of Executable Models.