The Model Driven Software Network

Raise your level of abstraction

Can you really use UML to generate majority of your source code?

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.

Views: 733

Reply to This

Replies to This Discussion

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.

You can generate 100%code from your models (for that you´ll need to use an Action Language, e.g.

However, I don´t think this is the important question. The important question if it is worth or not to do it. Defining a UML model complete enough to generate your full application will take time.

To me, the right way to go is to follow my Pareto principle for MDD ( "focus on the 20% of the modeling effort that suffices to generate 80% of the application code"

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

Hi Michal,


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.

I suspected that may have been what you meant. Agree that generating 100% of an application is not pragmatic, likely not viable, and not necessarily useful/better.

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:


In a project around 2001 we were working with an early version of a FMD system. E.g., for UI creation we had a 25000 loc template with 4 intermangled languagse (code generator, perl, html, javascript) which caused enormous pain. The pareto principle had really a valid point here.


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 I see that your organization is very commited to Model Driven approach. This is very encouraging. Why do you think not all software developers are so enthisiastic about it? Can you see any types of projects that wouldn't benefit from full code generation. Would it be size or implementation platform that would determine it? Does anyone else have any thoughts?
> ...not all software developers are so enthusiastic about it?

I see several reasons:

- first, many software developers are actually enthusiastic, but are not allowed to use it in a project; or they think it's cool but sense difficulties and so, as most often, prefer to avoid the one to be blamed

- due to the lack of standardization (developing a DSL in a project is a project in a project) there is the problem of "ad-hoc semantics", as a colleague expressed it once; there's one DSL guru who daily defines the meaning of the DSL anew, it's typically a bit trial and error for a rather long period, so the resulting language is not always the best one

- complexity management in the context of MD-transformations is a huge issue

- psychological reasons: as Rui wrote in the other discussion, as developers we primarily love only our own tools - DSLs and MDx-Models in general are languages, and for languages this is particularly true; furthermore developers prefer to work on the more interesting stuff and think that painting models is "boring application customization"

- exaggerated, misinterpreted agilitiy: some people translate "Big Design UpFront" to "Models Are Evil"; there are specific traps in agile methodology: it might be tempting to misuse agile's tight contact to the customer as a convenient business model, i.e. to talk and talk with him and draw him into each and every detailed problem, so one can sell manmonth after manmonth; this business model can be practised by companies as well as inhouse by IT teams

> ...types of projects that wouldn't benefit from full code generation..

In the long run, I think "Programming in Models" (of whatever type) will become mainstream as it is today with java/.net; still there will always be market segments/niches where the other languages survive, even exotic ones.

At present, FMD solutions are not universal solutions yet, so they have to be crafted for use in the most profitable areas; so of course platform, legacy db, ui, apps, skills etc. do matter. Target platform size is not so important as such, I'd say, e.g. an android oriented FMD might be worth implementing, it more depends on market size.

We have to watch that; I guess creating a word processor or spreadsheet in a model driven way could be undoable - on the other hand side look at Marko's posting about gentlewares new tool for creating a graphical editor.

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.




© 2019   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service