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. 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 behavior 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 a staggering 80% of all operations required to query/manipulate the applications’ data.
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?