<html>
<body>
At 21:14 17.01.2006, tim wrote:<br>
<blockquote type=cite class=cite cite="">I agree entirely that good
training material, tutorials and so on are <br>
vauluable documentation. So is pre-implementation doc explaining
what <br>
the original intent was; I find it rather useful as a way to know
<br>
when I'm finished and can bill the customer for one thing.<br><br>
However, the original post was about *references for the
classes*. <br>
That's a very different thing in a dynamic environment. I stand by
my <br>
assertion that such doc should be a part of the system, included in
<br>
the class and method sources. ...</blockquote><br>
I agree wholeheartedly that the doc should be part of the system.
Preferably, the program should be self-documenting.<br><br>
Brains clearly differ. To me, the class browser is OK when I stuudy toy
systems, but it is inadequate when I try to understand significant,
complex systems. My brain just cannot bridge the chasm between class and
method source code on the one hand and the objects and their interactions
at run time. I believe I need code that is higher level than the class
& method.<br><br>
I have just completed my initial submission for an invited "expert
voice" article for the Springer Journal on Software System
Modelling:<br>
<div align="center">The BabyUML Discipline of Programming <br>
where A Program = Data + Communication + Algorithms<br>
<a href="http://heim.ifi.uio.no/~trygver/2006/SoSyM/trygveDiscipline.pdf" eudora="autourl">
http://heim.ifi.uio.no/~trygver/2006/SoSyM/trygveDiscipline.pdf</a><br>
<br>
</div>
BabyUML is a multi-paradigm approach where I <br>
1) separate the object space recursively into components; each
component is an object that encapsulates its member objects.
(Tweak!?)<br>
2) delare a conceptual schema for the member objects as a UML class
diagram<br>
3) code the member object interaction with a sequence diagram for
each provided operation.<br>
4) link the roles of the interactions to member objects with
queries on the conceptual schema.<br>
5) code the internal behavior of the member objects with classes
& methods in the usual way.<br><br>
Complicated? Possibly. But I only intend to apply it when I must have it
to master complex systems.<br><br>
I have been in "writing mode" for quite some time now. I hope
to return to "coding mode" quite soon. The goal is to make
something that other people can play with.<br><br>
All the best<br>
--Trygve<br><br>
<x-sigsep><p></x-sigsep>
-- <br><br>
Trygve Reenskaug mailto:
trygver@ifi.uio.no<br>
Morgedalsvn. 5A
<a href="http://heim.ifi.uio.no/~trygver" eudora="autourl">
http://heim.ifi.uio.no/~trygver<br>
</a>N-0378
Oslo Tel:
(+47) 22 49 57 27<br>
Norway<br>
</body>
<br>
</html>