The best way to successfully apply the topics addressed in my articles and develop advanced modeling expertise is with detailed examples from your own application. The ready availability of an expert who can review models, deliver customized examples and patterns, answer hard questions and clearly demonstrate the practical impact of one modeling choice vs. another on both the usage and design requirements is critical to success with UML and MDA. Here are some specific ways I can make agile, articulate analysis and modeling skills available to your real-time, distributed or embedded application.

This article illustrates the platform independent timing and synchronization rules that modelers use and architects implement to support Executable UML applications. UML standardizes behavioral notations such as statecharts and sequence diagrams, but it does not define any synchronization rules. One of the most powerful features of Executable UML is that it does not constrain the implementation with unnecessary sequencing. In traditional programming languages the stream of processing is sequential by default unless intentionally diverted through a variety of platform specific concurrency mechanisms. The opposite is true in Executable UML. Everything happens in a concurrent, platform independent timeframe unless there is explicit synchronization. This allows us to create application models that can be deployed onto arbitrarily distributed platforms…

Rectangles are not enough. Here are some examples and guidelines for writing useful class descriptions to accompany your UML class diagrams.

A definition useful for platform independent requirements analysis is provided here. The spectrum of concrete to abstract categories of classes are covered. The identification constraint is introduced and some frequently asked questions about classes are answered.

The least important reason is “So that someone else can read my models.” Sure, everyone else wants me to document my models, but what’s in it for me??? It took me a few years to learn, but there are numerous selfish reasons why any serious, articulate modeler should always be writing. And the process won’t be drudgery if you write about the important stuff. The most important rule? Don’t ever waste your time restating what is already obvious on the diagrams.

Most modelers know that you can create a loop in a class model where one or more relationships start and end on the same class. While looping is frequently necessary, it can introduce unintended ambiguity leading to incorrect or buggy software. Here are some techniques to constrain your loops so that your models say what you really want them to say and your code matches the intended requirements.

Feel free to send e-mail to leon_starr (AT SIGN) modelint.com.

Whereas UML is just a standard notation, Executable UML is a full fledged programming language. With Executable UML you can create detailed specifications of application requirements that can be executed on a virtual machine. You can set breakpoints for states, actions, test asynchronous interactions and so forth just as any real developer can. It is supported by a number of tools and you can use it to generate highly efficient code for a wide variety of embedded and real-time distributed platforms.

This knol is excerpted from my book “Executable UML: How to Build Class Models”