On Mon, Aug 12, 2002 at 09:50:45AM -0400, Rocco Caputo wrote: > On Mon, Aug 12, 2002 at 12:45:53AM +0200, [EMAIL PROTECTED] wrote: > > On Sat, Aug 10, 2002 at 12:47:30AM -0400, Rocco Caputo wrote: > > > > > > 2. It is directly readable and parseable-- as text-- by humans. These > > > descriptions will exist in POD, and they will actually be part of > > > the documentation for a module. This will always ensure a minimum > > > standard of documentation is included with every working component. > > > > A textual presentation is easy to do and is similar to a class declaration. > > The advantage of the graph presentation can be created by an external viewer. > > I have used an OCL tool that did this and it was ok. It basically used > > the meanings of the graph's entities as keywords. > > > > I think that we should do it the same way. But we should try to specify > > the subset that we are going to use first. The prototype notation could > > be helpful, things like that. > > I have already registered Garrett Goebel's and will gladly consider > others. > > Please put together a prototype of your ideal notation using the echo > server as a basis for your examples. This way we can compare the same > program under different notations.
I do not think that this would be useful. The notation is not important. The semantic model behind it is. I'd like to see the semantic model of UML class diagrams being used. Because a notation is easier to do than a correct specification. And translating one notation to another is an fairly easy task for a human being when compared to translating semantic models. The latter is often not completely possible because different things are modelled. Which is true in our case as well, concepts like object associations do not exist in your draft. So comparing the notation does not give a usable result. As I said before, a good specification without ambiguities, omitted facts, .... is a lot of work. The posts with questions about the example show that as well. We can avoid this work if we use an existing model and specification. And users don't have to understand and translate yet another model. If I had given "my" notation I would have quoted the UML specification anyway. There must be a definition for the notation's elements. The elements themselves are often ambiguous, as "aggregates" etc. have showed. The notation should not rise a lot of discussion, because the class diagrams are a graph basically and there are not a lot of ways to express this. 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. torvald
