Where is MDA going to? My personal wish.

Many days ago I published a post about an MDA article , it was about Elaborationist and Translationist approach, and about a “hole” between them. Here it is my personal wish:

1) I'd like to have a computationally complete UML subset for the MDA context;

2) I'd like this subset to be as much general as possible;
3) I'd like to execute and test the models directly.

Having a computationally complete UML subset means that every model has its own semantic, and every model can be an actual part of a system. To define the best syntax for action semantic there is no need to chose between Object Constraint Language and Action Language, the right solution would be to have a mix of the two, defining a resulting language that inherits the best from both the declarative and the imperative approach. I wouldn't like specialised UML diagrams for the embedded systems and other diagrams for the business systems, the models should be domain independent. Does exist a good reason to define specialised UML diagrams with specialised semantic? Domain Specific Languages should be introduced only when really necessary.
I'd like to have the most general models, to exploit abstraction, to keep domain and platform details as near as possible to the end of the model transformation chain.
And finally, I'd like to execute and test models directly, is a key feature for an MDA tool, I don't like to write models and debug Java, C or wathever it was, “I think and write models, and I want to execute and debug modes!”.

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 :-)

UML completeness and complexity

So often I've heard IT people talking about their difficulty in using UML. The reason for this spread “feeling” maybe lays the fact the UML is now a very large set of conceptual tools, and it is still growing. Personally I understand and appreciate the great value of the work OMG's people is doing to complete UML, toward an actual Unified set of modelling elements; I think the community needs such formalised concepts. Nevertheless I see that for a lot of people is very difficult to approach analysis and design with UML: which diagram is more appropriate, from which point of view should this matter be modelled, which is the exact meaning of this set of elements, are all questions that can reduce the confidence in UML. I believe – and this is an opinion not a matter of fact – that a meaningful reduced set of UML could be a more aggressive proposal to push on UML in the IT community. What I'm thinking about is a subset of the whole UML from which would be possible to obtain the models we need, less diagrams but well known, widely used and completely understood. Finally, we could aim at very valuable objective, a completely computable UML. Currently many efforts are carried on to define specialised subsets of UML to fit the needs of particular fields of application, but this is not what I'm thinking about, I'd like to have a pervasive Unified Modelling Language and not many specialised Disjoint Modelling Languages.

At last, I know which is my job

Has always been a problem to explain to many people which was my job. Usually I was the “guy that works with the computers”... Yes, like the writers work with books, and the musicians work with guitars. Now things are changed, I know that when I write a piece of code I'm modelling an algorithm, I'm using the model suggested by the programming language, and when I test a program I'm executing instances of a model. To think about software engineering processes is thinking about models of activities and interactions; a software architecture is a model that drives the analysis and the implementation of an IT system. Software components and their interfaces are models. And finally, we have MDA that promotes the specification of IT systems as a sequence of related models.Unified Modelling Language!... Wonderful. Thanks MDA, thanks OMG and many thanks to all my colleagues. Now I know which is my job: “I think about Models!”.
“Uhm, interesting, you mean ... Top Models?”.

Which model for UI in the MDA?

User Interface (UI) is often an important part of an IT system, and MDA suggests to describe such a system as a set of related models. Finally, in our actual projects we'd like to follow an MDA process and to use MDA tools that could produce the executable code from models. In this scenario the UI is a domain of the whole system that requires to be modelled, with the ultimate goal of integrate it and generate it with all the other necessary application domains. I think that UML could be a good tool in describing some UI characteristics, for instance it might be possible to capture some common properties of the UI components: the displayable and editable class attributes, the navigation, the relation between class of forms, the common attributes of the UI components such as the “OK” action handler, the “Cancel” action handler and so on. But the responsibility of a modeller in the MDA context is to capture every application-significant aspect of a domain and, for the UI, properties like screen position, colours, dimensions, fonts, input masks, are fundamental requirements. At this point my personal idea is that UML alone it is not enough for a convenient modelling. Furthermore, we'd like to model UI in a WYSIWYG fashion. Maybe it turns out that a modelling tool, specifically designed for UI modelling, would be better: a rich application that let us draw a complete UI and produces the underlying UML. Often, formal input controls are also part of a non trivial UI, how can the tool cope with this kind of UI application logic? Are still the underlying UML and its meta model adequate? Or wouldn't be better to use a tool that generates a separate UI code module, that integrates with the other system domains with established interfaces, maybe forsaking this way the possibility of future XMI export and import?