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



Date view Thread view Subject view Author view

Dov Dori (dori@MIT.EDU)
Wed, 24 Jan 2001 21:42:52 -0500


Hi Daniel, I share much of the views you express here, and see lots of problems in UML that I believe I solved with Object-Process Methodology. You can download a few papers from www.sightcode.com Best regards Dov Daniel Jackson wrote: > > 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 > > To remove yourself from this list please mail puml-list-request@cs.york.ac.uk > with a message containing the word "unsubscribe". -- Dov Dori, Ph. D., Founder and CEO Sight Code, Inc. 27A Mica Lane Wellesley, MA 02481 ddori@sightcode.com www.sightcode.com Tel. 781-431-0433, Mobile 781-858-2867, Fax 781-416-1841 Visiting Assoc. Professor Engineering Systems Division School of Engineering Massachusetts Institute of Technology 77 Massachusetts Avenue, Building 37-447 Cambridge, MA 02139, USA dori@mit.edu Tel. 617-964-7930, Fax 617-253-8632 On sabbatical from Technion, Israel Institute of Technology http://ie.technion.ac.il/dori.phtml


Date view Thread view Subject view Author view