Tuesday 24 November 2009

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.

No comments: