The value of UML (or lack thereof) in the development process

[What follows was adapted from a discussion on LinkedIn on why companies developing software don't use UML more]

UML proponents argue that by using UML one gains the ability to properly represent important knowledge on the problem domain and intended solution design. That leads to good things such as improved communication and better quality of the software.

I certainly don’t question that. The ability of devising a solution at the right level of abstraction is extremely important. Yet, that on its own is not enough. It doesn’t help if the language that allows you to specify a solution at the right level of abstraction does not lead to running code (via code generation or direct execution). If one has to specify a solution again by implementing by hand (say, in Java or C#) what the model describes (i.e. using the model as a reference), that greatly offsets any gains from modeling. As the agilists say: Don’t Repeat Yourself. I won’t bore you with the consequences of breaking that simple rule, it must be obvious to any developer worth their salt.

If you are going to be pragmatic, and you cannot generate running code from your models, from a developer’s point of view, there is no much value for UML in the development process.

Developers play an increasingly important role in software product development. Non-executable UML models are seen as fluff, an unnecessary burden to software developers, and hence the poor reputation with that crowd, as the majority of the places using UML is unfortunately using it that way.

I see two solutions for this: either get models to be executable, or get programming languages to support a higher level of abstraction. Even though I am a believer of the former (and our work at Abstratt follows that approach – see AlphaSimple and TextUML Toolkit), I won’t be surprised if the latter ends up being the winning approach (see RAD frameworks such as Grails and Rails).

Do you agree? Which approach do you prefer? Why?

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

5 thoughts on “The value of UML (or lack thereof) in the development process

  1. Andriy Levytskyy

    January 10, 2011 at 2:02am

    It is a common opinion among developers that non-executable models are unnecessary burden. However I would argue that non-executable models are valuable at least as communication means (other examples are analysis and evaluation of design choices, etc..). They help engineers build the right system (even if the DRY principle is broken). However, this value is not always visible to developers.

    Returning to your question, I am wondering the same. Also, what is the difference between executable models and programming languages that support a higher level of abstraction?

  2. AlphaSimple Team

    January 10, 2011 at 7:08am

    Thanks for your comment, Andriy. I think for models intended to understand the problem, non-executability is not an issue. It is only when models are intended to represent a solution that the issue exists and modeling seems to be wasteful/unnecessary.

    > what is the difference between executable models and
    > programming languages that support a higher level of abstraction?

    That is a great question. I often ask myself that question. I think the difference is that modeling languages are not strongly tied to a specific execution environment (models are either transformed into artifacts of a lower level implementation-oriented language) or run on a high-level execution environment that can be implemented on top of other more basic execution environments), and models don’t have direct access to implementation-oriented low-level functionality (like a general purpose programming language is typically expected to provide, such as threads, files).

    Does that make sense to you?

  3. Andriy Levytskyy

    January 12, 2011 at 3:08am

    @ AlphaSimple Team:
    Yes, it make sense. In my opinion, when making a choice between the two solutions: 1) executable models and 2) programming languages that support a higher level of abstraction, other matters should have been addressed. These are:
    - Can my solution implement high quality languages (quality is important for language usability and integrity of models)
    - Is my solution agile enough to deal with language evolution? Does it support model migration?

    Assuming that these matters are taken care of, then IMO the solution choice is a matter of cost, concept reuse and end-user’s preferences/familiarity with the solution.. For example, programmer will feel more at home with programming languages that support a higher level of abstraction. I can imagine problem domains that share concepts with programming languages. On the other hand non-programmer would probably be indifferent to the choice.

    I think that in general both solutions will co-exist and will have its own users.

Comments are closed.