Re: pert/cpm calculation (was Re: kplato)
John Lamb <[email protected]>
| Newsgroups | gmane.comp.kde.kplato |
|---|---|
| Message-ID | <[email protected]> |
Dag Andersen wrote: > Ok, based on what we have discussed I've fleshed out some thoughts. > > If we separate pert/cpm calculation code from the nodes but allow the > code to call the nodes methods, I think the following should be > possible. If you want to insulate the code more, we need some sort of > interface class. It will depend as much (more?) on your code as on > 'kplato' code, I think. What do you think? It's probably too difficult to do the separation. Instead, I'll try some other way of isolating/testing stuff. > (Note that pert_ is prepended for all methods that is only used by > pert/cpm calculation) That's a really good idea, especially as it will work even within the KPTNode classes. What's important to me is to know what the algorithm may modify. > I plan to allow resource overbooking here (for now?). Then the user > can resolve conflicts manually. That makes sense. Later, we can add code to help assign resources in complex cases. > > I'm not sure where to eventually put more advanced resource analysis. > > To get at the constraints of a node: > node->constraint(); > If the constraint is ASAP or ALAP; no matter. > If it's StartNotEarlier, FinishNotLater, MustStartOn or MustFinishOn > you need the time: > node->constraintTime(); > > To set earliestStart/latestFinish: > node->setEarliestStart(time); > node->setLatestFinish(time); Is this value set by the user or calculated by pert/cpm? > To get a nodes list of child relations: > node->dependChildNodes(); > > To get the relation type: > relation->timingRelation(); > > To get the lag for a relation: > relation->lag(); > > To set errors: > node->setError(error); > Type of 'error' to be defined... > > To find out when to start/finish the node (within > earliestStart/latestFinish) and to calculate correct duration: > node->pert_setStartFinish(); > > To get the type of node: > node->type(); > which can be: Type_Project, Type_Subproject, Type_Task, > Type_Milestone, Type_Periodic, Type_TerminalNode, Type_Summarytask. > Type_TerminalNode I think you will make disappear, Type_Subproject and > Type_Periodic are not implemented yet. Type_Periodic will be the hard one! > Type_Project, Type_Subproject, Type_Summarytask can have children. > > To get a nodes list of children: > node->childNodeIterator(); Looks good. I suggest you post what you need to be done. I'm happy just to write and test the algorithms. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.