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.

Week 39 of 2009

This week I have been trying to finish off the OOA Dictionary. This should have been easy except for the fact that it made me think about a number of mapping issues. Obviously, that is the purpose of having a centralized multi-notation dictionary so it shouldn't have surprised me that this work would slip a bit. I completed most of the entries and a few of the issues raised are discussed below. The outstanding entries that I still need to finish off are the Operation and Simulation entries. Process Model, Action Language and Translation entries are light on the ground since the associated model elements don't exist yet.

The Information Model subsystem defines a multiple hierarchy for binary relationships. The first hierarchy defines simple, associative, composed and mathematically dependent relationships. The second defines loop independent and loop dependent relationships. A third implicit hierarchy defines competitive and non-competitive relationships, i.e. whether a relationship has an associated assigner model. Not all combinations make sense, e.g. composed relationships are always loop dependent. Some combinations make sense but aren't recommended, e.g. competitive simple relationships. The problem I had was to determine the best names to use for all legal combinations of these relationship types. I also redesigned some of the icons used here.

There are a number of changes that I need to make to the State Model subsystem: whether internal events are manually created or automatically determined (from Action Language code) needs to be configurable, I want to be able to control transition label formatting over multiple lines, a creation transition is needed so that there is something to select or delete in the STD editor, and it should be possible to associate multiple transition notes with a transition. However, I want to put this work off until the next build since there are a number of other related things that I need to finish off, e.g. the STT editor and the technical note defining state models. The main change I did make was to rename external entities in Executable UML notation from Actor to External Entity. The use of the term Actor here is similar to the use of the term Terminator in Shlaer-Mellor notation. More importantly, the term Actor is better used in the context of Use Cases which I discuss below.

I started on OOA work products then and one area of Executable UML that OOA Tool doesn't currently support is Use Cases since there is no equivalent in Shlaer-Mellor. I have used Use Cases on UML projects in the past as an alternative to writing traditional requirement specifications. If used correctly, they can help to identify the scope of a project and kick start the application domain. However, in my experience, they shouldn't be overused. The main Executable UML book [xtUML02] defines Use Cases very simply leaving out a lot of the more advanced features defined in UML Use Cases. Unfortunately, there are a few issues with how the basic features described in the book relate to the rest of Executable UML, e.g. how actors relate to external entities and interactions relate to external signals. I produced a simple information model for basic Use Cases and I plan to add it to the OOA of OOA as a new subsystem in the future. Two new diagrams will need to be supported: Use Case Diagrams and Use Case Activity Diagrams. I did have a think about whether to use Process Model notation for the Shlaer-Mellor equivalent of Use Case activity diagrams. However, I'm not sure anything would be gained since anyone defining use cases will expect to use UML notation to do so. Anyway, I'm not planning on implementing Use Cases until after the simulator is finished.

One of the tasks associated with the OOA Dictionary work was a facility to view the dictionary from within OOA Tool. I implemented a report view to do just that. However, images are always loaded from URLs in JEditorPane which gave me a headache since I don't want to extract the large number of icon image files out of the main OOA Tool Jar file. I eventually managed to work out how to create a custom ImageView that would load the icon images from the class path. This discovery should also allow me to clean up how Information Model Reports currently show graphical model images, i.e. the current design involves saving the image to a file and then referencing the file as a URL within the HTML report. This is a horrible design since no one expects a view operation to save a file in the background. This should only happen when the user wants to save the report as a HTML file. This change should also enable OOA Tool to be run as an applet within a web browser which I want to be able to do in the near future.

After testing what CSS styles are now supported in the Java SE 6 version of JEditorPane (so that I could format the OOA Dictionary within a report view), I decided to download the latest version of JDK 7 to see what future support there will be. The last build I downloaded was build 47 which I had no problems with. The latest early access build is 72. After I installed it I discovered OOA Tool wouldn't even build due to numerous inferred type errors. It pretty much ruined the rest of my day since I had to change numerous bits of code where Generic types were mixed with raw types. These errors aren't even warnings in previous JDK versions! JDK 7 now applies stricter mandatory rules which I'm sure will effect other people as well. I also had to download the latest version of Ant (version 1.7.1) to get my build scripts to work. After finally getting OOA Tool to build and run, I discovered that JDK 7 does have better support for CSS styles which was a bit of good news after a day of pain.

So next week, I have a few more dictionary entries to complete and then I can get back to doing something else - exactly what has not been decided yet!