Re: [Gnome-devtools] What we're doing.

[Andrew Sutton <asutton21 home com>]

Mark wrote:

> I would consider myself a hacker (as I do this for fun), but I
> definently see an advantage to design tools. I use them myself to a
> certain extent, like the UML templates in Dia. I'm not sure how well
> dialog-style interaction would go over with "hacker" types though, you
> would have to test that out. I think something that might interest you
> is that I'm working on the document parsing component of our development
> framework. Theorectically whith gpf it should be fairly easy to go from
> UML -> code and code -> UML, provided there is a proper mapping in the
> language. This would allow for a lot of self documentation (api docs,
> ect), and also allow for syncranization of the code and the
> documentation. So it should be very possible within our framework, to go
> back and forth between high level design tools and actual code, while
> self documenting. This would be very nice indeed, but right now I'm
> still working on the key framework component for this, gpf.
> 

eh... dialog interaction. ugh... that wouldn't fly well. unless my
understanding is way off, configuration management is the term given to
the configuration of the development environment. it fits nicely under
the "project management" subheading. i think the capabilities i was
describing earlier would be perfectly managed as a menu option. that way
there's less interaction with the the process since users - especially
people just concerned with writing code - probably won't need to see
that stuff. however, it should be there for larger more managed
(structured?) projects.

i'm not sure what the document parsing stuff is? i do like the code->UML
and UML->code idea. that's a very pricey option on the rational rose
stuff, especially the syncronization :) it's really sweet when it works.


Dave Camp wrote:

> > as pointed out, hackers aren't software engineers, and don't necissarily
> > see the process, just the code.
> 
> Well I strongly disagree with that.  But that's beside the point.

yeah... that was a little over generalized. i was considering myself
when i wrote that. before i started working, i never really saw the
benefit of a development process. most of the code i wrote went straight
from my head to code.

> Yes, this would be a nice capability.  I don't think our current
> design limits this in any way.  Again, we don't have infinite (or
> copious, or even sufficient :)) resources and can't focus on this
> aspect at first, but we are certainly keeping this sort of thing in
> mind and are working to keep the framework open to additions like
> this.

cool :) always nice to have a flexible design. here's a thought. leave
lots of room in the design for process based tools. basically define an
interface for handling particular aspects of the process (design,
requirements, whatever). tools for actually doing that can be added in
later. of course getting the tools to be aware of eachother and interact
intelligently. that could still allow a core project manager to focus on
process related aspects without actually implementing tools for certain
parts of the process. maybe...

Andrew Sutton
asutton21 home com