RE: Sets and bags || UML and PUML going astray



Date view Thread view Subject view Author view

Daniel Jackson (dnj@lcs.mit.edu)
Wed, 24 Jan 2001 21:39:17 -0500


perdita, ....D> both of these seem wrong to me, because they're both ....hopelessly bound up ....D> with the semantics of a particular programming language. ....D> if you don't ....D> have classes, attributes, messages, etc, none of this ....makes sense; .... ....Actually, if we had a modelling language that worked and ....was well defined ....for any language that had classes, objects, attributes and ....messages, I should say we were a long way forward. i disagree. one of the most valuable ideas in OMT, now apparently lost in UML, was that of an "analysis model" that abstracted away from implementation details. if your modelling language is built around programming language notions, you'll never be able to use it in the stages where it's most valuable -- long before you're worrying about code. ....D> this characterization of the static view is completely ....syntactic; .... ....Yes, indeed. .... ....D> to me, this suggests it won't be of much use (since it's ....relationship to ....D> the program text is trivial). .... ....Sorry? It has to be difficult to be useful? no, of course not. but every time you invent a new modelling language and advocate another kind of description that developers should produce, you need to make a case for what it adds. in particular, there's not much point inventing a language to say things that are already said perfectly well in code. and there's the argument for redundancy: it's useful to check the code against the design for conformance, but that's unlikely to give much benefit if the design is just a skeleton of the code. interpreting the object model as a heap invariant seems to me _much_ more useful than interpreting as a syntactic outline of what classes there will be and what fields they'll have. for one thing, you can express important but subtle properties that may turn out to be quite tricky to implement, but which are easy to express as invariants. ....D> a better approach, i think, is to give a semantics to ....the notation that ....D> maps it to a domain of mathematical objects that is ....precise and simple. .... ....err, no argument there, if we can produce such a semantics ....that is useful, ....i.e. that doesn't prevent people doing useful things with ....the notation. right, and i'd argue that it is precisely this mathematical intermediate step that allows you to apply the notation broadly. ....D> then, in a second step, we interpret the artifacts of interest by ....D> mapping to this domain. .... ....Hmm. I can suggest a great simple precise mathematical ....domain such that we ....can map the notation and the artefacts to it. The one point ....set. There are ....some missing conditions on what it would take to be useful here! of course: the domain has to be rich enough. ....I'm not denying you can do some useful things with your ....simple relational ....model; I know that you have. But I think you're being naive ....about UML: and ....I am really sick, this week especially, of the fallacy that ....if you can map ....into something you have ipso facto achieved something ....useful. I'm sure ....that's not what you meant, but that's how it sounded. i didn't mean that. for me, achieving something useful in a modelling language means -- having compelling examples that show that you can capture aspects of a real problem more effectively or with a simpler language than before; -- and/or being able to do something constructive with the description beyond reading it, such as automatic analysis that exposes errors, simulation, or synthesis of code. it's lack of evidence in any of these categories that makes me skeptical of UML. /daniel


Date view Thread view Subject view Author view