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.