Week 10 of 2011

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

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

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

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

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

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

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.