Week 5 of 2009

I was pretty confident that Build 013 would be released last week. However, I spent the first couple of days implementing Project Matrix support which wasn't even scheduled yet! I then spent another couple of days implementing a test harness to check the internal metamodel that I use to create metamodel population data. This identified a number of inconsistencies which I fixed and a couple of OOA Tool and metamodel bugs which I also fixed. Metamodel population is now complete. However, I still need to finish model population editing forms and a few related issues. Build 013 will be released this week without fail (I hope!).

The Project Matrix concept was first discussed in [ProjMatx84] and later adopted as part of the Shlaer-Mellor Method. I have modelled the underlying task and activity concepts as part of the Recursive Design subsystem of the OOA of OOA. Users can create whatever tasks they want to monitor and document on a project. The Project Matrix table shows tasks as rows and domains/subsystems as columns with activities as cells. A short note can be provided for display within an activity cell while a long note can be provided for display when an activity cell is clicked. The original paper on Project Matrix usage also suggested that the process behind the tasks being used should be documented using a process model allowing work flows and work products to be captured. This idea did not appear in any of the Shlaer-Mellor books. However, it may be worth following up once process modelling has been added to OOA Tool. There are no predefined tasks within OOA Tool at present. However, the notation of formalizing the Shlaer-Mellor Method as a process model with predefined tasks for small, medium and large projects is an attractive one.

Now you might be wondering what the internal metamodel test harness is needed for. OOA Tool could simply load the official metamodel and try to populate this directly when performing metamodel population. However, the Java population code would be very brittle and since the official metamodel has a tendency to change over time, this would lead to numerous bugs. The solution was to hardcode the official metamodel into a version specific population module. This hardcoded metamodel uses plenty of static constants to ensure Java population code doesn't get out of sync without compile-time errors appearing. The problem I then had was ensuring that the internal metamodel was not out of sync with the external official metamodel. This required a lenient project comparison facility since the internal metamodel treats all attributes as simple attributes (see discussion on static metamodel population below). However, the internal metamodel still uses all of the data types defined in the official metamodel for attribute value validation. Thus the job of the test harness was to report any differences between the internal and external metamodels. As it turned out there were a few errors detected which have been fixed. The need for a True Attribute object in the Information Model subsystem of the OOA of OOA was also discovered during this process.

It should be pointed out that a metamodel population is entirely static within OOA Tool while a model population needs to be dynamic reflecting relationship changes as they occur, i.e. referential and polymorphic attributes need to resolve their values across relationships. Making the metamodel population dynamic would be an enormous task since many of the relationships within the metamodel have very different representations within OOA Tool. This is compounded by the fact that old versions of the official metamodel need to be supported in OOA Tool ensuring that archetype templates don't need to updated every time the metamodel is updated. The main disadvantage to making metamodel populations static is that they must be manually repopulated by the user before running any translations.