Full code generation from UML class, state and activity diagrams

2011-03-10 – UPDATE: Interested in UML/TextUML and full code generation? You can now do that online using AlphaSimple

UML has become the lingua franca for modeling applications using the object-oriented paradigm. People use UML in many different ways (see the post on UML modes), ranging from as a communication tool to as a full fledged programming language that supports full code generation. This last way of using UML should puzzle most readers – how can UML models lead to full code generation?

UML has two diagrams that are used for behavior specification: the activity diagram and the state diagram. These two diagrams (more one than the other, depending on the nature of the subsystem being modeled), plus the class diagram (for modeling the structural aspects of the object model) provide the framework that supports the design of complex applications in a way that is fully complete (and thus allowing 100% code generation) while still implementation independent (see earlier post on platform independence). All the other diagrams (use case, sequence, collaboration) are interesting for gathering requirements, but are useless in modeling a solution that can be automatically transformed into a running application, and thus we will ignore them here.

Specifying structure with the Class Diagram

The class diagram is the most well understood of all diagrams in UML. You can model all structural aspects of your object model in the form of classes, attributes, operations and relationships between classes. This specification of structural aspects can then be used for generating (boilerplate) code, database schema, configuration files and so on so forth. This is great already, as that is most of the work. But without including behavioral aspects, it is impossible to do full code generation solely from the class diagram, you are forced to fill the empty methods with handwritten code (unfortunately this is how most vendors expect you to do model-driven development). Still, the class diagram is a fundamental one in which it provides a base framework the other diagrams can build upon.

Specifying dynamics with the State Diagram

The UML state diagram (derived from David Harel’s state charts) allows for a full design of the dynamic aspects of a system. One can model complex state machines using the state diagram, always in the context of a class described in the class diagram. Many mainstream applications do not have any interesting dynamics though, so in those cases the state diagram has limited value. However, in applications for certain industries (such as robotics, telecom and automotive) it is the most important diagram.

Specifying business logic with the Activity Diagram

The most underrated of the UML diagrams, the activity diagram has a key role: it is the only one to allow the modeler to specify behavior in a precise way. The Activity Diagram provides elements (such as actions, pins, data and control flows, signals) that allow specifying the meaning of a behavioral element (such as the body of an operation from the class diagram, or the effect of a state transition from the state diagram).

But no matter how important the UML activity diagram is, it has one strong limitation: it demands too much detailed information in order to be fully defined (and thus actually useful in the context of code generation). Any simple logic that could be written in a few lines in, say, Java, requires a graph with so many nodes that it is virtually impractical to use it with the graphical notation, severely hampering its more widespread adoption.

Have I just suggested that activity diagrams are useless for any serious usage? No! It is just the case that the graphical notation is too cumbersome, and it is not just a problem with the specific choice of symbols – there will never be any graphical representation that can be as expressive and concise for specifying behavior as your programming language of choice (even if your favorite language is as verbose as COBOL). So it is a matter of representation: a textual notation is much more appropriate than a graphical one. The activity diagram itself is fine, thanks.

So what is the textual notation for the activity diagram? There is none. I mean, not one defined by the OMG. Many companies have defined their own action languages (such as Pathfinder AL, Bridgepoint OAL, Kennedy Carter’s ASL) with compilers that provide a textual front-end for the UML activity diagram. TextUML itself has a bigger cousin (currently an ongoing work) that allows specifying UML activities in a way that is familiar to any programmer. Want to see what an action language looks like? Expect a new post on the subject (including our very own action language) here soon.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Comments are closed.