Week 7 of 2010

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

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

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

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

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

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

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.