IT Modernization < V. Hanniet

software model driven approaches

Lazy modeling?!

Yesterday I met Rémy Fannader, author of Caminao: a simple but very powerful modelization approach compatible with MDE practices. During a part of the discussion about how wide was the modeling state of art (as wide as at least one track for each artist ;D), popped out a simple illustration question: “May an abstract class inherit from a concrete class?”.

Remy’s answer is: “No, because the property “instantiable” from the parent class may not be verified by the child class”. Let’s challenge this sensible answer…

  1. From a requirements expression standpoint (my interpretation of Rémy’s standpoint)
    An abstract class is not instantiable because it doesn’t match with a real life business object. Abstract classes may be used during analysis time to merge various uses cases, but if we admit use of  inheritance a specialized class always inherits from a concrete class.
    And in another way, multiple inheritance produces critical problems  as soon as we want to prove that the analysis model match appropriately with the business need. Mathematical proofs are given by Lyskov (IMHO Lyskov just explains how transitivity applies to inheritance).
    So an abstract class may not derive from a concrete class in a requirement model.
  2. From a requirements expression standpoint, alternative version…
    An abstract class is by definition a class that can’t be instantiated. So, the propriety “instantiable” has some value at instantiation time, but before this time it doesn’t mean anything worthwhile!? Let’s imagine that we define some value to the “abstract” property during modeling time ; by example saying that abstract means “does not represent any real life business object”. Such an abstract class still may be useful at modeling time to represent… Say a type of non abstract classes? I can’t see, at modeling time, why we couldn’t have a class hierarchy as X (concrete) > Y (abstract) > Y1, Y2 (concrete). Following Lyskov rules, Y1 & Y2 inherit from X’s properties. No problem.
    By the way, multiple inheritance neither cause any problem at modeling time. As far as we don’t apply instantiation.
  3. At PIM time with generation/constraints?
    No way. This is not a question. What does become an abstract class when trying to generate/transform it into a programming object is irrelevant. A PIM is independent from any specific platform, so as from any programming language.
  4. Why using an abstract class into a model if we can’t instantiate it?
    Because it has been found useful and valuable by the person who used it in the model!
    For sure the “interface” notion, in Java by example, is a good way to instantiate  this class. And furthermore, even without such a notion, an abstract class may be compiled. The resulting executable object just contains pointers that are to be resolved later. At link time (static or dynamic library) or even at execution time (through indirection parameters, code injection at runtime…). We could even imagine that the instantiation details decision are left to a programmer that will fill up the code generated from the model.

Conclusion:

If we consider the question from a modeling context where the concrete/abstract instantiation properties mean something, as far as modeling is concerned an abstract class may inherit from a concrete class in a PIM… Unless modeling validation rules forbid it. Answer may be yes!

If we talk of modeling a program targeting a specific programming language… The answer is given by the language compiler!!

Well, how all this is related with lazy modeling? Answer is: don’t model with compiling constraints. For compiling matters we’ll see later…

PS: I found this idea of “lazy modeling” while walking this morning toward my office, inspired by Paris’s nice streets. Surprisingly (not so in fact as it becomes harder and harder to invent something today ;)), I found one interesting paper on this idea of “late binding” for models:
http://www.ics.uci.edu/~tproenca/icse2010/flexitools/papers/12a.pdf

Featured image taken from http://www.sanaeishida.com/weblog/

5 comments on “Lazy modeling?!

  1. modelpractice
    27/05/2011

    Great!

    Sadly, there are so many people prefer playing with toys to understanding the actual problem, even among researchers.

    |=

  2. Pingback: Evolution of Modeling Tools along the Project Life Cycle | Model Practice

  3. modelpractice
    19/06/2011

    Have read through the paper. Wrote a little comment here: http://modelpractice.wordpress.com/2011/06/04/lazy_modeling_tool_life-cycle/

    It’s mainly saying: “Fully agree to analysis of situation. Based on this, an investigation, focused on how the underlying logical structures develop during project progress and how tools suite to their different kinds/ complexities, would have sound very intriguing to me.”

  4. caminao
    21/06/2011

    Hi Vincent,
    What is at stake is the consistency between business objects and their system counterparts. And that consistency is compromised if identification mechanisms are not isomorphic, which is the case when objects can be instanciated independently of their roots in models. That is the rationale behind Liskov Substitution Principle, and can also be illustrated by the Diamond configuration in programming.
    Rémy.

  5. vhanniet
    21/06/2011

    Hi Rémy,
    I agree to require consistency between business objects and their system counterpart but, speaking of system modeling, the idea is to find a way to manage:
    – inconsistency between business objects themselves or, in a less sharper manner, not yet fully defined business objects
    – late changes in business objects consistency
    – not yet fully defined system architecture rules

    As it came last time we met, the concept may be to use MLOB: Modeling Large OBject (in reference to BLOB in data bases!).

    Liskov Principle is itself a principle that could be delegated to programming implementation, cf. http://en.wikipedia.org/wiki/Diamond_problem. The question is to ask at modeling time if this does really matter.

    PS: it’s funny to that BLOB is also used for Blob Architecture, cf.: http://fr.wikipedia.org/wiki/Blob_architecture (fr)

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

Information

This entry was posted on 26/05/2011 by in 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.