Wednesday 23 December 2009

Week 51 of 2009

I have spent the last week tidying and fixing various OOA Tool GUI forms. The process that I am following at the moment is that I start by checking model element classes against the OOA Interchange Format DTD. Once I'm happy there, I move on to checking any associated forms against the model element classes (most have at least one GUI form). Since many of the forms perform derived calculations using temporary information from the forms, their logic must match that used in the model elements themselves. It has not always been easy to eliminate duplication here and that has lead to some errors creeping in.

I also got a little sidetracked adding a navigation button mechanism for reference fields to the form editor. As I tidy up each form now, I'm swapping old reference fields to the new ones allowing users to immediately edit/view any associated model elements. This saves a lot of time when navigating a big model. Check out the data type forms to see this in action.

I had hoped to complete and release OOA Tool 1.0 Build 014 before Christmas but that isn't going to happen now. However, I know some people would like to look at some of the features that I have implemented over the last many months, e.g. polymorphic attributes. Thus, I'm going to release an ALPHA version of OOA Tool which should not be used to create models that you want to keep since you may not be able to load the models into the BETA version that will be released in a few weeks. An ALPHA version of OOA Tool can be downloaded from the following link:

2009-12-23_OOATool014_ALPHA (8.30 MB)
Although, the release has been compiled so that it can be run using J2SE 5.0, it should really be run using Java SE 6.0 so that you can see the new Nimbus look and feel in action.

Anyway, it's almost Christmas. Things are slowing down here a lot as usual! We have had lots of snow here in Colchester which is nice. I hope everyone has a good Christmas holiday. Don't forget to start thinking up some New Year resolutions.

Wednesday 16 December 2009

Week 50 of 2009

I had planned to publish this weekly report Monday but I thought I would just update a few web pages first. I then thought I would tidy up a few form classes fronting some data type classes before finishing changes to one of those pages. Now here we are and its Wednesday! I miss the discipline of working in a team reporting to someone who is always in a hurry.

Anyway, I have started checking my model classes against Version 0.05 of the OOA Interchange Format DTD and noting differences from the previous version. I've also started updating the change log on the main OOA Interchange Format page. I will also shortly be updating the change log in the OOA Tool Read Me detailing overall differences from the previous build. It's been so long since the last build was released I can't even remember what it looked like! I will continue to update these change logs until the next build is released now.

I spent most of the week in the Data Type subsystem since data types were poorly supported in the last build but are fully supported in the next build. This work is now complete except in relation to data type operators which is really part of the Operation subsystem. The only type of data type that is not supported is Composed Type which is discussed in [xtUML02]. Maybe I will add it in the future if I see a good justification for supporting it.

I also updated my References page to include the new book Model-Driven Development with Executable UML by Dragan Milicev [OOISUML09] which I bought from Amazon. It is a very meaty read (786 pages) and I have only just started to read it. Definitely a job to do while relaxing in a Coffee shop. The book discusses a new executable UML profile which it calls OOIS UML. I have yet to find a single mention of xtUML or xUML which is a bit disappointing. Obviously the author didn't want to be associated with any of this work. Dragan Milicev is based out of Belgrade and English probably isn't his first language. Yet, the text book is written in clear plain English (unlike some foreign text books). The author also presents his arguments in a logical incremental way which I like. Don't be put off by the fact that either the author or the publisher thought that the best way to market the book was to stick a big picture of the author on the book's cover! That might be a good strategy if the author was a nice looking lady since most of it's readers would be male but I'm not sure it was a good idea in this case. Anyway, once I have read more of the book, I will give a more complete review.

Monday 7 December 2009

Week 49 of 2009

A friend mentioned that I should take a look at SEMAT which is a new initiative to identify and formalize the theory behind and the kernel processes underpinning good software development practice. It's a very new initiative with a long list of supporters already. However, what do they really hope to accomplish?

Looking at the processes involved in software development is not what is lacking at present in my opinion. We really need to establish higher-order work products that are reusable across a wide user base. These higher-order work products need to be independent from but translatable to multiple platforms. This is what Shlaer-Mellor OOA/RD was (and still is via OOA09) and UML/MDA is meant to be achieving. Unfortunately, 99.99% of all developers continue to program applications with standard programming languages and techniques. As long as developers continue to mix implementation concerns into application concerns, broad reuse will continue to be a dream. An executable model capturing application concerns separately from implementation concerns is the only viable way to move the software industry forward. Who do we want to be doing implementation programming in 50 years? Us? No. Machines should be implementing solutions to our problems. We should be implementing those machines and innovating sophisticated service domains. We should be moving to a world of software factories and engineering laboratories not maintaining software sweatshops.

The articles on the SEMAT website talk about fashion and politics with regard to current software development practice. This will always be the case when you involve lots of people in any activity. I don't think there is much we can do about that. However, the basic premise behind SEMAT which is that a theory and set of kernel processes will make all the difference is wholly wrong in my opinion. I'm not against process initiatives such as the CMM (I haven't really looked at the current incarnation) which can be used to improve software quality within organizations. However, this doesn't move us away from software sweatshops it only ensures product quality and that everyone is sweating at an optimal level!

I won't be adding my support to SEMAT and I don't recommend that anyone else add their support to this mostly pointless initiative especially if you are already contributing to code generation activities elsewhere.

Rant over. I don't have much progress to report this week since I have been bogged down finished off stuff and fixing several bugs. However, I still expect to release Build 014 of OOA Tool before Christmas.

Wednesday 2 December 2009

Week 48 of 2009

My Internet is back! Life is just not the same without an Internet connection anymore. My girlfriend has been pigging out at the local McDonald's which is the nearest wifi point to our house so that she can run her web business. It brings to mind the Over-Logging episode of South Park where the Internet goes down. I like Virgin as a provider in general but their phone support is unbelievably bad. Even worst than BT's phone support! I only got thru to report a fault by ringing their 'I want to leave' phone number.

Anyway, the last week has not been one of my most productive. I've gotten myself bogged down with Name Management integration changes. I've also found and fixed a few bugs. I like the improvements but what the hell was I thinking when I decided to upgrade Naming to Name Management? I should be focusing on getting Build 014 out. I'm not going to spend anymore time on this report since I'm sure you would all like to see more progress and less chatter!

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.

Monday 16 November 2009

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.

Wednesday 4 November 2009

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!

Monday 26 October 2009

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.

Monday 19 October 2009

Week 42 of 2009

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

Monday 12 October 2009

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.

Monday 5 October 2009

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.

Monday 28 September 2009

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!

Monday 21 September 2009

Week 38 of 2009

I started this week by finishing off the view factory logic I mentioned last week. I discovered that Java reflection and generics don't mix well! The old factory logic used reflection to create a view using a standard constructor. However, I had to change all the view constructors to reference their model elements generically. Unfortunately, you don't seem to be able to create the generic parameters that are required to invoke the constructors using reflection. I've probably just missed something really simple! Anyway, I decided to implement the factory longhand using a big switch statement. A big advantage of this approach is that the compiler can check the constructors exist at compile time. The only disadvantage is the big and ugly switch statement.

The next thing I did was a total sidetrack but a useful improvement. I've extracted all notation specific object/role names from model elements into an OOA Dictionary. The dictionary provides the Shlaer-Mellor, Executable UML (xtUML) and Executable UML2 (xtUML + UML2) names and icons for all object/role names. The OOA Dictionary webpage just referenced is automatically generated from OOA Tool rather than manually maintained. This means that each future build will allow the user to browse the dictionary that is specific to that build since these names (and icons) are still evolving. I've also added the dictionary as a resource to the main website. However, this will always contain the latest version of the dictionary which may differ from that used in any given OOA Tool build.

A very interesting possibility now that I have a notation switchable dictionary within OOA Tool is that I could use it to convert any OOA of OOA within OOA Tool to use Executable UML terminology. I will need to extend the dictionary to include attribute names, verb phrases and role names. However, the vast majority of these either overlap the object/role names or won't need to be changed. Diagrams do need to be scaled after these conversions. However, I could determine appropriate defaults so that completely changing notation on a loaded metamodel is a one click action.

An even more interesting possibility is that I will be able to generate Executable UML metamodel populations so that archetype templates can reference Executable UML classes and attributes rather than Shlaer-Mellor objects and attributes. For example, the following simple archetype template which generates a list of qualified object names:

.select many objects from instances of Object
.for each object in objects
.select one domain related by \
Object: ${domain.Name}.${object.Name}
.end for
.emit to file "ObjectList.txt"
could alternatively be coded as:
.select many classes from instances of Class
.for each class in classes
.select one domain related by \
Class: ${}.${}
.end for
.emit to file "ClassList.txt"

OK, so what's next. I need to finish the OOA Dictionary webpage generator and ensure that all views reference the dictionary rather than hardcode notation specific labels. I also need to add a menu item (on the Help menu) for viewing a build specific dictionary within OOA Tool. After that I'm not sure since my To Do List is way too big and I seem to be picking items at random at the moment! I would like to hear from people with regards to what UML/UML2 names I should be using within the OOA Dictionary since I wouldn't claim to be an expert on UML terminology since it keeps changing!

Monday 14 September 2009

Week 37 of 2009

Java SE 6 executable Jar files don't seem to be limited to 64M on Vista x64 which means that running OOA Tool by clicking the Jar is probably better in the next release than running the Batch or Shell scripts that I also include in releases since event logging is now captured and viewable within OOA Tool. After some checking via Google, I discovered that executable Jar files can be executed with any JVM options by altering the following registry entry on Windows:

The current value on my machine is:

"C:\Program Files\Java\jre6\bin\javaw.exe" -jar "%1" %*
Changing this to the following increases maximum memory to 256M:

"C:\Program Files\Java\jre6\bin\javaw.exe" -Xmx256M -jar "%1" %*
However, this step doesn't seem to be necessary on Vista x64 since OOA Tool starts up with 903M by default on my machine! I'm not sure what you need to change to do the same thing on a Mac or under Unix.

My JBuilder 2005 IDE finally seems to be having problems building OOA Tool by itself. I have already had to work around some nasty JBuilder bugs, e.g. you can't break or continue directly out of a nested loop since JBuilder generates some shit bytecode that doesn't work. Note that all releases are built using an Ant build file and the latest JDK so these problems only effect me since I want to be able to instrument and step thru code using the JBuilder debugger. The latest problem seems to be related to too much complexity involving Java Generics. The JDK builds all of my stuff without a single warning (although I do have to use a few @SuppressWarnings("unchecked") directives). I can even build my stuff using JBuilder itself if I build all packages bar one first and then build the last package afterwards!

I have considered upgrading JBuilder to the latest version except they have moved JBuilder onto the Eclipse platform which means I will have to learn the Eclipse IDE to use it. If I'm going to learn Eclipse I don't see what additional benefits I would get from buying JBuilder since I'm not currently a Java Enterprise user. I also don't use JBuilder's GUI builder. If Embarcadero Technologies wants users like me to move to the latest version then they need to make the Professional version of the tool cheaper or they need to provide a Foundation version for free like they did in the past.

I mentioned Vista for the first time at the beginning of this blog because I have recently bought a new laptop (my old laptop kept overheating and shutting down). It's the first machine I have had with Vista, previous machines have all been running XP instead. It's also the first 64 bit machine I have had so I can now see how well Java x64 runs. There doesn't seem to be any problems running OOA Tool. A screenshot from my laptop is shown below:

From the screenshot, you can see that load times are longer in the latest build. This is a consequence of a safer model element design and the fact that I haven't spent any time optimizing load times yet. Most users will not need to load more than one project on startup so load times should not be more than a few seconds anyway.

One big drawback with Vista is that I can't get JBuilder 2005 to even install never mind run. I've tried copying the installed directory over from my desktop machine (as recommended by other developers in my position) but it still doesn't run. It looks like I will have to move to Eclipse once my desktop machine packs in.

OK, so what have I been doing other than messing with Vista and JBuilder this week? I have spent most of the week refactoring an application wide factory into OOA Tool. The existing design included two types of factory: model element factory methods which are defined on parent model elements (e.g. OOAObject class defines a createAttribute() method), and editor view factory methods which create an appropriate form/diagram/table/report view for a given model element. To debug OOA Tool I often have to tweek methods in various model elements to determine what's happening. I also have to add workarounds for backwards compatility. However, I really want to be able to subclass model elements when debugging and move any backwards compatibility code out of the main model element classes into subclasses. To do this with the current design requires subclassing at several levels, e.g. to create a new Attribute subclass we need to create new OOAObject, InformationModel, Domain and Project classes since creation is delegated at each level.

The solution on the model element side was to add a factory reference to all model elements. Root elements are passed a factory but have no parent. Non-root elements are passed a parent and optionally passed a factory. If no factory is given then a non-root element uses the factory of the parent. I also wanted to statically scope factories using Generics so the new signature of the ModelElement class is given below along with a brief outline of OOAObject:

public interface ModelElementFactory { }

public abstract class ModelElement<F extends ModelElementFactory,
                                   P extends ModelElement<F, ?> {
    private F m_factory;

    protected ModelElement(P parent, F factory, boolean deleted) {
        if (factory == null) {
            throw new NullPointerException("Factory required");
        // ...

    protected ModelElement(F factory) { // Root element constructor
        this(null, factory, false);

    protected ModelElement(P parent) { // Non-root constructor
        this(parent, (parent != null) ? parent.getFactory() : null,

    public final F getFactory() {
        return m_factory;

public interface OOAFactory extends ModelElementFactory {
    public Attribute createAttribute(OOAObject parent);

public class OOAObject<F extends OOAFactory>
        extends ModelElement<F, InformationModel<F>> {
    public OOAObject(InformationModel<F> parent) {

    public Attribute createAttribute() {
        return getFactory().createAttribute(this);

I'll leave this weeks report there since we seem to be getting a little bit technical with all this Java coding! Hopefully, I'll have more modelling specific stuff to report next week.

Monday 7 September 2009

Week 36 of 2009

A few distractions derailed this week's activities since they gave me some thinking time and I came up with a few new ideas! The main one being to merge in some Swing components that I developed just prior to starting this project. These components included: a console and I/O library for interactive console-like editor panes, an enhanced event logger (mostly internal benefits), and a status bar panel. I have now added a consoles tabbed pane at the bottom of OOA Tool and a status bar panel right on the bottom edge.

The consoles tabbed pane will always contain a System Log of colour-coded events which were previously sent to standard output. The System Log is highly configurable with many filtering and formatting options. It also allows logs to be saved as XML files. You will also be able to create command consoles for interacting with operating system specific shell environments. Simulation and translation logs will also appear here in the future.

The status bar includes a message area, a locale indicator (language only) and a clock. The main user of the status bar at present is the model element browser which displays the currently selected element in the status bar. Since the browser is normally given very little width, many elements will not be entirely visible in the browser. The status bar provides an easy way to see longer elements, i.e. just select the element. Both screenshots below demonstrate this.

The following screenshot shows OOA Tool (using the Java SE 6 Nimbus look and feel) after the Object.Prominent attribute has been changed (notice the pencil on the attribute's icon):

The following screenshot shows log messages at different levels in different colours (demonstrating some current BP loading problems!):

This new distraction has left a few loose ends to resolve. I need to do a sweep thru the code base ensuring that only the new event logger is used. I need to add a new View menu to the menu bar allowing some control over which panes are visible beyond the split pane controls. I also need to check the new components don't have any problems using the Nimbus look and feel. An ability to select locale will also be added.

I also need to think about resource bundle usage (for multiple language support) within OOA Tool since the new components already ultilize them. The main problem here if we want to fully support other languages is that Shlaer-Mellor and Executable UML names are very carefully thought out and controlled, more so than normal user interface titles and messages. Does anyone out there have any views with regard to additional language support? What do French, German, Russian, Japanese, Chinese etc. modellers want to see - English or their own language? Are there any UML tools out there that convert the UML metamodel into non-English for non-English users?

Monday 31 August 2009

Week 35 of 2009

Most of this week I have been finishing the changes that I started last week - the last 20% always takes longer than you expect! I have also been resolving some imported shape problems in Object Model diagrams (OIMs, OCMs and OAMs). Skip over the next few paragraphs for details.

One of the problems I discovered (in that last 20%!) was how responsive deleted model elements need to be while a project is being loaded. One of the changes I made was to stop deleted model element listeners from doing anything except awaiting a request to clear their deleted status. This reduces unnecessary derived calculations and stops listeners from expanding their listening scope until after their deleted status is cleared. The problem that I discovered was that some derived fields must be calculated so that cross references during loading can be resolved prior to those model elements having their deleted status cleared.

A massively cut down version of the Identifier class is shown below to highlight current listener design and the problem I mention above:

public class Identifier extends ModelElement<OOAObject>
        implements OrderedElement<OOAObject> {

    public static final String IDENTIFIER_ID_PROPERTY = "identifierID";

    public IdentifierListener implements PropertyChangeListener {
        public IdentifierListener() {

        protected void checkDeleted() {
            if (isDeleted()) {
                for (Attribute attribute : m_identifyingAttributes) {
            } else {
                for (Attribute attribute : m_identifyingAttributes) {

        public void propertyChange(PropertyChangeEvent event) {
            Object source = event.getSource();
            String propertyName = event.getPropertyName();
            if (source == Identifier.this) {
                if (propertyName == DELETED_PROPERTY) {
                } else if (propertyName == ORDER_PROPERTY) {
                } else if (isDeleted()) {
                    // Do nothing else if deleted
                } else if (propertyName == IDENTIFIER_ID_PROPERTY) {
                } else if (propertyName == IDENTIFYING_ATTRIBUTE_PROPERTY) {
                    Object oldValue = event.getOldValue();
                    if (oldValue instanceof Attribute) {
                        ((Attribute) oldValue)
                    Object newValue = event.getNewValue();
                    if (newValue instanceof Attribute) {
                        ((Attribute) newValue)
            } else if (source instanceof Attribute) {
                if (propertyName == Attribute.NAME_PROPERTY
                        || propertyName == Attribute.ORDER_PROPERTY) {

    private int m_order; // Set by parent object
    private String m_identifierID;
    private Identifier[] m_identifyingAttributes;

    public Identifier(OOAObject parent) {
        m_order = 0;
        m_identifierID = "";
        m_identifyingAttributes = Attribute.EMPTY_ATTRIBUTES;
        addPropertyChangeListener(new IdentifierListener());

    public final String getIdentifierID() {
        return m_identifierID;

    public void setIdentifierID() {
        int order = m_order;
        if (order == 0) {
        String identifierID = (order == 1) ? "I" : "I" + order;
            // Don't use order if 1 since "I1" looks confusing
        String oldIdentifierID = m_identifierID;
        m_identifierID = identifierID;
                          oldIdentifierID, identifierID);
Since identifier ID is used to reference target identifiers within participant mappings then it must be calculated even if identifier is currently deleted. However, the identifier ID calculation which depends on order being set by a parent OOAObject still requires the identifier to have been added to the parent object.

From the example above, you can see that all model elements have a model element instance and a separate listener instance (sometimes more than one). The listener drives all derived calculations and arranges for the spread of itself to other instances of interest. The new deleted status is used to control all such listeners but some derived calculations must continue independent of the deleted status. This is a consequence of using mathematically dependent attributes in preferred identifiers. I'm sure this is going to be an interesting problem to solve when I start creating my model compiler!

I can't remember whether I've already mentioned a name change (that I made some time ago) from Terminator to External Entity. The original Shlaer-Mellor books used both terms and I adopted the term Terminator (short and sweet!). However, other tool vendors all adopted the term External Entity instead. I later introduced an Entity supertype object above Terminator and Object. I finally decided to bite the bullet and replace all use of the term Terminator with External Entity. Both iUML and BridgePoint still use the term External Entity as a kind of Actor. However, OOA Tool simply uses Actor instead of External Entity when Executable UML notation is selected.

The problem with imported shapes is that imported objects (in OIMs), imported state models (in OCMs/OAMs) and external entities (in OCMs/OAMs) without links to other shapes on those diagrams are not reimported when a project is loaded. The original justification being that those shapes must be redundant. However, I now reimport those shapes if they exist in the XML project file. I have also added some extra actions to the OCM and OAM diagram editor to allow users to add existing external entities to those diagrams and remove them from specific diagrams. Obviously, external entities which have links to other shapes can't be removed. Once the next build is released I will have to update the various technical notes discussing OIMs, OCMs and OAMs.

A related issue is Subsystem Model diagrams (SCMs and SAMs) which don't currently show external entities at all. However, I think I will allow users to add external entities allowing subsystem communications/accesses to those external entities to be shown. I debated this issue with myself when I first coded the editors for those diagrams and I decided to stick with what is shown in the original Shlaer-Mellor books. However, I like the idea of being able to see subsystem communications/accesses to external entities and I think I will take advantage of the above change that I made with regard to reimporting shapes during project loading. However, I haven't coded this up yet.

Now, I have some loose ends to sort out and I need to finish off the technical note on identifiers but then I will refocus myself on the outstanding items required to get Build 014 released. I remember the days when I had a team working for me and I could delegate (sweet...)!

Monday 24 August 2009

Week 34 of 2009

This week I started with a nice Costa coffee (I like Starbucks but their cafe in Colchester has unfriendly staff and poor seating). I should have been nailing down the outstanding issues holding back Build 014 of OOA Tool. Instead, I had a think about some of the annoying design decisions I made when I started creating the model elements that realize the OOA of OOA within OOA Tool.

One of the most annoying (for me) is that I associate a dynamic parent with each model element. On reflection, a static unchanging parent is much safer and entirely acceptable for OOA Tool. You might not think it makes much difference. However, there is an enormous amount of listener code within these model elements allowing derived fields to push their changes out to GUI listeners which update the GUI as and when changes occur. There is also lots of unnecessary parent status checking. I also take advantage of the fact that the parent of a child is cleared when it is removed from the parent. Of course, removing the parent can cause problems with the deleted model elements which may still be in use! Thankfully, programmer deletion is logical rather than physically in Java so I don't need to worry about memory being reclaimed while still in use.

I also associate a changed status with each model element which I recursively clear after a project is loaded or saved. However, I hadn't got around to setting the changed status when non-derived fields are changed. An annoying side-effect of this was that I couldn't check whether any projects had been changed when the application is exited, i.e. a confirmation dialog is always popped up - very annoying.

A cut down outline of the ModelElement class is shown below:

public abstract class ModelElement {
    private ModelElement m_parent;
    private boolean m_changed;

    protected ModelElement() { }

    public ModelElement getParent() { }
    public void setParent(ModelElement parent) { }
    public abstract ModelElement[] getChildren();

    public boolean isChanged() { }
    public void setChanged(boolean changed) { }
    public boolean isChangedAnywhere() { }
    public void setChangedRecursively(boolean changed) { }

    protected void firePropertyChange(String propertyName,
            ModelElement oldValue, ModelElement newValue,
            boolean child) {
        if (oldValue != newValue) {
                propertyName, oldValue, newValue);
            if (child) {
                if (oldValue != null) {
                if (newValue != null) {

A cut down outline of the new improved ModelElement class is shown below:

public abstract class ModelElement<P extends ModelElement> {
    private P m_parent;
    private boolean m_deleted;
    private boolean m_changed;
    private boolean m_changedAnywhere;

    protected ModelElement(P parent) { }

    public P getParent() { }
    public abstract ModelElement[] getChildren();

    public boolean isDeleted() { }
    public void setDeleted(boolean deleted) { }
    public void setDeletedRecursively(boolean deleted) { }

    public final boolean isChanged() {
        return m_changed;
    public void setChanged(boolean changed) {
        boolean oldChanged = m_changed;
        if (changed != oldChanged) {
            m_changed = changed;
                CHANGED_PROPERTY, oldChanged, changed);
            ModelElement modelElement = this;
            while (modelElement != null) {
                modelElement = modelElement.getParent();
    public final boolean isChangedAnywhere() {
        return m_changedAnywhere;
    public void setChangedAnywhere() {
        boolean changedAnywhere = m_changed;
        if (!changedAnywhere) {
            for (ModelElement child : getChildren()) {
                if (m_child.m_changedAnywhere) {
                    changedAnywhere = true;
        boolean oldChangedAnywhere = m_changedAnywhere;
        m_changedAnywhere = changedAnywhere;
            oldChangedAnywhere, changedAnywhere);
    public void setChangedRecursively(boolean changed) {
        for (ModelElement child : getChildren()) {

    protected void firePropertyChange(String propertyName,
            ModelElement oldValue, ModelElement newValue,
            boolean child, boolean derived) {
        if (oldValue != newValue) {
                propertyName, oldValue, newValue);
            if (child) {
                if (oldValue != null && !m_deleted) {
                if (newValue != null && !m_deleted) {
            if (!derived && !m_deleted) {

This requires parents to be statically declared using Java generics and requires the parent to be passed to the constructor. The only root element without a parent being a Project in OOA Tool. However, it is still useful to know when a model element is removed so a new deleted status was added. The setting and clearing of this status is done when property changes are fired. I have also been able to clear up some minor memory leaks by making use of the deleted status to add or remove nested listeners in line with the deleted status.

I also added another flag to firePropertyChange() indicating whether a derived change has occurred. This allows us to set changed statuses automatically as a consequence. Since we have a fixed parent now we can also fairly easily determine a changed anywhere status for each model element where anywhere indicates at or below a given model element. The old design required a recursive check to be performed on request to determine whether changed anywhere. OOA Tool now adds a changed (or changed anywhere) overlay icon to tree browser icons when changed or changed anywhere statuses are updated. It can also be determined if any projects have changed when the user exits the application, i.e. no redundant dialog. However, there is a limitation here in that if a change is made and another change follows it which undoes the previous change, the model element will still be flagged as changed. This doesn't occur in any of the editor dialogs since they record the original values and always check the current values against the original values when determining whether a change has occurred.

These changes (80% done now) were for the most part straight forward except for the fact that there are 336 model element classes (744 classes in total)! However, there were a few places where I unnecessarily took advantage of dynamic parents and this code needed to be rewritten.

OK, this was a serious side-track from my current priorities. However, I am very happy with the changed and changed anywhere indicators in the tree browser. I am also much happier that the parent is always set now and its type can be statically determined reducing the need for so many casts.

Monday 17 August 2009

Week 28/29/30/31/32/33 of 2009

OK, back to the Shlaer-Mellor and Executable UML grindstone. I've have a few weeks away from modelling and tooling to clear my head. My highest priority now is to create a stable build to release the many features I have added and changes I have made to OOA Tool. The outstanding issues holding up the release are:

  • reworking OOA of OOA Metamodel 0.01 population logic since I have considerably expanded the Information Model and Data Type subsystems,
  • finishing the outstanding chunks of operation logic including predefined operations on all data types,
  • and reviewing and documenting OOA Interchange Format Version 0.05 since lots of changes have been made (but OOA Tool will still be backwards compatible with Version 0.04).
The next build won't include a working simulator since I'm not happy with all the semantics yet and I don't want people investing time creating Action Language code until I'm happy.

Over the last week, I had a good long look at the subject of object ordering within information models (another diversion!). Complete orderings across child-parent relationships are already handled using Arbitrary ID Attributes and Parent Allocated ID Types (important note to self: finish the technical note on Arbitrary and Ordinal IDs so that people know what I'm talking about!). Partial and complete orderings across objects within Action Language code is handled using an ordered by clause on select statements. However, such orderings are transitory in nature and prone to becoming out of date when an information model changes, e.g. what was once a complete ordering can become a partial ordering without anyone noticing. With regard to complete orderings, the logical place to look in an information model is an identifier since an identifier specifies the minimum information required to define a complete ordering. This lead me to subtype identifiers as either Unordered Identifiers or Ordered Identifiers (see Information Model). Now I'm not going to say too much here since I want to discuss the issues in full in a technical note on Identifiers which I hope to publish soon. However, objects can now define a preferred identifier and an ordered by identifier. If the latter is specified then the object in question is ordered and object instances can be compared using normal relational operators within Action Language code.

This work on ordered identifiers has also allowed me to think how limited but meaningful aggregation and composition relationships could be defined within Executable UML models. Composition relationships could result from child-parent relationships that result directly from Parent Allocated ID Types since those parents have specific duties to manage their children (even though those duties are automatically handled by a software architecture). While aggregation relationships could result from child-parent relationships that result from ordered identifiers. I'm going to add support for hollow and filled diamonds into OOA Tool and see how these ideas work within my example models.

Anyway, I hope to get back to weekly reporting now. If anyone wants to discuss any ideas then don't be shy.

Tuesday 7 July 2009

Week 26/27 of 2009

During the first week, I defined a new type of operation called an operator (unary operator, binary operator or dot operator). Operators are always owned by data types. Unary operators include: not, +, -, empty, not_empty and cardinality. Binary operators include: or, and, ==, !=, <, <=, >, >=, +, -, *, / and %. There are no plans to allow custom operator symbols at present. Dot operators are like object instance processes except that they are invoked on a data value operand rather than an object instance reference. However, all dot operator names must be unique within a data type. OOA09 does not allow any operation name (excluding operator symbols) to be overloaded using different sets of input parameters.

Operators were introduced so that the semantics of predefined operators on core types could be specified within a model. However, they now also allow new data types to be defined with custom semantics for those same unary and binary operators. For example, the Extended Boolean data type mentioned in [DataType97] can now be specified with correct implementations for not, and and or. However, to ensure operators are side-effect free, severe restrictions have been placed on what can be done within an operator body, i.e. operators can't access objects at all, can't generate events and can only invoke other operators.

During the second week, I spent some time nailing down process modelling. Other Shlaer-Mellor and Executable UML tool vendors have taken the view that process modelling adds no value. However, I think that process modelling provides the perfect mechanism for defining concurrent data flows within composed operations. To better facilitate the work, I split the old Process Model subsystem in the OOA Tool Model into a new Operation subsystem and a more focused Process Model subsystem. The Data Dictionary subsystem was also renamed as the Data Type subsystem at the same time. Process models in OOA09 allow concurrent data flows to be safely specified within a composed operation (action or synchronous service) since circular data flows are not allowed. However, most composed operations won't benefit from concurrent data flows and are more easily defined using an Action Language statement block.

Tuesday 23 June 2009

Week 24/25 of 2009

Progress has been slow over the last few weeks since I have been away in Nottingham empting a 20ft storage container holding all sorts of junk! I'm now trying to focus exclusively on coding operation support in OOA Tool. If I were working in a team as I have done in the past then we would sit around planning and reviewing a detailed design before we started coding each set of features. However, when you are working alone then the only approach that works in my experience is continuous prototyping and refactoring. Unfortunately, it can result in wasted effort when bad design decisions are discovered. I had planned on releasing Build 014 ages ago but implementing operation support has raised lots of issues which have lead to rework several times. In the previous weeks I have nailed down Recursive Design bridging operations. During the last week I have sorted out operation ownership which I discuss below. However, there is still more coding to do before operation support is finished.

In OOA09, operation ownership is split between real ownership and name ownership. Real ownership is the natural consequence of which OOA of OOA element is responsible for defining what operations, e.g. a Bridge defines and thus owns bridge operations. Name ownership is a partial relationship (i.e. not all operations are named) connected with Action Language syntax (i.e. how names are used to identify specific operations within code). All operations now have a mathematically dependent Name Owner Category attribute whose value is either:

  • None indicating an operation has no name,
  • Owner indicating the real owner is also the name owner,
  • Active Object indicating the active object associated with the lifecycle model which is the real owner defines the naming context,
  • Partitioning Object indicating the partitioning object associated with the multiple assigner model which is the real owner defines the naming context,
  • or Supertype Object indicating the supertype object of the subtype-supertype relationship associated with the polymorphic destination which is the real owner defines the naming context.
This attribute is used to navigate a mathematically dependent relationship to the name owner of a given operation. This classification took some time to resolve and there are issues with allowing non-Object owners to be name owners, e.g. Executable UML associates all operations with Classes while single assigner models in OOA09 can define state model processes whose names must be qualified using the assigner label prefix of their owner.

The table below lists all operation types along with their real owners and name owners:

OperationOwnerName Owner Category
Domain ObserverDomainNone
Bridge MappingBridgeNone
FunctionInformation ModelOwner
Attribute CalculationObjectNone
Relationship NavigationMathematically Dependent RelationshipNone
ActionState ModelNone
Synchronous ServiceTerminatorOwner
State Model ProcessLifecycle ModelActive Object
State Model ProcessSingle Assigner ModelOwner
State Model ProcessMultiple Assigner ModelPartitioning Object
Polymorphic ProcessPolymorphic DestinationSupertype Object
Bridging ProcessTerminatorOwner
Synchronous Return WormholeTerminatorNone
Asynchronous Return WormholeTerminatorOwner

From the table, it is clear that many operations have no name since they can't be explicitly invoked and thus require no name. Synchronous return wormholes require no name since they are always invoked on a specific return coordinate. Asynchronous return wormholes are given a name even though they are always invoked on a specific transfer vector but only so that transfer vector types can be meaningfully labelled.