Week 47 of 2009

I'm a day late this week since I sneaked out at lunch to see New Moon at the local cinema. I've already mentioned in the past that I am a vampire literature fan and I have read all the Twilight books. Yes, I'm a 40 year old bloke but I'm also a romantic at heart especially when vampires and werewolves are involved! Anyway, I thought it was pretty good with some realistic special effects even though it was made on a modest budget compared to 2012 which I watched last week. It was also pretty good but If I had to choose then it would loose!

Back to work related topics. I still haven't finished Naming which I have now renamed as Name Management. This fits better especially since I called the external entity in the OOA of OOA domain Name Manager. I spent considerable time implementing a state model with Action Language code for Name which parses original text into words. The algorithm is mirrored in my Java implementation. I've included below the state transition diagram (for Shlaer-Mellor users):

and the equivalent statechart diagram (for Executable UML users):

You will have to click on the images and zoom to see the details. However, it is worth discussing some Action Language coding points raised. The Start Parsing creation state doesn't strictly have to return name at the end to perform the creation but since I want to be able to animate state transition diagrams, It would be nice to know which active object is being followed. It also allows current_state to be set if necessary, i.e. I didn't need to assign it a value in the create object instance statement. You will also notice that I don't use event data item qualifiers in generate statements when the expression used is a simple data item with the same name. This saves a lot of redundancy. In the Parsing Complete final state I have commented out the unrelate statement since it is redundant in OOA09. I always automatically delete any relationship instances involving an object instance before removing an object instance since the programmer can't be relied upon to get this right. It is just too easy to forget. Finally, I would be interested to know if anyone has a solution for determining how we can skip trailing digits before we have reached Parsing Complete. The above algorithm has to go back and remove trailing numeric words if necessary.

The final topic this week is external types which are new in OOA09. I have been testing how useful they are and whether the current definition is sufficient with the work on Name Management that I have been doing. I realized that there are a couple of major deficiencies. First, how do I specific external literal values, e.g. how do I define Role and Phrase literal values in the OOA of OOA domain which are important in the model? Second, how do I test the OOA of OOA domain without a Name Management domain? Do I have to have all domains in place before I can perform simulations? To fix both problems I now optionally associate a literal type (a population independent type) with external types. I have also subtyped external value into Simple External Value and External Value Literal. External value literals have an optional actual value which is determined via a semantic shift mapping if defined. External types can now have a default value if they have a literal type. Furthermore, if the external type has no semantic shift mapping to another domain then the literal type will be used instead when simulating the domain. To help facilitate this, the literal type should implement the same operators as the external type. However, the literal type operators need only provide the minimum implementation necessary for simulation.

I also made a decision as to whether external types can be mapped to different actual types within a project. I decided that this would be a bad idea and so I will require all external types to resolve to at most one actual non-external type. It will still be possible to map an external type in one domain to another external type in another domain. However, all external types must eventually resolve to the same actual type. I had originally included some concept of generic type into external type but I can't see how it all fits together. I may in future add a separate generic type concept but I can't see a need for it at present. External types on the other hand are starting to play a much more significant role since they now facilitate a clean bridge mechanism.

With the improvements that I have made to external types, I am looking forward to creating an Arithmetic Calculator service domain in the future which would support arithmetic operators across a range of limited and unlimited number types. Arithmetic algorithms is one of my hobbies but I must resist since I am already massively behind with my work schedule.

Week 45/46 of 2009

Week 45 was pretty much a write off for personal reasons and it seemed pointless to publish a blog entry since I only completed week 44's weekly report half way thru week 45. I jumped back into Naming in week 46 and there is still some work to finish before it is completed. I've spent so much time on Naming not for the sake of improving Naming flexibility even though that has been greatly improved, the primary reason has been that the Naming service domain has allowed me to understand the requirements of a datatype-to-object bridge. Names and qualified names are defined as external data types in the OOA of OOA domain but exist as objects in the Naming domain. This is an important type of bridge that is not really discussed in the existing literature. Data types in general are very poorly handed in UML and were only starting to be discussed in the Shlaer-Mellor community before most of community jumped into the Executable UML pit of stagnation.

Anyway, I should probably mention why I needed the Naming domain in the first place. Shlaer-Mellor's primary concern is being able to define an executable model which can be automatically translated into code. Any names used within the model should be reused within any generated code to help identify correspondences between the model and the code. A single named element within the model may have many correspondences within a fragment of code. If non-alpha-numeric characters or letter-case is a significant part of a model element name then such correspondences may be significantly obscured. On the other hand I didn't want to lose the original text of the name supplied by the user. This essentially means that I need a Name object containing the original text with equality defined using a normalized version of that text. I also need a way to format the normalized name into many different formats.

So I needed a Name object and I could have then used object references where names are used within the OOA of OOA domain except for the fact that I don't want to allow users to define non-referential object reference attribute types so I would have to define a large number of additional relationships from various named elements to the Name object. This would invariably lead to a separate Naming subsystem. Since Naming is an entirely generic concept we might as well separate it out from the OOA of OOA domain and that is what I have done. The first version of the Naming domain was discussed in the Naming technical note. The new version includes qualified names (e.g. key letters and label prefixes) and improved name formatting. Since I haven't finished the new technical note yet I will include the new Naming OIM (for Shlaer-Mellor users) here:

and the equivalent class diagram (for Executable UML users):

Both diagrams will appear in the technical note when it is republished along with lots of other details.

A significant improvement to name formats involves numeric word formatting controlled by two attributes: Skip leading zero digits allows numeric words to be padded for various reasons without effecting formatted names, and Skip single digit less than allows single digit words to be dropped from formatted names (e.g. I1 is always shown as I in Shlaer-Mellor and Executable UML). All numeric IDs in OOA Tool are now padded to the same length depending on name type (e.g. if the maximum relationship number is 412 then relationship 36 will have a relationship ID of R036). This means that all numeric IDs are now lexically comparable making some code generation tasks easier without effecting work product presentation since I use the new formatting flags. Of course this means that numeric IDs in the OOA of OOA are now names rather than strings.

Getting back to the datatype-to-object bridge. The OOA of OOA now defines a Name Manager external entity including a whole heap of external types:

• Domain ID (e.g. D1),
• Bridge ID (e.g. B1),
• Layer ID (e.g. L1),
• Name (e.g. Information Model),
• Letters (e.g. IM),
• Identifier ID (e.g. I),
• Relationship ID (e.g. R1),
• Phrase (e.g. defines),
• Data Type ID (e.g. DT1),
• Key Letters (e.g. IM_O),
• Relationship Phrase (e.g. InformationModel_defines_Object),
• Label Prefix (e.g. IM_O-A),
• Event Label (e.g. IM_O-A1),
• Operation Label (e.g. IM_O-A.1).

All of which either map to Name or Qualified Name objects in the Naming domain, i.e. all of these types are actually object references. Furthermore, all of these types override the default equality == operator to compare Lower-case ID values rather than use object reference equality which is tied to Original text in the Naming domain. I hadn't planned to allow external operators when I originally though about bridges. However, sorting out this datatype-to-object bridge made the need for such operations obvious.

A number of external processes are also defined for creation (and searching) of names. Name creation processes map to synchronous services in the Naming domain. I have defined Name as an active object with a state model which defines the parsing of the original text into words, i.e. a name creation synchronous service actually generates an asynchronous creation event if exactly the same name doesn't already exist. I can do this by passing a transfer vectorreturn coordinate from the synchronous service to the creation event allowing a final Parsing Complete state to invoke a synchronous return back to the original synchronous name creation process in the OOA of OOA domain. This starts to show the power of bridges. Obviously, the software architecture needs to be able to generate efficient code for state models which only contain local events (excluding the original creation event).

Anyway, I probably shouldn't say anymore about this until after the new Naming technical note is published. With regard to the mythical next build, I think I'm going to have to temporarily disable some of the new features I've not yet finished (e.g. operations) so that I can release all of the other good stuff I have finished. The one important thing I have to do is sort out OOA Interchange Format 0.05 so that maintaining backwards compatibility after Build 016 is released is not a complete nightmare! Assuming I disable any incomplete features I should have a build released sometime in the next 2 weeks. Then I can get back to regular builds.

Week 44 of 2009

Last week I mentioned that I would provide a few screenshots of the new relationship identification scheme in OOA Tool. The first shows the Information Model subsystem from the OOA Tool Model which uses Shlaer-Mellor notation:

You can see that relationship IDs are still used as before but users can now search for relationships by a primary object followed by a verb phrase following by an optional secondary object. This is much easier and is more natural when tracking down a navigation in some Action Language code which no longer has to reference relationship IDs. There is still a minor issue here concerning which object is selected as the primary object in this scheme. I have chosen the first object for simple, composed and mathematically dependent relationships, the associative object for associative relationships and the supertype object for subtype-supertype relationships. Obviously, searching for details of a navigation from a secondary object is still more difficult at present. However, all navigations should involve the primary object, e.g. all subtype-supertype navigations involve the supertype object. The only partial exception is that a user could navigate across an associative relationship without explicitly referencing the associative object since the Shlaer-Mellor virtual machine can handle any navigation thru the associative object automatically.

For simple relationships, the initial choice of first object is often arbitrary and has been of little concern in the past. However, users may now want to select the most apprioriate primary object as their first object when creating simple relationships, e.g. in the relationship INFORMATION MODEL defines OBJECT, the INFORMATION MODEL object is definitely the most appriopriate primary object and thus should be first. Users can still swap first and second participants around later if they want to change their mind.

The second screenshot shows the Elevator PIM from the Starr01 Elevator Model which uses Executable UML notation:

You can see that relationship IDs are still used but are shown in the property list associated with each relationship.

I'll keep this week's report brief otherwise next week's report will be even briefer since I'm eating into next week's available time! However, I will mention that I revisited the Naming service domain used in the OOA Tool Model and the Naming technical note that was previously blogged. I've significantly revised the model and have resolved how the Naming service can be bridged to the OOA of OOA domain where names are used. However, I will leave the details until later since I plan on republishing the technical note. The new technical note also includes a Java Applet allowing name parsing and formatting to be demonstrated!