Re: Alloy paper



Date view Thread view Subject view Author view

robert france (france@CS.ColoState.EDU)
Sun, 30 Jul 2000 19:49:02 -0600 (MDT)


Hi Daniel, This is a quick response to say that I agree with your point about the lessons we can learn from starting from scratch and feeding those lessons into the development of the UML. In this light Alloy may provide insights that can lead to a better UML ... it is for this reason that I'm interested in your work on Alloy. More later on the rest of your email (I'm still trying to catch-up with duties that have become pressing during my vacation). Do you plan to attend OOPSLA'2000? There will be a pUML workshop there and I think a position paper on the contributions that Alloy can make will be useful. I'll post more on the workshop later this week. Cheers, 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/ On Sat, 29 Jul 2000, Daniel Jackson wrote: > 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