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!
2 comments:
You need a Project-like object to provide a context for defining Bridges (and Layers) since bridges obviously don't belong to either their client or server domains. You also need a context for integrating whole systems composed of multiple domains. I know some of the existing CASE tools have not always provided good support for projects. However, I don't think you can define a truly reusable domain without a standard framework for integrating domains which in OOA10 is the Project object.
I do now how a workable design for defining local and imported assets and am busy implementing it. I will provide a new Recursive Design model and more details of the implementation next week.
It is nice to see a technical comment here. Thanks.
Almost anything can be captured in the architecture domain. This has been one of the biggest failures of Shlaer-Mellor OOA/RD. Too much stuff was offloaded into the architecture domain. For me, the architecture domain allows a fully executable model to be optimized against non-functional requirements, e.g. processing, memory, distribution, resilience, etc. I don't believe the architecture domain is there is make the model executable in the first place. That would make reuse of service domains very difficult unless the same architecture domain was used. In OOA10, I have been trying to capture an OOA of OOA that allows a fully executable model to be specified as part of the formalism.
Post a Comment