[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?
Andriy Levytskyy
January 10, 2011 at 2:02amIt 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?
Jordi Cabot
January 10, 2011 at 2:33am> what is the difference between executable models and programming languages that support a higher level of abstraction?
Good point, in fact, languages like Umple (http://modeling-languages.com/blog/content/umple-language-model-oriented-programming) are a perfect example of this mixture.
AlphaSimple Team
January 10, 2011 at 7:08amThanks 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?
AlphaSimple Team
January 10, 2011 at 7:43amHi Jordi, you are right, Umple is a good example of an initiative that brings modeling concepts to programming languages. Other examples that allow describing associations (albeit with the purpose to support ORM) are JPA annotations and Grails GORM: http://grails.org/doc/latest/guide/5.%20Object%20Relational%20Mapping%20%28GORM%29.html
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.