I started this week by finishing off the view factory logic I mentioned last week. I discovered that Java reflection and generics don't mix well! The old factory logic used reflection to create a view using a standard constructor. However, I had to change all the view constructors to reference their model elements generically. Unfortunately, you don't seem to be able to create the generic parameters that are required to invoke the constructors using reflection. I've probably just missed something really simple! Anyway, I decided to implement the factory longhand using a big switch statement. A big advantage of this approach is that the compiler can check the constructors exist at compile time. The only disadvantage is the big and ugly switch statement.
The next thing I did was a total sidetrack but a useful improvement. I've extracted all notation specific object/role names from model elements into an OOA Dictionary. The dictionary provides the Shlaer-Mellor, Executable UML (xtUML) and Executable UML2 (xtUML + UML2) names and icons for all object/role names. The OOA Dictionary webpage just referenced is automatically generated from OOA Tool rather than manually maintained. This means that each future build will allow the user to browse the dictionary that is specific to that build since these names (and icons) are still evolving. I've also added the dictionary as a resource to the main website. However, this will always contain the latest version of the dictionary which may differ from that used in any given OOA Tool build.
A very interesting possibility now that I have a notation switchable dictionary within OOA Tool is that I could use it to convert any OOA of OOA within OOA Tool to use Executable UML terminology. I will need to extend the dictionary to include attribute names, verb phrases and role names. However, the vast majority of these either overlap the object/role names or won't need to be changed. Diagrams do need to be scaled after these conversions. However, I could determine appropriate defaults so that completely changing notation on a loaded metamodel is a one click action.
An even more interesting possibility is that I will be able to generate Executable UML metamodel populations so that archetype templates can reference Executable UML classes and attributes rather than Shlaer-Mellor objects and attributes. For example, the following simple archetype template which generates a list of qualified object names:
.select many objects from instances of Object .for each object in objects .select one domain related by \ object->Information_Model->Domain Object: ${domain.Name}.${object.Name} .end for .emit to file "ObjectList.txt"could alternatively be coded as:
.select many classes from instances of Class .for each class in classes .select one domain related by \ class->PlatformIndependentModel->Domain Class: ${domain.name}.${class.name} .end for .emit to file "ClassList.txt"
OK, so what's next. I need to finish the OOA Dictionary webpage generator and ensure that all views reference the dictionary rather than hardcode notation specific labels. I also need to add a menu item (on the Help menu) for viewing a build specific dictionary within OOA Tool. After that I'm not sure since my To Do List is way too big and I seem to be picking items at random at the moment! I would like to hear from people with regards to what UML/UML2 names I should be using within the OOA Dictionary since I wouldn't claim to be an expert on UML terminology since it keeps changing!
No comments:
Post a Comment