Pareto principle applied to MDD

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

The Pareto principle (also known as the 80-20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes.

This principle applies to many areas, e.g. “80% of your sales come from 20% of your clients” or “80% of your employee performance evaluation will come from just 20% of the items on your daily To-Do list”

What the rule tells us is that in anything a few (20 percent) are vital and many(80 percent) are trivial, and thus, to improve your productivity, you should focus on the 20% that makes a difference. Investing your time in the other 80% will only produce a slight improvement of your results.

I believe that this principle also applies to the area of model-driven development. I state the Pareto Principle for MDD as follows:

20% of the modeling effort suffices to generate 80% of the application code

This implies that, following a pragmatic MDD approach, we can boost our productivity and benefit from many of the advantages of modeling without the burden of defining complete and precise models. This is the assumption behind the services offered by the portal (btw, the XMI service will be released in the next days, stay tuned). I think that for many companies, this 80% of code-generation will be more than enough or, at least, a good starting point to experiment with MDD before deciding whether to adopt a full MDD-based development process.

Let me give you an example. To achieve a 100% code-generation of a software system we need to fully specify during the modeling phase the behaviour of all required system operations (e.g. using some kind of action language, as the one provided by the UML). However, it turns out that most of the operations (you guess it! around 80%) are simple CRUD (create/read/update/delete) operations, whose number, specification, parameters and behaviour could be automatically deduced from the static model elements in the class diagram! (e.g. if the class diagram contains a Customer class, it is not difficult to see that the system will need to offer operations to create new customers, to update each one of its attributes, … ). That is, with a 20% of the modeling effort (only the definition of the static aspects of the domain) we can automatically generate an staggering 80% of all operations required to query/manipulate the applications’ data (see a couple of case studies we did to validate this result as part of this paper )

For instance, given this model:

we could automatically generate this extended model:

where each operation specification AND body would be completely specified. For those interested in the details of the generation method used in this example, you can check the paper: Deriving Operation Contracts FROM UML Class Diagrams paper or in its extended version: Automatic Generation of Basic Behavior Schemas from UML Class Diagrams

AND remember! this IS just one example, I’m sure that the Pareto principle also applies to other aspects of modeling. Can you think of more scenarios?

Btw, with this post I say goodbye until next Monday/Tuesday. This evening I’m leaving FOR a four-DAY trip TO Cape Breton , following the trail OF my Cabot ancestor.

If you enjoyed this post you can subscribe TO this Software Modeling blog AND/OR follow me ON twitter OR through the portal’s mailing list . And if you really liked it help me pass it on to others by bookmarking and sharing the post using the links below:

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
  1. Anonymous
  2. jordi
  3. jordi
  4. Anonymous
  5. jordi
  6. Generating operation specifications from UML class diagrams:
  7. James Z
    • modelinglang


Your email address will not be published. Required fields are marked *