Monday, 26 January 2009

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.

Monday, 19 January 2009

Week 4 of 2009

The last week has gone too quickly again! I've been coding and testing most of the week trying to finish stuff for the next build. I'm almost there now. I still have some work to do on population editing forms and metamodel relationship population logic. I'm pretty confident now that Build 013 will be out this week.

I've also been having a number of discussions with people about reviewing parts of OOA09. The number of people interested in participating is increasing but I still need a few more reviewers. So if you would like to participate in OOA09 reviews get in touch now. The current plan is that all reviews will be conducted in the forum. The first review will cover information modelling and in particular the Information Model subsystem of the official metamodel:

Information Model Report
The above report doesn't include object, attribute or relationship descriptions yet but it will do before the review starts.

Don't be shy, get in touch if you want to talk about any Shlaer-Mellor OOA/RD or Executable UML/MDA topic.

Monday, 12 January 2009

Week 3 of 2009

First week is now over and I'm not sure where it all went! I've been answering lots of email, tweaking stuff on my website, getting a tooth filled, adding an RSS feed to the Portal website so that users can be informed whenever new releases are made.

I also read Leon Starr's recent article Time and Synchronization in Executable UML. It discusses the fact that time is relative to each state machine, actions aren't interruptible, events aren't lost while actions are being processed, events are processed one at a time and that events aren't generally ordered. The two exceptions being that events sent from a specific state machine to itself are always processed before other events and that events sent between two specific state machines are always ordered. What the article doesn't discuss is synchronization of access to attribute values or relationship instances. Since any state machine can access any attribute values and navigate any relationships, this is a significant synchronization issue which is left to the software architecture to sort out.

OOA09 will have to address this issue to ensure domains are reusable across different software architectures. This will be done by introducing units of locking and a locking strategy. Units of locking will be either accessor processes or complete actions if there is no process model (accessor actions or complete procedures in Executable UML). Basic locking strategy will be either none, pessimistic or optimistic. Pessimistic will lock any object instances or relationship instance sets before allowing a process or action to be started. Optimistic will lock object instances and relationship instance sets just before they are accessed. Pessimistic locking reduces deadlock possibilities but keeps more stuff locked for longer. The amount of locking required in a system depends on the number of threads being used. If there is only one thread, no locking is required at all. If each state machine has its own thread then every unit of locking needs to perform locking. Obviously, a domain needs to define potential threads so that synchronization can be tested. Anyone who reuses that domain can decide to use a subset of those threads and still be confident in the original testing but if they introduce additional threading then additional testing of the domain will be required. The whole concept of locks and threads (not just the design and implementation of locks and threads) is left to individual software architectures prior to OOA09. However, this leads to significantly reduced reusability across different software architectures. More on this stuff in the future. OOA09 will tackle these issues in its Simulation subsystem.

What's up for this week? I need to finish off Build 013 and get it released. The tasks that are outstanding are:

  • completion of arbitrary ID calculation logic along with an associated technical note,
  • completion of object instance table editor and other population editing forms,
  • completion of metamodel relationship population (metamodel object instance population is now finished),
  • and the normal updating of web pages and release files.
The complicated task is finishing the arbitrary ID stuff while the big task is finishing the table editors and forms associated with population editing. Metamodel relationship population coding is just tedious and energy sapping, i.e. each relationship in the metamodel requires a chunk of Java code to populate. If I'm lucky, the next build will get released at the end of this week, if I find problems or issues or I run out of time then it may not get released until next week or even the week after. The firm deadline for this build is the end of January.

Monday, 5 January 2009

Week 2 of 2009

Happy new year everyone.

This is the first of many weekly reports which aim to keep everyone up-to-date with what is happening to OOA Tool, OOA09 and the portal website. First, OOA08 will become OOA09 for obvious reasons! The portal website is being renamed from Shlaer-Mellor OOA/RD Portal to Shlaer-Mellor and Executable UML Portal since OOA Tool now supports Executable UML notation. I'm keeping the name OOA Tool for sentimental reasons even thought the CASE tool will be an analysis, design, implementation and testing tool. These weekly reports will not be duplicated on the portal website unlike most of the other blog entries which are actually important technical notes.

The main achievements for 2008 were:

  • major improvements to OOA Tool (now over 100KLOC of Java) including Executable UML support,
  • portal website created,
  • this blog created (which includes 16 technical notes),
  • OOA Interchange Format released and version controlled,
  • OOA of OOA released and version controlled,
  • and fUML captured as an Executable UML model.

The main objectives for 2009 are:

  1. release Standard edition of OOA Tool 1.0,
  2. ensure portal website provides the products, services and resources necessary for users to actually use Shlaer-Mellor or Executable UML on real projects.
These objectives include:
  • add simulator to OOA Tool,
  • finish translator in OOA Tool,
  • release and version control Action Language,
  • release and version control Archetype Language,
  • release and version control Pattern Language while allowing users to plug their own alternative into OOA Tool,
  • and release initial Java Software Architecture for translating a project into a standalone Java application.

And finally, I would love to hear from anyone interested in Shlaer-Mellor or Executable UML. Especially anyone thinking about using either on a real project.