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.
(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.
No comments:
Post a Comment