Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
How a Modeling Language Should Look Like and where UML Stands with Regard to this?
Posted by Sadek Drobi on Nov 09, 2008
Based on the book Domain Specific Modeling by Steven Kelly and Juha-Pekka Tolvanen, Lispy, the author of Learning Lisp blog, exposed some thoughts on how a modeling language should look like:
1) It should map to the domain problem concepts and not implementation details.
2) It has to be formalized and helpful not only for communicating with domain experts but also for development tasks by making it possible to generate from the models executable code, documentation and certain classes of tests, as well as by eliminating the need for implementing some other tests and by raising the level of abstraction for code maintainers.
3) It needs to have stand alone tooling support that would allow domain experts to “organize their frameworks and libraries in such a way that the models can be “compiled” into fully functioning code”, and this without them having to think in terms of code. To illustrate this idea, Lispy uses the analogy of compiling C to machine code, where C is in some way "a modeling language for machine code" and where C programmers don't have to modify the machine code compiled using compilers created by machine language experts.
So, to get a modeling language that is actually useful, you have to go “Domain Specific” on both sides of the problem: the modeling language has to map directly to the problem domain and the generated code has to map directly to the target environment. […]If the code generation process is too complicated, you may need better abstractions at the framework level. If the code generation process is impossible, then the modeling language may not be providing a detailed enough description of the requirements. If there is too much repetition in the models, then the modeling language will need to be extended to cover additional concepts.
Where does UML stand with regard to all these observations? According to the author, it is not an appropriate tool for model-driven development. It can’t be compiled, executed, or interpreted, thus being “reduced to the level of mere documentation” and adding “no more value to a project than an elaborate code comment”. According to Lispy, UML applies abstraction “at the wrong end of the problem” because it “is designed to map to coding architectures– and because of this it fails to raise the level of abstraction”
Seven Kelly has recently expressed similar opinion:
I'd always thought of UML as being more specific about implementation choices […] -- e.g. the restriction to an object-oriented language, and the individual classes, fields and methods of an implementation specified directly in the models. […]The only part of UML that is on a high level of abstraction is the Use Case diagram, and that's only at the total loss of precision.
However, reacting to his post, Franco Civello argued that it is still possible to use UML successfully in model driven development in order “to express precise models at a high level of abstraction”, provided that one only uses “those parts of the UML amenable to a precise interpretation”:
I will justify my position by giving one example of how UML can be used to write precise models with no implementation detail.
[…] having produced informal use cases to clarify requirements, and a domain model to get an initial understanding of the subject area, the analyst produces a precise specification model, in UML, in which the system to be developed is represented as an object, belonging to a type (note, not a class, as the system is an abstraction used to define visible behaviour, not a software entity to be directly implemented in e.g. Java).
Steps in the use case flows are then formalised as operations on the system type, with a declarative specification of behaviour based on the notion of functional contract, written as pre- and post-conditions expressed on an underlying model (the system type model, derived closely from the domain model).
Lispy judges this approach interesting and he argues that it is not necessarily in contradiction with what Kelly and Tolvanen suggest in their book. UML is used to map the domain problem rather than to describe the code architecture, there is a certain level of formalization and, as highlighted by Franco Civello, “an executable subset of UML, xUML, is also available and supported by some tools”.
More on "What a Modeling Language Should Look Like."
by
Paul Stoaks
Posted
Isn't this what MDA set out to do
by
Bob Groeneveld
Posted
-
I agree wholeheartedly with most this post. The points are very good. One of the things that I am struggling with, in general, is "What is Modeling" or "What is Model Driven Design"? It seems to me that we have to agree on that, then it becomes easier to talk about the requirements on a modeling language. The bias of the discussion here is, as is often the case, really on high level design or, to put it more bluntly, "a higher level of abstraction for implementation." I think this is a mistake.
If one looks at "modeling" as part of the design process in other domains (architecture, aerodynamics, mechanical engineering, etc.) one sees the following:- The model is used, interactively with stake-holders, to refine requirements. As such, the model can be made to "behave" like the system being developed sufficiently to be useful for discussion and the model communicates clearly and naturally in a way that ALL stakeholders can understand.
- The model is used, interactively, to explore the design space. Architectures, algorithms, and technologies can be "tried" in the context of the model to determine which meets the requirements "best." As such, the model must be "analyzable" in a variety of ways, one of which is clearly "execution." This activity often crosses "domains" (e.g. hardware & software.)
I think that these two "purposes" of a model yield most of the requirements mentioned in the post, with one notable exception. That exception is implementation generation. While none of us can argue about "how nice this would be", I would argue that it's not a "must have" requirement. Indeed, it is my opinion that requiring a modeling language to stretch from requirements analysis to implementation generation is a "bad idea" that leads to overly complex modeling languages. Intead, the goal of the "modeling language" should be to span the gap from requirements analysis to detailed design where detailed design languages (like UML) can take over.
For more on this topic, may I respectfully suggest the following:
www.foresightsystems-mands.com/blog/systems-eng... - The model is used, interactively with stake-holders, to refine requirements. As such, the model can be made to "behave" like the system being developed sufficiently to be useful for discussion and the model communicates clearly and naturally in a way that ALL stakeholders can understand.
-
The goals set out in this article and the book Domain Specific Modeling (which I haven't read yet) are I think along the lines of what MDA set out to achieve. I am not an advocate of MDA but I think that the idea of MDA; to have several levels of models (PIM/PSM, with their specific intents), is to bridge the gap between Business Domain Specific and Development Domain Specific needs.
I would argue that in a lot of material about DSL's this difference is not addressed. A lot of DSL's I see around are actually Development Domain Specific Languages and therefore not very helpfull to bridge the gap between business and development needs.
To fully cover the needs of all stakeholders (as mentioned in point 2) ) one needs an elaborate implementation of the Languag Workbench idea that Fowler wrote about. There are several ways to approach this I think. At the moment I have not seen anything working that remotely covers the goals mentioned here (I have not seen the Intentional Workbench yet so there is hope ;-) ). I think however it is not really constructive/helpfull to polarise the differences in efforts being made at this time. And I think DSL's should be compared to MDA (if one wants to compare them to OMG held standards) and not UML.
2 comments
Watch Thread Reply