Raise your level of abstraction
I've a read number of posts regarding DB schemas being driven by UML models. I am wondering how useful UML is in generating non-structural parts of the application. What about activity diagrams and sequence diagrams? Does anyone have experience in generating more than just the class shell from UML? I have found this question intiguing enough to set up a 6 questions survey. I would appreciate it if anyone wanted spare 2 minutes to complete it. I look forward to feeding results back to the forum if there are any.
Activity diagrams are too coarse grained IMO. But if you are dealing with a coarse grained DSL, it might work. Sequence diagrams are intended to model specific scenarios from an interaction PoV, not to model general behavior.
Support for action semantics in UML allows you to model behavior. With behavior in your model, you can generate 100% of the code.
For instance, in AlphaSimple, you can generate something like a JPA entity with queries and behavior from a model like this (or this, if you prefer a class diagram). This is work in progress, but if you would like to be an alpha/beta tester, let me know.
I'll post our numbers to the survey on monday. What classes and lines are you counting? domain model, technical model, generated code?
We split behaviour into:
- little things like validations, without any significient flow; these need not be modelled themselves (it makes no sense to "model" a regexp), but they need to be "sticked" to the model (see also golden-egg-discussion here )
- business transactions (higher lever workflow likes and lower level mini-transactions for the UI); they are all treated the same (see Transaction example ); they can be modelled as a state machine, either drawn or textually, but they need not; the only requirement is a transaction interface which exposes a state attribute; this fits very well to the POC/UI approach, which tries to capture user requirements in form of nested (mini)processes
- complicated calculations & dirty tricks which almost always will best be expressed in the implementation language, but aren't the majority of behaviour
As for UML; literally: not really, except for special cases; interpreted as "UML class diagrams plus a little more UML plus UML compatible extensions plus possibly DSL layers on top of that", then: yes, you can.
I was wondering why, if you could generate 100% of your code from models, this isn't yet the industry standard. I guess may have a valid point (Pareto principle). It may not be efficient enough to go for full generation. Andreas and Rafael you both mentioned DSL. Do you think that defining your own DSL and transofmation rules (instead of using UML profiles) could improove this efficiency? Or would it again be pointless because it would take too long to come up with the DSL?
AlphaSimple looks really good. Your GUI was generated from the model or did I get it wrong?
Andreas classes in technical model please.
Thanks for filling in the survey
I think I may disagree from Jordi - I think you either generate 100% of an artifact or it isn't worth it, and that it is worth to enrich your model as much as necessary in order to achieve that (while still avoiding implementation concerns in the model).
Re: DSL - I don't think DSLs are a requirement for code generation - I do see value in general purpose languages like UML (AlphaSimple uses UML).
Re: AlphaSimple - yes, the prototype UI and behavior automatically derived from the model.
We may not disagree so much :-)
My point is that you should generate 100% of the "artefacts" (to use a neutral word) of your application that you target to code-generate from models. What I´m not so sure is that you should try to generate all the artefacts of your application.
Don´t get me wrong, as a modeler believer I´d probably aim for the 100% generation approach in most scenarios but from a pragmatic point of view I think the 80/20 may work best specially when introducing modeling in a new development team.
Our experience with a now 4 year running project (a continuously evolving system) is that there are different phases. The first phase lasted about 4-6 month, where the initial application is build and the major goal is to cover all aspects reasonably. In this phase the CRUD operations are the majority.After this phase, for another few months, wizards-like transactions are introduced, the core operations still CRUD, but enriched with user guidance and sequence control, help texts etc. Then, after the customers got more and more used to the application, convenience, ergonomics and efficiency become major topic. Interesting questions like "can we, after a first wizard like data entry, access the same data in arbitrary sequence from different tabs and by choosen that radio box over there another three tabs open with...". In the currently ongoing phase, CRUD plays next to no role anymore.
Another project, started about a year ago, follows a rather similar path: CRUD in the early phase being a reasonable starter, but becoming less important as the systems grows and is being used. This second project is nevertheless still fully MD (FMD), which means the 80/20 rule cannot be applied anymore.
I did fill out the survey and sent you an email with explanation of the numbers.
As for DSL/efficiency:
The reason is obviously the huge complexity that's inside the "UI issue". A DSL on top of UML solves a part of the problem, but I doubt this alone will suffice (it suffices of course to simplify the model, but it does not sufficiently simplify the transformation, not at all). You need more. DSL ist not the wrong direction, but only one means of many. Our approach comprises these additional ones: a UI runtime component, which is able to render UIs based on rather abstract information attached to the object model, an extended object model (business interaction layer) containing transactions, plus additional means to reduce the complexity within the transformation itself. See earlier post here for details.
So, yes, it takes long to come up wih a solution (including DSL; it took us already 15 years, still not solved 100%), but it's not impossible to tackle those 20%.
Andreas ! You mentioned in the reply that
"complexity management in the context of MD-transformations is a huge issue"
I need some advice from you about how to handle that complexity. We have enough knowledge about the DSLs but, but the MDD discussions ignore the
Code Generator part of the Language Workbench. I am really seeking references from you that help me in structuring or architecturing the Code Generator. How to architect the Code Generation that support application evolution.