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).
One final thing. I would like to thank Kennedy Carter and Ian Wilkie in particular for making the following white papers publically available:
No comments:
Post a Comment