> 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. 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? (rambling again...) This message posted from opensolaris.org
