Re: Alloy paper



Date view Thread view Subject view Author view

Daniel Jackson (dnj@lcs.mit.edu)
Sat, 29 Jul 2000 21:58:25 -0400


Robert, >From our point of view, I think the interesting questions are independent of whether we should fix UML or start again. Perhaps UML is here to stay, and we'd do best to fix it rather than contribute to the proliferation of languages that UML was designed to curb. But I do think that it's important to ask ourselves the question of what we'd come up with if we started again, and that's really what my Alloy paper is about (albeit for a small part of UML). So rather than argue about what our tactics should be, we should try and figure what in UML is essential and what is peripheral, what is good and what is bad. Then if we decide to focus on fixing UML, we can at least work on the parts that are worth fixing. In my Alloy work, for example, I have taken the navigation idea from Syntropy/OCL, which seems to me to be a very nice idea, but I've given it a simpler and more uniform semantics. Here's a more controversial comment. I'm not sure that the "informal nature" of UML is ever an advantage. There are some things that will never be formalizable, and for sure they do not benefit from being put in a formal Procrustean bed. And there are some things that we don't understand well enough to formalize; I still have no clear story for my undergraduate software engineering students about what a module dependency means, for example. But what disturbs me about UML is that much of its informality is just sloppiness. Take aggregation, for example. It's not as if the issue is new. Clever people have been thinking about what it might mean for decades (eg, in semantic data modelling long before object oriented methods were popular). And more recently, there are a host of methods and books that seem to have at least addressed such issues and come to some resolution: Syntropy, Fusion, Catalysis, Fowler's patterns book, etc. So it seems a great pity to me that after all this progress, UML should come and describe such notions as if nobody had ever thought about them before. --Daniel ----- Original Message ----- From: "robert france" <france@CS.ColoState.EDU> To: "Daniel Jackson" <dnj@lcs.mit.edu> Cc: <puml-list@cs.york.ac.uk> Sent: Friday, July 28, 2000 10:14 PM Subject: Re: Alloy paper > Hi Daniel, > Sounds interesting! I'll definitely read it. The pUML > approach has its critics in the informal and formal camps. > Speaking in very loose terms: > On the one hand there are those that feel that the > problems with the UML and OCL are too severe and that > a much cleaner, precise (and smaller) language can be built > from scratch (using best experiences from the FM community); > on the other hand there are those that view the informal nature of the UML > as a plus. > > As an academician I can appreciate the first view; > as an academician that has worked with industry - > some would say I'm now contaminated :) - I have some > sympathy for the second view. A solution that is > acceptable to industry may lie somewhere in between. > This is what we are trying to do within the pUML > group. In the end a new language like > Alloy may turn out to be a more > superior language; but history reminds us that this > is not enough to gain acceptance in industry. > > As an interesting option, have you considered defining > a UML profile for Alloy (i.e., using a UML-like syntax > for Alloy language elements) ... > > Robert > > ==================================================================== > Robert B. France, Assoc Professor | Tel: 970-491-6356 > Computer Science Department | Fax: 970-491-2466 > Colorado State University | Email: france@cs.colostate.edu > Fort Collins, CO 80523 | www.cs.colostate.edu/~france/ >


Date view Thread view Subject view Author view