Model Driven Architecture® & MDD

Blog chiuso

2009-06-20T15:40:00.000-07:00

E' stato trasferito suL BLOG di Soluta.Net
Buon Proseguo
Pierfranco Ferronato

Where is MDA going to? My personal wish.

2006-10-29T09:35:00.000-08:00

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

2006-10-15T03:31:00.000-07:00

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

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.
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

2006-10-07T13:27:00.000-07:00

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

2006-10-06T12:59:00.000-07:00

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?

2006-10-05T12:13:00.000-07:00

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?

Hierarchies: only a human artefact?

2006-09-12T08:24:00.000-07:00

Most of the solution in SOA, like the cluster of UDDI registries, are based on an hierarchical structures because this is the way humans do in order to deal with complexity, i.e. in order to create comprehensible models.

But as a matter of fact, the reality is not hierarchical at all, this is the reason why information models becomes more and more unmanageable with the increase in complexity. Below a certain degree of complexity, the model can be oversimplified and a hierarchy represent a good approximation, but when complexity increases, it becomes impossible to stick to an hierarchy because reality is not as simple and it's based on different models and topologies, for example Scale Free Networks.

The risks in understimating MDA

2006-09-07T14:14:00.000-07:00

MDA, if applied correctly, promises to change the way we deal with software development:

is it everything going to change?
Are we really going slim down classical software development methods and processes?
What shall we expect and tackle in a MDA/MDD based project?

The idea is that those problems, the same old problems are still here, and the risk is in underestimating their impact.
MDA approach need to be supported by a proper method, process and tool otherwise it'd not be possible to achieve the provisioned advantages, on the contrary the project may collapse at a faster pace then non MDA based projects.

The impact of UML documentation on software maintenance

2006-09-02T10:16:00.000-07:00

There is an interesting article on IEEE transaction on Software engineering volume 32 June 2006 about "The impact of UML documentation on software maintenance".

The conclusions of two experiments are mostly consistent.

No savings in effort are visible.

the conclusion of the article are:
This pare presents the results of two consecutive experiemnts which have taken place in two different locations. The goal was to shed some light on the cost effectiveness of model-driven development with UML. because this is a very large area of ivestigaiton, we focused on whether models help software engineers to make quicker and better changes to existing systems. It is very ocmmon in practice to have software engineers making changes to systems they have not developed and maintenance consumes a large portion of the resources in typical software organisations . This why we thouht that this was an important first question to investigate , though we realize that model-driven development can be useful in many others ways(e.g. code generation). The result of our two expriments are mostly consistent. When considering only the time required to make code changes , using UML documentation does help to save effort overall. On the other hand, when including the time necessary to modify the diagrams, no savings in effort are visible. However, in term of the functional correctness of the changes, both experiments seem to indicate using UML has a significant , positive impact on the most complex tasks.

In my opinion this result reflects two importants points
1) the tools for approaching MDA are not mature , they can improve in usabilty
2) the skills for working with MDA with effectiveness are very high

what we need to lower the cost are probably some tools MDA that simplify the use of some subset of UML, so we can use "normal" people.

what you think?

Where is MDA going to?

2006-08-31T09:35:00.000-07:00

Recently, while digging into the Internet searching illuminating words about MDA, I found an interesting article written by Ashley McNeile. The author presents very clearly the opposition of two mainstreams in developing MDA tools, the Elaborationist and Translationist approaches. Recently, during the last year, I've been involved in two different MDA projects, the first was actually an Elaborationist one, and the latter absolutely a Translationalist MDA project. I have a steady personal idea about the two approaches, quite a clear envision, supported also by these two recent personal experiences.
Is really so difficult for the opposite methodologies to converge into a comprehensive one?
I've my personal opinion about it, stay in touch, I'll write out more in the future...

Software engineering: and oximoron (and it will be forever)

2006-08-31T02:47:00.000-07:00

The civil engineering principles and practises start from the obvious real fact that "it costs more (much more) to change than to create" and this undoubtable fact is reflected and it influences the entire approch.
In IT, on the other hand, the undoubtable fact is that it costs less (much less) to change than to create (at least in the short term in the life cycle of projects) and this has badly influenced the IT practises until the early time when complexity and urgency became a preminent factor.

But now we are not yet able to get rid of the Software Engineering principle in IT! We still look at it as the leading light, the guiding principles. But this is badly influencing the practise, approach and methods of IT. The early 90s heavvy methods are still here with us even thought something is moving in the right direction: MDA.
The software developement processe need to leverage its own advantages which is flexibility and adaptability instead of flighting it. The fact that is cheaper to change than to build is a value added, unque to IT because of its inner "soft" soul, it's not a deficiency to fight.
Beside the fact that in IT no one can affort to wait one or two years before having a usable software product (which is common for planning, builiding and using a bridge or a skyscraper). Let's assume that in IT we first build and then we change: it's in the human nature. In engineering practise, we first want to plan and then to build because we can not economically and practically afford to move a house or to move a window. This approach has emerged naturally more then 2000 years ago, IT is not as lucky: it is just 50 years old and we are probably now understanting how to deal with it.

Software artifacts are far more adaptable then any other hardware or concreate stuff. Let's then create an approach, process and supporting tools that not only accept this fact but also use it at the value add, the leading principle. In essence MDA is exactly doing this: creating an approach founded on "flexibility" that accepts, admits and wants IT system to be build by continuous changes. Yes it sounds like the Iterative & Incremental approach, but not as a cure to the heavvy engineering approach of IT, but as a prime strategy. In essence MDA wants to even ease and support the fact that it is cheaper to change than to build and put it as a "method".

We have to dare, and to get rid of the past approaches and go in another direction supporting a characteristic that was considered the "devil", it is in reality a good think if wrapped around a formal approach that OMG is actually defing and formalizing.

On the other hand, we shall not fall in the error of considering that MDA is "do & try", "do & fix" or "plan afterward" on the contrary: changes need to be planned. MDA, making a comparison with civil engineering, is building a development method (development here is used in a broader sense) around the uncontrovertible fact that the cost of moving a pillar is far less expensive then the cost of building it! Would we have the actual Eng. methods in civil construction, for example, if adding a story to a building would be as cheap as building it since tbe begining? Not indeed, then we have to assume the same in IT, and start all over again with a different new mindset: a tabula rasa.

MDD/MDA and the role of the Development Process

2006-08-28T07:42:00.000-07:00

MDD tends often to underestimate the impact of the software factory: in details, the role of the process. The organization of work and the hierarchy changes, it is not the usual software engineering process with Analysis-design-code-test, but a rather different approach where test happens in either a PIM environment, where the design happens is an parallel task out of the streamlined production process.

Under-estiamating the role of the process can reduce the advantage of MDD/MDA.

The development process when working with in MDD/MDA has been devided between different groups, testing and technology mapping have to be considered.

MDD can push the development process at a speed where the planning is postponed and will create obstacle and difficoulties in further phases of the project like it happended with 4GL. Planning as well as an accurate requirement capture and a proper analisys modeling greatlny contribute to the success of and MDD based development process.

Embracing the usual software engineeting process when applying MDD is overlookin the problem and increases the risk of the project.

Obeo MDA Tool by Acceleo

2006-08-27T16:25:00.000-07:00

Obeo has released an MDA Open Source tool, Acceleo.
It interesting to notice that more and more MDA tools are available out there which also support UML2, QVT, MOF and are based on the Eclipse framework.
Last but not least this is FL/OSS