Shlaer-Mellor and Executable UML Portal

Week 10 of 2011

2011-03-14T16:32:00.003Z

I haven't posted any blogs for some time now. However, I haven't abandoned the world of Shlaer-Mellor and Executable UML. The last activity I talked about was a Chess Tool application. I was starting to get carried away with the software architecture. However, the purpose of the activity was to provide a simple but realistic Shlaer-Mellor and Executable UML case study. It became apparent to me that without action language support, the case study wouldn't be particularly repeatable. Too much effort was going into the software architecture without a process level framework being in place. That process level framework should be provided by an action language and an associated runtime environment.

Now, I have been told by a number of you out there that I should have worked harder to get the simulator working in OOA Tool. Unfortunately, I persisted in my top-down approach which ran out of steam last year. The OOA of OOA in OOA Tool is too big and complex to implement a clean action language when there is only me doing the work!

So, just after Christmas, I started a new code base using some of the software architecture from the Chess Tool application. The overriding objective of this code base is to run action language programs. The target deliverables would be an interpreter, a formatter for colour coding source code, a debugger and a set of standard services. A model compiler supporting archetype templates was not a target deliverable for the first release. I also decided early on that I couldn't afford to link the code base to OOA Tool without a significant chance that I got side tracked sorting out OOA Tool issues.

Since I started on this, I have barely looked back. An OOA information model for the interpreter was produced hand-in-hand with the Java code. This forms the basis for metamodel services which will need access to this information for document and code generation purposes. I have used my normal pattern language to produce a syntax grammar for the action language. I'm calling the action language TAL (ooa Tool Action Language). It's a significant evolution of OAL which I have always preferred over ASL (sorry guys!). It also has no similarities with Alf, the new OMG UML action language which is a monster just like UML itself (sorry guys!!). How anyone expects to be able to generate code for different languages and platforms from Alf without an expert team on hand is anyone's guess. It would seem to me that a major objective of Alf is that it requires tool vendors to create model compilers. However, I believe users should be able to accomplish that task themselves which is why TAL has tried to keep things simple where it can.

I don't want to talk too much today. I had planned to rollout the first release last week. However, the Programmer's Manual and User Guide were in very poor shape and I had a few weak areas to sort out. I decided to hold off for a few weeks to get things in better shape.

Week 47/48 of 2010

2010-12-06T12:50:00.005Z

I've been working on the software architecture of the Chess Tool application for the last two weeks. I've also been trying to stay warm given the cold snap here in Colchester. I don't ever remember seeing snow in November before! Anyway, I going to discuss the Values subsystem of the software architecture in this blog. The latest OIM is given below:

The subsystem originally started off with a small set of data value subtypes but has expanded over time to include most of the data values defined in the Data Type subsystem of the OOA of OOA. However, I have discovered some issues with how I defined data values in the OOA of OOA which I will mention as I discuss each subtype below.

Undefined Value is implemented as a Java enum with a single UNDEFINED value. It is useful when dealing with generic values. However, it is not that useful generally since most assignment targets can (and should) be specifically typed. For example, a numeric value attribute will be typed as a NumericValue and if conditional then undefined is represented using null or an associated value status set to UNDEFINED.

Boolean Value is also implemented as a Java enum with FALSE and TRUE values. In my OOA of OOA, I also allowed users to define false and true aliases. However, on reflection that was a bad idea since Action Language code that uses the aliases can hide bugs where a user thinks an alias is TRUE when in fact it is actually FALSE. Instead, users should use enumerated values instead of aliased boolean values.

Enumerated Value design has undergone a number of iterations. The first requirement was to be able to map enumerated types/values to Java enum's which implement Specific Enumerated Type and Specific Enumerated Value interfaces. These values are associated with static enumerated type information allowing them to be used statically within generated code. I supplemented this with a Qualified Enumerated Value allowing a system dependent type to be associated with an enumerated value. However, such values can't be used statically within generated code. Later I added the concept of a Generic Enumerated Value which is enumerated type independent. It can be matched against any enumerated value with the same legal value name. However, generic enumerated values are not ordered and so can't be used in relational comparisons (unless a promotion to a typed value is possible).

Symbolic Value encapsulates Java String values. However, Java string length is based on 16 bit character counts for backwards compatibility, not Unicode character counts. I prefer to use actual Unicode character counts instead.

Numeric Value has numerous subtypes which have evolved considerably. They are shown on the OIM in promotion order from left to right. Automatic ID Value encapsulates non-negative Java int values (no time unit). Limited Integer Value encapsulates Java long values. Integer Value encapsulates Java BigInteger values. Decimal Value encapsulates Java BigDecimal values. Rational Value encapsulates a numerator/denominator pair allowing lossless division and the representation of negative zero, NaN, Infinity and -Infinity values. Rational Interval Value encapsulates a rational interval with a lower endpoint numerator, an upper endpoint numerator and a shared endpoint denominator. This is a more specialized numeric value not often supported in traditional programming languages.

The final subtype is Floating Point Value which encapsulates Java double values. Such values are normally approximate values since underflow and overflow is handled using approximation without user intervention. For this reason, all such values are prefixed with '~'. Once a numeric value is promoted to a floating point value, it is never narrowed without user intervention since all previous subtypes are assumed to be exact values while floating point values are assumed to be approximate.

All of the above subtypes handle negative zero consistently. However, whether a negative zero is preserved after been assigned to an assignment target (attribute, variable etc.) depends on the numeric type of that target. Most programming languages only handle negative zero in floating point arithmetic. However, I believe multiply and divide should be defined consistently across all numeric values, i.e. result sign is negative only and always if operand signs differ. However, negative zero is invisible when comparing numeric values. It only has a significant impact when it is used as a divisor resulting in a signed infinity (assuming dividend non-zero).

Rounding modes are associated with numeric types not numeric values. However, most programming languages perform rounding immediately when integer divide is performed. I prefer to promote the result of a division with a non-zero remainder to a rational value and leave any rounding to when the result is assigned to a target with an associated numeric type. Obviously, the remainder '%' operator doesn't make any sense without immediate rounding to determine the remainder, i.e. a lossless remainder operation always returns zero! Lossless (or lazy) division can have a significant impact on how code executes if the user assumes implicit immediate rounding. However, it should be possible for an analyst to change a numeric type without reworking Action Language code so inconsistent arithmetic rules across numeric types is something that should be avoided.

Numeric value also supports an optional time unit allowing duration values to be defined. This concept may be extended in future to support other unit types. However, allowing time units now helps develop an understanding of how units can be supported in the future. Subtracting a time from another time results in a duration. Performing arithmetic on two durations requires the duration time units to be the same. This can be done automatically except where one operand is DAY or smaller and the other is MONTH or larger since you can't convert durations between days and months outside the context of specific times.

Time Value is no longer a numeric value since most arithmetic operations don't make sense. Only subtraction of time values is allowed. I originally defined time values as numeric values in my OOA of OOA. An optional time unit is associated with time values so that when times are subtracted, the time unit of the resulting duration can be determined. The time unit is also used when converting time values into numeric magnitudes. Underlying time values are represented in UTC time relative to the Java Epoch ('1970-01-01 00:00:00'). An optional time zone is also associated with time values for determining calendar specific component values such as year, month, day etc. However, time unit and time zone are not preserved during assignment to a time typed target since that target will specify it's own preferences.

Handle Set Value allows object instance subsets to be represented. They are created from object instance lookups and relationship navigations. All non-empty handle sets are backed by the full set of object instances (which acts as the universal set) so that absoluteComplement() can be invoked on such values. Empty handle sets are another matter. A Qualified Handle Set Value allows backed empty sets to be created but such values can't be used statically since they are system dependent. That was why I introduced a Specific Empty Handle Set Value which allows an empty set to be statically defined for handle sets with specific object/class names. I also defined a Generic Empty Handle Set Value for situations where the object name is unknown. However, specific and generic empty sets have no associated universal sets so absoluteComplement() can't be applied to them.

I initially left handle sets unordered. However, most set operations (contains, union, intersection, difference) are much quicker when the sets are consistently ordered. To make consistent ordering possible, I now define a system-wide fixed ordered automatic ID literalID on all object instances. Such an ID is easy to allocate and defines a run-time ordering across all object instances. I also use this ID when formatting handle set literals. However, this ID is not persisted across runtimes.

Composite Value allows structured values to be created with readable but non-writeable components. Such values are discussed in xtUML02. I wasn't going to support composite values initially. However, they have immediate application as input/output parameter sets. They can also be used to create object instance snapshots when necessary. I don't currently allow composite values with no components.

List Value allows generic value lists to be created and iterated over. Such values should never be associated with attributes since they should never have a multiplicity of many. However, they may be created and passed as parameters or event data items since we allow a multiplicity of many on parameters in general. More commonly, they are useful within Action Language operation bodies where processing has been divided into stages. I'm not sure there are any benefits allowing other collection types (e.g. Bag, Set and OrderedSet) since their use is strictly temporary and localized.

I've run out of time so I won't go into predefined operations today or literal string syntax. Next time, I will also discuss the Types subsystem which sits above the Values subsystem.

Week 39/40/41/42/43/44/45/46 of 2010

2010-11-22T12:44:00.007Z

This weekly report is actually a two monthly report! I just haven't had much enthusiasm for blogging. However, apart from last week (I was up in Nottingham visiting relatives) I have been busy on the Chess Tool case study previously mentioned. Lets start with the domain chart:

I'm only showing the Shaler-Mellor diagrams here. However, I will write up the case study as a multi-notation technical note in the future given Executable UML versions of all diagrams. The application domain covers Chess rules and the playing of Chess games. I spend a couple of weeks immersing myself in the world of Chess. The current OIM for the Chess domain is given below:

I've also modelled the lifecycles of matches, human players and computer players but I don't want to overload this blog with too many diagrams. They will all be in the final case study report. I will also leave further discussion of the Chess model to the report since I want to overview my other progress. I haven't progressed the User Interface domain far yet since I'm fairly confident I can tackle it last.

I initially placed the XML based Persistence domain above the Software Architecture domain as a proper service domain. This is fine for formatting purposes. However, for XML parsing the domain starts to rely heavily on metamodel mappings. Since this would make the case study more complicated than necessary I decided to move persistence below the software architecture, i.e. it's now an implementation domain allowing the XML parser factory logic to be hand coded. The J2SE XML parser will now load initial XML files parsing them into DOM structures which will now be traversed with custom code resulting in the population of initial Chess and User Interface object instances. This kind of decision as to what domains will be code generated and which won't needs to be made with care. Ones that should be excluded will often involve integration with existing libraries. In this case, I'm taking advantage of the J2SE XML libraries to do the actual parsing. If I was going to implement the low level parser then I would have kept persistence as a service domain.

After I looked at the Persistence domain, I moved onto the Software Architecture domain. I'm been on this for many weeks now. My intention with this case study was to manually generate code (since OOA Tool doesn't support Archetypes yet). However, I still want to model the architecture and design archetypes to control the manual generation of this code. I've gotten carried away with this! I starting with Data Values (and literal syntax) and the predefined operations supported by these values, moved onto Data Types (and declaration syntax) and the validation processes involved, then onto system, domain, object, attribute, link and operation instances. I then started to instantiate Chess versions of object instances etc. so I can understand what needs to be generated by archetype templates in future. In parallel, I created simulated versions of object instances etc. that could be used to run a simulation within OOA Tool in future. Since then I have been experimenting with mixed generated/simulated code. Complicated operation instances can be hand coded while simple operation instances can use Action Language parsed expressions. The current OIMs for Values, Types and Instances are shown below:

All of the above has been implemented in Java using Eclipse which I've been using for the first time trying to put JBuilder to bed. I'm starting to wonder If I can implement a complete Action Language driven virtual machine here which I hadn't planned to do for this case study. I will have to see how things go.

My experience with Eclipse has been mixed. Refactoring is much more powerful than in JBuilder 2005, but search and replace across a project is pretty crap in Eclipse. Maybe there is a plugin somewhere that fixes this. I'm also finding the debugger difficult to use. Maybe it just takes time and I've gotten used to the JBuilder debugger. One thing that annoys me is that the cursor in Eclipse seems to jump about a bit opening windows unexpectedly. I think there are some bugs here. I will say using generics in Eclipse is a completely different experience than trying to use it in JBuilder which is badly broken in that area.

I've also been using the released version of OOA Tool Build 014 to create the Chess Tool models. I have discovered a number of bugs during this process that required me to hack the XML to fix a corrupted "ChessTool.ooa" file. If anyone has a similar experience then they should email me their model I will fix them for you. I don't want to return to OOA Tool development at this time but I will document the bugs I have found (and associated workarounds) in the future.

I've also been following the debate on referential attributes in the Executable UML forum but my yahoo account doesn't seem to be working properly - it doesn't recognise my email when I try to login, yet it's still forwarding me email updates - weird! Referential attributes are crucial to the Shlaer-Mellor and Executable UML experience in my opinion. However, I have found situations were cardinality limits beyond zero-one-infinity can be beneficial in a model without creating models susceptible to change, e.g. a binary relationship in the Shlaer-Mellor metamodel has exactly two participants by definition. I may allow such explicit cardinality constraints to be shown on Shlaer-Mellor OIMs in the future.

Week 32/33/34/35/36/37/38 of 2010

2010-09-27T13:39:00.002+01:00

Sorry for the lack of blogging. I've been focusing on other things for a while now. I've been on a serious diet/exercise plan for more than a year now, dropping my weight from more than 125kg (20 stone) to below 90kg (14 stone) now with only 5kg left to reach my target weight. Unfortunately, my concentration has been very poor in recent weeks while I got down from 95 to 90kgs. I'm running 5km most days now as part of the plan. One of my problems is how to fit in a nice big pizza (I'm addicted) once a week without blowing the plan! Another problem is my cash reserves are now running low so I will be returning to IT contracting in the next 3-6 months for refinancing. Any projects looking for Java/OOA tooling/code generation experience then let me know :). However, I have no intention of stopping OOA Tool development.

Anyway, what to focus on while dropping my last 5kg. I'm loath to focus on the next build at the moment while my concentration is not 100%. So instead I'm going to do a small case study using OOA Tool, documenting the study in a series of technical notes over the coming weeks. I thought about doing a telecoms or banking example but it might turn some people off so I'm going with a Chess program that everyone can probably relate to.

I'm also going to use the activity to get to grips with Eclipse as a development tool. I've been using JBuilder 2005 for many years now but even they have moved to an Eclipse based platform. So why should I pay for the new version of JBuilder when I can download a free version of Eclipse? So I've installed the JEE build Helios SR1 version of Eclipse on my XP desktop and Vista laptop. I'm also restricting my OOA Tool use to Build 014 which is the current release. One problem I found with Eclipse was that it mostly assumes an internet connection to download additional features/plugins. That's fine with my laptop but I keep my desktop isolated for safety and never connect it to the internet. So I'm going to have to restrict my use to what's in the shrink wrapped JEE build, at least until I really know my way around Eclipse allowing me to manually download and install additional features.

I'm not going to say much about the case study since I want to publish the first part by the end of the week but I will include Shlaer-Mellor and Executable UML diagrams with the target platform being Java based. I will release all of the code created which won't be automatically generated since OOA Tool Build 014 doesn't support code generation. The purpose of the study is to see OOA in action rather than code generation. However, I will try to keep coding as template oriented as possible.

Now for other stuff. I'm not seeing much happening in the world of Executable UML. The world of Shlaer-Mellor is mostly restricted to this blog so not much happening there either! Kennedy Carter have now become Abstract Solutions with Allan Kennedy leaving to do his own stuff. I wish Allan and the other guys (especially Chris and Ian) all the best and I hope Abstract Solutions continues to provide Executable UML solutions to customers. Of course that requires customers with the vision to see the long term benefits.

Week 29/30/31 of 2010

2010-08-11T14:40:00.005+01:00

I've been a bit busy over the last few weeks and didn't manage to slot in any blogging time. Sorry about that. The majority of my effort over that time has focused on a redesign of the attribute hierarchy and a reimplementation of various attributes in Attribute. There were a number of problems and limitations with the previous design which have been bugging me for some time now.

As a consequence, I completely rewrote the Attribute Classification technical note. Normally I would publish all technical notes on this blog first while also publishing another version (which I update over time) on the www.ooatool.com website. However, since I have started making the website versions notation-switchable, the blogged version has become less and less useful. Especially since the majority of current users switch to Executable UML notation anyway (and I still prefer Shlaer-Mellor notation). Thus, I will no longer publish technical notes in full here. I've also dropped any reference to creation date from new technical notes since the last updated date is much more relevant than when it was created. I recommend long-standing users scan the above technical note switching between notations since there are quite a few changes between the notations. The reworked Information Model subsystem of the OOA of OOA is shown below:

A reworked Data Type subsystem is also shown below:

With data type usage extracted into a new Data Type Usage subsystem:

During the redesign of the attribute hierarchy, I made a number of significant changes:

Literal attributes are distinguished separately from simple attributes now. As a consequence, default and initial values no longer have final statuses. I've also changed the attribute suffix in Shlaer-Mellor from "F" to "L" while Executable UML still uses "frozen" and Executable UML2 still uses "readOnly".
Users will now only be able to specify data types and conditional statuses for base attributes (previously, manual data types and conditional statuses could be set on all attributes). As a consequence, data types can't be incompatible anymore (except for polymorphic base attributes which are treated specially).
Conditional statuses of referential and polymorphic attributes are now assumed to be false unless proved to be true (previously, we assumed true unless proved to be false). This reflects the idea that conditional attributes are the exception rather than the norm.
The qualifier polymorphic is now mapped to abstract in Executable UML and we no longer use "P" suffixes to identify such attributes. Instead we use an "abstract" suffix in the browser and omit the suffix entirely on class diagrams relying on the use of an italic font.

I've also been working on a design for UML aggregations and compositions which I will discuss in full after it's implementation is complete (and I can show some class diagrams with diamonds on them). These concepts deal with ownership across relationships and I have been calling them child-parent relationships in Shlaer-Mellor so far. However, I'm planning on eliminating the terms child and parent. I'm also planning on renaming Parent Allocated ID Type to Owner Allocated ID Type (or Aggregate Allocated ID Type in Executable UML).

Week 28 of 2010

2010-07-20T16:02:00.005+01:00

I've been very busy over the last week, extending and evolving the OOA of OOA. I've also been implementing some OOA Tool changes with regard to Arbitrary ID Types which have been completely overhauled. Let's start with the Recursive Design subsystem which is shown below:

This hasn't changed much over the last week. The Location attribute on Software Product has expanded into several attributes reflecting the new implementation within OOA Tool. The user can set a manual location (relative or absolute). However, a default location (relative if parent location defined, absolute otherwise) is always defined and used if no manual location is specified. A parent location (absolute if defined) is always defined for software products enclosed within other software products, e.g. code modules are enclosed within projects and/or external projects. Manual and default locations are resolved relative to any parent location. All locations are specified as URIs while the final location should also be a valid absolute URL. Using URIs here blurs the distinction between file system and web locations. OOA Tool also converts to and from platform specific paths allowing normal file chooser dialogs to be used.

Another change involves the new Work Product object, a subtype of software product. This change expanded so much over the week that a new Work Product subsystem had to be added to the OOA of OOA. This sounds like a major pollution of the domain, especially since I have previously mentioned that I wanted to evolve the Diagramming domain used in the OOA Tool project into a more general Work Product domain covering diagrams, tables and other graphical constructs. However, I'm only concerned with OOA/RD specific information in the new subsystem. No mention of size, location or other graphical pretty printing is involved. The Work Product subsystem is shown below:

As this subsystem evolved from a few objects into 25 objects, I made a number of important discoveries:

each diagram product has it's own notation which may differ from the enclosing project's notation reflecting the reality in OOA Tool while table products do not,
a new Information Model Partition object was required to formalize this subsystem and as a result, I was able to simplify the messy unassigned/assigned object/relationship cluster in the Information Model subsystem,
archetypes can determine diagram locations (e.g. when generating reports) from a metamodel population by looking at instance data associated with this subsystem,
imported objects and event destinations are modelling issues best captured in the OOA of OOA rather than as diagram pretty printing,
tasks and task activities (now called Work Cells) have a proper home and it's in this subsystem,
and I identified the need for allowing generalized data types in polymorphic attributes since I can't resolve the polymorphic row and column attributes on Table Cell without it (more soon).

The new subsystem also makes bridging to a generic Work Product domain much easier since each diagram and table product now has an object in the OOA of OOA domain which can be mapped to a counterpart in the generic domain. The new Information Model subsystem is shown below:

You should see how the new Information Model Partition object eliminates the need for unassigned/assigned object/relationship objects. I haven't made the change in OOA Tool yet since it will probably involve lots of work. However, the above subsystem is much cleaner with the change.

You may also notice that I have replaced Arbitrary ID Attribute with System Set Attribute. System set attributes allow system reallocated IDs, current subtype and current state attributes to be added to an object (and provides room for future system derived attributes). As far as current state is concerned, OOA91 allowed users to access it while OOA96 disallowed such access. I'm in favour of allowing controlled access to current state information. My initial plan was to provide a special current state (and current subtype) expression syntax within the Action Language to support this. However, this is messy since it complicates the Action Language and hides such access from any model reviews. The better approach is to allow users to add a current state attribute (which is set by the system) to an appropriately related object, e.g. the current state of a lifecycle model can be added to it's active object. I already automatically define an Enumerated State Type for each state model allowing such an attribute to be typed. I've extended this idea to allow the current subtype of a subtype-supertype relationship to also be added to an object since I also already automatically define an Enumerated Subtype Type for each subtype-supertype relationship. This allows identifiers to be defined which include the current subtype! Current subtype attributes should only be added to the appropriate supertype object. As a result of the overall change, I've also replaced the "(A)" suffix with an "(S)" suffix within information models.

I was also going to talk about the revamped Arbitrary ID Type which I've already coded up but time has run out (I'm trying to limit weekly reporting to a few hours a week now!). I'm definitely planning a new OOA Tool build now since the current metamodel won't load into the currently released build.

Week 27 of 2010

2010-07-12T16:21:00.003+01:00

I've had a very productive week modelling wise. I've been trying to finish off the Recursive Design subsystem in particular. However, I've also been resolving a few cross-subsystem modelling issues as well. If some on you are wondering what's happening with the OOA Tool 2 development. It relies heavily on the OOA of OOA unlike OOA Tool which quietly added a few extra details not in the old OOA of OOA, e.g. location information and code module support. I also want to ensure populations (including runtime populations) are fully defined in the OOA of OOA before coding the virtual machine in OOA Tool 2.

I realised one nasty issue with regards to metamodel population objects was caused by an identifier simplification that I've been using for a long time now. The simplification in question is the use of a standalone arbitrary ID attribute for identifying information models when I should have used the enclosing domain's compound identifier. The advantage gained was being able to refer to an information model using only a single referential attribute. The disadvantage was that several objects need to refer to both an information model and the enclosing domain using different referential attributes. I could have added loop constraints to ensure the referenced information model is the one defined by the referenced domain. However, I haven't being adding those constraints to date. The nasty issue only surfaced during a moment of reflection - metamodel population objects actually need to refer to two different projects, the first being the population project and the second being the metamodel project. The extent of this dual project relationship is something that definitely should be visible in the OOA of OOA but was being hidden by my identifier simplification. I've now entirely eliminated the arbitrary ID defined in information model using the enclosing domain's compound identifier instead. This took many hours! The moral of this story is don't shortcut compound identifiers in complex domains.

Now back to the Recursive Design subsystem, the latest version of which is shown below:

I've now added support for Code Modules since most developers want to bundle code into manageable files in the real world. Operations can still be coded within the model but the user will now be able to locate the actual code inside an external Action Module associated with the enclosing domain. I will have to extend the Action Language syntax to include operation definition statements so that multiple operations can be defined within a single code module. However, this change will make code reviews and configuration management much easier. Code modules also include archetype templates (see Archetype Language) and pattern sets defining syntax and lexical grammars (see Pattern Language). This does offer the possibility of manageably supporting multiple languages since we could associate a particular language with a given code module.

I've also added the concept of a Software Product which is a locatable software component at the highest level. I haven't used the word component since it would clash badly with the UML component concept. Software products include code modules (discussed above), projects and external projects (loaded from ".ooa" files), and output products generated from translations. The current version of OOA Tool also implements a few custom output products, i.e. diagrams and information model reports. Information model reports will be reimplemented using archetype templates in the future. However, diagram image generation will have to remain a custom output product for now since I imagine creating a ".png" template directly is a really difficult task!

All software products have a lifecycle. Code module lifecycles include states such as loaded, parsed, changed and saved. Project lifecycles include states such as changed and saved. External project lifecycles include states such as loaded. Output product lifecycles include states such as generated, saved and loaded. A related active object is External Asset which defines states such as loaded (has a similar state model to external project). Obviously, all of the mentioned state models will also define one or more error states etc. I haven't finished modelling the various state models yet so I can't include them here. I originally tried to keep this concept out of the OOA of OOA. However, that was a mistake with regards to the Recursive Design subsystem since it's purpose is to define how domains are integrated and reuse enabled. On the other hand, I don't like having the Task and Task Activity objects in the OOA of OOA which is almost certainly domain pollution. However, I'll keep them for now since I want to maintain support for Project Matrices (one of the original Shlaer-Mellor work products) without adding a new project management service domain. I did move (a while ago) this pollution from the Recursive Design subsystem into a separate Recursive Design Project Management subsystem to isolate it.

I've also added asset dependencies to the model. Domains should have no dependencies since they define a world in isolation. Bridges and layers obviously have domain dependencies. Input populations also have domain dependencies. Transformations have domain and input population dependencies. They may also have simulation dependencies if part of an input population is generated. There should be no code module dependencies across assets since operations remain hidden within their enclosing domain. The same should be true for pattern modules. Even though syntax might be shared across domains, e.g. I've reused some bits of Java syntax within the action, archetype and pattern languages. I'm not planning on formalizing any such sharing. Archetype modules are a little bit different since I could imagine wanting to share some templates across multiple software architecture domains. This is why I have captured the includes relationship on the model. However, changing a shared template could completely break one or more of the software architectures unless very careful consideration was given to any changes. Balancing the risks here, I'm currently going to require any included archetype modules to be defined within the same domain as the includer. This places the responsibility of checking any changes on the user which I believe is required in this situation. Comments welcome.

Remember, we are enabling Asset reuse, not Code Module reuse in the OOA of OOA. Code is simply implementation logic within an asset.

I was also going to talk about a bunch of other stuff today but it's already 7pm and I want to do some real work tomorrow! I'm almost certainly going to release a new build of OOA Tool now before OOA Tool 2 is rolled out since I'm making lots of changes to the OOA of OOA some of which I want to use to model the OOA of OOA! Anyway, enough for now.

Week 26 Addendum

2010-07-07T08:50:00.004+01:00

I finished the report yesterday and then headed off to the coffee shop to reflect (and flesh out the next modelling task). In particular, I thought about how I might access thread pool allocation colouring within an archetype template to generate the necessary code. It occurred to me that I would need to manually create a new colour for each thread pool instance using yesterday's model - not good! After some rework, I ended up with the following revised Colour subsystem:

The above model adds the concept of an Indexed Colour (I did call it an Array Colour for a while) which allows a colour to be defined which implicitly defines a component colour for each indexed element. Object instances are used for indexing purposes. Using the thread pool allocation issue as an example, "Thread Pool Allocation" would be an indexed colour indexed by instances of Thread Pool. Each instance of thread pool that a user creates within a simulation results in an implicit component colour of "Thread Pool Allocation" being created. To allocate event destinations etc. to a given thread pool, the user creates an Indexed Colouring Rule which references the "Thread Pool Allocation" colour and the given thread pool's object instance (along with the contents of the rule of course!).

We also need to add support for indexed colours to the Boolean binary operator which tests for colouring in the Archetype Language:

objectInstance ( coloured | marked )
    [ domain '@' ] colour [ '[' objectInstance ']' ]

Where the first objectInstance expression references the instance being checked and the second references an instance of an architectural concept (e.g. thread pool). To demonstrate the above, yesterday's example archetype code fragment is expanded below to support a PersistanceControl object from a user defined Persistence domain:

.Select many objects from instances of Object
    where selected coloured Persistence@Persist
.for all object in objects
.Select one persistenceControl
    from instances of Persistence@PersistenceControl
    where object coloured Persistence@Persist[selected]
.// Generate code to persist using control settings...
.end for

From the above, we can see that indexed colours can be checked for in a generic sense, i.e. all objects with any "Persist" colouring are selected at the start.

The only other change I made to the Colour subsystem was to refactor two ownership relationships into one. Specifically, top-level colouring rules are defined by either input populations or transformations. Since both are assets, I added a new Colouring Rule Owner object between them and asset. I'm now able to use a single defines relationship for top-level colouring rules.

Week 26 of 2010

2010-07-06T05:59:00.005+01:00

I've continued work on the Recursive Design, Population and Colour subsystems of the OOA of OOA. I dropped the term Colour Model as it didn't add any value. The Colour subsystem is shown below:

The basic points to note are:

Any domain can define logical Colours (called Marks in Executable UML), not just architectural domains since any domain can define archetypes for translation (e.g. a non-architectural domain may create an archetype to generate an external configuration file and use one or more colours to control the process). Even the OOA of OOA domain defines a number of colours (see next bullet).
Colouring Rules (called Marking Rules in Executable UML) are defined by either input populations (allowing boundaries to be defined), simulations (allowing thread pool allocations, breakpoints and logging to be defined) or translations (allowing archetype specific colouring to be defined). All colours used with input populations and simulations are predefined by the OOA of OOA domain.
The result of applying a colour rule prior to a translation is always zero or more Coloured Object Instances (called Marked Objects in Executable UML) referencing either metamodel or model object instances. The fact that we treat metamodel data just like ordinary model data makes the process here very simple.
Visual colours are outside the scope of the OOA of OOA. Instead they are associated with work products such as diagrams and tables. The idea being that on a given diagram (e.g. an OIM) a user can associate a particular visual colour (e.g. green) with a colouring rule (e.g. the boundary rule associated with a specific input population) which applies a specific logical colour (e.g. Boundary defined by the OOA of OOA domain) to it's data. Such colour selections are normally transient.

The need for input population boundaries is particularly strong where generated populations are concerned. Metamodel populations and output populations from long simulations can be really big. If your transformation only uses a small subset of such data then a boundary can be defined by colouring objects within the boundary. Population data outside a boundary is never generated as long as the boundary is specified on the generated population itself, not a composed population which contains the generated population. One may even want to specify a boundary on a simple population to stop users adding specification data outside the scope of the population's intended use.

The need for simulation colouring rules is weaker since colours can't be accessed at runtime without providing access to metamodel data. However, the mechanism does allow concepts such as thread allocation, breakpoints and logging to be easily specified. Other concepts may be added in future. One benefit of using colouring rules here is that a translation can access them quite easily (e.g. to add simulation specific logging to generated software).

Population Selection Rules are defined using a series of inclusion/exclusion criteria. The first rule will always be an include rule. Any children will be exclude rules. Any grandchildren will be include rules etc. For example, the top level include rule may select a particular domain, with child rules excluding particular subsystems. We can combine these rules with Set Expression Rules for union, intersection and difference. Many top-level colouring rules will actually be a union set expression rule containing multiple include population selection rules. Thus, we probably don't need population selection rules to be any more flexible. A possible exception concerns the Where Selection Rule which only allows limited expressions to be defined at present.

What's not obvious from the above model is how colours are used to control archetype translations. This is done by adding a new Boolean binary operator to the Archetype Language:

objectInstance coloured [ domain '@' ] colour

Where objectInstance is an arbitrary object instance expression and domain is the name of the domain which defines the statically referenced colour (which is optional if colour defined in archetype's domain). The operator simply checks for the presence of a coloured object instance for the specified object instance. An Executable UML version of the operator will also be supported:

object marked [ domain '@' ] mark

Colours are always statically referenced within archetypes allowing OOA Tool to track colour usage and rename colours automatically if necessary. I can't see a real need for archetypes to dynamically access colours at present. An example archetype code fragment is given below:

.Select many objects from instances of Object
    where selected coloured Persist
.for all object in objects
.// Generate code to persist...
.end for

Once again for those Executable UML users out there:

.Select many classes from instances of Class
    where selected marked Persist
.for all class in classes
.// Generate code to persist...
.end for

I won't go into anything else this week since I've probably already said enough! If anyone has any views on how I'm intending to support colours (and marks) then please comment (or drop me an email).

Week 25 of 2010

2010-06-30T15:34:00.004+01:00

This week's report is a little late since I thought I might finish some modelling first. The only problem with that is that modelling often leads to more modelling! I've been working on the Recursive Design and Simulation subsystems of the OOA of OOA. In fact, I've now replaced the old Simulation and Translation subsystems with new Population, Population Runtime and Colour Model subsystems. Most of the old Simulation subsystem was actually concerned with population data anyway. I've moved the few objects directly relating to simulation and translation into the Recursive Design subsystem which is a good home for them anyway. The new Recursive Design subsystem is shown below:

You can now see that recursive design involves partitioning a system into domains, bridging between domains, adding layers to those domains if appropriate (new in OOA10), populating those domains, simulating the system for testing and translating the system into the final software product. Recursive design also involves colouring arbitrary aspects of the model and/or data to control aspects of simulation/translation such as population boundaries and thread allocations. I'm providing support for basic thread pools during simulation to help facilitate successful reuse, i.e. users should always test concurrent models using multiple thread simulations. There are many other architectural concerns that are not supported during simulation. Those concerns can only be tested by running a translated version of the system using an appropriate software architecture. I may need to add support for additional architectural concerns in future, e.g. concurrent access controls. Any comments here?

Colour models and Colours in Shlaer-Mellor are known as Marking Models and Marks in Executable UML. This is a neglected area of Shlaer-Mellor methodology and not well defined in MDA either. However, the need for those ideas became evident as I started to think how I would capture thread allocations for simulation purposes and population boundaries where I want to include a subset of a given population in a simulation/translation (a good example here are metamodel populations which rarely need to used entirely). I'm still working on the Colour Model subsystem so I won't show it here. I have been thinking how I can incorporate colour models into OOA Tool but I'll leave that topic to another day also. One interesting issue with colours is how you access that information within archetype templates which traditionally only accesses object, attribute and relationship instance data.

Back to populations. The new Population subsystem is shown below:

I've made quite a few changes here. Populations are now either Input Populations which are project assets in their own right (i.e. can be imported into other projects), Executable Populations used with simulations or Translatable Populations used with translations. Input populations are Simple Populations (i.e. user data), Metamodel Populations, Composed Populations allowing a set of input populations to be merged into one, and Output Populations which are derived from the output state of a completed simulation run (e.g. a software architecture may code an optimizer as a model that can be simulated to generate optimization flags that can then be passed as input into a translation). Composed populations is a powerful concept when combined with output populations allowing multi-stage build processes to be defined.

An interesting issue with translation is what do you do about derived attributes and relationships? Do you use an active population during translation so that derived attributes and relationships are still determined on demand or do you pre-calculate all such information before you start the translation. I've taken the view that pre-calculation is best so that translation will in the most part be a deterministic process, i.e. if you recalculate on demand then the results may change if the calculation logic is non-deterministic (e.g. involves current time). However, this means that I can't set any attributes during translation (which is probably a bad idea anyway). In the above model, a translatable population is an input population with all derived data pre-calculated.

Population data and executable population data is shown in the model above. However, runtime population data could not also be shown without considerable mess. Thus, I've put all supplemental runtime population data into a new Population Runtime subsystem. This was the work I was trying to finish before I did this report but I haven't quite finished it yet so I won't include it here yet. An additional requirement here is that sufficient data be gathered so that an automatically generated Thread of Control Chart (or Sequence Diagram) can be associated with each simulation run.

So I plan on finishing the Population Runtime and Colour Model subsystems now. I'm considering whether it's a good idea to add support for what I've done here to OOA Tool immediately without waiting for OOA Tool 2 to be completed. It would allow me to validate some of the ideas. The problem is that without a working Action Language and Archetype Language, it doesn't give us much.

Week 24 of 2010

2010-06-21T14:39:00.002+01:00

I worked on the Simulation subsystem of the OOA of OOA most of the week since OOA Tool 2 needs an OOA virtual machine immediately (all derived calculations will be coded using Action Language code rather than Java code). The bulk of the Simulation subsystem focuses on data populations and the instance data associated with different types of population.

Simple populations define Object Instances, Base Attribute Instances (simple, arbitrary ID and mathematically dependent attributes), Relationship Instances (simple, associative and subtype-supertype relationships) and Participant Instances. It also defines Counterpart Mapping Instances allowing object instances in one domain to be converted to counterpart object instances in another domain within bridging code. The only population dependent values that can be used in simple populations are object instance values. Any attribute instances with a population dependent type that isn't an object instance type will have an undefined value.

Arbitrary ID attributes have a current value representing an allocated arbitrary or ordinal ID. The system automatically allocates or reallocates IDs as and when needed within limits controlled by the analyst, e.g. ordinal IDs reflect an ordering which must be preserved. Within limits, these IDs may be used outside of the system. For both of these reasons, arbitrary ID attributes require instance data. I really must finish writing up the technical note on arbitrary IDs in OOA10!

Mathematically dependent attributes can be calculated in many different ways. The simplest is on demand which doesn't require instance data. However, a minimum duration between recalculations can also be used by the analyst to restrict how often resource intensive calculations are performed. Presentation data rarely needs to be calculated more than once per second. We may also want to write calculation code which uses previous values to optimize the current iteration (verifying that the previous value is still current may be very fast and worth the effort). These kinds of analysis optimization are difficult to automate at present but should be used sparingly. None of these reasons require a current value to be persisted long-term. However, they do present a need for instance data at some point.

Referential and/or polymorphic attributes have no instance data since they are calculated on demand which generally isn't often since their main purpose in life is to ensure the model is formalized. Composed and mathematically dependent relationships also have no instance data since they are also calculated on demand.

Executable populations extend simple populations with Event Destination Instances, Event Instances, Event Data Item Instances, Operation Instances and Input Parameter Instances. It also defines Threads and Thread Allocations allowing concurrent processing resources to be allocated. The population dependent values that can be used in executable populations are object, event or operation instance values. Return coordinate and transfer vector values can't be used.

Simulations are started by generating an event or invoking an operation. An executable population allows us to define a set of triggers which can be run. It also allows us to define a thread allocation policy which is the minimum information required to execute a realistic concurrent simulation. A default mapping to multiple threads for concurrent simulation purposes is not useful in my view. If you aren't interested in defining a thread allocation policy then use a single thread. I should point out that some systems may require a minimum number of threads to avoid deadlock, e.g. invoking a synchronous service across a bridge will generally block a thread.

Runtime populations extend executable populations with Generated Event Instances (specifying whether delayed and/or recurring), Invoked Operation Instances, Output Parameter Instances and Return Communication Instances (allowing us to track return coordinate and transfer vector returns).

Generated event instances are queued on threads as determined by the thread allocation policy and are consumed as determined by OOA policy. Delayed events block the stream of events between a source/target pair of event destinations (key OOA policy is to ensure sequential processing of events between source/target pair). Recurring events are re-queued after they are consumed allowing heartbeats to be implemented. However, re-queued events may not stop a simulation from completing.

Invoked operation instances are logically pushed on to threads as invoked and pulled off when invocation completes. However, these instances may persist for various reasons, e.g. logging. A thread will also block after invoking a bridging operation mapped to a synchronous service awaiting a synchronous return operation with the correct return coordinate. A thread can also block for other reasons, e.g. awaiting input/output.

Return communication instances allow us to track how timely and often returns occur. Return coordinates must have a single timely return since a thread is waiting for the results. If a timely return does not occur then the system may generate a default return and any later return would then be flagged as an error. Transfer vectors are more flexible as determined by the analyst. They may be conditional or have a multiplicity of many. However, if not conditional then a default initial return may be generated if a time constraint has been specified. Whether any later return is flagged as an error would then depend on whether multiple returns are allowed.

Once I finish tidying up the Simulation subsystem then I will update the OIM on the website. I also need to ensure I have a clean workable design for representing runtime models in OOA Tool 2 based on this work. I also want to be able to generate Thread of Control Charts (and Sequence Diagrams for Executable UML) from runtime populations on completion.

Week 23 of 2010

2010-06-15T15:36:00.002+01:00

This week was very short since I travelled up to Nottingham to attend a family 50th celebration. I also spent some time with my much neglected relatives!

My current development focus is on the new OOA Tool 2 framework. Two subsystems of that are Dictionary and Repository. The dictionary subsystem is a compact metamodel suitable for representing the OOA of OOA. It adds support for multiple notations and Java locales (language and country). It also adds support for generic GUI presentation and validation which will evolve as the needs of the generic GUI expand. I've implemented a DictionaryTool which can convert any domain (loaded from a "<project>.ooa" XML file) into a dictionary (stored as a "<domain>.dictionary" XML file). The core dictionary files are generated from the "OOATool.ooa" model which continues to evolve (using the current version of OOA Tool).

The repository subsystem defines rows (objects/attributes are represented as tables/columns in the dictionary), transactions and location nodes. Rows not only represent object instances, they also represent relationship instances as column data since they are resolved to object references as required. Rows also represent event destination and event data since simulation objects are mapped to special tables in OOA Tool 2. This allows me to treat all data changes in a uniform way for transaction purposes. The alternative would require special undo/redo handling for every new type of data change. I've just started reworking the Simulation subsystem of the OOA of OOA so that all required special tables for simulation can be identified and implemented. Execution (rather than modelling) is the priority for OOA Tool 2. Repository data will also be stored as XML files but that work hasn't been done yet. I also need to implement a RepositoryTool which can convert any OOA Tool "<project>.ooa" XML file into a single "<project>.ooa2" XML file. The generated repository file will reference the previously generated core dictionary files which will be included in future OOA Tool 2 releases. I'll leave discussion of location nodes to another day.

I'll cut it short this week so I can start some real work! I just hope England does better come Friday!!

Week 15/16/17/18/19/20/21/22 of 2010

2010-06-08T06:49:00.002+01:00

Sorry for the silence here but I have been adjusting to single life again and it's been more difficult than anticipated.

Yesterday I finally released Build 014 of OOA Tool. However, I abandoned attempts to finish all of the features that I had started. The main reason for the release was to make available the version of the tool that I am currently using to develop the OOA Tool 2 platform. Now if I have an idea that I want to blog about that uses any of the features that were implemented in that codebase then I can go ahead and blog about it. Knowing that users can replicate any models that I show. One example is reverse parent-child relationships which I blogged about a few days ago. Whether I release any further builds based on this codebase will depend on whether I discover any serious bugs before the new platform is ready. If anyone has a problem loading their existing models using this build then they can email me their ".ooa" file and I will fix any format problems they have.

Last week, I published a new technical note for the first time in ages regarding reverse parent-child relationships. I used this note as a vehicle for testing out some new JavaScript and CSS rules allowing notation to be switched using a control that persists as a cookie across web sessions. Executable UML users can set this once and reduce the amount of Shlaer-Mellor speak they have to wade thru. Shlaer-Mellor users will also be able to avoid the amount of UML stuff they have to ignore. Now it will take time to roll out notation switching across the whole website but that is my ultimate objective. Note that the notation switching JavaScript code only works with the latest browsers, e.g. Firefox 3 or IE 8. I'm not going to bother trying to support old browsers.

Formalizing Reverse Parent-Child Relationships

2010-06-04T14:47:00.002+01:00

A notation switchable version of the following technical note can be found here: Technical Note - Formalizing Reverse Parent-Child Relationships.

Parent-child relationships are binary relationships where one participant has some form of ownership over the other. They often appear on information models as defines or contains relationships and on UML models as compositions or aggregations. The parent will normally have a longer lifespan compared to the child and will often be one-to-many but not always. In OOA10, a parent-child relationship can be explicitly formalized by adding an Arbitrary ID Attribute to the child and then using a Parent Allocated ID Type to formalize the attribute. The relationship can be ordered by specifying the type as ordinal. Ordinal ID base attributes are normally called Order in my models while non-ordinal arbitrary ID base attributes are simply called Arbitrary ID. In either case, OOA Tool automatically annotates the attribute with an "A" suffix (short for arbitrary) followed by the relationship ID of the parent-child relationship (see diagram below for examples).

All of the above is fairly straight-forward. However, there is a complication when creating reverse or secondary parent-child relationships where the child needs to reference it's own parent to formalize a second relationship between the parent and child or where the parent needs to reference a specific child for special treatment. For simplicity I will refer to both types of relationship as reverse relationships from now on. Reverse relationships will normally be one-to-one since parent-child relationships are normally one-to-many. This technical note aims to discuss some issues with formalizing such relationships. A simple example involves the relationships between Object and Identifier in the OOA of OOA. There are two obvious relationships here, the parent-child relationship defines and the reverse relationship is preferred by. The diagram below illustrates four different ways of formalizing the reverse relationship. To simplify matters, the four approaches were all defined in the same domain so I have had to use object name qualifiers, e.g. Object A and Identifier A for approach A, etc.

Starting with approach A which is the obvious approach in OOA91. The parent-child relationship R1 is formalized using Identifier A.Object against the preferred identifier of Object A with Object A.Name as the base attribute. In OOA91, we could formalize the reverse relationship R2 using Object A.Name and Object A.Preferred Identifier since we can still manually specify Name as a base attribute. OOA10 takes this option out of the hands of the modeller to greatly tighten the rigor of information models, i.e. attributes are only base attributes when they are not referential or polymorphic attributes. However, OOA Tool still allows this approach to be captured but both Object A.Name and Identifier A.Object are annotated in the OOA Tool browser with the warning "Only circular references" indicating that no base attribute could be found.

Moving onto approach B which replaces Object A.Preferred Identifier with the referential attribute Identifier B.Preferred mapped to Object B.Name. This looks a little weird when you first see it but one must remember that referential attributes are not implementation fields, only a modelling mechanism to formalize relationships. Approach B has the same relationships as approach A but we have moved the formalization from the parent to the child avoiding the problem with base attributes. However, in doing so we have weakened the formalization since Identifier B could potentially be the preferred identifier of another object entirely which we certainly don't want. In OOA10, we can add a loop constraint to the reverse relationship R4 to ensure this doesn't happen. This approach works but may confuse some.

Approach C changes Identifer B.Preferred into the boolean attribute Identifer C.Preferred and makes the the reverse relationship R6 a mathematically dependent relationship (added in OOA10). The main problem with this approach is that we need to stop an object having more than one preferred identifier. We have two choices here with regard to the Action Language code formalizing R6:

we can decide which identifier flagged as preferred is actually the preferred identifier (e.g. first flagged) but we can't use the boolean attribute directly as an indicator,
or we can determine all preferred identifiers and the modeller can rely on a constraint error being flagged if more than one preferred identifier is set.

Both choices still require careful coding when determining preferred identifiers and setting them.

The final approach D which is the recommended approach since it has none of the drawbacks of the previous approaches yet it can always be used to formalize reverse relationships. It uses the associative object Preferred Identifier to formalize the reverse relationship R8. The only perceived disadvantage here is the addition of the new object. However, this is a modelling mechanism and does not imply any additional implementation code is required. Modellers may try to avoid this approach to reduce clutter but the previous approaches add complexity and additional error possibilities. If an Identifier D.Preferred boolean attribute is still desirable (perhaps to allow changes to be more easily observable in another domain) then a mathematically dependent attribute can still be added to Identifier D which checks whether a Preferred Identifier exists.

As a side note, the OOA of OOA actually uses approach A and is able to do that because Name isn't defined as a base attribute of Object in the Information Model subsystem. Instead Object is a subtype of Entity which defines Name as a base attribute. This indirection performs a similar role as the associative object in approach D. However, adding a subtype-supertype relationship above a parent is not a general solution to the problem which is why it's not given as an approach here.

Week 13/14 of 2010

2010-04-12T14:13:00.002+01:00

I'm going to keep this report brief since most of what I'm doing at the moment is framework and GUI coding. I hope everyone had a good Easter break. I've spent the last 2 weeks recoding the application/applet GUI classes which provide the user's front-end to OOA Tool 2. The overriding priorities for the new code is that it be seriously scalable and easily maintainable. I'm also putting all UI text in a resource bundle that will allow users to override for their locale (I might even have a go at producing a French resource bundle). In the original code, I was trying to be too clever in certain areas which was fine initially but as requirements grew some of this code resulted in unnecessary rework.

One example here regards various colour-coded text editors where I created my own StyledDocuments allowing the user to edit multi-colour text, e.g. for Pattern/Action/Archetype Language code. The problem here is that the underlying Java classes are pretty fragile and I'm being nice here! Whenever any of the various syntaxes changed I would have to rework these classes. A simpler approach is to use a split pane with plain text in the top for user editing and in the bottom HTML text providing optional colour highlighting. When the syntaxes become final I can then invest some time in creating custom StyledDocuments if necessary. Furthermore, the HTML text can be generated using templates which allows for user customization which is a nice extra feature.

Well that's all for now.

Week 12 of 2010

2010-03-30T09:55:00.003+01:00

Work is progressing nicely on OOA Tool II. I spent some time getting the new GUI framework started this week. I've been able to drop some nasty workarounds from OOA Tool I that were needed because of J2SE 5.0 bugs. There are a lot less bugs in Java SE 6.

I'd like to talk about a mapping from objects, attributes and subtype-supertype relationships (SSRs) to tables and rows. Within OOA Tool I, object instances stored as rows were mapped directly to objects. However, the design required a knowledge of subtype-supertype relationships and an ability to migrate between subtypes while preserving object instance references. I wanted to take SSRs out of the picture entirely in the more generic OOA Tool II architecture. Otherwise, I would need to add the concept of SSRs into the Data Management dictionary subsystem.

To eliminate SSR's, objects and the SSR's that bind them are used to create object families (an object family is the set of objects inter-related by an SSR graph) and object combinations (an object combination is a subset of objects that may exist at one time as part of an object family instance, i.e. it defines a particular combination of SSR choices). The algorithm used to determine these is highly recursive and quite complex (maybe another day!). Each object family has one or more root objects (objects which never participate as subtypes) and one or more object combinations. The name of each object family can be derived from it's root objects and in many cases there will only be one. The name of each object combination can be derived from it's leaf objects (objects which never participate as supertypes).

In the new design, an object instance reference is actually an object family instance reference with an object reference for type qualification. While an object family instance held as a row within a repository table contains the cells for all potential attributes that an object family instance may have. It also has a current object combination indicator allowing us to determine which cells are currently accessible.

Migration now involves updating various cells in a row along with a simply change of object combination indicator. To determine if a particular object family instance reference is still valid one only has to check whether the current object combination indicated includes the object used as the qualifier within the reference. When an row is marked as deleted, depending on a setting associated with any reference holders (i.e. cells in other object instance family rows) we can now either: make reference holders invalid since they hold an invalid reference, automatically remove the reference from any holders allowing the holders to remain valid, or attempt to delete any reference holders to fix the situation.

Cast operations between different objects are easily performed by creating a new object reference containing the same object family instance reference but with a different object qualifier. Obviously, a cast is statically invalid between objects in different families, and dynamically invalid to an object not included in the current object combination indicated by the referenced object family instance. The scheme that I have adopted cleanly eliminates all SSRs without losing the benefits. The primary disadvantage is that each table row is now potentially much bigger than it needs to be. However, memory in my experience is not a resource in short supply.

Some graphic examples would have been nice here but I don't want to spend all day on this blog. Hopefully, I'm managed to convey the basic approach I'm using to eliminate subtype-supertype relationships (which are difficult to implement without recursive algorithms everywhere) from the OOA Tool II architecture by adding object families and combinations (which are easy to implement with simple lookups).

Week 11 of 2010

2010-03-22T07:45:00.004Z

This week was very productive, focused mainly on the new Data Management domain at the heart of the new OOA Tool II architecture. I had some interesting thoughts on how OOA Tool has evolved and how it will evolve in the future:

OOA Tool I (previously labelled OOA Tool 1.0) was incrementally prototyped. The approach allowed me to develop a rich OOA of OOA going beyond what was originally specified in OOA91 and OOA96, in step with a tool that supported it. However, over the last year I have spent a lot of time trying to make what should be simple changes work. Prototypes are just not scaleable or maintainable beyond a certain size and OOA Tool I has 145,000 lines of compact Java. However, without the knowledge gained from this prototype I would never have been able to develop a suitable architecture for the next version.
OOA Tool II will comprise a completely generic configurable core (the Data Management domain) driven by XML dictionary/repository files for OOA of OOA, Work Product and GUI domain metadata/data. This version will include a working simulator and translator. It will allow me to develop one or more working software architectures (Shlaer-Mellor RD style).
OOA Tool III (in the future) will use archetype templates to generate custom business objects and editor forms with a much reduced need for the previous generic configurable core. This version should be very fast (not that speed has been a problem so far) and may even include a web interface since we could generate active web content rather than traditional Java code. This version will fully demonstrate the power of Shlaer-Mellor OOA/RD, i.e. a code generation tool built using code generated from itself.
OOA Tool IV? I'm not sure what major architectural improvement would drive this version. Perhaps a knowledge based query driven design assistent developed using the previous version could be used to automatically generate the necessary RD mappings to a generic software architecture. This is what I originally imagined OOA Tool would evolve into - an OOA/RD CASE tool with AI support for OOA/RD.

Now to progress on OOA Tool II:

Now that I have dropped J2SE 5.0 support, I can take advantage of bundled features of Java SE 6. Loading OOA project files with Java SE 6's built-in XML parser is extremely easy. The first task was to load the OOA of OOA domain and create a suitable dictionary for the Data Management domain. Once created, this can be saved to a XML dictionary file for faster loading later. Last week, I mentioned that I would probably hand-code these dictionary files. However, it has become obvious that the process can be automated (with some hints not captured by OOA Tool at present) allowing future OOA of OOA changes to be deployed to OOA Tool II quickly. This involves mapping Objects, Attributes and Relationships to Node Types, Subnodes and Property Types (I will discuss this mapping in the future since it is a design problem for anyone generating code from Shlaer-Mellor OOA models).
The second task now that the dictionary (i.e. metadata) is populated (or at least on the way to being populated) from the OOA of OOA domain, is to populate the repository from one or more project files using the OOA Interchange Format. Since I have already been using Java's built-in XML parser to do this task - no problem here. Except that the mapping from XML element/attributes to node/property types (in my dictionary) is a quirky one since the OOA Interchange Format was developed by hand. Future versions of the format will be generated automatically from the dictionary which is itself generated from the OOA of OOA.
I have also extended the Data Management domain to include a Data Management Language that is a cross between an Action Language and an Archetype Language. This is going surprising quickly. I hope to develop the final Action/Archetype Languages as subsets of this language (maybe with a different syntax) making the simulator and translator relatively easy work. I will publish the syntax for this in the future.
I haven't started working on the generic GUI yet since I first needed to be able to load metadata and data to browse. However, I will create a basic GUI domain especially for menu controls since OOA Tool I is mostly driven by menu controls and it would be nice for these to be configuration driven. The main components that I need are a tree browser and form editor. The tree browser is mostly generic in OOA Tool I. However, I want to incorporate more drag-and-drop functionality in OOA Tool II. Form editors in OOA Tool I were mostly hand-coded and this will be one of the major improvements of OOA Tool II since I will use a completely generic form editor. Obviously, I need sufficient information in my metadata to configure these. However, final validation of constraints is left to validation checking functions in business logic plug-ins (most OOA of OOA objects will have a hopefully small business logic plug-in). It should be possible to generate this logic automatically from an OOA model if all mathematically dependent attributes and relationships are coded in the OOA model (which they are not at present).

Obviously, the mythical build 014 for OOA Tool is on hold at present. However, coding of the OOA Tool II core is going fast enough that it will probably be the basis for the next build. I would estimate the work taking a few months. The difficult issues here will relate to moving across and testing all of the OOA of OOA business logic (constraints and derived calculations).

Week 8/9/10 of 2010

2010-03-15T12:50:00.003Z

I have lots to say this week! I've been remiss over the last few weeks (i.e. no blogging) because I have had so many new ideas that I didn't want to sit down and try to explain them until the ideas had more fully matured. Some of these ideas have gone in unexpected directions and so now I have to sit down and do some explaining. Each of the different areas that I have been working on is numbered below.

(1) I evolved the Diagramming domain into a more complete Work Product domain with Diagram, Table and Template subsystems (not all done yet). The mission statement for the new domain covers work product information that needs to be persisted along with OOA of OOA information in model files. This is distinct from what is needed to display and change the work products in a GUI. This domain will be published since it forms part of the OOA Interchange Format.

(2) I also evolved the Naming domain to Name Management then to Text Management and finally to a Data Management domain with Dictionary, Repository, Change Control and Text subsystems. This domain will now be proprietary in nature but will have an open interface for user supplied language resources (e.g. French resources).

The Dictionary subsystem will allow notation and locale (language, country etc.) specific titles and icons to be loaded from Java resource files. The dictionary itself will now be loaded from an XML file. This XML file will initially be hand coded for OOA Tool but will later be generated from the OOA of OOA via an archetype template. Yep, I'm moving towards a self-generated OOA Tool.

The Repository subsystem with include built-in file system support that will allow all files to be loaded either from a local or networked hard-drive or over the internet. This will later be expanded to support database persistence and shared access.

The Change Control subsystem breaks down all changes into atomic reversible changes which are bundled into reversible transactions. Complete validation checks are then performed before transactions are committed. The repository will only save committed transactions. Users will be able to cancel a transaction or undo previous transactions (in order obviously). They will also be able to redo transactions etc. This will be a massive change from what is currently supported in OOA Tool.

The Text subsystem expands on the previous Name Management domain. I may separate this subsystem back out in future.

(3) I added concepts of Empty State, Deleted State, Creation Transition, Deleted Transition, Deleted Event and Communication Path to the State Model subsystem of the OOA of OOA. These changes were the result of a better understanding of what is needed by the Table subsystem of the new Work Product domain and what is needed to support Shlaer-Mellor and Executable UML notation.

It also reflects an important shift from user controlled memory management to automatic garbage collection, i.e. Deletion State is where user requests a deletion while Deleted State is a logical state after which deletion has occurred via garbage collection (a state which has meaning in the model but not at run-time). I personally don't believe it is possible for users to safely manage memory allocation and deallocation. For this reason, OOA10 reflects this assumption. You can still create C archetypes with memory allocation and deallocation logic but executing a delete object instance Action Language statement does not immediately delete an object instance. It only requests that a deletion should be carried out once all references to the object instance are cleared. However, users will not be able to search for a deleted object instance or navigate to such an instance but there may be any number of events carrying references to a deleted object instance (which we can't delete without unknown repercussions). There may also be actions being executed in parallel with access to deleted object instances (which would be impossible to delete).

(4) I have also been thinking about how to commercially manage reusable assets using public/private key encryption. Service domain suppliers will have their own public/private keys for their products (packaged as model files). They will securely distribute the public keys to licensed users. They will then encrypt the associated products (i.e. model files) using their matching private keys allowing the products to be openly distributed across the internet. Users download the products over the internet but have to manually enter any public keys into OOA Tool to access the products. OOA Tool will decrypt as required. This approach also allows users to verify the source of the products since public/private key encryption can be certicate based.

This approach can be extended to allow controlled user access (without having to securely distribute public keys) using an OOA Tool supplied public/private key combination. OOA Tool will include it's own public key hidden within itself while the private key will be made available to suppliers on request. Each imported domain will then be assigned an access level (from most restrictive to less restrictive):

View - View domain as black box only allowing user to see control reception points, e.g. synchronous services, external events etc.
Simulate - View domain as black box but allow OOA Tool simulator to access whole of domain for simulation purposes (users can't trace into domain making reverse engineering difficult).
Translate - View domain as black box but allow OOA Tool simulator and translator to access whole of domain (obviously, output files from translator make reverse engineering easy).
Edit - View domain as white box giving users full access.

The OOA Tool public/private key can be used as well as the the supplier's own public/private key to provide a flexible solution for commercial distribution of OOA assets.

(5) Finally, I have come to realize that the architecture of OOA Tool 1.0 is fatally flawed since it is not scalable or maintainable. The new Data Management domain will form the basis of future OOA Tool 2.0 development. The OOA Interchange Format will evolve in a controlled fashion so that users will be able to load old models. I may also continue with the old infrastructure for a few more builds. However, I will start to migrate stuff over as soon as the new stuff is stable. Since the Data Management domain will deliver a majority of OOA Tool 2.0's functionality, I have decided to make it a proprietary domain and not publish the domain's model. However, the OOA of OOA and Work Product domains will continue to be published and obviously the OOA Interchange Format will continue to be completely open. The new architecture should allow me to create changes in the OOA of OOA and rapidly roll them out. It should also allow me to make significant generic changes in the GUI without having to manually update large amounts of model specific GUI code.

That's all for now. Comments always welcome.

Week 7 of 2010

2010-02-23T14:33:00.002Z

I continued working on the Recursive Design subsystem (follow this link if you want to understand what is discussed below!) and it's implementation within OOA Tool this week. I have moved bridge mappings, wormholes and control reception points into the Operation subsystem. This makes the RD subsystem much more managable and makes room for future growth, e.g. additional types of reusable assets will probably be added.

I replaced Domain IDs (Dn), Bridge IDs (Bn) and Layer IDs (Ln) with Asset IDs (An). This change means that bridge links within Domain Charts now use Asset IDs rather than Bridge IDs. However, I convert Bridge IDs when a model is loaded to maintain backwards compatibility. This also allowed me to change Data Type ID format from DTn to Dn.

Domain Activity is now Asset Activity allowing bridge and layer activities to be captured in a Project Matrix. I also renamed Activity to Task Activity to avoid confusion. However, to keep Project Matrix size down, columns are now only added when there is at least one activity in a column. Thus, they now look very empty to begin with. Note that, activities are project specific, i.e. are not loaded from imported assets.

Domain names are an interesting issue. They are currently unique within a project and are used as domain shape names within Domain Charts. However, imported domains load their names from an external project and thus may break uniqueness. This can be avoided by adding an External Name attribute to Imported Asset. However, you then have two names which may get out of step in a significant way. The alternative is to drop the uniqueness constraint and allow domain names to be duplicated. Since we now use domain role names within bridge mapping and domain observer code, this shouldn't be a big issue. I would need to change domain shape names to use Asset IDs. Domain Chart diagrams can also qualify duplicated domain names using Asset IDs to avoid confusion (if necessary). I'm 95% sure that I should choose the latter solution. Arguments to the contrary are welcome.

A similar issue concerns the multiplicity of bridge associations, i.e. whether each client/server domain pair can have at most one bridge. This made sense when all assets being bridged were local to a project. However, one may want to import two domains along with a existing bridge between the two domains, yet also add additional bridge mappings using an additional local bridge. This changes the multiplicity of R7 (in the RD OIM referenced above) to many. One could even imagine creating two local bridges within a single project to facilitate reuse by separating core bridge mappings from application specific bridge mappings. Making this change seems to be well justified so I will go ahead and change this next week.

I also downloaded the latest JDKs from Sun's website. I am now using Java SE 6 build 16 (JDK 1.6.0_16) for development and testing purposes. I also downloaded and tested Java SE 7 beta build 76. This beta still can't display HTML tables correctly so I can't recommend it yet. I also attempted to download J2SE 5.0 (JDK 1.5.0_22) but have gotten no response from Sun from a form request I submitted. It has reached end of life but I was still hoping to support it until Java SE 7 is finally released. Since it can't be downloaded anymore, I have decided to drop support for J2SE 5.0 from the next OOA Tool build. That means that I can now start using features that where added in Java SE 6 and remove numerous workarounds for J2SE 5.0 bugs (mostly GUI related). The next build will use the new class file format (50.0) so it definitely won't be runnable using J2SE 5.0. Speak now if anyone has issues with this decision, e.g. if you are running OOA Tool on a platform without Java SE 6 support.

Week 6 of 2010

2010-02-16T06:32:00.003Z

I'm slowly getting back into things this week. However, I haven't been focusing on the priority one item which is to get Build 014 released. Instead, I have been trying to sort out a workable design for high-level reuse in the Recursive Design subsystem of the OOA of OOA. Enabling reuse of service domains and software architectures has always been a primary objective of OOA10 and OOA Tool. However, the current version of OOA Tool only supports reuse via copy and paste.

I've been working on a few ideas for reusing domains for some time. The main issue that has stopped me implementing an approach has been how to resolve parent links from a domain to the enclosing project, many of which are GUI related. I originally wanted users to be able to open multiple projects within OOA Tool where one project reuses one or more domains from another project. I envisaged a particular domain having only one actual instance at any one time. However, this leads to all sorts of linkage problems that could not be resolved without increasing the complexity of the current implementation considerably. Thus, I decided to abandon the goal of having only one instance of a domain at any one time. When a domain is imported into another project and separately loaded then it will be copied into that project but will not be persisted with the project. Users will also not be able to edit imported domains. They will be able to reload them. Automatic synchronisation may be possible in the future but will probably be processor intensive.

I also decided to broaden reuse across a number of high-level assets including domains, bridges and layers. I will probably add populations and transformations (simulations and translations) to this list in the future. This was done by defining a new Asset object which generalizes high-level reusable components. To reuse an asset within a project, users must first define an External Project allowing the location of the asset to be specified, then an external asset can be defined which imports the desired asset from the external project. The asset can then be loaded from the specified location, e.g. the associated information model can be loaded. Users can also load the whole of the external project into OOA Tool. In this situation, any external assets which are loaded (or reloaded) should be loaded from the current instance of the external project which may have been edited since it was loaded.

Bridges and layers introduce an additional resolution issue when they are reused. A simple mechanism for importing a bridge would be to ensure both the client and server domain were already imported from that external project. However, either or both domains may have already been imported from another external project. Alternatively, a newer or compatible version of one of the domains may already be defined in the project. The approach that I have decided to adopt for now is to require users to explicitly resolve client and server domains when they import a bridge from an external project. If the domains are incompatible with any bridge mappings then appropriate errors will be flagged separately. The same applies to layers, users will need to explicitly resolve all connected domains when a layer is imported.

This approach provides considerably flexibility but leads to an interesting problem. How do we identify client and server domains within bridge mappings, e.g. when we want to qualify a data type. I had envisaged using domainName@ prefixes as needed within bridge mapping code. However, we may want to resolve a client or server domain to a domain with a different name. The solution I have adopted is to define domain role names and use those within bridge mappings instead, i.e. users will now use client@ or server@ prefixes instead. This solution can also be adopted in domain observer code assuming each connection defines a unique role name.

OK, so I have a workable design for domain (and other asset) reuse within projects. I have started implementing the above design and another week or so should see this work finished. This work needed to be done sooner rather than later anyway. Comments always welcome but I prefer them in English!

Week 3/4/5 of 2010

2010-02-09T16:10:00.003Z

I haven't been able to spend much time on this project over the last few weeks. I've done some modelling and fixed a few OOA Tool bugs but I haven't made substantial progress towards getting the next build released. However, some of the bugs might be quite annoying for anyone using the last ALPHA release so I have done another release which can be downloaded from the following link:

2010-02-08_OOATool014_ALPHA2 (8.33 MB)

Week 2 of 2010

2010-01-18T11:55:00.006Z

My enthusiasm still seems to be on holiday at the moment. It better come back soon or I'm going to be pissed! I spent most of this week doing admin stuff and going over last year's progress in detail. I've renamed OOA09 to OOA10. I also moved my whole website onto a new server at www.easily.co.uk to take advantage of a free bandwidth offer. I reinstalled the forum from scratch using the latest version of the software. However, within 5 minutes of installing it I already had several bots trying to register user accounts. I've now disabled user registrations. I would love to get the forum going but anyone who wants to register will now have to email me first.

Below is a summary of last year's progress:

January

Added Project Matrix support.
Added Metamodel Population support.

February

Released Build 013 of OOA Tool.
Created an OOA model of fUML.
Published technical note on Attribute Classification.
Referential and polymorphic attributes now calculated automatically in model populations.
Abstracted concept of operation and parameter out of OOA of OOA's process model subsystem.
Adopted Nimbus (from Java SE 6) as default look and feel for OOA Tool.

March

Added Object Instance Type support.
Redesigned and reimplemented preferred types.
Worked on Action Language syntax and semantics.
Adopted policy of automatic creation of supertypes so that users do not need to relate or unrelate subtype-supertype relationships any more.
Predefined type visibility within tree browser now depends on whether they are referenced within model.
Added Event Reference Type support.
Mathematically dependent referential attributes which link to mathematically dependent relationships added.
Simplified default value design on attributes and data items.

April

Major rewrite of attribute's derived fields which are pretty complex.
Published technical note on Custom and Automatic Key Lettering.
Added Enumerated Subtype Type and Enumerated State Type support.

May

Added four new statements to Action Language which aren't defined in OAL: a declare statement, a switch statement, a migrate statement, and a delete event instance statement.
Published technical note on Synchronous Communications between Domains.
Published technical note on Asynchronous Communications between Domains.
Prototyped wormholes and bridge mappings.
Evolved concept of watchpoint mappings into domain observers.

June

Published technical note on Semantic Shift.
Explored use of declare statement in error handling.
Considered introducing mathematically dependent objects but have held off for now.
Identified need for operation owner and semantics of operation name ownership.

July

Added data type unary/binary/dot operators as a new type of operation.
Renamed Data Dictionary subsystem as Data Type subsystem.
Identified clear role for process models as means of identifying concurrent data flows which is no longer a responsibility of the Action Language.

August

Explored partial/complete ordering of objects and identified a potential use for aggregation and composition within Executable UML.
Added Ordered Identifier support.
First major refactoring of OOA Tool code - made ModelElement parents static, added deleted status, improved changed status and used Java generics to specific parent type.
Allow users to control importing of objects and event destinations in various diagrams.

September

Merged in some Java classes from a previous project: status bar component, console panel component, and improved event logging.
Second major refactoring of OOA Tool code - added factory reference to all ModelElement classes using Java generics to control typing, and added view factory mechanism.
Third major refactoring of OOA Tool code - encapsulated all Shlaer-Mellor and Executable UML terminology into OOA Dictionary component, added OOA Dictionary web page generator to that component.

October

Added version control to OOA Dictionary and can generate OOA Dictionary web page within OOA Tool.
Old icons recoloured and lots of new icons added.
Now allow subtype-supertype relationships with only one subtype participant.
Added automatic backup mechanism for model files.
Modelled a new File System domain which will be bridged to the OOA of OOA (and implemented in OOA Tool) in the future.
Added Layer concept to Recursive Design subsystem.
Final attributes are now tagged with an "(F)" suffix in OIMs.
Verb phrase concept is split into verb phrase before and verb phrase after to clarify meaning and allow generalization.
Roles which appear within associated verb phrases are now highlighted on OIMs and class diagrams.
Added concept of qualified verb phrase providing a more stable identification scheme for relationships compared with relationship IDs.

November

Resigned Naming domain as Name Management domain, adding a Name Manager external entity to OOA of OOA encapsulating all the various types of name and qualified name used within the OOA of OOA.
Created a detailed state model for name parsing.
Added numeric word formatting support to Name Format and decided that numeric ID names within OOA of OOA should be padded by default.
Developed data type to object bridging ideas from OOA of OOA to Name Management bridge - external types now allow a literal type to defined which allows external types to have default values, and external operators can be defined on external types which may override predefined operators such as equality.

December

Added support for reference field navigation to OOA Tool GUI which was incorporated into all data type forms.
Finished all outstanding tasks in the Data Type subsystem.

What it does not include is a working simulator or model compiler. The original goal for 2009 was to get OOA Tool out of BETA which requires working simulation and full translation. What went wrong?

The first thing that went wrong was that I didn't perform enough analysis of the Operation subsystem before I jumped into coding. This is an area that isn't well defined within Shlaer-Mellor or Executable UML, especially with regards to bridging operations. I was also determined to find a role for process models within the framework. The Operation subsystem also interacts with an Action Language subsystem that also isn't well defined with each tool vendor defining their own action language. The result was numerous iterations of ideas and a considerable amount of recoding.

The second thing that went wrong was a number of major refactorings of the OOA Tool code base. These required major effort to complete since the code base is already so large (almost 140K LOC excluding comments). They have improved the code considerably but each major refactoring left me pretty drained. Of course, if I was generating my model element classes from archetype templates and the OOA of OOA then these refactorings would have been much much easier.

The third thing that went wrong was that I made too many changes to the code base making me reluctant to release ongoing builds until a stable build was ready. The OOA Interchange Format and OOA of OOA then got out of step. This turned Build 014 (which has still not been released) into a year long effort rather than a 3 month effort. Not being able to release any stable builds has been a big downer and reduced external interest in the overall project.

So what now? I need to stabilize everything I'm doing. Get Build 014 released. Publish a number of partially complete technical notes that should have been published last year. Make my website notation switchable since I don't like mixing terminology within my web pages and I have no intention of giving up on Shlaer-Mellor notation even though most users are more interested into Executable UML notation. I then need to plan out future builds so that they are more timely. I would still like to get OOA Tool out of BETA this year but I would settle for a working simulator with a version controlled Action Language.

I'll end this week's report with a suggestion that you all have a browse of Kennedy Carter's new redesigned website. Hopefully, they will continue to expand the online content now that it has been refreshed.

Week 1 of 2010

2010-01-11T07:55:00.002Z

Happy New Year everyone. We have still got plenty of snow here in Colchester which is unusual. I'm also just recovering from a stinky cold which I probably picked up in the Costa coffee shop I like to chill out in. I had hoped to be productive over the Christmas period which so didn't happen. Instead, I've read lots of novels. English TV is always full of repeats and rubbish during Christmas. Although one of my favourite BBC shows Being Human has just started a new series.

I need to get my priorities straight this year and ensure that I deliver working code generation in OOA Tool. My biggest problem will be motivation since I have been working on the project for a full 3 years now by myself. Many features (and technical notes) were left unreleased last year because I failed to finish off the features in a releasable form. This must not continue this year. I have decided to allocate another full year to the project. However, after next year I will probably return to mainstream consulting/development for a break and to shore up my finances. The project will still continue part-time after that. I have no doubts about the overall goals and objectives of the project. However, getting other people to participate in the project has been incredibly difficult. I hope more people will contact me this year with a view to contributing or sharing models etc. Drop me an email if you want to get involved.

Week 51 of 2009

2009-12-23T07:27:00.006Z

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.

Week 50 of 2009

2009-12-16T07:44:00.002Z

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.

Week 49 of 2009

2009-12-07T13:08:00.002Z

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.

Week 48 of 2009

2009-12-02T14:38:00.002Z

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!

Week 47 of 2009

2009-11-24T07:52:00.009Z

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.

Week 45/46 of 2009

2009-11-16T13:02:00.008Z

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 vector~~return coordinate from the synchronous service to the creation event allowing a final Parsing Complete state to invoke a synchronous return back to the original synchronous name creation process in the OOA of OOA domain. This starts to show the power of bridges. Obviously, the software architecture needs to be able to generate efficient code for state models which only contain local events (excluding the original creation event).

Anyway, I probably shouldn't say anymore about this until after the new Naming technical note is published. With regard to the mythical next build, I think I'm going to have to temporarily disable some of the new features I've not yet finished (e.g. operations) so that I can release all of the other good stuff I have finished. The one important thing I have to do is sort out OOA Interchange Format 0.05 so that maintaining backwards compatibility after Build 016 is released is not a complete nightmare! Assuming I disable any incomplete features I should have a build released sometime in the next 2 weeks. Then I can get back to regular builds.

Week 44 of 2009

2009-11-04T06:47:00.005Z

Last week I mentioned that I would provide a few screenshots of the new relationship identification scheme in OOA Tool. The first shows the Information Model subsystem from the OOA Tool Model which uses Shlaer-Mellor notation:

You can see that relationship IDs are still used as before but users can now search for relationships by a primary object followed by a verb phrase following by an optional secondary object. This is much easier and is more natural when tracking down a navigation in some Action Language code which no longer has to reference relationship IDs. There is still a minor issue here concerning which object is selected as the primary object in this scheme. I have chosen the first object for simple, composed and mathematically dependent relationships, the associative object for associative relationships and the supertype object for subtype-supertype relationships. Obviously, searching for details of a navigation from a secondary object is still more difficult at present. However, all navigations should involve the primary object, e.g. all subtype-supertype navigations involve the supertype object. The only partial exception is that a user could navigate across an associative relationship without explicitly referencing the associative object since the Shlaer-Mellor virtual machine can handle any navigation thru the associative object automatically.

For simple relationships, the initial choice of first object is often arbitrary and has been of little concern in the past. However, users may now want to select the most apprioriate primary object as their first object when creating simple relationships, e.g. in the relationship INFORMATION MODEL defines OBJECT, the INFORMATION MODEL object is definitely the most appriopriate primary object and thus should be first. Users can still swap first and second participants around later if they want to change their mind.

The second screenshot shows the Elevator PIM from the Starr01 Elevator Model which uses Executable UML notation:

You can see that relationship IDs are still used but are shown in the property list associated with each relationship.

I'll keep this week's report brief otherwise next week's report will be even briefer since I'm eating into next week's available time! However, I will mention that I revisited the Naming service domain used in the OOA Tool Model and the Naming technical note that was previously blogged. I've significantly revised the model and have resolved how the Naming service can be bridged to the OOA of OOA domain where names are used. However, I will leave the details until later since I plan on republishing the technical note. The new technical note also includes a Java Applet allowing name parsing and formatting to be demonstrated!

Week 43 of 2009

2009-10-26T12:31:00.005Z

I've got lots to talk about this week. I started the week by implementing a feature that I've been thinking about for ages - automatic backups when saving. When a project is saved, the old version will now be renamed (not overwritten) using a "~1" suffix. If a "~1" backup already exists then it will be renamed as "~2" etc. How many backups are allowed is now controlled by the user preference Maximum Backups which can be set from the Preferences menu. This also applies to other input files such as action, archetype and pattern files.

After this was done, I started thinking about a File System service domain for OOA Tool so that that the concept of location, location format etc. would not pollute the OOA of OOA domain. I've mentioned previously that I was going to do this. I've almost finished the model now but I will leave a detailed discussion for a separate technical note. However, I will mention that this domain allows files to be located using a filename or a URL from an underlying file system or from an internet but files won't be saveable to an internet.

While I was creating the File System model, I ran across a nasty bug in OOA Tool. I could not save my model since some validation logic was stopping me from creating an unloadable model but it didn't give me enough information to work out how to make my model loadable again! Since I've been coding OOA Tool (132KLOC currently) by myself, I have to code in an ultra-protective way to ensure bugs don't cross logic boundaries. My strategy in this situation was a little too overprotective! I have fixed the actual bug now. However, I have also introduced a dialog to give the user the opportunity to save a model anyway since a clever user may be able to patch the XML file themselves (or email it to me and I will do it). Moving forward, I need to add a new automatic fix option that would involve the selective removing of broken elements from a model. Obviously, it shouldn't actually be needed but the OOA Tool software is constantly expanding and I prefer to over validate than under validate.

Since I was looking at file issues, I also had another look at how projects can be linked together allowing domains and bridges to be reused without resorting to copy and paste. This is a serious problem that sits at the heart of my vision to enable a marketplace for service domains. I've already captured some of my ideas in the Recursive Design subsystem of the OOA of OOA but the ideas aren't implemented yet. One aspect of the model that I realised wasn't well thought out was the ownership of domain observers by the domain being observed. Domain observers sit above multiple domains observing one aspect of one domain but potentially effecting any number of domains as a consequence. Thus, they should really be owned by the project rather than the observed domain. However, if I did this, I would lose the ability to reuse the domain observers from another project. A concept was missing which I will add in the near future. I'm calling this concept a layer and it will own a set of domain observers. Users will be allowed to import layers which sit over already imported domains. These layers mirror aspects in aspect-oriented programming which I discussed last week. Maybe I should think about supporting more aspect-oriented features within layers? As always, comments welcome.

During the week I also decided to make a small notation change in Shlaer-Mellor OIM diagrams. Literal attributes which have an initial value which is also the final value are now shown with an "(F)" suffix. I was already using the suffix in the browser but I decided that it should also be visible on the diagram. This is a tricky area since I don't want to change Shlaer-Mellor notation, only add to it were necessary. In this case, the new suffix will only appear if users are using the new literal attribute feature of OOA09. Executable UML users will already see a "{frozen}" suffix instead while Executable UML2 users see "{readOnly}" since this property was renamed in UML2.

Somehow I got sidetracked during the week into looking at participant verb phrases and multiplicity. One area of confusion regards binary participant verb phrases. I originally associated the verb phrase before the participant with the participant but I changed this to the verb phrase after several builds ago. I did this because all participants have a natural verb phrase after. However, I didn't previously capture this in the Information Model subsystem. I have now added a polymorphic attribute Verb Phrase After to the Participant object along with additional attributes in the various subtype objects. I also added a mathematically dependent attribute Verb Phrase Before to Binary Participant since that is what is used when displaying a binary participant as a connector. This should clear up any verb phrase confusion now. I also decided that associative participant verb phrases should be displayed on OIM and class diagrams (if defined) to help ensure associative objects are appropriately named. I also visited multiplicity issues but I think I will leave this discussion to another day when I have less to talk about.

An interesting verb phrase display tweak that I implemented in OOA Tool this week is that roles that appear within associated verb phrases are now shown on OIM and class diagrams by tweaking the fonts, e.g. DOMAIN assumes capabilities provided by server DOMAIN highlights the fact that server is the role name by removing the italics. Executable UML adds italics to roles instead while Executable UML2 uses bold for roles. Binary relationships with long verb phrases can now define roles which are taken from those verb phrases to make navigation expressions within code less verbose while at the same time not defining hidden information. Roles can be viewed as abbreviated verb phrases as a consequence. This should stop users defining short but meaningless verb phrases because of worries that the code will be horribly verbose (and they don't want to define hidden role information), e.g. who wants to write domain->Domain['assumes capabilities provided by server'] when they can write domain->Domain[server] instead while avoiding hidden information and preserving the original longer verb phrase.

The final thing I want to discuss is relationship IDs which have caused me loads of problems while implementing metamodel population logic (which involves thousands of lines of code within OOA Tool). Relationship IDs are great for cross-referencing referential attributes and composed relationships on an OIM or class diagram. They are also convenient for use in OOA Interchange Format files. However, they are not so good when you are browsing relationships with the OOA Tool tree browser and they are a nightmare when manually coding logic derived from a model. It is easy to mistake the meaning of a relationship ID in this context since the ID contains no semantic information. Any such code can also be very brittle, i.e. if the relationship ID changes in the model you must change it in the code. I've already eliminated the need to use relationship IDs within Action Language code by allowing verb phrases and roles to be used instead. I also allow verb phrases and roles to be dropped when the destination object is sufficient information in itself.

However, how do you identify an arbitrary relationship within a domain without using a relationship number or ID? I finally determined a solution which revolves around a relationship verb phrase, the object before and optionally, an object after. Associative relationships can be identified using the associative object along with the verb phrase defined on the associative participant. Other binary relationships can be identified using the first object, the verb phrase after associated with the first object and the second object. The second object can be dropped for reflexive relationships, i.e. where first and second object are the same. Subtype-supertype relationships can be identified using the supertype object along with an implicit "is a" verb phrase. These conventions mostly work as is. However, to ensure uniqueness, an algorithm may need to alter (using some form of suffix) some verb phrases in a similar way to how key letters are always made unique in OOA Tool. I've now added Custom Verb Phrase (optional), Default Verb Phrase (derived), Verb Phrase (derived) and Qualified Verb Phrase (derived) to all relationships as part of the implementation of this new alternative identification scheme. Users can rely on default verb phrases with automatic addition of suffixes where necessary. However, they can also define custom verb phrases if they want to make relationship identification easier. The qualified verb phrase attribute holds a compound value composed of several names. I need to add a new Qualified Name object to the Naming service domain to handle this. This discussion is easier to visualize when you are sitting in front of OOA Tool but you have to wait for the next build for that. I will give you some screenshots next week when I finish updating the browser to sort relationships using the new scheme.

Week 42 of 2009

2009-10-19T12:09:00.005+01:00

I've finally finished the OOA Dictionary and I don't want to look at it again anytime soon! Unfortunately, I didn't have the energy to write descriptions for all the entries especially since I would have to write templated descriptions so that terminology references within the descriptions would be notation specific without having to rewrite each description for each notation. I did spend sometime trying to adapt bridge terminology for Executable UML which according to [xtUML02] should allow explicit and implicit bridging (discussed below). The implicit kind being aspect-oriented in nature.

I discovered that Project Technology's old host name www.projtech.com has finally been dropped by Mentor Graphics and reused by some German company for who knows what! I've now removed all references to it from my website. I also checked that all the links on the References page are still active. Unfortunately, the University of Surrey appears to have dropped their Executable UML course CS387 and removed the course contents from their website. I also added the following whitepaper references:

[UML05] Unified Modeling Language Specification - Version 1.4.2 - formal/05-04-01 which is the final ISO/IEC specification for UML 1.4 (xtUML is an informal profile of UML 1.4)
[UMLSuper09] OMG Unified Modeling Language™ (OMG UML), Superstructure - Version 2.2 which defines part of the current UML 2 specification
[UMLInfra09] OMG Unified Modeling Language™ (OMG UML), Infrastructure - Version 2.2 which defines another part of the current UML 2 specification
[Balcer09] Beyond Referential Attributes which I commented upon within the LinkedIn Executable UML group (the only active Executable UML group that I know of)

I decided to allow subtype-supertype relationships (generalizations in UML) to have a single subtype participant (subclass end in UML). There are no examples of single subtype relationships in any Shlaer-Mellor book that I am aware of. This is because such relationships are supposed to represent complete classifications and any classification should include at least two instances in theory. UML on the other hand allows single subclass generalizations since such relationships don't generally represent complete classifications. However, Executable UML only supports generalizations that are complete (and disjoint) which is why I didn't originally intend to support single subclass generalizations. However, I have found myself capturing partial models of existing models and Executable UML models of existing UML models (e.g. the Executable UML Foundation model) where only a single subclass end is defined. One can convert such relationships into 1:1 simple associations but the fact that the relationship captures a part of a classification is then lost. Note that the classification is technically complete in the partial model since the scope of the partial model is narrower than the original model. Obviously, the implementation of a single subclass relationship is exactly the same as a 1:1 simple association, i.e. navigation from superclass to subclass is not conditional.

Now lets discuss explicit and implicit bridges in Executable UML. I initially thought that I could map control reception points in Shlaer-Mellor to join points in Executable UML - wrong! After a good read of the existing aspect-oriented literature I discovered that the only feature of bridges that relates to aspects in any way is what I've called domain observers. Bridge mappings define explicit bridges between wormholes and control reception points. There is no equivalent terminology in UML or aspect-oriented programming so for the moment I've retained the Shlaer-Mellor terminology for explicit bridges in the Executable UML part of the OOA Dictionary.

Now to implicit bridges. Aspect-oriented programming selects (via a pointcut) parts of a program (called join points) to which additional behaviour (called advice) are spliced in. In OOA09, domain observers (including object observers, event generated observers and operation invoked observers) remotely observe behaviour in a domain allowing behaviours in the same domain or in other domains to be triggered. There are parallels here between domain observers and join points, pointcuts and advice. However, domain observations are all asynchronous in nature (e.g. operation invoked observers observe the completion of an invocation and thus have access to the input and output arguments of the invocation) and there are no current plans on allowing synchronous splicing of behaviour which is the hallmark of aspect-oriented programming. I don't believe it is possible to create a reusable domain that would allow splicing of synchronous behaviour (e.g. by allowing the output arguments of an invocation to be changed) without a serious risk of the original functionality breaking. Another difference is that domain observers in OOA09 are only allowed to use control reception points to effect any changes in a domain. There are no current plans to allow domain observers to bypass the public interface to a domain. Such hacking is not clever and won't be supported! It is worth noting that all domain observers (and bridge mappings) should still be carefully reviewed when any associated domain is changed (even with the restrictions in OOA09) since there is a risk that any assumptions that were made no longer hold. Concluding this discussion, I can't currently see any good parallels between implicit bridges in Executable UML and aspect-oriented programming so I have also retained the Shlaer-Mellor terminology for implicit bridges as well. Comments welcome.

That's about all for this week. However, I would like to mention the forum on my website which is sadly neglected. Anyone who wants to register on the forum must email me separately so that I know you are a real person. I have discovered that there are a lot of spam bots out there that try to automatically register on forums. I'm not sure what they are trying to do exactly since I block all registrations at present but it does mean that I can't easily determine real users requesting registration. In any case, no real discussions are currently happening on the forum. I hope this will change in the future.

Week 41 of 2009

2009-10-12T12:15:00.002+01:00

I'm not often pleasantly surprised by Microsoft but I was when I discovered Microsoft Security Essentials. It provides totally free virus protection on XP and Vista. Now, I'm not a big fan of giant companies squishing little ones by dumping free software into the marketplace. However, the existing virus protection vendors have been pissing me off for years. They are almost impossible to uninstall and the last two I used were constantly reminding me to renew their subscription even though I had lots of time left on my existing subscription. The first time this happened a few years ago, I renewed by mistake thinking my time was up. It wasn't, I still had 6 months left on the old subscription. Anyway, I hope they all disappear into oblivion now!

With regards to OOA Tool, the week has progressed very slowing with my attention moving from one area to the next trying to tie off loose ends. I didn't manage to finish any bigger items so there isn't much to talk about here!

Perhaps I could talk about the confusing world of events and signals. Shlaer-Mellor users don't need to worry about signals at all. However, Shlaer-Mellor users may be confused by internal and external events which should really be called internal and external event generations (as opposed to invocations) since they relate to the generation of events rather than the specification of events. The OOA Dictionary retains the original names even though they are a little confusing since they appear frequently in the existing literature. However, internal and external process invocations (which are a similar concept) are not shortened to internal and external processes since the latter does not appear in the existing literature.

Executable UML users do have to worry about events and signals and to confuse matters further, xtUML [xtUML02] and xUML [xUML04] use the terms differently. Now, UML2 [UMLManual05] uses the term event only when discussing state models. The term signal is applied to classes carrying information for asynchronous communications. The more general term message is normally used when discussing communications in general. This contrasts with Shlaer-Mellor which uses the term event in all of these situations. Now xtUML uses the term event correctly according to UML2, although signal event might be more appropriate but unnecessary since call events and change events aren't supported. I'm skipping over time events here even though delayed events (a similar but different concept) is supported in Shlaer-Mellor and Executable UML. However, xtUML uses the term signal for generated events (i.e. internal and external events in Shlaer-Mellor) which isn't really correct. Executable UML doesn't allow classes containing event information to be defined. This is a tricky area but using the term signal here is probably less confusing than using event. On the other hand, xUML uses the term signal almost exclusively which also isn't correct. OOA Tool always uses xtUML conventions but Executable UML users should note that there are small differences between xtUML and xUML.

A final note for anyone here in the UK. I watched Micro Men the other day on iPlayer seeing how Clive Sinclair and Chris Curry kick started the micro computer industry here in the UK. Unfortunately, both of their companies failed. Very sad for the UK. I still have a Sinclair QL in good condition although I haven't had it out of the box in the last 10 years! I don't know what happened to my Sinclair Spectrum but that was my very first computer. I never did buy a BBC Micro but I remember using one briefly in college.

Week 40 of 2009

2009-10-05T13:22:00.003+01:00

The whole of this week has been spent working on the OOA Dictionary and the metamodel populator which now uses the dictionary. I also spent several hours recolouring all the icons so that they match the colours used in OOA Tool. I created the original icons using Paint but it rounded off the colours when the icons were saved. I now use Paint.NET which is a very easy to use free tool which has no problem handling 24-bit colours with transparency.

As I just mentioned, a chunk of my time was spent recoding the metamodel populator to use the dictionary. I already had a heap of work to do here since the populator has gotten massively out of step with the Information Model and Data Type subsystems. Metamodel Populations now have their own notation and version allowing archetype templates to be coded using Executable UML class and attribute names (as was discussed in a previous blog). However, this raised the issue of dictionary version control. I don't want to make the dictionary independently version controlled. However, a given metamodel version must continue to use the same dictionary names. I've done this by defining all Metamodel 0.01 entries in the class OOADictionary0_01. The original OOADictionary class now extends this adding entries which aren't needed in the metamodel. When I create a Metamodel 0.02 in the future, I will also create an OOADictionary0_02 and insert it between the OOADictionary0_01 and OOADictionary classes. I can add or statically override entries in the OOADictionary0_02 class without effecting the Metamodel 0.01 population logic while the main OOADictionary class simply uses all of the latest entries without worrying about versions.

I also made a number of Executable UML name changes, e.g. Enumerated Type and Legal Value are now Enumeration and Enumeration Literal. I also noticed that UML2 uses a modified symbol for active classes, i.e. a left and right bar is added to the rectangle. As a consequence, I added a whole heap of modified UML2 icons (look in the dictionary to see). I haven't updated the diagram editors yet but I will do when I next delve into them.

I'll keep this week's blog short since I'm already posting late due to unforeseen real-world problems. I will continue working on the metamodel populator next week. I also want to ensure all entries have an icon so a few still need to be done. I'm also continuing to ponder whether there are more appropriate Executable UML names I could be using in some cases.

Week 39 of 2009

2009-09-28T12:23:00.004+01:00

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!

Week 38 of 2009

2009-09-21T12:46:00.009+01:00

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->Information_Model->Domain
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->PlatformIndependentModel->Domain
Class: ${domain.name}.${class.name}
.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!

Week 37 of 2009

2009-09-14T08:44:00.008+01:00

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:


HKEY_CLASSES_ROOT\jarfile\shell\open\command

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,
             true);
    }

    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) {
        super(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.

Week 36 of 2009

2009-09-07T09:13:00.006+01:00

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?

Week 35 of 2009

2009-08-31T07:22:00.005+01:00

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() {
            checkDeleted();
        }

        protected void checkDeleted() {
            if (isDeleted()) {
                for (Attribute attribute : m_identifyingAttributes) {
                    attribute.removePropertyChangeListener(this);
                }
            } else {
                for (Attribute attribute : m_identifyingAttributes) {
                    attribute.addPropertyChangeListener(this);
                }
                setBrowserLabel();
            }
        }

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

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

    public Identifier(OOAObject parent) {
        super(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) {
            return;
        }
        String identifierID = (order == 1) ? "I" : "I" + order;
            // Don't use order if 1 since "I1" looks confusing
        String oldIdentifierID = m_identifierID;
        m_identifierID = identifierID;
        fireDerivedChange(IDENTIFIER_ID_PROPERTY,
                          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...)!

Week 34 of 2009

2009-08-24T07:57:00.005+01:00

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) {
            m_propertyChangeSupport.firePropertyChangeEvent(
                propertyName, oldValue, newValue);
            if (child) {
                if (oldValue != null) {
                    oldValue.setParent(null);
                }
                if (newValue != null) {
                    newValue.setParent(this);
                }
            }
        }
    }
}

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;
            m_propertyChangeSupport.firePropertyChange(
                CHANGED_PROPERTY, oldChanged, changed);
            ModelElement modelElement = this;
            while (modelElement != null) {
                modelElement.setChangedAnywhere();
                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;
                    break;
                }
            }
        }
        boolean oldChangedAnywhere = m_changedAnywhere;
        m_changedAnywhere = changedAnywhere;
        m_propertyChangeSupport.firePropertyChange(
            CHANGED_ANYWHERE_PROPERTY,
            oldChangedAnywhere, changedAnywhere);
    }
    public void setChangedRecursively(boolean changed) {
        setChanged(changed);
        for (ModelElement child : getChildren()) {
            child.setChangedRecursively(changed);
        }
    }

    protected void firePropertyChange(String propertyName,
            ModelElement oldValue, ModelElement newValue,
            boolean child, boolean derived) {
        if (oldValue != newValue) {
            m_propertyChangeSupport.firePropertyChangeEvent(
                propertyName, oldValue, newValue);
            if (child) {
                if (oldValue != null && !m_deleted) {
                    oldValue.setDeletedRecursively(true);
                }
                if (newValue != null && !m_deleted) {
                    newValue.setDeletedRecursively(false);
                }
            }
            if (!derived && !m_deleted) {
                setChanged(true);
            }
        }
    }
}

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.

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

2009-08-17T09:12:00.003+01:00

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.

Week 26/27 of 2009

2009-07-07T07:46:00.003+01:00

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.

Week 24/25 of 2009

2009-06-23T08:09:00.004+01:00

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:

Operation	Owner	Name Owner Category
Domain Observer	Domain	None
Bridge Mapping	Bridge	None
Function	Information Model	Owner
Attribute Calculation	Object	None
Relationship Navigation	Mathematically Dependent Relationship	None
Action	State Model	None
Synchronous Service	Terminator	Owner
State Model Process	Lifecycle Model	Active Object
State Model Process	Single Assigner Model	Owner
State Model Process	Multiple Assigner Model	Partitioning Object
Polymorphic Process	Polymorphic Destination	Supertype Object
Bridging Process	Terminator	Owner
Synchronous Return Wormhole	Terminator	None
Asynchronous Return Wormhole	Terminator	Owner

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.

Week 22/23 of 2009

2009-06-07T09:13:00.002+01:00

I've been working on Recursive Design bridges, Process Model operations and Action Language statements. Over the last few weeks I've published a number of technical notes on synchronous communications, asynchronous communications and semantic shift in an effort to nail down exactly how operations of all kinds will be implemented in OOA09 projects. A number of bridge mapping variations were explored before I settled on what was discussed in the technical notes, e.g. watchpoint mappings have been replaced with domain observers. These technical notes will continue to be tweaked (e.g. there are a few counterpart mapping points which I skipped over that are worth discussing) until I have finishing implementing the discussed logic in OOA Tool which I am in the process of doing. I've also published a draft overview of the OOA09 Action Language. However, this won't be complete for a while yet since I want to implement some of the syntax first.

During this work, I've noticed that Mathematically Dependent Objects (which would be called derived classes in xtUML if the concept existed) exist in several subsystems of my OOA of OOA, i.e. objects with no user changeable attributes at all. The first example being completely predefined data types (not core types) which are automatically created when certain related objects are created, e.g. an Object Instance Type is created whenever an Object is created. The second example being predefined parameters which are automatically created when certain operation related objects are created. Now, I've already added Mathematically Dependent Relationships (called derived associations in xtUML) as a new concept to OOA09 after Mathematically Dependent Attributes were added in OOA96. Should I add Mathematically Dependent Objects as well? The concept definitely exists and is a logical extension of what already exists. What would the semantics be? What hooks would I need to add? When would the hooks be triggered? Could they be implemented efficiently? However, I'm not going to sidetrack the next build with this as a new feature but I will continue to explore it as a concept. Let me know if anyone has any related ideas.

Semantic Shift

2009-06-01T12:59:00.012+01:00

Semantic shift occurs when a data value of one data type is converted into a data value of another data type. All such conversions require a semantic shift mapping. OOA09 specifies a set of predefined semantic shift mappings which can be used within a domain or between two different domains. OOA09 also allows counterpart mappings and user-defined semantic shift mappings to be defined on a bridge. All semantic shift mappings are implicitly invoked during Action Language assignment or parameter passing. Counterpart mappings and user-defined semantic shift mappings can only be implicitly invoked within bridge mappings and domain observers since they always involve data types from different domains. Although there is no Action Language cast operator, a declare statement can be used to perform an explicit semantic shift, e.g.

declare n as Real;
declare integer_n as Integer = n;

There are many situations where a semantic shift mapping can result in an error. If a user wants to handle the error within their Action Language code then the semantic shift must be performed between a mandatory attribute or data item and a conditional attribute or data item, e.g.

declare text as String = "Hello World";
declare unsafe_text as empty or one String = text;

// The following generates a run-time error!
declare unsafe_n as Integer = text;

// The following is entirely safe
// as long as the necessary checks are performed
declare safe_n as empty or one Integer = text;
if (empty safe_n)
   // Handle syntax or out of range error...
end if;

// The following generates a run-time error!
declare unsafe_m as empty or one Integer = unsafe_text;

// The following is entirely safe
// as long as the necessary checks are performed
if (empty unsafe_text)
   // Handle missing text...
end if;
declare safe_text as String = unsafe_text;
declare safe_m as empty or one Integer = safe_text;
if (empty safe_m)
   // Handle syntax or out of range error...
end if;

In addition to type specific errors, a semantic shift between a conditional attribute or data item and a mandatory attribute or data item always generates a run-time error when the source value is empty, i.e. a NullPointerException in Java.

It is important to note that bridges do not define their own data types. All data types referenced within a bridge mapping are from either the client or server domain. All data types referenced within a domain observer are from one of the domains defined within the domain observer's enclosing project. It is also worth noting that the only data stored in a bridge is cached counterpart mappings. The Shlaer-Mellor concept of semantic shift was first discussed in [Wormhole96].

The Executable UML core types (Boolean, String, Integer, Real, Date, Timestamp and Arbitrary_ID) which are all predefined types in OOA09 are not global types. However, there are predefined semantic shift mappings between the same core types in all domains, i.e. core types from all domains can be used interchangeably.

There are predefined semantic shift mappings between all boolean types since all boolean values have the same semantics or meaning in OOA09 even if they have different aliases. There is also a predefined mapping to String which converts a boolean value to the boolean type's notation independent alias for that value, e.g. Boolean true value maps to "True" (not Shlaer-Mellor "TRUE" or Executable UML "true"). The reverse String to boolean type mapping is also predefined where aliases or the hard-coded "True" or "False" names are fuzzy matched according to standard name comparison conventions (see Naming).

There are no predefined semantic shift mappings between any enumerated types since each legal value has its own unique meaning. A user-defined semantic shift mapping (which should always use a switch statement for safety) must be defined whenever any such conversion is required. However, there is a predefined mapping to String which converts an enumerated value to the enumerated type's notation independent name for that value. The reverse String to enumerated type mapping is also predefined where legal value names are fuzzy matched according to standard name comparison conventions.

There are no predefined semantic shift mappings between symbolic types in general since each symbolic type is assumed to have unspecified but definite semantics. The only exception involves the core type String which has no syntax, semantics or length restrictions. All symbolic types have a predefined semantic shift mapping to String. The reverse String to symbolic type mapping is also predefined. However, an error will occur if a target pattern is not matched or text length is invalid.

There are no predefined semantic shift mappings between numeric types in general since each numeric type is assumed to have unspecified but definite semantics. However, there are predefined semantic shift mappings between all numeric types and several core types including String, Integer and Real since core types are assumed to have no domain specific semantics. Additionally, there are predefined semantic shift mappings between all numeric types with a Time value format and the core types Date and Timestamp. There are also predefined semantic shift mappings going in the reverse direction in both cases. For all numeric values, truncation of decimal places may occur during a semantic shift. For time values, scaling up or down of time units may also occur during a semantic shift. However, one should note that time values in OOA09 are always stored as universal time (i.e. GMT) values relative to the Java Date Epoch (1 January 1970).

There are predefined semantic shift mappings between all arbitrary ID types and several core types including String and Integer. There are also predefined semantic shift mappings going in the reverse direction. These are in addition to the predefined semantic shift mappings between Arbitrary_ID core types in all domains. However, great caution should be used when passing arbitrary ID values around since arbitrary ID attributes may have their values reallocated automatically whenever object instances are created or deleted or whenever related object instances are assigned new arbitrary ID values.

There are no predefined semantic shift mappings between object instance types. However, a counterpart mapping can be defined between an object instance in one domain and an object instance in another domain. A counterpart mapping operation is invoked whenever a specific object instance in the client domain is shifted for the first time. The operation is expected to return the counterpart object instance in the target domain. The operation may return nothing if the counterpart mapping is conditional. However, the operation will not be invoked again in the future. Once a counterpart mapping has been established between two object instances then the link remains in a bridge cache until either of the object instances is deleted. This is not a flexible mapping for dynamic counterpart relationships. It is equivalent to joining two classes in different packages using multiple inheritance. It creates a permanent link which is only broken when one part is deleted. Although counterpart mappings are one-way, a counterpart mapping and it's reverse mapping share the same bridge cache. Once a link has been formed in either direction, a semantic shift can be performed in both directions as long as counterpart mappings were defined in both directions. Dynamic counterpart relationships can still be created using user-defined semantic shift mappings between object instance types. However, such mappings are always re-invoked when a semantic shift is requested, i.e. counterpart mappings will always be much faster.

There are no general purpose predefined semantic shift mappings involving event instance, return coordinate or transfer vector types. However, an event instance type for a solicit event parameter of a request wormhole has a predefined mapping to a transfer vector type for an event data item or input parameter of a control reception point (see Asynchronous Communications between Domains). In the opposite direction, a transfer vector type for a self parameter of an asynchronous return wormhole has a predefined mapping to an event instance type for a self parameter of an asynchronous return mapping.

There are predefined semantic shift mappings between all data types and all external types (in another domain) since converting an arbitrary data value into an external value only involves wrapping the original data value as an external value. No information is lost in the process. However, the reverse mapping is not so straightforward. If an external type has only been mapped from a single data type (across all bridges) then the reverse mapping is entirely safe. Otherwise, the reverse mapping is only safe if the wrapped data value has exactly the same type as the target type. An error is generated if the actual type does not match the target type.

User-defined semantic shift mappings can only be defined in a bridge between client and server data types. An analyst should not need to define a mapping between two data types within the same domain. User-defined semantic shift mappings between boolean types should never be defined since boolean value semantics are fixed across all domains. User-defined semantic shift mappings involving core types should also never be defined since core value semantics are also fixed across all domains. A user-defined semantic shift mapping between a pair of object instance types should not be defined if a counterpart mapping for that pair is already defined. User-defined semantic shift mappings should also not involve return coordinate or transfer vector types. Finally, user-defined semantic shift mappings must never involve external types since the predefined semantic shift mappings involving external types always take precedence. Given these restrictions and rules, user-defined semantic shift mappings should never overlap any of the predefined semantic shift mappings.

Semantic shift mappings are summarized in the following table:

Source Type	Target Type	Semantic Shift Mapping
Boolean Type	Boolean Type	predefined
Boolean Type	`String`	predefined
`String`	Boolean Type	predefined (error if boolean value not fuzzy matched)
Enumerated Type	`String`	predefined
`String`	Enumerated Type	predefined (error if legal value not fuzzy matched)
Symbolic Type	`String`	predefined
`String`	Symbolic Type	predefined (error if pattern not matched or length invalid)
Numeric Type	`String`	predefined
Numeric Type	`Integer`	predefined (truncate decimal places)
Numeric Type	`Real`	predefined
Numeric Type (with `Time` value format)	`Date`	predefined (scale up or down to match time units, truncate decimal places)
Numeric Type (with `Time` value format)	`Timestamp`	predefined (scale up to match time units, truncate decimal places)
`String`	Numeric Type	predefined (error if not real or out of range, truncate to maximum decimal places)
`Integer`	Numeric Type	predefined (error if out of range)
`Real`	Numeric Type	predefined (error if out of range, truncate to maximum decimal places)
`Date`	Numeric Type (with `Time` value format)	predefined (error if out of range, scale up or down to match time units)
`Timestamp`	Numeric Type (with `Time` value format)	predefined (error if out of range, scale down to match time units)
Arbitrary ID Type	`String`	predefined
Arbitrary ID Type	`Integer`	predefined
`String`	Arbitrary ID Type	predefined (error if not integer or out of range)
`Integer`	Arbitrary ID Type	predefined (error if out of range)
`Arbitrary_ID`	`Arbitrary_ID`	predefined
Object Instance Type	Object Instance Type	counterpart mapping (error if no counterpart and mapping not conditional)
Event Instance Type (for solicit event parameter of request wormhole)	Transfer Vector Type (for event data item or input parameter of control reception point)	predefined
Transfer Vector Type (for self parameter of asynchronous return wormhole)	Event Instance Type (for self parameter of asynchronous return mapping)	predefined
Data Type	External Type	predefined
External Type	Data Type	predefined (error if actual type not target type)
Data Type	Data Type	user-defined (error if no return value and mapping not conditional)

Week 21 of 2009

2009-05-26T07:28:00.003+01:00

First off, my week numbers seems to be off my one. This weekly report covers the previous two weeks which are actually week 20 and week 21 (not week 21/22). I can't go back and change the previous weekly report headings since I will break any cross references to those weekly reports.

I have been working on Action Language syntax and semantics, trying to nail down a sufficient but minimal Action Language for use in OOA09. I've been trying not to rush decisions here since I will have to live with these choices for the foreseeable future. One area in particular that I have been trying to nail down relates to wormholes and bridge mappings. To this end, I wrote a number of recursive design technical notes describing synchronous and asynchronous communications across bridges:

These notes took most of last week since they forced me to clarify a number of important issues, e.g. what happens when return coordinates and transfer vectors go out of scope.

I also realized that watchpoint mappings (object created mappings, object deleted mappings, object updated mappings, event generated mappings and operation invoked mappings) would not be sufficiently flexible. I would also need to allow reflexive bridges in certain situations. The problem here is the assumption that a watchpoint mapping involves two domains. It really involves one or more domains. Therefore, I am replacing watchpoint mappings with domain observers (object created observers, object deleted observers, object updated observers, event generated observers and operation invoked observers). These will be defined on domains rather than bridges but will have access to all domains used in the enclosing project. This will also eliminate the need for reflexive bridges.

Asynchronous Communications between Domains

2009-05-24T12:06:00.007+01:00

This technical note should be read after Synchronous Communications between Domains since I have tried to avoid repeating myself too much here. Most asynchronous communications between domains involve:

request wormholes (domain-crossing events or bridging processes) in client domains,
control reception points (external events or synchronous services) in server domains,
and request mappings in bridges.

However, asynchronous communications may also involve:

solicit event parameters on request wormholes,
asynchronous return wormholes in server domains,
asynchronous return mappings in bridges,
and transfer vector types.

Request wormholes are associated with a terminator in a client domain and include domain-crossing events and bridging processes. A domain-crossing event may have any number of carried data items. A bridging process may have any number of user-defined input or output parameters. However, output parameters are not relevant here when dealing with asynchronous communications. Bridging processes are normally used for synchronous communication. However, they may also be used for asynchronous communication as long as a synchronous return mapping exists.

Control reception points are associated with a terminator in a server domain and include external events and synchronous services. External events indicate internal events (state model, domain-crossing or polymorphic events) that can arrive from outside a given domain via a specific terminator. Events may have any number of carried data items. Synchronous services may have any number of user-defined input or output parameters. However, output parameters are not relevant here when dealing with asynchronous communications. Unlike bridging processes, synchronous services may be used in a purely asynchronous manner since the results may not be required by a particular client domain. Dummy return coordinates are passed to synchronous services when they are invoked asynchronously allowing the server domain to execute a dummy synchronous return unaware that it has been invoked asynchronously.

A request mapping in a client-server bridge is implemented using an Action Language statement block. It maps a request wormhole to a control reception point. If the request wormhole is a domain-crossing event then the carried data items are passed as input parameters into the request mapping. Otherwise, the input parameters of the bridging process are passed into the request mapping. Request mappings have no output parameters. The code in a request mapping must either generate the associated external event or invoke the associated synchronous service. It may also decide to do neither without consequence. Output parameters should not be accessed when invoking a synchronous service asynchronously. Any attempt to do so is a static coding error. There may be any number of request mappings for a given request wormhole.

External events may be both unsolicited and solicited. Request mappings to external events define unsolicited events which either represent a new thread of control within the server domain or extend the existing thread of control associated with the client domain's request wormhole. Solicited events within a client domain on the other hand extend an existing thread of control associated with a previously invoked request wormhole to a server domain. Solicited events are defined using solicit event parameters on request wormholes. A request wormhole (whether used synchronously or asynchronously) may have zero to many solicit event parameters. A solicit event parameter holds a complete event instance created in a client domain which is then passed to a server domain as a transfer vector. The transfer vector can then be used to invoke an asynchronous return wormhole in the server domain which as a consequence generates a solicited event in the client domain.

[Wormhole96] proposed that transfer vectors should encapsulate partial event instances with all event data items determined from asynchronous return wormhole input parameters. OOA09 doesn't allow partial event instances at all. It does allow an event instance to be created from another event instance allowing new event data item values to be supplied. It also allows event data items to be read from an event instance in the same way as attributes can be read from an object instance. This allows full or partial overriding of event data items on event instances. However, this always involves creating a new event instance since event instances are immutable in OOA09.

Solicited event parameters have a multiplicity and conditionality providing some indication as to how many solicited events are expected by the client domain. If more than one solicited event is generated when no more than one was expected then an error should be reported but the solicited event is still generated. If no solicited events are generated but at least one was expected and all transfer vectors go out of scope then an error should be reported. A solicited event is not automatically generated here. This behaviour differs from what happens when all return coordinates go out of scope and a synchronous return hasn't been invoked. This is because a missing asynchronous return is a protocol error which should be handled in the appropriate state models while a missing synchronous return is a permanently blocked concurrent thread.

An asynchronous return wormhole is an abstract process associated with a terminator in a server domain which may be invoked in any composed operation (action or synchronous service). It may have any number of user-defined input parameters. Asynchronous return wormholes have no output parameters. A self parameter with a transfer vector type is also automatically defined. However, explicit asynchronous return wormholes are not always required in OOA09 since transfer vectors may arrive in a domain in a complete state allowing a solicited event to be immediately generated without involving an asynchronous return mapping.

An asynchronous return wormhole is normally invoked on a transfer vector value using an invoke return statement, e.g.

transfer_vector.return(message:"Hello World");

However, an implicit asynchronous return wormhole involving a complete transfer vector (one not associated with an asynchronous return wormhole) is always invoked using an ordinary generate statement, e.g.

generate transfer_vector;

The generate statement is used in this case since an asynchronous return mapping is never involved, i.e. the transfer vector's event instance is immediately generated (or delayed if a delay clause is used).

An asynchronous return mapping in a client-server bridge is implemented using an Action Language statement block. It maps an asynchronous return wormhole to a solicited event parameter. It is invoked whenever an asynchronous return is performed using a partial transfer vector. No asynchronous return mappings are required (or possible) for complete transfer vectors. The input parameters associated with a asynchronous return mapping match the input parameters of the asynchronous return wormhole. Asynchronous return mappings have no output parameters. A self parameter with an event instance type is also automatically defined. The self parameter contains the event instance wrapped by the asynchronous return wormhole's transfer vector. It can be used immediately to generate a solicited event. However, some adjustment will normally be required using the input parameters. Any adjustment will involve creating a new event instance. The code in an asynchronous return mapping will normally generate the associated external event. However, it is not required to do so. If there are no asynchronous return mappings for an explicit asynchronous return wormhole then the partial transfer vector is treated like a complete transfer vector, i.e. a solicited event is automatically generated from the transfer vector's wrapped event instance. However, this should be reported as an error. This behaviour differs from what happens when no synchronous return mapping is specified. If you don't want an asynchronous return then you shouldn't pass a transfer vector into a control reception point.

A predefined partial transfer vector type is defined for each asynchronous return wormhole allowing partial transfer vectors to be safely passed around within a domain since the parameters associated with a partial transfer vector can be statically determined within Action Language code. A single predefined complete transfer vector type is also defined allowing solicited events to be generated without the need for an explicit asynchronous return wormhole or an asynchronous return mapping. The predefined complete transfer vector type is generic. The predefined partial transfer vector types are partially generic in that they can be used across multiple control reception points.

Synchronous Communications between Domains

2009-05-18T12:10:00.009+01:00

All bridges between domains allow communications in both directions. Even though the domains being bridging are labelled as either client or server. Those roles may be reversed for a given communication. Explicit communications between domains are known as wormholes in Shlaer-Mellor OOA/RD. Wormholes were introduced in OOA96 and later defined in [Wormhole96] as an alternative to domain-crossing events and bridging processes. However, OOA09 integrates these concepts together to gain benefits from both approaches. All synchronous communications between domains involve:

bridging processes (request wormholes) in client domains,
synchronous services in server domains,
request mappings in bridges,
synchronous return wormholes in server domains,
synchronous return mappings in bridges,
and return coordinate types.

A bridging process is an abstract process associated with a terminator in a client domain which may be invoked in any composed operation (action or synchronous service). It may have any number of user-defined input and output parameters. A thread of control passes from one domain to another when a bridging process is invoked. A synchronous return must be invoked by a server domain to continue the original thread of control. Whether processing can still occur within the client domain while waiting for a synchronous return depends on how many concurrent threads have been allocated to the client domain.

A synchronous service (as defined in [SyncServ96]) is a composed operation implemented using an Action Language statement block or a process model. It is associated with a terminator in a server domain. It may have any number of user-defined input and output parameters. A special Return Coordinate parameter is also defined automatically. This parameter is required to invoke a synchronous return wormhole. Return coordinates can be passed on within the server domain as event data items or ordinary parameters and stored as attributes. However, they should not be stored for long since the client domain is waiting for a result. They can also be passed to other domains as external values. However, they can't be used to invoke synchronous returns in other domains.

A request mapping in a client-server bridge is implemented using an Action Language statement block. It maps a request wormhole (domain-crossing event or bridging process) to a control reception point (external event or synchronous service). A synchronous communication always requires a bridging process and a synchronous service. If a domain-crossing event is mapped to a synchronous service then any synchronous returns will be ignored. If a bridging process is mapped to an external event then no synchronous return is possible since new return coordinates are not passed to external events. However, it is still possible to carry an existing return coordinate via an event. The input parameters associated with a request mapping match the input parameters associated with the bridging process. Request mappings have no output parameters. The code in a request mapping must invoke the synchronous service converting bridging process input parameters to synchronous service input parameters.

There may be any number of request mappings for a given bridging process. However, only one synchronous return can be used to satisfy a given invocation. OOA09 allows multiple request mappings, all of which may invoke a synchronous return. Only the first response will be used to satisfy the request. Any additional responses will be ignored. Whether it is good design practice to allow multiple responses here is open to debate. If all return coordinates associated with the synchronous services invoked in response to a bridging request go out of scope then the bridging process invocation can terminate. If all output parameters associated with the bridging process are conditional or have default values then this is a recoverable error that should be flagged but is otherwise acceptable. If there are any mandatory output parameters without default values then this is a fatal error with serious consequences since the original thread of control can't continue. All such fatal errors can be eliminated from deployed systems by ensuring that all bridging process output parameters are either conditional or have a default value. A software architecture may place time limits or other restrictions on bridging processes as long as a default synchronous return is possible, e.g. a software architecture may break a deadlock by invoking default synchronous returns on deadlocked synchronous communications.

A synchronous return wormhole is an abstract process associated with a synchronous service (and as a consequence a terminator) in a server domain which may be invoked in any composed operation (action or synchronous service). The input parameters are automatically determined from the output parameters of the associated synchronous service. Synchronous return wormholes have no output parameters. A self parameter with a return coordinate type is also automatically defined. However, explicit synchronous return wormholes are not actually required in OOA09 since synchronous return mappings and return coordinate types are associated directly with synchronous services rather than synchronous return wormholes. The only benefit of an explicit synchronous return wormhole is that it can be labelled and shown separately on process models.

A synchronous return wormhole is normally invoked on a return coordinate value using an invoke return statement, e.g.

return_coordinate.return(message:"Hello World");

However, within a synchronous service statement block, a synchronous return wormhole can also be invoked using an ordinary non-empty return statement, e.g.

return message:"Hello World";

An empty return statement can't be used for this purpose even if there are no output parameters.

A synchronous return mapping in a client-server bridge is implemented using an Action Language statement block. It maps a synchronous service to a bridging process. It is invoked whenever an explicit or implicit synchronous return occurs. The input parameters associated with a synchronous return mapping match the output parameters of the synchronous service while the output parameters match the output parameters of the bridging process. The code in a synchronous return mapping must convert the synchronous service output values to bridging process output values. If there are no synchronous return mappings for a synchronous service then any synchronous returns will simply be ignored.

A predefined return coordinate type is defined for each synchronous service allowing return coordinates to be safely passed around within a domain since the parameters associated with a return coordinate can be statically determined within Action Language code. There is no generic return coordinate type in OOA09 as a consequence. However, that does not mean that return coordinates can't be passed to a service domain as external values since any return coordinates must be passed back to their server domains (requiring type verification) before they can be used.

Week 19/20 of 2009

2009-05-11T06:33:00.006+01:00

I didn't have much to report last week since I was mostly doing behind the scenes coding for OOA Tool. This week I returned to the Action Language. The first step was to revisit the syntax grammar for OAL since I want the Action Language for OOA09 to be backwards compatible where possible. The second step was to update the syntax grammar for the OOA09 Action Language. The third step is to update the overview documentation which hasn't been uploaded yet. Later steps include updating the parser in OOA Tool, implementing an interpreter and debugging interface, and updating the Action Language Subsystem for the OOA of OOA. Only the first two steps will be discussed here. The general overview should be uploaded in the coming week and the other work will completed later.

There are three documents that define the Object Action Language (OAL) from Mentor Graphics:

BPAL97 which defines the Action Language in BridgePoint 4.2,
OAL02 for later versions of BridgePoint,
and OAL08 for the latest version of BridgePoint UML Suite.

OAL has undergone very few changes over the last 10 years. One could say the same for the Action Specification Language (ASL) from Kennedy Carter. However, As I have said before, I prefer the simplicity of OAL. I updated the OAL syntax grammar in the BridgePoint 4.2 Model to handle BPAL97, OAL02 and aspects of OAL08 with other aspects mentioned in embedded comments. The only aspect of OAL08 which has not been captured is the new send statement relating to components and interfaces. The OAL syntax grammar is given below:

Syntax and Lexical Rules for Action Language

The OOA09 Action Language is currently captured as part of the OOA Tool Model. However, it will shortly be put under change control in the same way as the OOA of OOA and OOA Interchange Format are under change control. The OOA09 syntax grammar is given below:

Syntax and Lexical Rules for Action Language

OOA09 adds a small number of new statements:

a declare statement,
a switch control structure statement,
a reclassify object instance statement,
and a delete event instance statement.

There are numerous other changes but I will only discuss the new statements above today. The other changes will be discussed in detail in the Action Language overview which should get uploaded in the coming week.

The declare statement allows stronger and weaker type checking. Variables can still be implicitly declared using assignment statements etc. However, users can now declare variables explicitly using predefined types or user defined types from their model. New data types can't be (and don't need to be) defined within Action Language code. All implicit variable declarations can now be replaced with explicit declarations if needed. The declare statement also allows transient non-object instance sequences and sets to be specified since multiplicity is associated with data items (e.g. variables) in OOA09.

The switch statement allows enumerated types to be used safely (including current_subtype and current_state information) since all legal values must be handled as cases. If new legal values are added or old ones are removed then all associated switch statements will need to be updated. Java and C++ switch statements cover up errors far too easily.

The reclassify object instance statement enables users to drop explicit creation and deletion of non-leaf object instances and subtype-supertype relationships. Non-leaf object instance creation will be disabled by default in OOA Tool. However, for backwards compatibility with OAL, users will be able to create non-leaf object instances but if they do so they will need to create all non-leaf object instances and will need to relate and unrelate all subtype-supertype relationships.

The delete event instance statement is part of the delayed event support added to OOA09. Event instances can be created and stored and later turned into generated event instances which may be given a delay when generated. Rather than add the cancel statement (specified in xtUML02) which only cancels a single generated event instance. OOA09 cancels all generated but delayed event instances associated with a specific event instance when it is explicitly deleted. However, OOA Tool will also support the complete Timer interface defined in BridgePoint for backwards compatibility.

On a final note, I came across the ModelDriven.org Portal which includes a downloadable Foundational UML (fUML) Reference Implementation. Like OOA Tool, it's written in Java and requires Java SE 6 or later. I haven't explored it yet.

Week 18 of 2009

2009-04-27T07:50:00.002+01:00

I had hoped to get back to finishing the Action Language overview which I put on hold to mull over some choices I have to make. I sometimes find that putting off an arbitrary choice for a while can lead to a better choice later. I have found that making the wrong design choice can lead to lots of rework later. Here I am looking forward to providing Action Language code for all the mathematically dependent attributes in the metamodel. However, I want to be sure the Action Language addresses my requirements.

Instead, I implemented EnumeratedSubtypeType allowing users to determine the current subtype of a subtype-supertype relationship. This will allow users to switch (using the new switch statement) on a subtype without needing to perform multiple subtype-supertype relationship navigations. I also implemented EnumeratedStateType allowing users to determine the current state of a state model. OOA91 gave users access to the current state of a state model while OOA96 dropped this feature. OOA09 gives users access to current state since it is very useful for bridging and debug code. OOA09 recommends that both current subtype and current state should primarily be used with the new switch statement since all cases must be supplied and an error will be reported if a new case is required or an old case is redundant. Both types are always predefined and can be used as attribute types. They only appear as browsable types below subtype-supertype relationship and state model respectively when they are referenced by one or more attributes or data items.

I also rewrote the entity (object and terminator) key letters calculation logic so that key letters are always unique. Prior to Build 014 (the next build), non-unique key letters would simply be shown in red. The new logic which is discussed in detail in the previous blog now always generates unique key letters.

On an Action Language related issue, I managed to download the latest copy of Mentor Graphics BridgePoint UML Suite Object Action Language (OAL) manual. The main changes from OAL02 involve support for components, interfaces, ports and inter-component communications. Some form of array access which is not discussed in the body of the document also appears in the syntax grammar. However, I was surprised not to see a new variable declaration statement since I had previously spotted a BridgePoint pre-release note that suggested a variable declaration statement was going to be added. I won't be providing any support for components or interfaces in OOA Tool since it adds nothing (in my opinion) to OOA or xtUML. I will however be defining a variable declaration statement which is sorely missing from OAL.

Finally, I just want to mention that a new Executable UML group has been created by Lee Riemenschneider on LinkedIn. I added a few postings and I hope the group will provide a useful forum for Executable UML (and Shlaer-Mellor) specific discussions.

Custom and Automatic Key Lettering

2009-04-23T11:48:00.004+01:00

Shlaer-Mellor OOA uses key letters to identify various model elements. Objects and terminators (collectively known as entities) define key letters (normally an abbreviation of their names) as a unique short identifier. Key letters can be used to identify entities within Action Language code. However, OOA09 also allows entity names to be used within Action Language code instead. For this reason, key letters are not allowed to match another entity's name.

Key letters (often referred to as key letter singular in old Shlaer-Mellor literature) where introduced in OOA91 at a time when there was minimal CASE tool support. UML has no similar notion since it was defined with CASE tools in mind. That said, key letters still have a useful role to play with regards to event and operation labelling. Within OOA Tool, users can leave the creation and updating of key letters entirely in the hands of OOA Tool.

Key letters are also used to compose event and operation labels via the Label Prefix attribute on Operation Owner. While entity key letters are no longer strictly necessary in their own right, they are essential for use within event and operation labels since event and operation meanings are not by themselves unique. The format of event and operation labels will not be discussed here. However, they do rely on the fact that key letters are always unique.

OOA09 defines key lettering on the Entity object. It defines a Name attribute, an optional Custom Letters attribute, a mathematically dependent First Letters attribute and a mathematically dependent Key Letters attribute. The custom letters attribute allows users to specify their own key letters for an entity. However, the custom letters must be unique otherwise they will be ignored. The first letters attribute is derived from the name attribute and is composed from the first letter of each word in the name (see Naming). This is the recommended convention for key letters. However, first letters may not always be unique which is why custom letters may be needed for some entities.

OOA91 also defined the notion of subsystem prefix letters allowing an optional common key letters prefix to be defined for all objects within a subsystem. Prefix letters can't be defined for terminators since terminators are never assigned to a subsystem. OOA09 requires any prefix letters to be automatically added to assigned object key letters. The prefix letters must not be included in custom letters (otherwise it will be duplicated) and is not added to first letters. It is always added to key letters, i.e. it can't be selectively dropped from a single object's key letters. Prefix letters are not defined as a unique identifier on subsystem so two or more subsystems may use the same prefix letters. Prefix letters normally end with an underscore but that isn't a requirement.

All entity key letters must be unique within a domain. If custom letters (with any prefix letters added) is defined which doesn't match another entity's name or custom letters then it is used. Otherwise, first letters (with any prefix letters added) is used instead. If the first letters match another entity's name, custom letters or first letters then a suffix is added to make the final key letters unique. The suffix used is "_z", "_zz", "_zzz" etc. The convention is a little arbitrary but it does ensure key letters are always unique. Users should (but are not required to) define custom letters when first letters are not unique which will be obvious when the sleep suffix appears.

Week 16/17 of 2009

2009-04-20T07:52:00.002+01:00

Back to work after Easter. I hadn't planned on having a long Easter break. However, I started reading the novel Guilty Pleasures, the first in the Anita Blake: Vampire Hunter series by Laurell K. Hamilton. I then went on to read the next 15 novels in the series back to back!! I'm not exactly happy with the direction the series is now heading in, i.e. more and more sex while less and less plot. However, you can't help getting attached to most of the characters in the series. Anyway, all of that reading made a good diversion from OOA modelling and Java coding.

Prior to the Easter diversion, I continued reworking and finishing various bits of OOA Tool code associated with Attributes and Data Types. I rewrote a number of algorithms including those for Mapping Complete, Mapping Compatible and Data Type Acceptable. I added a Manual Constrained attribute to Referential Attribute Mapping and rewrote the Loop Constrained and Constrained algorithms. Most of these algorithms will be published as Action Language code within the OOA of OOA once I have finished the simulator allowing the Action Language code versions of the algorithms to be tested.

While coding OOA Tool, I spend a significant amount of time coding model element listeners since most model elements within the OOA of OOA have derived attributes which depend on many other model elements. OOA Tool automatically refreshes itself when any model elements change rather than relying on manual refreshes. This listener logic which can be very complex, needs to be completely automated in the Java software architecture, i.e. the model compiler. This will require automatic analysis of the dependencies within attribute calculation code. I am currently hopeful that this can be done efficiently without the need for design colouring. I eventually hope to replace the OOA of OOA model element Java classes in OOA Tool with classes generated directly from the OOA of OOA metamodel.

I also spent some time searching the web for any other projects, forums or blogs relevant to Shlaer-Mellor and/or Executable UML. I didn't find any ongoing projects in the public domain. The only active forum seems to be The Model Driven Software Network. I'm not a member of the OMG and so can't report on any activity there, other than to say, not much is happening in the public areas. I haven't found any other bloggers with an active interest in Shlaer-Mellor and/or Executable UML. It is all very disappointing.

Week 15 of 2009

2009-04-06T12:11:00.002+01:00

I have spent most of this week reworking and finishing various bits of OOA Tool code associated with Attributes and Data Types. This rework was and still is a diversion from finishing the Action Language overview. Once I have finished this stuff, I will finish off the overview and then try to wrap up a new build. When I talk about finishing the overview here, I also include finishing the Action Language syntax along with a parser to test the syntax. Unfortunately, the next build won't be ready before the end of April.

I mentioned mathematically dependent referential attributes last week and I have now started to use them in the Information Model and Data Dictionary subsystems, e.g. Attribute.Data Type, Attribute.Initial Value and Data Item.Data Type. I also discussed in Week 10 of 2009, letting analysts use object instance types with simple and mathematically dependent attributes as long as they enable a project level option to do so. However, I no longer think there are any good reasons for allowing analysts to use object instance types with attributes now that mathematically dependent referential attributes are supported. If anyone can think of a good scenario where an object instance typed attribute is needed then let me know. I should point out that there are a number of different ways that object instance values may already be stored within model population attribute values:

as a mathematically dependent referential attribute value,
as an external typed attribute value which encapsulates an object instance value passed from another domain,
and as an event instance typed attribute value which encapsulates an object instance self reference and/or one or more object instance value arguments.

Week 14 of 2009

2009-03-30T13:01:00.002+01:00

I've been working on a variety of things this week including event instance support, default values and mathematically dependent referential attributes. I won't expand on the event instance stuff yet since the Simulation subsystem still needs work. However, I will discuss the use of default values and introduce a new OOA09 feature which links mathematically dependent attributes with mathematically dependent relationships allowing caching and observation of those relationships.

The original Shlaer-Mellor Method discouraged the use of default values. Most developers will check the usage of an operation before they change it. However, checking the usage of a default value before changing it can be much more difficult leading to unexpected errors after a default value change. Executable UML does support the concept and OOA09 also allows default values on some data types and some attributes (as initial values and literal values).

After some though, I have replaced initial values on simple attributes and literal values on referential attributes with default values and initial values on all attributes. All attributes can now define a default value (which must not be UNDEFINED) assuming the attribute has a data type which allows a default value, e.g. default values are meaningless for external types since all external values must be created in another domain. In addition, all attributes now define an initial value which is used during object instance creation. The initial value matches the default value if defined, otherwise it will match the attribute type's default value if one is defined and the attribute is not conditional. Otherwise, the initial value will be UNDEFINED.

It is worth discussing OOA09 error handling behaviour here. Mathematically dependent attributes always retain their previous value when an attribute calculation fails. This will match the initial value defined above if the attribute calculation fails when first invoked. OOA09 also allows an attribute calculation to access the current values associated with the mathematically dependent attributes being calculated allowing iterative algorithms to be used. Referential attributes and polymorphic attributes both default to the initial value defined above if referential or polymorphic resolution fails. However, resolution errors can only occur when a model is incomplete or invalid.

OOA09 now also allows a default value to be associated with a data item (event data item, parameter or variable). This allows new event data items or parameters to be added to events and operations without requiring all usage of those events and operations to be changed.

Now onto mathematically dependent referential attributes. OOA09 introduced the concept of a mathematically dependent relationship which is resolved on demand when navigation is required across the relationship. However, the execution of the navigation logic is always on demand. There are situations where the navigation logic must be calculated in a more controlled fashion for performance reasons. For example, determining the data type associated with an attribute requires a complex resolution algorithm to be applied to all attributes on all objects within a domain. Even though the attribute to data type relationship is mathematically dependent, it can't be determined on demand in the real world. I initially got round this by defining ordinary mathematically dependent attributes (i.e. the Data Type and Data Type Predefined attributes) which can be used to determine the navigation quickly on demand. Those mathematically dependent attributes can be determined using an all attributes all objects algorithm which isn't recalculated more than once per second.

In a ideal world, we only need a single attribute here whose data type is an object instance type and whose value can be used to immediately navigate the relationship. This is exactly what a mathematically dependent referential attribute is. It is a mathematically dependent attribute with an object instance type which formalizes a mathematically dependent relationship without the need to define any relationship navigation operations. Obviously, mathematically dependent referential attributes can't be used to formalize many-to-many mathematically dependent relationships. Use of an object instance type here is perfectly acceptable since the implied relationship is explicitly defined. An (M-Rn) suffix is used to indicate mathematically dependent referential attributes.

Week 12/13 of 2009

2009-03-23T08:11:00.003Z

I've been off duty (I wouldn't exactly call it a holiday) for most of week 12 and week 13. However, I did spend a few days back on data types sorting out the issue of predefined type visibility.

In the Week 10 of 2009 weekly report I mentioned splitting data types into user defined types and predefined types. All predefined types now exist in all domains but aren't always visible. When to make them visible was an outstanding issue. I could have required the analyst to explicitly import predefined types. The problem here is that this would not work well for implicitly declared predefined types in Action Language code. Either the analyst would forget to import a predefined type or import predefined types that aren't being used. Instead, I introduced a Reference Count attribute on all data types. This reference count includes manual data type references from attributes and data type references from data items (event data items, parameters and variables). All data type references on attributes are derived from manual data type references so we don't have to count them as well. All predefined types with positive reference counts are now automatically visible while those with zero reference counts are hidden.

The main complication here is that bridge mappings associated with bridges may include data type references (in parameters or variables). Do we include such references in reference counts associated with domain specific data types. It feels like domain pollution. However, I don't see any way of eliminating the need for data type references within a bridge mapping operation and if we don't include such references then the analyst will not be able to identify those references via a data type form. I'm not sure whether this is a real issue for the analyst. However, I am also going to use this reference count to determine which predefined types to include in metamodel populations. There is no benefit adding all predefined types to a metamodel population, only those which are actually referenced need to be included.

Another issue is the shear volume of predefined types that may exist in a model. An object instance type exists for every object, an event instance type exists for every event, a current subtype type exists for every subtype-supertype relationship and a current state type exists for every state model. The last two types are new and will be discussed in greater detail at a later date. Obviously, not all of these will be referenced within a project and thus won't be visible. However, enough will be visible to swamp the tree browser in OOA Tool. To counter this, data types are now distributed across the tree browser:

object specific arbitrary ID types and object instance types are now shown below their associated objects,
event instance types are shown below their associated events,
return coordinate types and transfer vector types are shown below their associated return wormholes,
and the remaining data types are shown below their associated information model as normal.

Week 11 of 2009

2009-03-09T08:12:00.005Z

I've been working on the Action Language for OOA09. I was planning to publish a technical note on Action Language design. However, that discussion will now be included on the main Action Language page when it is published (hopefully this week). I will also be putting the Action Language under change control and it will be a major feature of the next OOA Tool build. A number of interesting issues have surfaced during this work:

Are collections needed in an Action Language?
Should the creation (and deletion) of supertype object instances (and the associated subtype-supertype relationships) be completely automated?

The first issue will be covered in a separate technical note while the second issue is discussed below.

Most of the existing Shlaer-Mellor and Executable UML Action Languages (e.g. [OAL02] and [ASL03]) take the view that all object instances are created and deleted separately from each other and that subtype-supertype relationships are related and unrelated separately also. However, [xtUML02] proposed that supertype object instances and subtype-supertype relationships (called generalizations in Executable UML) should be created automatically whenever leaf object instances are created. Furthermore, when a leaf object instance is deleted, all supertype object instances and the associated subtype-supertype relationships should be automatically deleted. Where a leaf object instance is part of a multiple subtype-supertype hierarchy then a leaf object from each hierarchy must be specified in the Create object instance statement. This proposal significantly reduces the amount of creation and deletion code required in an application, especially if the application uses lots of subtype-supertype relationships.

Shlaer-Mellor and Executable UML also support the concept of subtype migration while most object-oriented programming languages do not. If users are no longer able to relate and unrelate subtype-supertype relationships then we need some way of performing subtype migration. xtUML02 proposed a new Action Language statement that could reclassify object instances:

RECLASSIFY OBJECT INSTANCE variable FROM objectName TO objectName

However, this proposal requires multiple statements to perform reclassification across multiple hierarchies which is potentially inefficient since each statement may require a complete rebuild of the object instance hierarchy if the deployment programming language is object-oriented. An alternative more generic and potentially more efficient statement is given below:

RECLASSIFY OBJECT INSTANCE variable AS objectName { ',' objectName }*

There is no need to specify a from clause here. There is also no need to specify a leaf object for each hierarchy unless you want it to be a specify subtype in each hierarchy after the statement is executed.

OOA09 will adopt this approach for object creation and deletion and will support the above reclassify statement. However, for backwards compatibility with OAL, a Manual Supertype Creation : Boolean = FALSE attribute will be added to projects to allow users to create object instances without automatically creating supertype object instances and the associated subtype-supertype relationships. However, using this option will not be recommended since it is verbose and error prone. It will of course need to be used in projects loaded from BridgePoint export files.

On a completely separate note, the programme for Code Generation 2009 has now been published. I went last year and wrote up some notes (see Code Generation 2008). However, I am somewhat disappointed with this year's programme. There doesn't seem to be anything for hardcore 'model is the code' analysts and developers. Chris Raistrick from Kennedy Carter is giving an unspecified talk on Executable UML. However, it will probably be an overview or basic tutorial like last year. I would have liked to have seen some Action Language (rather than DSL) talks. Some discussion on what the OMG is doing with action semantics and fUML would have been useful. Any progress on the new RFP for a standard UML Action Language would also have been very interesting. However, I will admit to not proposing any talks for this year's conference and there are lots of things I could have talked about. Public speaking isn't one of my core skills unfortunately (nerves tend to get the better of me). Maybe, I will propose some talks for next year. I am not yet decided on whether I will go this year.

Week 10 of 2009

2009-03-02T07:24:00.003Z

I'm still working on operations and parameters but I had to take a detour into the Data Dictionary subsystem this week. First to implement Object Instance Types and then to redesign what it means to be a preferred type. I also revisited Action Language design since I've had a number of requests for more information on this. I hope to publish a technical note next week explaining my design choices for the OOA09 Action Language. I'm not sure yet how much executable support for the Action Language will be in the next build. However, the OOA Tool simulator is high on my priority list.

Now back to data types. Object instance references (sometimes called handles) are required at the event and operational level, e.g. Lifecycle Model actions define a Self Parameter which references the event destination object instance. There aren't any special attributes for object instance types so they are always predefined. I have adopted the naming convention Object Instance<Example Object> for object instance types. It is important to note that data types are independent of multiplicity and conditionality in OOA09 since they define a single unit of data. Most programming languages define multiplicity as a special type of data type, e.g. int[]. However, OOA09 associates multiplicity with data items (event data items, parameters and variables). This eliminates the need for multiple forms of object instance types (or other data types).

I originally introduced the notion of a predefined type so that Executable UML Core Types could be defined in a standard way while also allowing any OOA09 compatible tool to add their own predefined types, i.e. actual predefined types are defined at the tooling level rather than by the formalism. However, I ran in to a problem when I started looking at the typing of parameters and variables across all the operations required in OOA09. Action Language code requires permanent implicit access to a subset of core types (i.e. Boolean, Integer, Real and String) so that transient expressions can be evaluated. It also requires permanent implicit access to all object instance types so that results from a Select statement can be properly typed. To enable implicit access, all predefined types are now permanently defined in all domains. Furthermore, actual predefined types are now defined by the formalism, i.e. OOA09 compatible tools can't define their own predefined types anymore. OOA Tool now parses but ignores all predefined types when a project is loaded and no longer outputs predefined types when a project is saved. However, this change introduced several additional problems.

The first problem was that users could no longer define their own core types. This problem was solved by allowing users to create user defined types which override predefined types while still allowing users to access the original predefined types. To specify a predefined type, a user simply needs to add a <> suffix. However, this suffix doesn't need to be used for predefined types unless the user has overridden those predefined types. Within the OOA of OOA, all data type identifiers now include a predefined status to ensure predefined types are distinct from user defined types.

Another minor problem was that the OOA Tool tree browser becomes cluttered with predefined types. I solved this by no longer showing predefined types in the tree browser. However, I will need to provide some way of accessing predefined types in the future since data type forms show all references to those data types and that information is useful even for predefined types.

An interesting issue with regards to object instance types is whether to allow them to be used as attribute types. The obvious answer is no since you are effectively defining a hidden relationship by doing so. However, there is no technical reason for saying no. I think I will provide a project (and user property) level option for allowing object instance attribute types which will default to disallowing them. This logic can be incorporated into the existing Data Type Acceptable status associated with attributes.

Week 9 of 2009

2009-02-23T07:35:00.002Z

I continued working on operations and parameters this week. Creating a clean parameter based interface for Action Language code has required a considerable amount of iteration between modelling and coding. I'm trying to find a balance that results in a clean but simple OOA, Java and XML representation for operations and parameters. If I was generating the Java and XML directly from the OOA using archetypes then this wouldn't be an issue. However, since I'm creating an egg without a chicken at present I have to factor in all three.

I found a nasty J2SE 1.5 bug in GridBagLayout which results in OOA Tool locking up when there are more than 512 rows (see Java Bug ID 5107980). I hit this MAXGRIDSIZE limit when I tried to open a Subsystem editor in the OOA Tool project. The Subsystem editor tries to list all objects and relationships showing which subsystem each is assigned to. The bug is fixed in Java SE 6 (since the limit is removed entirely) but there are no plans to fix the bug in J2SE 1.5. I added a quick workaround which traps the problem but doesn't fix it. Build 014 now shows a blank panel if the limit is exceeded rather than locking up OOA Tool. To fix the problem entirely, I would have to stop using GridBagLayout which I don't want to invest time in at present since the problem is fixed in Java SE 6.

My confidence in J2SE 1.5 took a knock after finding this problem. I've only stayed with this version since the Mac still doesn't fully support Java SE 6 even though J2SE 1.5 is now End of Life. I've now decided to move to Java SE 6 as my default platform while still retaining J2SE 1.5 support for the moment at least. The latest version of Java SE 6 is build 12 which includes the new Nimbus look and feel. It looks better than Metal so I will use this as the standard look and feel from now on (while still allowing users to select their preferred look and feel). There were a few minor display issues when I first switched to Nimbus in OOA Tool but these are fixed in Build 014.

Week 8 of 2009

2009-02-16T07:15:00.003Z

I've been working on mathematically dependent attributes and the framework behind their associated value calculations. This involved revisiting the Process Model subsystem to sort out the layer between models and Action Language code. The top-level concept in the Action Language subsystem is the Statement Block which defines a sequential set of executable statements along with a scope for defining local variables. My initial thought was to define different types of top-level block for value calculation, relationship navigation, actions, synchronous services, etc. However, the distinction between event data items and parameters led to some hidden dependencies in Action Language expressions. Thus, I expanded my initial generalization of operation (which previously included synchronous service and process) to include all processing activities. This means that all statement blocks are now encapsulated in an operation with defined parameters including:

self parameter (which normally contains an object reference),
received event parameters (which reference event data items),
simple input parameters,
return parameter,
and simple output parameters (allowing multiple return values).

Some operations have fixed input and output parameters while others have user defined input and output parameters.

Operations themselves include:

attribute calculations (for calculating one or more mathematically dependent attributes),
relationship navigations (for navigating across a mathematically dependent relationship),
actions (performed on entry to a state),
synchronous services (for defining the public interface to a domain),
processes,
functions (for defining reusable side-effect free calculations),
and bridge mappings (for mapping wormholes to control reception points).

Functions are like transformations within process models except that they can be defined on any operation owner and used within any operation.

Processes include:

simple processes (including accessors, transformations and tests),
state model event generators,
polymorphic event generators,
request wormholes including:
- domain-crossing event generators,
- and bridging processes,
synchronous return wormholes,
and asynchronous return wormholes.

In OOA91, simple processes are accessors, transformations or tests. Other processes include event generators and wormholes (added in OOA96). The objective being to partition processing into fundamental processes. However, this categorization is not really exclusive. Tests are processes returning values (normally boolean) used in conditional control flows. However, many transformations also return test values as well as their transformation outputs. Accessors are further categorized as either create accessors, read accessors, write accessors or delete accessors. OOA09 takes the view that simple processes are atomic access units that may include multiple accessors, transformations and tests. The important thing here is to ensure that hard constraints are not broken after simple processes are executed, e.g. don't create a supertype object in one process and the associated subtype object in another process. Simple processes still can't generate events and event generators still can't perform accesses or return output values in OOA09. This change in focus with regards to process partitioning is a crucial difference between OOA91 and OOA09.

While bridge mappings include:

request mappings,
synchronous return mappings,
asynchronous return mappings,
create counterpart mappings,
semantic shift mappings,
and watchpoint mappings including:
- object created mappings,
- object deleted mappings,
- object updated mappings,
- event generated mappings,
- and operation invoked mappings.

I won't get into bridge mappings this week since it is a big topic.

I should also mention operation owners which include:

objects,
mathematically dependent relationships,
event destinations,
and bridges.

Most operations will be owned by event destinations (state models, terminators and polymorphic destinations) in OOA09 rather than objects. This is because Shlaer-Mellor is lifecycle centric rather than object centric. Objects own value calculations (for mathematically dependent attributes). Mathematically dependent relationships own relationship navigations. State models own actions, simple processes and state model event generators. Terminators own synchronous services, request wormholes (domain-crossing event generators and bridging processes) and return wormholes. Polymorphic event destinations own polymorphic event generators. Bridges own bridge mappings (all varieties). In addition, all operation owners may own one or more functions.

The next build of OOA Tool should allow all of the operations defined above to be created. However, I'm not sure yet whether I will have graphical process models in the next build. There are other issues to be resolved involving data and control flows before graphical process modelling can be delivered.

Week 7 of 2009

2009-02-09T12:22:00.004Z

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

2009-02-05T08:02:00.017Z

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

Attribute

1.

Descriptive Attribute

Naming Attribute

Referential Attribute

2.

Identifying Attribute

Non-Identifying Attribute

The attribute classification hierarchy in OOA09 is shown below:

Attribute

1.

True Attribute

Base Attribute

1.

Simple Attribute

Arbitrary ID Attribute

Mathematically Dependent Attribute (Derived Attribute in Executable UML)

2.

Descriptive Attribute

Naming Attribute

Referential Attribute

Polymorphic Attribute

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

2009-02-02T08:26:00.004Z

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:

Week 5 of 2009

2009-01-26T07:35:00.002Z

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

2009-01-19T08:04:00.002Z

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

2009-01-12T07:32:00.008Z

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

2009-01-05T12:51:00.005Z

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:

release Standard edition of OOA Tool 1.0,
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.

Loop Dependent Relationships

2008-10-29T07:21:00.009Z

Relationship loops appear everywhere in information models. Most of these are loops of independent relationships. However, there are times when a loop-closing relationship is dependent on the relationship loop being closed.

OOA91 introduced the concept of a composed relationship (called an equal set constrained relationship in Executable UML) where the loop-closing relationship is equivalent to the composition of the relationships in the rest of the loop. In many cases, composed relationships are redundant and shouldn't be modelled by the analyst. Obviously, a composition containing a single relationship is always redundant and thus is not allowed. However, sometimes the nature of the composed relationship differs from the set of relationships which compose it even though the formalization is determined from those component relationships. The verb phrases used should highlight the differences. Composed relationships shouldn't be composed from other composed relationships. It would be possible to allow this as long as there was no circular compositions. However, such relationships can be difficult to understand and add little value. OOA Tool does not currently allow such relationships.

On a more pragmatic note, composed relationships allow heavily navigated complex relationship chains to be simplified. This technique should be used sparingly since it is a pollution of the information model. However, in some cases, it can significantly improve the readability and maintainability of Action Language code. Note that, composed relationships can be changed later without having to change any such code, e.g. the composition could be changed slightly or the composed relationship could be changed to become a mathematically dependent relationship.

The multiplicity and conditionality of composed relationships is initially determined directly from the component relationships. However, OOA Tool allows this to be changed reflecting the fact that the composed relationship should be modelling new information. The composed relationship can't increase multiplicity or add conditionality to component relationships. This will be flagged as an error in OOA Tool. However, many can be reduced to one and conditional can be changed to mandatory. This allows an additional constraint to be defined in the information model. Whether the final translated system checks this constraint is determined by the software architecture that you use. However, this constraint should be checked automatically by your simulator during testing.

OOA08 goes even further with composed relationships, it allows a participant mapping to be defined which can be used to constrain one or more referential attributes. This participant mapping is never used to navigate the composed relationship and a composed relationship is never created using an Action Language link statement. However, when other relationships are created which share referential attributes with a composed relationship's participant mapping then they can be checked against the composed relationship's navigation results. OOA Tool's tree browser shows referential attribute mappings for composed relationships in gray within referential suffixes.

This mechanism is sometimes useful since referential attributes aren't inherited in subtypes. An attribute may formalize a relationship in a supertype which is also used to formalise another relationship in a subtype. However, only referential attributes which are used as part of the supertype's identifier are 'inherited' in subtypes, i.e. they are used to formalise the subtype to supertype mapping. I have seen models where an analyst has added a common referential attribute to the supertype's identifier so that it can be used in the subtype. Identifier's should never be polluted in this way since the uniqueness constraint imposed by the identifier is always weakened (and sometimes completely broken) when redundant attributes are added.

Another type of loop dependent relationship is the subset constrained relationship. The concept of constrained relationships was introduced in OOA96. It annotates one or more of the referential attributes associated with the participant mapping which formalises the constrained relationship with a small 'c'. However, the concept was developed further in Executable UML [xtUML02] where the relationship label of a subset constrained association is annotated with a subset constraint indicating the relationship loop. OOA08 adopts a combination of the approaches. It annotates the relationship label of a constrained relationship (e.g. R2 ⊆ R3 + R1) and it annotates one or more referential attributes with a small 'c' in the appropriate part of the referential suffix. OOA08 allows simple relationships, associative relationships and mathematically dependent relationships to be constrained. Constrained relationships can constrain other constrained relationships since each constraint is checked independently using underlying relationship formalizations. The relationship loop being constrained may also contain only a single component relationship (unlike composed relationships which must be composed from two or more component relationships).

Below is an example of a constrained relationship in Shlaer-Mellor notation taken from [OOA96] (see page 14):

It uses the constrained relationship to impose the constraint that students can only be advised by a professor on the staff of the department in which the student majors in. This same example is shown below in Executable UML (xtUML) notation:

Note that, constrained referential attributes are not currently marked with a small 'c' in Executable UML class diagrams. However, OOA Tool does mark constrained referential attributes within its tree browser.

OOA Tool allows any referential attribute mappings to be marked as constrained. However, only referential attribute mappings associated with a constrained relationship should be marked as constrained since the flag currently has no meaning in other contexts. OOA Tool highlights informal constrained flags within its tree browser but it will still mark up the appropriate referential suffixes on Object Information Models. OOA Tool will only automatically mark one or more of the referential attributes of a constrained relationship if the analyst hasn't explicitly marked one of them already. This allows an analyst to more explicitly identify which attribute is being constrained. OOA96 only requires a single attribute to be marked. OOA Tool, by default, marks all referential attributes formalizing the constrained relationship except those which also formalise the first or last relationship from the associated relationship loop. However, in practice, this will normally be a single attribute.

The multiplicity and conditionality of a constrained relationship can initially be determined directly from it's dependent loop of component relationships. Obviously, OOA Tool allows this to be changed reflecting the fact that a constrained relationship should be a subset of it's dependent loop. However, a constrained relationship can't increase multiplicity or remove conditionality. This will be flagged as an error in OOA Tool. It can reduce many to one and mandatory to conditional. This differs from a composed relationship which acts like a superset constrained relationship since it allows conditional to be changed to mandatory but not vice versa.

Object Information Model Notation

2008-10-14T06:25:00.018+01:00

This is the fourth in a series of technical notes outlining the Shlaer-Mellor and Executable UML notation supported by OOA Tool. This technical note covers partial and complete Object Information Models (OIM) which are used to show the objects, attributes and relationships within a domain or subsystem. If a domain is partitioned into subsystems then each subsystem has a partial OIM showing assigned or imported objects along with assigned relationships. This is instead of showing a complete OIM for the entire domain. OIMs also show preferred identifiers, mathematically dependent statuses and referential attribute mappings.

Object Information Models in Shlaer-Mellor notation used to be called Information Structure Diagrams [OOA91]. However, the name Object Information Model was adopted later since OIMs are complemented by Object Communication Models and Object Access Models. This is the only name used in OOA08 and in OOA Tool (when using Shlaer-Mellor notation). Object Information Models are called Class Diagrams in all Executable UML variants, including [xtUML02] and Executable UML2. However, the Executable UML variant [xUML04] makes various minor changes to the Class Diagram notation described here which OOA Tool does not support.

There are a number of other name changes which are relevant here when switching between Shlaer-Mellor and Executable UML notation:

Information Models are known as Platform-Independent Models (PIM),
Objects are known as Classes,
Binary Relationships are known as Binary Associations,
Composed Relationships are known as Equal Set Constrained Associations,
Subtype-Supertype Relationships are known as Generalizations,
Participants are known as Relationship Ends,
Supertypes and Subtypes are known as Superclasses and Subclasses,
and the term mathematically dependent is replaced by derived, i.e. Mathematically Dependent Attribute becomes Derived Attribute and Mathematically Dependent Relationship becomes Derived Association.

Below is an example Object Information Model in Shlaer-Mellor notation taken from [OOA91] (see page 4):

Another example Object Information Model showing instances of all notationally different forms of object, attribute and relationship is shown below:

Objects are represented using rectangle shapes containing the object name, key letters and number along with attribute names (prefixed by star or round bullets). The attributes which compose the object's preferred identifier are prefixed by a star bullet. Imported objects are represented using dashed (and half transparent) rectangle shapes containing the same information as normal object shapes. A from annotation is always shown below imported objects, indicating which subsystem the object is imported from. On partial OIMs, key letters always include any prefix letters associated with the subsystem.

Attributes can be hidden by manually reducing the size of an object or imported object shape (after changing the shape's Preferred Size Usage attribute to None or Use As Maximum Size). An OIM which shows no attributes on any of the included objects is called an Overview Object Information Model (it used to be called an Overview Information Structure Diagram in [OOA88]).

Within object shapes, mathematically dependent attributes (introduced in [OOA96]) have an (M) suffix. Referential attributes have an (R) or (Rn, Rn...) suffix where the relationship IDs identify referential attribute mappings, i.e. the relationships that the attribute formalizes. The relationship IDs in a referential suffix may end with c indicating that the reference is constrained. Constrained referential attributes are supported in OOA Tool. However, better support for defining loop constraints will be added in the future. Polymorphic attributes (introduced in OOA08) have a (P) or (P-Rn) suffix where the relationship ID identifies the subtype-supertype relationship determining the polymorphic attribute's scope. Within OOA Tool's browser, naming attributes have an (N) suffix but this suffix is not used in OIMs.

Relationships are represented using rectilinear links labelled with relationship IDs. Relationships are either binary relationships or subtype-supertype relationships. Binary relationships are either simple relationships, associative relationships, composed relationships or mathematically dependent relationships. A binary relationship between an object and itself is called a reflexive relationship. Reflexive relationships are symmetric if both ends of the relationship have the same multiplicity, conditionality and verb phrase. Otherwise, they are called Asymmetric reflexive relationships.

Binary relationships connect a first and second object shape. Simple relationships are centrally labelled with the relationship ID. Associative relationships connect an associative object shape with a binary relationship. The point where the associative object shape connects to the binary relationship is labelled with the relationship ID. Composed relationships are centrally labelled with a summary of the composition, e.g. R10 = R2 + R3 + R4. Mathematically dependent relationships (introduced in OOA08) are centrally labelled with the relationship ID and an (M) suffix. Subtype-supertype relationships connect a supertype and two or more subtype object shapes. The link segment connected to the supertype object shape has a split bar labelled with the relationship ID on the left and the fixed partial verb phrase is a on the right.

A first or second object shape connector is either a single arrow or double arrow (if multiplicity is many) with an optional C annotation (if conditional). The connector is also annotated with the verb phrase (in italics) from the opposite participant, e.g. the verb phrase contains (from R2 in the diagram above) is associated with the LEFT SUBTYPE participant but shown on the RIGHT SUBTYPE connector. If there is no verb phrase and the participant's role (introduced in OOA08) has been changed from the default (i.e. first or second) then the connector is annotated with the role instead. An associative object shape connector is a plain line. A binary relationship connector from an associative link is either a single arrow or a double arrow (if multiplicity is many) with an optional C annotation (if conditional). Conditional in this sense means that the associative object can exist independently of the associative relationship. Associative relationship conditionality was introduced in OOA08. OOA96 introduced a special notation for symmetric reflexive relationships. No arrows or annotations are shown on one end of the relationship, i.e. the second object shape connector is a plain line. Such relationships are normally formalized using an associative object, e.g. R12 in the diagram above. Supertype and subtype object shape connectors are plain lines.

An example Class Diagram taken from [xtUML02] (see page 315) is shown below:

The second Shlaer-Mellor example above is also shown below in Executable UML notation:

Classes are represented using rectangle shapes split into three compartments. The first compartment contains the class name centred in bold along with the key letters and number as a right aligned UML property string. Attribute names along with associated data type names and any initial values are shown in the second compartment. Preferred identifiers are not shown on class shapes. However, identifier IDs for preferred and secondary identifiers are included in the UML property strings associated with identifying attributes in the second compartment. Event names are optionally shown in the third compartment. The class shape must be manually increased in size to show events (after setting Preferred Size Usage attribute to None or Use As Minimum Size). The second and third compartment can be hidden by manually reducing the size of a class shape (after changing the shape's Preferred Size Usage attribute to None or Use As Maximum Size). Imported classes are represented using half transparent rectangle shapes containing the same information as normal class shapes. An imported from annotation is always shown right aligned (just below the class name) in the first compartment of imported classes, indicating which subsystem the class is imported from.

Within the second compartment of class shapes, derived attributes have a slash '/' prefix. Conditional attributes are not currently distinguished in Executable UML class diagrams. However, a [0..1] multiplicity expression is normally shown immediately after the attribute name. The name of an attribute's data type (if defined) is shown after the attribute name prefixed by a colon ':' separator. This is followed by the attribute's initial value (if one is defined) prefixed by an equals '=' separator. Identifying attributes have an {In, In...} property set where the identifier IDs identify which identifiers the attribute is part of. Note that, I1 is always abbreviated to I. Referential attributes have an {Rn, Rn...} property set where the relationship IDs identify referential attribute mappings, i.e. the relationships that the attribute formalizes. Referential attributes without referential attribute mappings and constrained referential attributes are not distinguished on class diagrams. Polymorphic attributes (introduced in OOA08) are shown in italics and have a {P-Rn} property where the relationship ID identifies the generalization determining the polymorphic attribute's scope. Literal value attributes have a {frozen} property indicating that they can't be changed. All properties associated with an attribute are included in a single right aligned UML property string.

Relationships are represented using rectilinear links labelled with relationship IDs in italics. These are solid links except for links between association classes and binary associations which are short dashed links. Relationships are either binary associations or generalizations. Binary associations are either simple associations, association class associations, equal set constrained associations, subset constrained associations or derived associations. However, OOA Tool does not currently support subset constrained associations. It will when better support for loop constraints are added. A binary association between a class and itself is called a reflexive association. Executable UML does not support aggregations, compositions or n-ary associations. Furthermore, only disjoint complete generalizations are supported.

Binary associations connect a first and second class shape. Simple associations are centrally labelled with the relationship ID. Association class associations connect an association class shape with a binary association. The point where the association class shape connects to the binary association is labelled with the relationship ID. Equal set constrained associations are centrally labelled with the relationship ID and equal set constraint, e.g. R10 {equal, R2, R3, R4}. Derived associations are centrally labelled with the relationship ID prefixed with a slash '/'. Generalizations connect a superclass and two or more subclass shapes. The link segment connected to the superclass shape is centrally labelled with the relationship ID (in italics) on the left and the fixed constraint {disjoint, complete} on the right.

All class shape connectors except for superclass shape connectors are plain lines. A superclass shape connector is a large hollow arrow. Multiplicity and conditionality on first or second shape connectors are indicated using one of the following annotations: 0..1 for zero or one, 1 for exactly one, 0..* for zero or more, or 1..* for one or more. These connectors are also annotated with the verb phrase from the opposite participant, e.g. the verb phrase contains (from R2 in the diagram above) is associated with the LeftSubtype participant but shown on the RightSubtype connector. If there is no verb phrase and the participant's role has been changed from the default (i.e. first or second) then the connector is annotated with the role instead. A binary association connector from an association class is also annotated with one of the above multiplicity and conditionality annotations if multiplicity is many or conditionality is true. An explicit 1 annotation is never used here. A multiplicity of many indicates that there may be many association class associations between any given first and second class. A conditionality of true indicates that the association class can exist independently of the association class association. This level of formality (which is not defined in standard UML) is required to validate navigation across arbitrary relationships in Executable UML.

Finally, the second Shlaer-Mellor example above is also shown below in Executable UML2 notation:

Rather than repeat what was previously discussed, only the differences between Executable UML and Executable UML2 notation are listed below:

Imported classes are represented using half transparent rectangle shapes (with half transparent borders) containing the same information as normal class shapes. A from annotation is always shown centred (just below the class name) in the first compartment of imported classes, indicating which subsystem the class is imported from.
The colon ':' separator used between attribute and type names now appears without a proceeding space.
Conditional attributes are indicated by including a [0..1] multiplicity expression immediately after any type name.
Literal value attributes have a {readOnly} property indicating that they can't be changed.
Relationships are represented using rectilinear links labelled with relationship IDs in bold.
The links between association classes and binary associations are still short dashed links but dash lengths are slightly longer in Executable UML2.

Subsystem Communication Model Notation

2008-09-30T08:36:00.012+01:00

This is the third in a series of technical notes outlining the Shlaer-Mellor and Executable UML notation supported by OOA Tool. This technical note covers Subsystem Communication Models (SCM) which are used to show the subsystems within a domain and identify any asynchronous communications between those subsystems. The model itself is automatically derived. However, OOA Tool currently requires someone to layout the model since automatic layout of diagrams where all nodes are connected in many ways is incredibly difficult to perform.

Executable UML [xtUML02] does not name SCMs explicitly. However, diagrams in UML are generally called diagrams, not models. Furthermore, Object Communication Models are called Collaboration Diagrams in Executable UML while Collaboration Diagrams are now called Communication Diagrams in UML2. Thus, the name Subsystem Collaboration Diagram is used here when referring to an SCM in Executable UML notation while the name Subsystem Communication Diagram is used instead in Executable UML2 notation. The other Executable UML variant [xUML04] doesn't seem to use SCMs at all.

Below is an example Subsystem Communication Model in Shlaer-Mellor notation taken from [OOA91] (see page 153):

Subsystem Communication Models are very similar to Subsystem Relationship Models and Subsystem Access Models. They all represent subsystems using rectangle shapes containing the subsystem name, optional prefix letters and an optional number range along with prominent object names (prefixed by square bullets). The relative position of the prefix letters and number range was reversed in OOA08 compared to OOA91. OOA08 adopts a format consistent with that used for Objects within Object Information Models. Showing prominent object names in subsystem shapes is also a new feature of OOA08.

All internal asynchronous communications (i.e. internal events generated within state actions) from state models in a source subsystem to state models in a target subsystem are listed on a single rectilinear link with an arrow pointing to the target subsystem. Only the meaning of internal events is shown, i.e. supplemental data items are not shown on SCMs. Any asynchronous communications going in the opposite direction are listed on another rectilinear link with an arrow pointing in the opposite direction. These links only exist if one or more asynchronous communications exist. However, since subsystems within a domain are peer-to-peer, there may be many such links in a typical domain.

Asynchronous communications between subsystems and terminators (which are subsystem independent) are not shown on SCMs in OOA91. They are currently not shown on SCMs in OOA08 either. However, this may change in the future. There is a need to capture the external interface to a domain. This could partially be accomplished by showing external events (those generated outside the domain or within synchronous service actions) from terminators to subsystems and domain-crossing events from subsystems to terminators on SCMs.

The Shlaer-Mellor example above is shown below in Executable UML notation:

Another example Subsystem Collaboration Diagram taken from [xtUML02] (see page 273) is shown below:

Subsystem Collaboration Diagrams are very similar to Subsystem Relationship Diagrams and Subsystem Access Diagrams. They all represent subsystems using folder shapes containing the subsystem name. Prominent objects are not currently shown.

Subsystem dependencies listing asynchronous communications are represented using short dashed rectilinear links. The internal events are shown on a floating arrow pointing at the target subsystem. Unlike Shlaer-Mellor SCMs, there is never more than one link between any two subsystems, i.e. two links between a particular pair of subsystems in Shlaer-Mellor are replaced with two floating arrows on a single link in Executable UML.

Finally, the Shlaer-Mellor example above is also shown below in Executable UML2 notation:

Subsystems are still represented using folder shapes containing the subsystem name. However, the subsystem name is now shown in bold. Furthermore, the subsystem's optional prefix letters and number range is now shown as a right aligned UML property string below the subsystem name. This is consistent with how key letters and numbers are shown on class shapes within Class Diagrams.

Subsystem dependencies are still represented using short dashed rectilinear links. However, a consistent dash length is used across all package diagrams in Executable UML2. See page 43 of [UMLManual05] for an example UML2 package diagram. More significantly, the single floating arrows at each end of these links are replaced with multiple leading or trailing arrows (one per event). In UML2, events going in both directions can be listed together in sequence number order since each event is prefixed or suffixed with an arrow indicating the event's direction. However, sequence numbers are not used in Executable UML. Thus, OOA Tool keeps events which are going in the same direction together and separated from events going in the opposite direction.

Subsystem Relationship Model Notation

2008-09-25T15:53:00.012+01:00

This is the second in a series of technical notes outlining the Shlaer-Mellor and Executable UML notation supported by OOA Tool. This technical note covers Subsystem Relationship Models (SRM) which are used to show the subsystems within a domain and identify any spanning relationships between those subsystems. The model itself is automatically derived. However, OOA Tool currently requires someone to layout the model since automatic layout of diagrams where all nodes are connected in many ways is incredibly difficult to perform.

Executable UML [xtUML02] does not name SRMs explicitly. However, diagrams in UML are generally called diagrams, not models. Thus, the name Subsystem Relationship Diagram is used here when referring to an SRM in Executable UML notation. The other Executable UML variant [xUML04] doesn't seem to use SRMs at all.

Below is an example Subsystem Relationship Model in Shlaer-Mellor notation taken from [OOA91] (see page 153):

Subsystems are represented using rectangle shapes containing the subsystem name, optional prefix letters and an optional number range along with prominent object names (prefixed by square bullets). The relative position of the prefix letters and number range was reversed in OOA08 compared to OOA91. OOA08 adopts a format consistent with that used for Objects within Object Information Models. Showing prominent object names in subsystem shapes is also a new feature of OOA08.

All key letters for objects assigned to a subsystem begin with the subsystem's specified prefix letters. Prefix letters are automatically added to key letters in OOA Tool. All objects and relationships assigned to a subsystem should have numbers within the subsystem's specified number range. However, automatic numbering of objects and/or relationships can be disabled in OOA Tool which may lead to objects and relationships having numbers outside the specified number range (see Manual and Automatic Numbering).

All spanning relationships between a particular pair of subsystems are listed on a single rectilinear link. These links only exist if one or more spanning relationships exist. However, since subsystems within a domain are peer-to-peer, there may be many such links in a typical domain.

Below is an example Subsystem Relationship Diagram in Executable UML notation taken from [xtUML02] (see page 271):

Subsystems are represented using folder shapes containing the subsystem name. Prominent objects are not currently shown. Domains and subsystems use the same folder shapes since both are a type of UML package. However, Executable UML (xtUML) uses a smaller width folder for domains compared to subsystems and subsystem shapes show the subsystem name vertically centred (as packages should in UML).

Subsystem dependencies listing spanning relationships are represented using short dashed rectilinear links. They don't have an arrow since they are bidirectional dependencies. The spanning relationships are shown as a UML property string on the link. All UML property strings within OOA Tool use brace spacing in a consistent way, i.e. no space after '{' or before '}'.

Finally, the Executable UML example above is shown below in Executable UML2 notation: