Week 7 of 2009

Since nobody made any suggestions for the next build, I've gone with the first choice I gave last week, i.e. finish implementing model population as a precursor to full simulation support.

I started with referential and polymorphic attribute instances. In a deployed system, referential values (and polymorphic values mapped to referential values) would be accessed rarely if at all. Furthermore, all referential and polymorphic values must ultimately map to existing base values or be undefined. Thus, both can be calculated on demand (unless watchpoint mappings involving those attributes exist) apart from the fact that their values are accessed repeatedly when object instance tables are viewed in OOA Tool. As a consequence, referential and polymorphic values are cached in OOA Tool but this caching would not normally be required in a deployed system. These cached values need to be cleared whenever dependent base values or navigated relationship instances are changed. There is a balance to be made here between the amount of effort required to determine if a cached value should be cleared and the amount of effort required to calculate the cached value. If watchpoint mappings are listening to referential or polymorphic attribute changes (not recommended) then we will need to spend a considerable amount of time deciding whether to clear and recalculate those values. Watchpoint mappings (see Recursive Design subsystem) are not implemented in OOA Tool yet.

I then started looking at mathematically dependent attributes (called derived attributes in Executable UML). This is going to be the main feature in Build 014 since it will allow Action Language code to be executed for the first time in OOA Tool. After looking over all the mathematically dependent attributes defined in the OOA of OOA, I quickly realized that a simple one-in one-out function was not sufficient to calculate all of those attributes. Some attributes could be calculated on demand since the calculation would always be quick. However, other calculations may be very expensive. So expensive that ways need to be found to limit the number of times those values are recalculated. A Maximum Recalculation Interval is useful here for human-only information such as statistics and pretty labelling. There is no point recalculating such values more often than a human can process them. Delayed recalculation is an interesting topic which warrants further discussion. There are also situations where all object instances should have one or more mathematically dependent attribute values calculated at once, e.g. subsystem number ranges. Thus, a value calculation may map to one or more mathematically dependent attributes and may apply to one or all object instances. Next week I will add support for value calculations and implement mathematically dependent attribute instances (before implementing statement block execution logic).

Since I spent the week thinking about attributes and attribute instance implementation, I also deciding to have a think about attribute classification. I wanted to be sure I hadn't made any mistakes here. I did in fact decide to move the Naming attribute which was defined on Simple Attribute to Base Attribute after doing this analysis. I captured some of this analysis in the previous blog. The IE numbered bullet bug caused me some grief here and I ended up bypassing numbered bullets in that blog, yuk!

Attribute Classification

The attribute classification hierarchy in OOA88 and OOA91 is shown below:

Attribute

1. 1.
   • Descriptive Attribute
   • Naming Attribute
   • Referential Attribute


2. 2.
   • Identifying Attribute
   • Non-Identifying Attribute

The attribute classification hierarchy in OOA09 is shown below:

Attribute

1. 1.
   • True Attribute
     
     
     • Base Attribute
       
       
       1. 1.
          • Simple Attribute
          • Arbitrary ID Attribute
          • Mathematically Dependent Attribute (Derived Attribute in Executable UML)
       
       
       2. 2.
          • Descriptive Attribute
          • Naming Attribute
     
     
     • Referential Attribute
   
   
   • Polymorphic Attribute


2. 2.
   • Identifying Attribute
   • Non-Identifying Attribute

In the above classifications, a numbered list represents an and hierarchy while a plain list represents an or hierarchy, e.g. an attribute is true or polymorphic and identifying or non-identifying. Attributes can also be classified according to their associated data type. However, data type hierarchies will not be discussed here.

OOA96 introduced mathematically dependent attributes which are discussed in [31May08].

OOA09 introduces polymorphic and arbitrary ID attributes. Polymorphic attributes (and true attributes) are discussed in [26May08]. A detailed discussion on arbitrary ID attributes will be published soon. OOA09 also introduces base attributes (and simple attributes) because all referential attributes must resolve to a single base attribute (see [29May08]) and all base attributes are descriptive or naming attributes.

Arbitrary ID attribute could be merged with simple attribute except that it has a very different lifecycle. Although arbitrary ID attributes can be assigned values like simple attributes, any assigned values are temporary in nature since the allocation of arbitrary ID values is platform controlled not user controlled. Anyone who assigns a value to an arbitrary ID attribute needs to understand how long that value will persist (arbitrary ID types provide some control here but not complete control). For ordinal arbitrary ID values, the user is rarely interested in the exact value, only it's ordering relative to other object instances. For non-ordinal arbitrary ID values, the user is almost never interested in the exact value. Furthermore, the user may never actually need to access such values at all, i.e. the arbitrary ID attribute may only exist in the information model to formalize one or more relationships.

Naming attributes are those representing arbitrary names and labels. Most but not all arbitrary ID attributes are naming attributes. Mathematically dependent attributes are often used to create formatted names and labels from more primitive naming attributes. The distinction between descriptive and naming attributes is not essential for code generation purposes and many information models will ignore this classification defining all base attributes as descriptive attributes.

Identifying attributes are central to the idea that relationships should be formalized in information model specific terms allowing constraints between relationships to be clearly specified. However, the object identities defined by identifying attributes are not fixed and may change frequently depending on the number and nature of the identifying attributes that compose each identifier. The reason that mathematically dependent, referential and polymorphic attributes may be identifying attributes is that the implementation of object identity within Action Language code is normally based on object instance references (or handles). It only appears within an information model that object identity is implemented using identifying attributes. Of course, this appearance was reinforced in OOA91 because Lifecycle Model directed events carry identifying attributes to reference destination object instances. This is no longer the case in OOA09.

Some would argue that a software architecture should be free to choose how it implements object identity. However, the reality is that you can only use mathematically dependent, referential and polymorphic attributes as identifying attributes on secondary identifiers unless you use some concept of object instance reference. And even if you do stick to simple attributes for identifying attributes, you still need to be able to handle changes to those attributes. You can of course, use identifying attributes to find object instances (using a select statement) when those object instances are known to be consistent. However, in most cases, object instances are found by navigating relationships and relationship instances are best realized using object instance references (not identifying attributes).

Week 6 of 2009

I finally released OOA Tool 1.0 BETA Build 013 last Friday. It shouldn't have taken three months to roll out all of the features in that release. Unfortunately, I started making changes on a number of parallel tasks and didn't want to release a broken build. I will try to avoid tackling too many parallel tasks in the next build. The main features added in Build 013 were:

• expanded and fully implemented data types,
• metamodel population generation for version 0.01 of the official OOA of OOA,
• model population editing,
• project matrix support,
• and a new Executable UML2 model for the Executable UML Foundation (fUML).

All of the data types defined in the official metamodel Data Dictionary subsystem are now supported in OOA Tool. However, there are a few data types not in the official metamodel yet, e.g. reference types, return coordinate types, transfer vector types and abstract types. The additional data types will be added as they become needed.

The metamodel population support is sufficient for generation of Information Model Reports now. I just need to reintegrate the translator I wrote last year into the project population framework that underpins the model and metamodel populations. There was one feature that I had thought about but haven't implemented yet and that is the ability to link a metamodel population to an external metamodel project. As discussed in last week's weekly report, an internal metamodel is used to ensure Java population coding doesn't get out of sync with the metamodel. However, this means all attributes are defined as simple attributes causing some (e.g. arbitrary ID attributes) to be flagged in red when you browse metamodel population data. It would be nice if OOA Tool allowed you to reference an external metamodel which would include correctly typed and fully resolved attributes. However, the external metamodel would still need to be validated against the internal metamodel when it is loaded.

The model population support allows object instances and relationship instances to be created and edited. However, it doesn't support mathematically dependent attributes, referential attributes or polymorphic attributes yet. These attributes remain undefined when object instances are created. It also doesn't support all forms of arbitrary ID attribute yet. Population constraint validation is also missing at the moment. However, this requires some notation of transaction to be effective. More on this in the future.

The project matrix support was a secondary feature. I'm not planning on doing any more work on project matrix tasks or activities prior to getting OOA Tool out of beta.

The fUML modelling I did was part of my effort to keep abreast of what is happening in the OMG with regards to making UML executable. It should be possible to create an executable fUML library from an OOA09 project that could be executed in a third party UML tool or load an fUML library into OOA09 as an implementation domain. The limitation here would be what event dispatch scheduler and polymorphic operation dispatcher the external fUML library would require. fUML defines variation points so that the current Executable UML tool vendors don't have to agree a standard policy on event scheduling and polymorphic dispatching. The other sticking point here is the XMI standard which is basically a waste of space! The only way this will ever work is if everyone adopts a single interpretation, e.g. the Eclipse implementation. However, you still have the basic problem that XMI is independent of the UML metamodel and both are regularly being changed. The OOA Interchange Format on the other hand is independent of the OOA of OOA since it defines an implicit OOA of OOA within it's DTD. The purpose of the OOA Interchange Format is to allow the exchange of projects between tools. The purpose of the OOA of OOA is to define a data model for translation purposes. Obviously, changes in one will effect the other but these changes are controlled separately. In my opinion this is a major scalability flaw in the XMI/UML design.

Now to discuss the next build, i.e. what should be in it? There are a number of areas outstanding that can be tackled now:

• finish model population support by implementing non-simple attributes including mathematically dependent attributes (this will require the Action Language to be documented and put under change control),
• integrate and update the previously implemented translator based on BridgePoint's old Archetype Language (this will require the Archetype Language to be documented and put under change control),
• clean up the integration of patterns with symbolic types (allowing plugin alternatives), defining the default Pattern Language in a separate domain and ensuring it is documented and put under change control,
• fix some outstanding issues with the state modelling design and merge the State Model subsystem into the official metamodel,
• finish process modelling design and implementation,
• and finish off the remaining technical notes on Shlaer-Mellor and Executable UML notation (and I'm sure I will find a few presentation issues I need to fix in OOA Tool when I do so).

My current plan is to start with the first item. However, I'm willing to listen to suggestions. Does anyone have any strong feelings about what should be implemented and released next?

One final thing. I would like to thank Kennedy Carter and Ian Wilkie in particular for making the following white papers publically available:

• OOA 97,
• Polymorphic Events in OOA/RD,
• and OOA 97 and Executable UML.

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.

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.

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.

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.