[kplato] Application Class Structure

[Chris Clarke]

On Sunday 15 July 2001 13:19, John D Lamb wrote:

John,

> I just saw Thomas Zander's class structure. This is good. I think we
> need to be clearer about the difference between time dependency and tree
> dependency. Here's an example of activities for a "coffee" project:

[Snip example]

> I think eventually kplato will need both structures, but the time
> dependency is more important initially.

I'm not quite sure what you mean here:  the KPTNode class does have two sets 
of dependencies:

The tree dependency is managed by the XChildNode methods (e.g. addChildNode), 
and managed in the m_nodes list.

The time dependency is managed by the XYDependNode methods (e.g. 
addParentDependNode), and managed in the m_dependChildNode, and 
m_dependParentNode lists.

Are you thinking you want to rename these, or are you considering a different 
structure for managing the two lists?

> Time dependency: I think we should record the dependency as a list in
> both nodes. So for example, task Y would have Z as a following node and
> Z would have Y as a predecessor. Provided the class structure only
> allows dependencies to be added in pairs, I don't think this would be a
> problem, even if it's not strict OOP. I don't think we should record
> implicit dependencies (e.g. X before U). I think we'd need to allow the
> user to put in dependencies like X before Y, Y before Z, Z before X.
> Users should be able to put in inconsistencies while developing a
> project. We can always check for inconsistencies easily.

The framework is there for this, with the m_dependChidNode, and 
m_dependParentNode lists.  Methods have been prototyped to manage these lists 
seperately.

Cheers,
Chris.
-- 
Chris Clarke
chris.clarke@cfourconsulting.com
http://cfourconsulting.com