IT Modernization < V. Hanniet

software model driven approaches

Lazy modeling (2): laziness attitude

Say that lazy means not going till something’s end. Lazy modeling means doing models that don’t hold all the material they could carry. Say we talk about MDD(a) (What else? ;D), so we talk about a PIM(b) which describes business/functional/architectural requirements.

This PIM holds decisions about a solution to an initial business need that has be solved with (part of) an application:

  1. Some details about business objects(c) (ex: business objects properties)
  2. An arrangement of functional requirements in a way that is independent from a platform implementation… But not independent from the fact that these requirements have to be implemented in an application (ex: relations between business objects)
  3. Eventually explicit or implicit applicative architecture hints/directives

For sure, such information is highly valuable as directives to the material solution builders – I mean developers. Usually developers are human, but in MDD part of their job may be delegated to code generators (or something equivalent like a model interpreter).

Wait a minute. How do developers work when they don’t have a PIM in input? Here I talk about 90% (at least) of application development projects, even if we are mainly interested with the others 10%. They indeed have the same kind of input, roughly:

  1. High level specifications
  2. Low level specifications
  3. Programming rules (in best cases !)

However these specifications are given in a usually less formal, more opened, more inconsistent, but maybe easy for anyone to read, so in a more lazy way.

This is a first laziness footprint: we are all used to deal with laziness as the way we build applications is based on lazy fully adopted practices.

The main impact? Final decision is delegated to developers. And unless eventually using high level TDD(d), final implementation is always the result from a negotiation between stakeholders and developers… And all the Agile project team around them ;D !

For some other reasons, among them the impossibility to fully model the real world (ask physicians, or better: meteorologists!), we can’t have complete models of fully expressed needs:

  1. Business level – We have to deal with legacy systems: >90% business objects (here I mean by example virtual classes reversed on top of DB content) yet exist… And they are usually not 100% consistent (a pity they didn’t use models 30 years ago!). Furthermore, stakeholders often have partly concurrent goals or don’t tell all the truth at the beginning of the project
  2. Functional level – Functional designers have ideas, and models may captures these ideas in a very productive way. But nothing tell that these ideas are consistent and stable. In fact, untill seeing the final application running functional designers rarely put their head on the billot…
  3. Applicative architecture level – Yes! Applicative architecture may be fully defined. It easy, it’s just a matter of choices in discrete lists of possibilities. Advice to keep it at an easy level: put only one architect on this subject ;D

So what?
Don’t try to put all the stuff in models. Except if you want to work without any human developer, try to put sure things in models and let a part of the work to developers. They are used to it… And they do love that!

Be lazy: keep models simple. It’s always better than no model at all. And if developers can easily understand models and their requirements embedded semantic in regard with what they have to code… They even should forgive you to use some code generation ;D

(a) MDD = Model Driven Development, which stands here for any forward-MDE approach including MDA
(b) PIM = Platform Independent Model, which stands for any DSL, based on UML or not
(c) here business objects stand for business classes…
(d) TDD : Test Driven Development

Featured image taken from


One comment on “Lazy modeling (2): laziness attitude

  1. meinte37

    Another way of saying more or less the same thing: be Agile about your models, which also means that you’d have to be with your DSL/meta models.

    I tend to focus first and foremost on stuff that’ll give me the highest ROI in terms of productive gains. Often enough, that’s something on the business (objects) level since writing all the related artifacts (POJOs, O/R mappings, CRUD screens) is a simple but tedious and repetitive activity. On the functional level, it’s often some sort of screen or process flow. After having gone for the low-hanging fruits, it tends to be easier to decide what fruit you’ll leave hanging.

    This process is easier when dealing with a PSM and much harder when dealing with a PIM – even though the distinction is somewhat irrelevant in real life (imho) since many customers need to see something in PSM-form (i.e., a running application which has an architecture which has at least some influence on what the PIM would look like). You’re likely to end up much earlier on a functional level than on a business (objects) level here, which often means a more difficult (because more expressive) modeling language.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


This entry was posted on 07/07/2011 by in MDD / MDA, Modeling and tagged , , , , .

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 188 other followers

Creative Commons License
IT Modernization < V. Hanniet by Vincent Hanniet is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.