On Tue, Aug 13, 2002 at 12:39:08PM -0500, Garrett Goebel wrote: > From: Rocco Caputo > > [EMAIL PROTECTED] wrote: > > > > > > So we should talk about the semantic model. Illustatring > > > this with notations might seem useful, but as we > > > experienced in this thread it really produces > > > misunderstandings. So we will have to give > > > specifications. Which leads us to the UML specification, > > > again. And this is what I suggest, reading the UML specs > > > and discussing if (and how) we have to adjust or > > > extend it to fit POE. > > > > > > As this might require too much time, reading tutorials > > > or introductions would be enough as well to be able to > > > know what is being talked about. > > > > > > The UML specs can be found on www.omg.org/uml (can't > > > give a direct url, get no connection atm). If other > > > people find good introductions/tutorials it might be > > > helpful to post the URLs here. > > > > I have spent the better part of the weekend and Monday > > researching the UML. I still don't know enough to discuss > > it, but I have been avoiding reading the specification > > directly. > > AFAIK, the Uml is still a modelling language and not yet a > programming language. So while the recently approved "Action > Semantics" (http://cgi.omg.org/docs/ad/01-03-01.pdf) gives a > specification for communicating state. It still doesn't give > us the textual notation we can use with Perl.
In the code vs. doc context it still belongs to code, I think. It models as well as code. It does not specify how to achieve this, but this doesn't matter. > I gather that Rocco Caputo would prefer a textual notation > that looks like Perl. Whereas torvald is recommending XMI. > > While XMI is adequate to the task, it isn't for humans. So > there's no way perl programmers are going to inline XMI in > their code. They might however consider something like HUTN. > HUTN stands for Human-Usable Textual Notation, and is based > on XMI. In fact it is round trip mappable between MOF (Meta- > Object Facility) and XMI... and more importantly you can > actually read it. No I don't prefer XMI if delevopers have to write it. As I said before, the notation is not the problem. > HUTN > slides: http://www.dstc.edu.au/Research/Projects/Pegamento/hutn/edoc2001.ppt > spec: http://cgi.omg.org/cgi-bin/doc?ad/02-03-02 > > Both the slides and the proposal (sections 2.6-2.8) show > examples of a MOF model represented in XMI and HUTN. > > However, HUTN seems oriented toward describing objects... > I suppose XMI is too for that matter. I haven't yet read > enough to figure out how someone would model states in HUTN. > Still, it's food for thought... and might help prevent the > tendency to reinvent wheels. Whose states do you want to model? What I've seen of the UML state diagrams is probably not really good for what a POE developer might need. Writing some sort of automaton instead of message passing code is hard with the usual state machine, as they're not powerful enough. To me Petri Nets seem to be much more useful, preferable in connection with Perl code. Generally I would say that we should start with class diagrams only. It should be the type which is most suitable for replacing code. I'll take a look at the HUTN stuff, but don't have much time right now. torvald
