So I had set out for doing the RationalRose file-format reader for Modlr. As I discussed earlier I was intimidated by the non-xml-file-format, and discouraged by the details in the format.
So I first made some logic that turned it into XML, then I made a plugin to Modlr that could deduce a Model from XML… So there is no escaping this I guess – I need to actually read and interpret the data…
BTW If anyone wonders why I have not done this until now it was because I was skiing – first in Sälen, Sweden – brilliant weather, ok hills, then in BadGastain, Austria – ok weather , brilliant hills!
1: RoseImport ri = new RoseImport(); // This reads the mdl and turns it into XML
2: ri.OpenFile(textBoxFileName.Text, true);
3: _es = EcoSpace;
4: _createdobjects = new Dictionary<string, IEcoObject>();
5:
6: InstansiateObjects(ri.XDocument); // This should interpret the xml content and match it with the model I have
7: foreach (XDocument xd in ri.CatFiles) // RoseImport also find CAT file references and reads those too
8: {
9: InstansiateObjects(xd);
10: }
Since I am lazy, stressed and living in Sweden, the country with the highest taxes in the world, I really need to be efficient about this…
My model was deduced from the XML so I am pretty sure that the names in the XML will be the same in my model.
Using the meta information from eco I can go like this to instantiate the correct objects:
1: IEcoObject existing = null;
2: XElement keyelement = xe.Elements("key") as XElement;
3: if (keyelement != null && keyelement.Value != null)
4: {
5: string Key = keyelement.Value;
6: if (_createdobjects.ContainsKey(keyelement.Value))
7: existing = _createdobjects[keyelement.Value];
8: }
9: if (existing == null)
10: {
11: IClass iclass = EcoServiceHelper.GetTypeSystemService(_es).TypeSystem.
12: GetClassifierByName("ro_" + xe.Name.LocalName) as IClass; // My model prefixed all rose classes with ro_
13: existing = EcoServiceHelper.GetObjectFactoryService(_es).CreateNewObject(iclass);
14: if (keyelement != null && keyelement.Value != null)
15: {
16: _createdobjects.Add(keyelement.Value, existing);
17: }
18:
19: }
Ok , moving on to the attributes:
1: foreach (XElement child in xe.Elements())
2: {
3: if (!child.HasElements)
4: {
5: IElement elem = existing.AsIObject().Properties[child.Name.LocalName];
6: if (elem != null && !(elem is IObjectList))
7: elem.SetValue<string>(child.Value);
8: }
9: else
10: {
11: // load association
12: }
13: }
If my model had better typed values, like double, int, etc I would need to work on the parsing, but I am fine with strings.
And the associations:
1: // load association
2: IElement elem = existing.AsIObject().Properties[child.Name.LocalName];
3: if (elem is IObjectList)
4: {
5: foreach (XElement associationobject in child.Elements())
6: {
7: IEcoObject associaionInstansiatedObject=InstansiateObjects(associationobject);
8: if (associaionInstansiatedObject.AsIObject().UmlClass.ConformsTo((elem as IObjectList).UmlClass))
9: (elem as IObjectList).Add(associaionInstansiatedObject);
10: else
11: System.Diagnostics.Debug.WriteLine(string.Format("Tried to add a {0} to a list of {1}, association was {2}",
associaionInstansiatedObject.AsIObject().UmlClass.Name,
(elem as IObjectList).UmlClass.Name, child.Name.LocalName));
12: }
13: }
Note the last line where I check if the loaded data actually will be valid to add in this association… Since my model was deduced from XML it is probably lacking important abstractions (inheritance). And sure enough, running this on a mdl file gave me this output:
1: Tried to add a ro_Class to a list of ro_Class_Category, association was logical_models
2: Tried to add a ro_Class to a list of ro_Class_Category, association was logical_models
3: Tried to add a ro_Class to a list of ro_Class_Category, association was logical_models
4: Tried to add a ro_Class to a list of ro_Class_Category, association was logical_models
5: Tried to add a ro_Class to a list of ro_Class_Category, association was logical_models
6: Tried to add a ro_Association to a list of ro_Class_Category, association was logical_models
7: Tried to add a ro_Association to a list of ro_Class_Category, association was logical_models
8: Tried to add a ro_Association to a list of ro_Class_Category, association was logical_models
9: Tried to add a ro_Association to a list of ro_Class_Category, association was logical_models
10: Tried to add a ro_Association to a list of ro_Class_Category, association was logical_models
11: Tried to add a ro_Association to a list of ro_Class_Category, association was logical_models
12: Tried to add a ro_Association to a list of ro_Class_Category, association was logical_models
13: Tried to add a ro_Association to a list of ro_Class_Category, association was logical_models
14: Tried to add a ro_Association to a list of ro_Class_Category, association was logical_models
15: Tried to add a ro_ClassDiagram to a list of ro_UseCaseDiagram, association was logical_presentations
This leads me to believe that the association logical_models really should point to some abstraction rather than to the ro_Class_Category itself… Keep in mind that I know nothing about what all this mean yet, I am just as ignorant to stuff maintained by IBM as IBM is of me (wow that is a lot).
So I change the model by introducing a superclass called LogicalModel (made sense since the association was called that):
BTW: I moved around the attributes (removing them from the subclasses to the superclass) with the newly implemented copy-paste function of the Modlr-tree (Yippy!).
I found some more missing abstractions that I added. Finally the output list was empty. No more errors.
At this point I need to actually understand what it is I am doing – after all I am supposed to understand the content of the rose file in order to turn the artifacts within into modlr objects (defined by, what we call, extendedmodellayer).
No better way than to use the EcoSpaceDebugger and autoforms. Load my sample mdl again:
There is a ro_ClassDiagram that looks interesting:
…it has a multi link called Items that contain ro_ClassView and ro_AssociationView…
Looking closer in the ro_ClassView – I guessing that this is what ModelLayer calls PlacedClass:
…I wonder how if finds the ro_class… I am guessing it uses the quidu reference…
Using the ecospace debugger I wrote this ocl: ro_Class.allinstances->select(quid='"3BDC6B1A02D7"') and sure enough:
So I will amend the model to keep this knowledge in a derived association.
The Derivation expression is “ro_Class.allinstances->select(quid=self.quidu)->first”
Not only does the derived association help me when looking in autoforms and writing code; it also ensures that things stay optimized. A derived association is subscribed to by the eco-runtime, and the value is cached until it changes. And when it changes it is merely marked as out of date, so it is only updated if someone tries to read it again.
It is easy to imagine that I would write code and look up the ro_Class from the ro_ClassView.quidu whenever I needed it; but the derived association removes the need for repetitive, error prone, performance hurting, hard to find code and brings it up in the light, as a first class member of the ro_ClassView ready to serve whenever I need it – available in the model for everyone to see. How beautiful is that?
So I am not going to bore you with all the details – I will continue to work on this – the main purpose of this post was to explain how I use eco to move away from time consuming hand coding techniques, towards building and using tools to get the job done.
Get out of the middle ages – become model driven.
