The Model Driven Software Network
Raise your level of abstraction
Should UML use MDD or just be a graphical language ?
This question could seem stupid but ....
Concerning UML modeling which is my domain I have more and more doubt about the need to generate all the code from the model.
The class diagram which is usually used to generate the code can generate up to 80% of the needed code. Problems are:
- the generated code has no traceability with the original model. This is like two different projects for me. Once the codding stage has started if requirements change then it is impossible to go back to the model and generate again without either loosing existing code or keeping existing code with a trick which is not really clean.
- the code needs to be deployed and tested. Developers need therefore to change it and add persistence and presentation layers. Generating too many code is taking too much time to change it and it would save time just having the project structure. For example what is the interest of adding methods in the code if UML MDD can not generate business rules ?
For these two reasons and many others (e.g. jee development) I now recommend to my customers to use UML with almost no code generation and keep it at graphical level for documentation purposes. The only generated code is the skeleton of the application (e.g. classifiers) and the persistence attributes.
Information is graphical and in the model but will not generate any code. This is only used for project documentation.
My question is: Should UML use advanced MDD or just be a graphical language with a light MDD (e.g. only generate the skeleton of the application - I mean only classifiers) ?
Concerning UML modeling which is my domain I have more and more doubt about the need to generate all the code from the model.
The class diagram which is usually used to generate the code can generate up to 80% of the needed code. Problems are:
- the generated code has no traceability with the original model. This is like two different projects for me. Once the codding stage has started if requirements change then it is impossible to go back to the model and generate again without either loosing existing code or keeping existing code with a trick which is not really clean.
- the code needs to be deployed and tested. Developers need therefore to change it and add persistence and presentation layers. Generating too many code is taking too much time to change it and it would save time just having the project structure. For example what is the interest of adding methods in the code if UML MDD can not generate business rules ?
For these two reasons and many others (e.g. jee development) I now recommend to my customers to use UML with almost no code generation and keep it at graphical level for documentation purposes. The only generated code is the skeleton of the application (e.g. classifiers) and the persistence attributes.
Information is graphical and in the model but will not generate any code. This is only used for project documentation.
My question is: Should UML use advanced MDD or just be a graphical language with a light MDD (e.g. only generate the skeleton of the application - I mean only classifiers) ?
Replies to This Discussion
-
Permalink Reply by Rui Curado on -
UML with light MDD sounds like a "half-solution". I guess no-one is looking for that. On the other hand it seems that UML needs add-ons (like annotations?) to properly support code generation.
So, generating just the app skeleton is OK, but since it is the "skeleton" (backbone) of the app, every detail of such app relies on that skeleton. Adding protected code regions at such a high level would not work: A simple change in the app's architecture could wipe-out, or just orphan, large amounts of code.
In such scenario we are back to the "UML as documentation". Again, will developers bother to keep the UML "document" up-to-date? I know they should, but will they? Of course that would be a team problem, not UML's fault.
-
Permalink Reply by Vlad VARNICA on -
It is already possible to generate jee annotations from a model using a Jee profile.
This profile provides persistence annotations which are saved as stereotypes in the model and displayed graphically.
It seems to me that very few are really using Jee profiles because mixing PSM information with PIM at model level is not well accepted. Profile adoption has failed till today. I don't know why !!
-
Permalink Reply by Ulrich Brawand on -
Working with UML has two advantages:
1. UML is well known. You don't have to explain it (more or less).
2. There exists a lot of tools supporting UML as a modelling language.
For me it's not a question of "should UML use MDD ...". Right question is "Should MDD use UML as modelling language?"
Light MDD is not an option for me. If the UML model is on the same abstraction like the code (one class in diagram creates one class in code) then you will end in graphical programming. Then you will gain no advantage.
If you use UML with Profiles then you will reach a higher abstraction. This way you can specify elements of you own domain and you will receive a DSL. With a profile you specify one single information in the model which will be transformed into a bunch of classes, methods, relations and property files.
For me, UML will bring power to a project if you have an intelligent transformation framework that knows the metamodel of UML and the type system of the expression language is extended by every element of a profile.
Otherwise you will only have a tool for documentation with realy no advantage.
-
Permalink Reply by Scott Finnie on -
OK I'll bite :-)
What you describe is exactly the reason why there was a backlash against UML 5-7 years ago and, by extension, MDD.
Fundamentally it comes down to productivity. If the effort required to create and maintain the application increases through using the tool then its use has to be questioned.
What are the options? The first is as you suggest, what Martin Fowler calls "Model as Sketch". Use UML to convey ideas but don't treat it as anything other than a drawing. The logical next step here is to ask why you need a 'modelling' tool at all, when all you're doing is drawing pictures. A white board, dry marker (and maybe a digital camera) are better tools for that task. Of course, this isn't MDD. There's no discernible productivity over 'coding' because you /are/ 'coding'.
To get the benefits advertised for MDD needs an approach that improves productivity, not just for initial generation but for ongoing evolution and maintenance. My own experience is this really needs a modelling language that is complete for the domain at hand and can be translated completely and automatically into the required application. A half-hearted combination - such as using UML to generate structure, then filling in the blanks - seldom provides any useful productivity gain.
So in answer to your question: it depends. But if all you're going to do is generate class structures and maybe getters/setters, think long and hard about why you're using a 'modelling' tool - most IDEs will do that for you.
- Scott.
-
Permalink Reply by Vlad VARNICA on
-
UML can for example add information in the model which can not codded in Java code . I think that Java is a great language but also really poor has soon as you need to describe object relation with other objects and methods behaviors. This additional UML information could be crucial as soon as the project is getting bigger or developed by teams not based in the same office.
I have seen developers spending over 90% of time just trying to guess how and where to write a new method inside an existing software. Once the method has been added they are not even sure that it was at the right place and that the current object will react as it should during the execution of a task including many option (e.g. business rules).
We can still add Javadoc but this javadoc usually describe what is done but doesn't give a view of why and how.
Print traditional UML documentation is painful and only give an answer to "What" and not to "Why" and "How". I noticed that if project manager, modeler and developer have just spent few minutes to add a comment directly in the model (e.g metamodel documentation and contrainst) on each new method it would have saved 90% of the job of the developers trying to maintain the software which has not been developed by himself. It would have also improved quality because explaining how the object should behave would make it easier to add additional code.
This an example in which UML used for only documentation purposes is already a great value without even talking about further MDD uses. It seems to me that the first stage of providing a good documentation has failed till today because being stuck in high level of abstractions before even resolving basic daily needs of team works !!
-
Permalink Reply by Scott Finnie on
-
Trouble is, the model and code aren't kept in sync. As long as there's a "human in the loop" the documentation and the code will diverge sooner or later.
I agree there is value in a pictorial representation, in particular the ability to see structure (i.e. relations among objects) as you suggest.
My original point in this respect was simply that, since it's just a picture, you don't need a fancy tool to keep it in. And in fact, since the picture ceases to have use as soon as it diverges from the code, then it's often sufficient simply to draw it on a whiteboard.
But I come back to the crux of the matter: if you're getting increased (and sustained) productivity with what you're doing then by definition it's worth it. There are no absolutes.
-
Permalink Reply by Vlad VARNICA on
-
I agree Scott that model and code are not kept in synchro. This is for me a technical problem. I have written a short product article on this subject at : http://www.forum-omondo.com/documentation_eclipseuml_2008/waterfall...
When modeling you can decide to have either multiple models which are only a view of a piece of the software or a single model. Having multiple models is requires model transformation later which make synchro impossible. The only reliable solution is to map the full project with UML and allow a merge mechanism at intermediate stage. This is not live code and model synchronization because the model is updated a different stage and not by the developer who is codding.
This is why UML traceability is important from requirement, modeling, development, testing and deployment. We don't really need advanced ALM products !! just a good start at the first modeling stage using a single UML model and saving information directly in the metamodel in an XMI format and I think then that all the project cycle including iterations would be possible.
-
Permalink Reply by Pedro J. Molina on -
Hi Vlad.
I just posted a proof of concept about what it can effectively genererate from a minimalistic (UML?) class model.
So, my response to your question could be: based on a solid semantic in the model, you can generate as much as you can. This will prevent coding errors, for sure.
If you have a full UML model as the source, the richness of your model is highly enhanced at the cost of closing and defining the semantic of each primitive you employ. You know: adding the missing semantic to UML or using profilling techniques to constraint the model.
Regards,
About
Badge
© 2010 Created by Mark Dalgarno on Ning. Create a Ning Network!
