Richard L. Hamilton wrote: >> Hey everyone >> >> Last semester I wrote a few UML activity diagrams >> (basically flow >> diagrams) for some parts of the kernel I've been >> studying. It was a >> project for a SW engineering class. I've been >> thinking about sharing >> them with you and getting your thoughts on it. >> >> I wrote them to help me browse the code. When reading >> the source, >> sometimes I had to follow 10-20 different calls in >> 10-20 diff files. >> It's easy to get lost. >> >> I think these diagrams can be very helpful in a >> number of situations, >> both for people starting to read the code and whoever >> wrote it. The idea >> is to provide an intermediate level of information >> about the >> implementation between Solaris Internals and the >> source. >> >> I've posted what I've done so far here >> http://blogs.sun.com/rv/resource/browser/browser.html >> >> I'd like to know what you think of it, whether it's a >> good idea or not. >> >> There are clearly some problems with it, keeping it >> updated and possible >> inconsistencies to name a couple. >> >> Please let me know what you think. Comments and >> suggestions are much >> appreciated. >> >> thanks >> > > I wonder if those could be more or less automatically generated, > whether from cflow output, or by duplicating much of what it does. > (absent source availability for the Studio version, one could always > look at the GNU version) If that was possible, they could be generated > on the fly (or cached, to be updated only if the timestamp of one of the > source files changed), so they'd always be current (and as complete as you > wanted to set up the site for). Producing decent graphical layouts > automatically might be tricky, but there must be some open software that > deals with similar layout problems, to use as an example or starting point.
I think the problem right now is more conceptual than of implementation. By that I mean what kind of diagrams would be helpful. The existing ones aim at giving both mid and low level information. Is that the way to go? I personally think so, but I have heard otherwise and I'd like to hear more opinions on that. > Ultimately, a really swift graphical source browser could drill down to > the code itself. But maybe it should exist in two versions: server-side, > for distributed read-only use, and as client-side bits in Java that worked > as part of an IDE to provide the graphical browsing, maintenance of > a local workspace from a repository via (for example) subversion, editing, > testing, and return of updates (not necessarily to the repository; perhaps > to some other place for further testing or approval). > > In other words, in the long run, why not have an environment that ties > it all together? Those are good ideas, but the whole environment might not apply to complex projects such as the kernel. If you could chose just a couple of functionalities instead of the whole package - diagramming in this case - would be good. -- Rafael Vanoni rafael.vanoni at sun.com http://blogs.sun.com/rv
