I have a set of schedule files (MS Project files converted to XML) which are different versions of the same schedule, but updated at different times. My project is Kleio, so I've taken the Hismo metamodel for evolution - (History, Version, Snapshot - from Girba, 2005) and created 3 new classes:
KleioScheduleHistory (subclass of HismoAbstractHistory)
KleioScheduleVersion (subclass of HismoEntityVersion)
KleioSchedule (subclass of MooseEntity)
(These are analogues to, say, HismoClassHistory, HismoClassVersion and FAMIXClass.)
I've simplified this somewhat, as there are also Activities (Tasks) and Resources to consider. These are not important to my question.
When I load the schedule data into these classes, I first create one KleioScheduleHistory for the set of schedules (the history). I then create a KleioSchedule for each schedule (the snapshots), and finally I create an instance of KleioScheduleVersion (the versions) for the snapshot using:
KleioScheduleVersion class >> with: aVersionEntity inHistory: aHistory withReferenceVersion: aReferenceVersion.
This creator method is a modified version of HismoEntityVersion class >> with: aVersionEntity inHistory: aHistory withReferenceVersion: aReferenceVersion. Rather than inherit this creator method from HismoEntityVersion, I've re-written it, as the HismoEntityVersion only works for sub-classes with a name starting with Hismo (see source - 'Hismo' is hard wired as the class prefix!! bad karma).
So far, so good.
My question however is:
What is the significance of the attribute aReferenceVersion in the creator method with:inHistory:withReferenceVersion for the HismoEntityVersion (and so KleioScheduleVersion) class?
What problem is it trying to solve? i.e. Why does the HismoEntityVersion creator method have this field as an attribute? I can set it to nil, but what functionality in the Hismo framework would I then be missing?
Alan.