10

I came accross the accronym MDSE today on infoq, and the information I could find what quite unclear and the description was full of buzzwords :

MDSE is about enabling software engineers to work at a level of abstraction where requirements, architecture and design information is maximally ordered (in terms of information "entropy") and preserved. (Call this the "design work product"). Further, MDSE should provide engineers with the means to verify and validate their designs primarily terms of their "design work product"

And apparently, everyone is doing it: (from the article again)

We’re at the dawning of the age of MDSE. In the next 5 – 10 years we will see a significant shift towards MDSE, to the extent that I believe that by the end of this period perhaps 60 – 80% of software will be designed using model based techniques.

I would like to have a concrete, buzzword-free description of what MDSE is. Is it drawing UML boxes and generating code with it, like they did in the 90s with Rational Rose?

(while were at it, if anyone has an example of software generated using those techniques, I would really like to see a concrete example).

  • 2
    This sounds similar to Domain Driven Design. Basically, put business logic in your models. Related buzzword: Fat Model, Skinny Controller. – Greg Burghardt Jul 3 '15 at 1:38
  • I suspect a buzzword free description is unlikely as they seem to be integral to the concept's very essence. – whatsisname Sep 1 '15 at 5:40
1

"model driven software engineering (MDSE)" is the marketing promise of software tool manufacturers that "soon" significant parts of software can be generated out of software-models.

The interview partner in the article you are refering to , Robert Howe is a tool manufacturer (see http://www.verum.com/ for details)

But against tool manufacturer-s promises mdse has not become mainstream yet.

The hybris internet shop system is a working example of "MDSE": you as a software developper maintain xml-model-files ("*-items.xml") and codegenerators/interpreters generate db-modell/java-code for persistence/guis out of it. If you need an additional attribute just add it to the xml-model and after the generator/interpreter has done it-s job you can use the attribute to implement the business logic.

0

IMHO "model driven" is a big exaggeration, especially when used in conjunction with buzzwords like "design" or "software engineering" (instead of "development"). It was probably invented by some people having the misconception "software design" is done by drawing some mostly graphical models with UML, like an architect is drawing a blueprint for a house, and "coding" is just like laying the bricks for the house, following the blueprint. (I hope I do not have to explain here why this is wrong, if you have a different opinion, please read "Code as Design" by Jack Reeves first before downvoting me.)

This is a great mental model for those people calling themselves "architects", "business analysts", "designers", "software engineers", which have studied five years of computer science, but only half a year of real programming experience (at maximum), and now looking for a job in the software industry which includes "designing software" without coding. I guess this is the real reason why this "model driven" buzzwords are so popular.

Don't get me wrong, I am big fan of models and code generators for reducing the need to write boilerplate code manually. In some restricted areas like, for example, databases, (data) models can be indeed a good instrument for communicating with domain people. Sketching data flow between components by models is IMHO one of the most important techniques for bringing structure into a software system (unfortunately, the UML people forgot refused to include data flow diagrams in their notation; instead, they added a bunch of redundant, unnecessary stuff which nobody uses in practice).

But I would call this "model supported software development", not "model driven software engineering", which makes hopefully clear that modeling just supports the main activities in development, instead of beeing the main activity itself.

  • Hummm... Very reductive answer, based on a bad opinion concerning some IT professionals... – Rénald Oct 21 '15 at 7:01
  • @Rénald: well, there is nothing in my answer which is not based on personal experience. And I do not say that are no experienced architects, BAs or designers out there - but when they are really experienced, they probably do not believe in the false promises of MDSE. – Doc Brown Oct 21 '15 at 11:08
-1

This reminds me a lot of Fat models, skinny controllers concept.
The main idea of this concept is to put as much of the business logic as possible into the model and keep the controller and a view very simplistic.
Personally, I find this a very interesting idea, though I haven't had a chance to use it.
Surprisingly, 8 out of 10 top links in google search speak against it.
But, if you think of a model not as a single class, but a facade of multiple internal classes it makes perfect sense to keep the business logic in the model.

  • 1
    I don't think it means model as in MVC, but 'modelling' as in system-design. – gbjbaanb Oct 1 '15 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.