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 13:42:33 -0500


i am struck by some comments in perdita's email that seem to be symptomatic of why UML's gone astray. forgive my directness here, but i think these issues are important, and i'm worried that the PUML group is exacerbating the problem rather than solving it. first, this business about "static" vs "dynamic": ....I think _one_ of the root causes of UML's ambiguity is that ....there is a confusion between static and dynamic associations. What do ....we want to *use* associations for? .... ....Static: I want associations to tell me something about the structure ....of the associated classes. If you want the presence of an ....association between two classes to model the existence in one class of an ....attribute whose type is the other class, then you tend to view ....associations as almost-classifiers. .... ....Dynamic: I want associations to tell me something about the ....dynamics of my system. An association between A and B means simply that an ....object of one of the classes may send a message to an object of the ....other, then it is more natural to view the (identity-free) links as primitive with the ....association seen as a relation. both of these seem wrong to me, because they're both hopelessly bound up with the semantics of a particular programming language. if you don't have classes, attributes, messages, etc, none of this makes sense; and if you want to make it precise, you'll need to elaborate what you mean by these terms, and thus bind the modelling language to a particular programming language. do we really want to think of UML as a graphical notation for C++? this characterization of the static view is completely syntactic; to me, this suggests it won't be of much use (since it's relationship to the program text is trivial). the dynamic view doesn't appeal to me either; i can't see what use cardinalities will be in such a context. a better approach, i think, is to give a semantics to the notation that maps it to a domain of mathematical objects that is precise and simple. then, in a second step, we interpret the artifacts of interest by mapping to this domain. for object models, i take as the domain labelled graphs or relations. each object model denotes a set (usually infinite) of such graphs. for an object model of a program, we can interpret the heap as such a graph; the object model is then a heap invariant. for an object model of a problem domain, we can interpret the real world and its entities and their relations as such a graph. the advantages of this approach are: -- decoupling programming languages from modelling languages -- getting a simpler semantics and making tool support possible -- allowing a smooth transition from problem to solution object models it also makes it possible to use object models in more abstract settings. we've used Alloy, our modelling language, to analyze naming schemes, security domains, and network topologies, for example. doing this with a language that has a "rich" notion of objects and associations would be awkward at best. second, a response to a more general comment: ....*However*, I do think we need to work in the context of ....UML, or at least in ....the context of modelling languages, because that's where ....the problem is. no it isn't! the problem is in the context of developing software. it may well be the case that UML has become more of a problem than a solution, but we should think carefully about whether it's a problem that's important enough to work on. i wish instead we could focus our PUML discussions on case studies and real practical problems and be less distracted by the self-inflicted complexities of UML. /daniel


Date view Thread view Subject view Author view