11 Jun
2013
11 Jun
'13
11:10 a.m.
In the description of Girba, 2005, "Modeling History to understand Software
Evolution", there is a small statement on "referenceVersion" in the Hismo
metamodel:
"Each Version has a reference to the so called referenceVersion which
provides a fixed point in the historical space."
This is implemented in Moose Hismo, but there is little description of its
relevence to modelling. What is meant by "fixed point in the historical
space"? In fact, there is an interface to set it to easily set it to nil!!
(HismoEntityVersion class >> with:inHistory:)
Can Tudor or someone else able to describe why referenceVersion would be
important in time based analysis?
Could this be, for example, the "baseline" to which other copies are
compared? Can we have a different referenceVersions in different
HismoHistoryGroups? Can we change the referenceVersion on the fly during
analysis? I can see hints in the names of methods (e.g.
isBornPriorToOrInReferenceVersion), but I can't quite catch the semantics.
Can you give some guidelines on which version should be selected as the
referenceVersion, and why?
As I've described earlier, I'm trying to analyse different versions of
system development schedules. I'm trying to use the Hismo framework to its
best advantage, so I'm trying to understand the semantics as well as the
code.
Alan.
--
View this message in context:
http://forum.world.st/What-is-the-relevence-of-referenceVersion-in-Hismo-tp…
Sent from the Moose mailing list archive at Nabble.com.
12 Jun
12 Jun
4:15 p.m.
hello
in which context are you doing this task?
Stef
On Jun 11, 2013, at 11:10 AM, badja <alan.mcnamara(a)badja.com> wrote:
In the description of Girba, 2005, "Modeling
History to understand Software
Evolution", there is a small statement on "referenceVersion" in the Hismo
metamodel:
"Each Version has a reference to the so called referenceVersion which
provides a fixed point in the historical space."
This is implemented in Moose Hismo, but there is little description of its
relevence to modelling. What is meant by "fixed point in the historical
space"? In fact, there is an interface to set it to easily set it to nil!!
(HismoEntityVersion class >> with:inHistory:)
Can Tudor or someone else able to describe why referenceVersion would be
important in time based analysis?
Could this be, for example, the "baseline" to which other copies are
compared? Can we have a different referenceVersions in different
HismoHistoryGroups? Can we change the referenceVersion on the fly during
analysis? I can see hints in the names of methods (e.g.
isBornPriorToOrInReferenceVersion), but I can't quite catch the semantics.
Can you give some guidelines on which version should be selected as the
referenceVersion, and why?
As I've described earlier, I'm trying to analyse different versions of
system development schedules. I'm trying to use the Hismo framework to its
best advantage, so I'm trying to understand the semantics as well as the
code.
Alan.
--
View this message in context:
http://forum.world.st/What-is-the-relevence-of-referenceVersion-in-Hismo-tp…
Sent from the Moose mailing list archive at Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:32 p.m.
Not sure on your question: "What context?" I'll try to explain but I may
not be addressing what you may be wanting to know.
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.
--
View this message in context:
http://forum.world.st/What-is-the-relevence-of-referenceVersion-in-Hismo-tp…
Sent from the Moose mailing list archive at Nabble.com.
8:19 p.m.
Thanks alan.
Is it a master project? PhD? with which university?
On Jun 12, 2013, at 7:32 PM, badja <alan.mcnamara(a)badja.com> wrote:
Not sure on your question: "What context?"
I'll try to explain but I may not be addressing what you may be wanting to know.
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.
View this message in context: Re: What is the relevence of referenceVersion in Hismo?
Sent from the Moose mailing list archive at Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:28 p.m.
PhD with University of Technology, Sydney - www.uts.edu.au
On 13 June 2013 04:19, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote:
Thanks alan.
Is it a master project? PhD? with which university?
On Jun 12, 2013, at 7:32 PM, badja <alan.mcnamara(a)badja.com> wrote:
Not sure on your question: "What context?" I'll try to explain but I may
not be addressing what you may be wanting to know.
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.
------------------------------
View this message in context: Re: What is the relevence of
referenceVersion in
Hismo?<http://forum.world.st/What-is-the-relevence-of-referenceVersion-in-Hismo-tp4692748p4693052.html>
Sent from the Moose mailing list
archive<http://forum.world.st/Moose-f1310756.html>at
Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
15 Jun
15 Jun
8:34 p.m.
PhD with University of Technology, Sydney -
www.uts.edu.au
Cool :)
let us know how we can help.
Stef
On 13 June 2013 04:19, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote:
Thanks alan.
Is it a master project? PhD? with which university?
On Jun 12, 2013, at 7:32 PM, badja <alan.mcnamara(a)badja.com> wrote:
Not sure on your question: "What
context?" I'll try to explain but I may not be addressing what you may be wanting
to know.
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.
View this message in context: Re: What is the relevence of referenceVersion in Hismo?
Sent from the Moose mailing list archive at Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
17 Jun
17 Jun
8:05 a.m.
Ben,
For what it is worth, all my code will be released under MIT licence:
http://ss3.gemstone.com/ss/Kleio.html
It is private at the moment, but I will open it up once there is some
results to show.
Regards,
Alan.
On 16 June 2013 16:02, Ben Coman <btc(a)openinworld.com> wrote:
**
That sounds really interesting. Is any part of it planned to be open
source?
btw, good to see another Aussie on the list (I'm in Collie Western
Australia studying remotely at University of Southern Queensland)
cheers -ben
badja wrote:
Not sure on your question: "What context?" I'll try to explain but I may
not be addressing what you may be wanting to know.
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.
--
View this message in context:
http://forum.world.st/What-is-the-relevence-of-referenceVersion-in-Hismo-tp…
Sent from the Moose mailing list archive at Nabble.com.
------------------------------
_______________________________________________
Moose-dev mailing
listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
20 Jun
20 Jun
3:38 p.m.
Hi,
Hismo aims to offer you the possibility to navigate both in space and in
time. To this end, you need to always know where you are.
referenceVersion is similar to mooseModel in FAMIX entities. From any FAMIX
entity you can quickly navigate to the model object. In the same way, from
any version entity you can navigate to the top-most version (usually a
version corresponding to a MooseModel instance).
Let's take an example. Imagine you have a history of 5 models (instances of
MooseModel) holding FAMIX objects.
And now, imagine that the version of a class A in your hand, and you would
want to know that it exists in the version 2. So, you would get the object
corresponding to system version 2 and then use existsInReferenceVersion: to
check your version object (see below):
existsInReferenceVersion: aReferenceVersion
"answers if the history has a version in aReferenceVersion"
^(self versions
select: [:each | each referenceVersion = aReferenceVersion]) isEmpty not
referenceVersion is supposed to be immutable (so you should not change it
dynamically).
Does it answer the question?
Cheers,
Doru
On Tue, Jun 11, 2013 at 11:10 AM, badja <alan.mcnamara(a)badja.com> wrote:
In the description of Girba, 2005, "Modeling
History to understand Software
Evolution", there is a small statement on "referenceVersion" in the Hismo
metamodel:
"Each Version has a reference to the so called referenceVersion which
provides a fixed point in the historical space."
This is implemented in Moose Hismo, but there is little description of its
relevence to modelling. What is meant by "fixed point in the historical
space"? In fact, there is an interface to set it to easily set it to nil!!
(HismoEntityVersion class >> with:inHistory:)
Can Tudor or someone else able to describe why referenceVersion would be
important in time based analysis?
Could this be, for example, the "baseline" to which other copies are
compared? Can we have a different referenceVersions in different
HismoHistoryGroups? Can we change the referenceVersion on the fly during
analysis? I can see hints in the names of methods (e.g.
isBornPriorToOrInReferenceVersion), but I can't quite catch the semantics.
Can you give some guidelines on which version should be selected as the
referenceVersion, and why?
As I've described earlier, I'm trying to analyse different versions of
system development schedules. I'm trying to use the Hismo framework to its
best advantage, so I'm trying to understand the semantics as well as the
code.
Alan.
--
View this message in context:
http://forum.world.st/What-is-the-relevence-of-referenceVersion-in-Hismo-tp…
Sent from the Moose mailing list archive at Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
23 Jun
23 Jun
6:17 a.m.
Doru,
I'm starting to understand.
"Let's take an example. Imagine you have a history of 5 models (instances of
MooseModel) holding FAMIX objects."
Ah ha. I've been looking at a history and all the versions and snapshots
being within a /*single*/ MooseModel. But you are suggesting I should have
a MooseModel for my data at each point in time, then model the time
relationships between them using the Hismo history classes.
Can I confirm that then the HismoAbtractVersion (as subclassed) and
HismoAbstractHistory (as subclassed) instances therefore sit *outside* the
MooseModel instances.
The MooseModel instances (in your example 5 instances) would consist of
FAMIX class instances, and would not include any Hismo class instances. The
history instances (e.g. HismoClassHistory) would point to version instances
(HismoClassVersion) which in turn would point to FAMIX class instances
(FAMIXClass) - and only these FAMIX instances will be in the (5)
MooseModels.
Is this correct?
--
View this message in context:
http://forum.world.st/What-is-the-relevence-of-referenceVersion-in-Hismo-tp…
Sent from the Moose mailing list archive at Nabble.com.
7 a.m.
Hi,
You are correct.
You need to build a so called HismoModelHistory that will be formed by
versions corresponding to your snapshot models. Take a look at
MooseSampleData>>initialize for an example of how to initialize this.
Doru
On Sun, Jun 23, 2013 at 6:17 AM, badja <alan.mcnamara(a)badja.com> wrote:
Doru,
I'm starting to understand.
"Let's take an example. Imagine you have a history of 5 models (instances
of
MooseModel) holding FAMIX objects."
Ah ha. I've been looking at a history and all the versions and snapshots
being within a /*single*/ MooseModel. But you are suggesting I should have
a MooseModel for my data at each point in time, then model the time
relationships between them using the Hismo history classes.
Can I confirm that then the HismoAbtractVersion (as subclassed) and
HismoAbstractHistory (as subclassed) instances therefore sit *outside* the
MooseModel instances.
The MooseModel instances (in your example 5 instances) would consist of
FAMIX class instances, and would not include any Hismo class instances.
The
history instances (e.g. HismoClassHistory) would point to version instances
(HismoClassVersion) which in turn would point to FAMIX class instances
(FAMIXClass) - and only these FAMIX instances will be in the (5)
MooseModels.
Is this correct?
--
View this message in context:
http://forum.world.st/What-is-the-relevence-of-referenceVersion-in-Hismo-tp…
Sent from the Moose mailing list archive at Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
7:48 a.m.
Doru,
Many thanks. I'll let you know how it goes.
Alan.
On 23 June 2013 15:00, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
You are correct.
You need to build a so called HismoModelHistory that will be formed by
versions corresponding to your snapshot models. Take a look at
MooseSampleData>>initialize for an example of how to initialize this.
Doru
On Sun, Jun 23, 2013 at 6:17 AM, badja <alan.mcnamara(a)badja.com> wrote:
Doru,
I'm starting to understand.
"Let's take an example. Imagine you have a history of 5 models (instances
of
MooseModel) holding FAMIX objects."
Ah ha. I've been looking at a history and all the versions and snapshots
being within a /*single*/ MooseModel. But you are suggesting I should
have
a MooseModel for my data at each point in time, then model the time
relationships between them using the Hismo history classes.
Can I confirm that then the HismoAbtractVersion (as subclassed) and
HismoAbstractHistory (as subclassed) instances therefore sit *outside* the
MooseModel instances.
The MooseModel instances (in your example 5 instances) would consist of
FAMIX class instances, and would not include any Hismo class instances.
The
history instances (e.g. HismoClassHistory) would point to version
instances
(HismoClassVersion) which in turn would point to FAMIX class instances
(FAMIXClass) - and only these FAMIX instances will be in the (5)
MooseModels.
Is this correct?
--
View this message in context:
http://forum.world.st/What-is-the-relevence-of-referenceVersion-in-Hismo-tp…
Sent from the Moose mailing list archive at Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3975
days inactive
3987
days old
11 comments
5 participants
participants (5)
-
Alan McNamara -
badja
-
Ben Coman -
Stéphane Ducasse -
Tudor Girba