15 October, 2006

The PRC UML set of models

Suppose we have a subset of UML for which a completely defined computational semantic exists. So, for such a set, could even exists a Virtual Machine that would able to simulate, debug and execute every model formalised in that UML's subset. Let's call this subset cUML, like “computable” UML and the corresponding Virtual Machine the cVM. That would be a great point to start from, because we might be able to construct every system that could be modelled with cUML, as an actual executable model in the cVM, in the the best spirit of MDA that fosters system construction by models and model transformations.


The problem now might be how to execute in the VM a model that is a UML model, but not a completely cUML model – i.e. a model that contains some elements that are not representable in cUML.


But always in the MDA's realm we could design and implement a transformation, from a UML model into a cUML model. Suppose for instance, that we have a BPML model, say M, that is contained in UML, but not contained in cUML. We could than write a transformation from M to M', where M' has exactly the same behaviour as M, but M' completely belongs to cUML. That could be a transformation from UML's metamodel to cUML's metamodel (and cUML's metamodel is still a subset of UML's metamodel). In that case we would be able to execute M' – and thus M – in the cVM !


What does this mean? In my opinion this means that we could have a great tool to execute a very large set of models, I would call this set the PRC UML set, where PRC stands for Primitively Recursive Closed. This is not a very new idea, it is the same idea used in the theory of computation where the PRC sets are basilar. The PRC UML set is composed by all that models that can be written in terms of cUML's elements, models constructed by composition and recursion of cUML models. That would be a great tool in our hands.


To be more practical I would say that

  1. If you have a cVM, and you are facing for instance a problem that could be modelled as BPML, don't stop you from executing it, find a transformation – maybe a manual transformation as a first approach – to obtain an equivalent cUML model, and execute it! For instance, if in cUML we have class diagrams, state diagrams and action language to model behaviour, than we can transform an activity diagram, a sequence diagram or maybe a BPML diagram into cUML. It's not impossible and it's not absolutely wrong. Having a non executable model is not a good reason to stop from executing it, al least in many practical cases.

  2. One fine day, someone could formalise and produce an automatic transformation from UML to cUML, in that case we all would have a way to execute high level UML models into a cVM. In other words we don't have to wait for a completely formalised computational semantic for UML – a Titan's job (*) – we could do that kind of magic with only a small cVM and a bunch of good transformations !

(*) I didn't use *Titanic*, for obvious reasons :-)


0 comments: