[kplato] CVS Diff changes

Thomas Zander kplato@kde.org
Thu, 5 Jul 2001 09:07:55 +0200


On Wed, Jul 04, 2001 at 05:25:12PM -0700, Chris Clarke wrote:
> Thomas,
> 
> Your initial code looks good.  I've attached a few changes to the hierarchy, 
> as detailed below.
> 
> Changes:
> 
> * Added a virtual add/insertDependNode to KPTNode; any type of node can have 
> dependencies (task, milestone, even resource). 

ok

> * Put skeleton code in the above functions to ensure the node has no children 
> before allowing relationships to be inserted

ok.
 
> * Removed the empty add/insertDependNode from KPTMilestone; milestones can 
> have dependencies (to define what tasks must complete for the milestone to be 
> declared for instance)

But not children, right?  (meaning; there can be nothing dependent on a milestone)
Then the addDependParentNode() is a better choice.

Oops, I see I replaced the addDependNode with addDependChildNode and
addDependParentNode in KPTNode, but not in its decendants..
Could you, I'm leaving in an hour.
 
> * Added a virtual removeDependNode to KPTNode (for completeness)

same as above.

> * I've reversed the list and functions in KPTNode to assign resources which 
> have associated risks (it was originally the other way around).  From the 
> application side it makes more sense to assign a list of resources to the 
> task and then associate a risk with each resource.
> 
> * A KPTResource is actually a KPTNode, because it exists in the tree just 
> like any other node.  I've put in the public inheritance to show that.  (If 
> you want an analysis of this, look at 
> http://master.kde.org/pipermail/kplato/2001-June/000042.html and my follow up)

Well, you are right that it exists in the tree structure, but not right in saying
its in the same leagea as a  node.

- Resources exist outside of the project scope, they can be used over several 
projects.
- Resources don't have about halve the functionality stated in the kptnode, 
things like starttime/duration dependent nodes are all not for resources.

My goal was to add a resource-pool later which manages the resources (between
different projects etc), this can't be done in a nice way if resources are 
not a seperate object.

> * KPTRisk (and all the associated functions) get moved out of KPTResource and 
> up into KPTNode.  The theory behind this is when I'm planning, anything in 
> the near future will be broken down into subtasks, then resources, and 
> planned down to the last person.  Things farther in the future will not be 
> planned to the same detail -- I'll give the task an estimated duration and 
> risk, then when I get closer I'll break it down into resources.  Basically 
> the test is any node that does not have children can have a duration and a 
> risk assigned to it.

hmm, does that not break the things we discussed earlier, that only a resource
combined with a task can have a risk??

I don't fully understand your reasoning here, we are working or relations and
you talk about user behavior..

If you are right that a task can have a duration and risk, no problem, but this
is new to me.
 
> * Moved all KPTResource functions (which were KPTRisk originally :-) out of 
> KPTNode and into KPTTask; from what I can see it only makes sense to
> assign resources to tasks -- we wouldn't assign them to milestones or
> other resources.

Right, makes OO programming a tad harder, since we have to make sure to use
KPTTaks at the points we are using risks/resources. 
But ok.

> Thoughts:
> 
> * I wonder if the expected/optimistic/expected duration, and risk should be 
> moved into their own class -- one thing that I can see is in the situation I 
> listed in the KPTRisk changes, when I get around to doing a better breakdown 
> on the later tasks as soon as I create a subtask under it all the durations 
> and relationships should get bumped down to that subtask (because you aren't 
> allowed to have relationships or risks unless you are a leaf node).  
> Encapsulating the duration might make that a bit easier to do.

Sounds good, I think you should have a data-only class for that and leave
the calculations stuff in the node-and-friends. So asking a task will 
do something like:
 do we have a timing-object?
 yes: use it to calculate stuff, and return that.
 no: ask all our children to calculate theirs and add that, then return.


> Did you get all that? :-)

Thinks so ;))
 
> I've attached the diff file, it's probably easier to see the code changes 
> than understand my above explanations.  Feel free to tear my ideas apart.  
> This does compile on my machine.
> 

Ok, as I have about 30 mins left before I leave, I just commited this, 
please take care about the point of resouces, that is the only thing I 
think you made a thinking error.

Further; looks good and thanks ;)


ps. you can always use cvs update -D "yesterday" or simular to get back
to an earlier version.
(cvs update -D "1 May 2001", cvs update -A to get back to current version)

-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new