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!

Week 43 of 2009

I've got lots to talk about this week. I started the week by implementing a feature that I've been thinking about for ages - automatic backups when saving. When a project is saved, the old version will now be renamed (not overwritten) using a "~1" suffix. If a "~1" backup already exists then it will be renamed as "~2" etc. How many backups are allowed is now controlled by the user preference Maximum Backups which can be set from the Preferences menu. This also applies to other input files such as action, archetype and pattern files.

After this was done, I started thinking about a File System service domain for OOA Tool so that that the concept of location, location format etc. would not pollute the OOA of OOA domain. I've mentioned previously that I was going to do this. I've almost finished the model now but I will leave a detailed discussion for a separate technical note. However, I will mention that this domain allows files to be located using a filename or a URL from an underlying file system or from an internet but files won't be saveable to an internet.

While I was creating the File System model, I ran across a nasty bug in OOA Tool. I could not save my model since some validation logic was stopping me from creating an unloadable model but it didn't give me enough information to work out how to make my model loadable again! Since I've been coding OOA Tool (132KLOC currently) by myself, I have to code in an ultra-protective way to ensure bugs don't cross logic boundaries. My strategy in this situation was a little too overprotective! I have fixed the actual bug now. However, I have also introduced a dialog to give the user the opportunity to save a model anyway since a clever user may be able to patch the XML file themselves (or email it to me and I will do it). Moving forward, I need to add a new automatic fix option that would involve the selective removing of broken elements from a model. Obviously, it shouldn't actually be needed but the OOA Tool software is constantly expanding and I prefer to over validate than under validate.

Since I was looking at file issues, I also had another look at how projects can be linked together allowing domains and bridges to be reused without resorting to copy and paste. This is a serious problem that sits at the heart of my vision to enable a marketplace for service domains. I've already captured some of my ideas in the Recursive Design subsystem of the OOA of OOA but the ideas aren't implemented yet. One aspect of the model that I realised wasn't well thought out was the ownership of domain observers by the domain being observed. Domain observers sit above multiple domains observing one aspect of one domain but potentially effecting any number of domains as a consequence. Thus, they should really be owned by the project rather than the observed domain. However, if I did this, I would lose the ability to reuse the domain observers from another project. A concept was missing which I will add in the near future. I'm calling this concept a layer and it will own a set of domain observers. Users will be allowed to import layers which sit over already imported domains. These layers mirror aspects in aspect-oriented programming which I discussed last week. Maybe I should think about supporting more aspect-oriented features within layers? As always, comments welcome.

During the week I also decided to make a small notation change in Shlaer-Mellor OIM diagrams. Literal attributes which have an initial value which is also the final value are now shown with an "(F)" suffix. I was already using the suffix in the browser but I decided that it should also be visible on the diagram. This is a tricky area since I don't want to change Shlaer-Mellor notation, only add to it were necessary. In this case, the new suffix will only appear if users are using the new literal attribute feature of OOA09. Executable UML users will already see a "{frozen}" suffix instead while Executable UML2 users see "{readOnly}" since this property was renamed in UML2.

Somehow I got sidetracked during the week into looking at participant verb phrases and multiplicity. One area of confusion regards binary participant verb phrases. I originally associated the verb phrase before the participant with the participant but I changed this to the verb phrase after several builds ago. I did this because all participants have a natural verb phrase after. However, I didn't previously capture this in the Information Model subsystem. I have now added a polymorphic attribute Verb Phrase After to the Participant object along with additional attributes in the various subtype objects. I also added a mathematically dependent attribute Verb Phrase Before to Binary Participant since that is what is used when displaying a binary participant as a connector. This should clear up any verb phrase confusion now. I also decided that associative participant verb phrases should be displayed on OIM and class diagrams (if defined) to help ensure associative objects are appropriately named. I also visited multiplicity issues but I think I will leave this discussion to another day when I have less to talk about.

An interesting verb phrase display tweak that I implemented in OOA Tool this week is that roles that appear within associated verb phrases are now shown on OIM and class diagrams by tweaking the fonts, e.g. DOMAIN assumes capabilities provided by server DOMAIN highlights the fact that server is the role name by removing the italics. Executable UML adds italics to roles instead while Executable UML2 uses bold for roles. Binary relationships with long verb phrases can now define roles which are taken from those verb phrases to make navigation expressions within code less verbose while at the same time not defining hidden information. Roles can be viewed as abbreviated verb phrases as a consequence. This should stop users defining short but meaningless verb phrases because of worries that the code will be horribly verbose (and they don't want to define hidden role information), e.g. who wants to write domain->Domain['assumes capabilities provided by server'] when they can write domain->Domain[server] instead while avoiding hidden information and preserving the original longer verb phrase.

The final thing I want to discuss is relationship IDs which have caused me loads of problems while implementing metamodel population logic (which involves thousands of lines of code within OOA Tool). Relationship IDs are great for cross-referencing referential attributes and composed relationships on an OIM or class diagram. They are also convenient for use in OOA Interchange Format files. However, they are not so good when you are browsing relationships with the OOA Tool tree browser and they are a nightmare when manually coding logic derived from a model. It is easy to mistake the meaning of a relationship ID in this context since the ID contains no semantic information. Any such code can also be very brittle, i.e. if the relationship ID changes in the model you must change it in the code. I've already eliminated the need to use relationship IDs within Action Language code by allowing verb phrases and roles to be used instead. I also allow verb phrases and roles to be dropped when the destination object is sufficient information in itself.

However, how do you identify an arbitrary relationship within a domain without using a relationship number or ID? I finally determined a solution which revolves around a relationship verb phrase, the object before and optionally, an object after. Associative relationships can be identified using the associative object along with the verb phrase defined on the associative participant. Other binary relationships can be identified using the first object, the verb phrase after associated with the first object and the second object. The second object can be dropped for reflexive relationships, i.e. where first and second object are the same. Subtype-supertype relationships can be identified using the supertype object along with an implicit "is a" verb phrase. These conventions mostly work as is. However, to ensure uniqueness, an algorithm may need to alter (using some form of suffix) some verb phrases in a similar way to how key letters are always made unique in OOA Tool. I've now added Custom Verb Phrase (optional), Default Verb Phrase (derived), Verb Phrase (derived) and Qualified Verb Phrase (derived) to all relationships as part of the implementation of this new alternative identification scheme. Users can rely on default verb phrases with automatic addition of suffixes where necessary. However, they can also define custom verb phrases if they want to make relationship identification easier. The qualified verb phrase attribute holds a compound value composed of several names. I need to add a new Qualified Name object to the Naming service domain to handle this. This discussion is easier to visualize when you are sitting in front of OOA Tool but you have to wait for the next build for that. I will give you some screenshots next week when I finish updating the browser to sort relationships using the new scheme.

Week 42 of 2009

This summary is not available. Please click here to view the post.

Week 41 of 2009

I'm not often pleasantly surprised by Microsoft but I was when I discovered Microsoft Security Essentials. It provides totally free virus protection on XP and Vista. Now, I'm not a big fan of giant companies squishing little ones by dumping free software into the marketplace. However, the existing virus protection vendors have been pissing me off for years. They are almost impossible to uninstall and the last two I used were constantly reminding me to renew their subscription even though I had lots of time left on my existing subscription. The first time this happened a few years ago, I renewed by mistake thinking my time was up. It wasn't, I still had 6 months left on the old subscription. Anyway, I hope they all disappear into oblivion now!

With regards to OOA Tool, the week has progressed very slowing with my attention moving from one area to the next trying to tie off loose ends. I didn't manage to finish any bigger items so there isn't much to talk about here!

Perhaps I could talk about the confusing world of events and signals. Shlaer-Mellor users don't need to worry about signals at all. However, Shlaer-Mellor users may be confused by internal and external events which should really be called internal and external event generations (as opposed to invocations) since they relate to the generation of events rather than the specification of events. The OOA Dictionary retains the original names even though they are a little confusing since they appear frequently in the existing literature. However, internal and external process invocations (which are a similar concept) are not shortened to internal and external processes since the latter does not appear in the existing literature.

Executable UML users do have to worry about events and signals and to confuse matters further, xtUML [xtUML02] and xUML [xUML04] use the terms differently. Now, UML2 [UMLManual05] uses the term event only when discussing state models. The term signal is applied to classes carrying information for asynchronous communications. The more general term message is normally used when discussing communications in general. This contrasts with Shlaer-Mellor which uses the term event in all of these situations. Now xtUML uses the term event correctly according to UML2, although signal event might be more appropriate but unnecessary since call events and change events aren't supported. I'm skipping over time events here even though delayed events (a similar but different concept) is supported in Shlaer-Mellor and Executable UML. However, xtUML uses the term signal for generated events (i.e. internal and external events in Shlaer-Mellor) which isn't really correct. Executable UML doesn't allow classes containing event information to be defined. This is a tricky area but using the term signal here is probably less confusing than using event. On the other hand, xUML uses the term signal almost exclusively which also isn't correct. OOA Tool always uses xtUML conventions but Executable UML users should note that there are small differences between xtUML and xUML.

A final note for anyone here in the UK. I watched Micro Men the other day on iPlayer seeing how Clive Sinclair and Chris Curry kick started the micro computer industry here in the UK. Unfortunately, both of their companies failed. Very sad for the UK. I still have a Sinclair QL in good condition although I haven't had it out of the box in the last 10 years! I don't know what happened to my Sinclair Spectrum but that was my very first computer. I never did buy a BBC Micro but I remember using one briefly in college.

Week 40 of 2009

The whole of this week has been spent working on the OOA Dictionary and the metamodel populator which now uses the dictionary. I also spent several hours recolouring all the icons so that they match the colours used in OOA Tool. I created the original icons using Paint but it rounded off the colours when the icons were saved. I now use Paint.NET which is a very easy to use free tool which has no problem handling 24-bit colours with transparency.

As I just mentioned, a chunk of my time was spent recoding the metamodel populator to use the dictionary. I already had a heap of work to do here since the populator has gotten massively out of step with the Information Model and Data Type subsystems. Metamodel Populations now have their own notation and version allowing archetype templates to be coded using Executable UML class and attribute names (as was discussed in a previous blog). However, this raised the issue of dictionary version control. I don't want to make the dictionary independently version controlled. However, a given metamodel version must continue to use the same dictionary names. I've done this by defining all Metamodel 0.01 entries in the class OOADictionary0_01. The original OOADictionary class now extends this adding entries which aren't needed in the metamodel. When I create a Metamodel 0.02 in the future, I will also create an OOADictionary0_02 and insert it between the OOADictionary0_01 and OOADictionary classes. I can add or statically override entries in the OOADictionary0_02 class without effecting the Metamodel 0.01 population logic while the main OOADictionary class simply uses all of the latest entries without worrying about versions.

I also made a number of Executable UML name changes, e.g. Enumerated Type and Legal Value are now Enumeration and Enumeration Literal. I also noticed that UML2 uses a modified symbol for active classes, i.e. a left and right bar is added to the rectangle. As a consequence, I added a whole heap of modified UML2 icons (look in the dictionary to see). I haven't updated the diagram editors yet but I will do when I next delve into them.

I'll keep this week's blog short since I'm already posting late due to unforeseen real-world problems. I will continue working on the metamodel populator next week. I also want to ensure all entries have an icon so a few still need to be done. I'm also continuing to ponder whether there are more appropriate Executable UML names I could be using in some cases.