Many systems are deployed today using Executable UML and an appropriate model compiler. Among these systems we count:
The list is long and growing, as you would expect. Each model compiler compiles an Executable UML model to a specific target implementation: a software platform. The relationship between a model compiler and a software platform is analogous to the relationship between a language compiler and its hardware platform. Programming language compilers abstract away details of the hardware platform so that a programmer can express what needs to be done without reference to hardware platform issues, such as register usage and the organization of physical memory. In addition, the language compiler provides the run-time system that manages and localizes these issues. Similarly, model compilers abstract away details of the software platform such as how data is accessed, tasking structures, and concurrency, so that a modeler can express what needs to be done with reference to them. In addition, the model compiler provides the run-time system that manages and localizes these issues. Executable UML doesn't include notation to capture these issues for the same reason a programming language doesn't include register allocation or memory organization mechanisms: It would defeat the whole purpose. However, we can use the existing notation of Executable UML to capture the concepts of tasks, processors, and concurrently executing units in terms of classes, associations, and attributes between them. But now we need to select a model compiler, one that compiles to a software platform appropriate to the system. There are two complementary ways to tack down a woolly phrase such as "appropriate to the system," and they depend on the concept of a fit between a context and a "form," the entity under construction. |