MetaData Pattern Mining Workshop 1998

Ralph E. Johnson & Joseph W. Yoder

Contents

• UDP
• Objectiva
• Argo

Hartford Insurance Company Framework Framework by Jeff Oakes

1. I guess the anthropomorhization of the rules and computations is where our variation differs the most. However, I very much liked your use of Rose. Can you tell me what the interface is, or how to get its specification? I think this would be a major plus for our product definition, too.
2. I also saw your framework as having more developed view customization services, that you had reflexively developed as well.
3. As for my reference to emphasis, I believe there is an underlying common theme shared by all of our frameworks. And, the differences are a function of customer perceived hot spots, and our available energy to respond to them. Sorry, I do not believe there are distinct domain specific structures and/or solutions at this level of design.
4. Having said that I must also say that it will always be true that distinct applications (and/or distinct customers) will perceive hot spots differently and with different priorities. These differences will lead to coincidental few distinctions, and emergence of alternative variations earlier or later. This will lead to apparent differences which far over-shadow real distinctions. In other words I believe that our rule objects, Francis' relationship distinctions, and Michell's view customization maps are inevitable developments in any of these fw's, should they enjoy a long enough life.

Objectiva Telephone Billing System by Francis Anderson

1. Analysis of the different Data and Relationship Types. I did not see the distinction between Continuous and Discrete (Enumerated) data in either of the other two systems, nor the distinction between composition (Tree structure) and inclusion (DAG) as being distinct from regular associations. Michel appeared to handle associations as "ComplexAttributes", and Jeff's components only appeared to form a Tree.
2. Optimization of storage requirements. Having used only an ODBMS, we were particularly sensitive to storing simple values (Strings, Numbers, etc.) as though they were complex objects i.e. treating a value as a reference. This made us concerned with "flattening" objects, and not a more dictionary-based implementation of VariableState. Michel directly used the dictionary implementation; Jeff had the attribute (value) directly responsible for recording its own history, i.e. knowing its context, and thus his values had become complex objects anayway.
3. Not everything is a hot spot. Maybe it is due to not having done as much iteration / refactoring, but Entity has a much more traditional subclass hierarchy, and BusinessObjects are expected to be implemented as a combination of classes and rules expressed in EntityTypes, rather than just in user-defined rules. To that extent, we are still just parameterizing hot-spots, rather than parameterizing everything. Although where one draws the line, I am not sure. I guess it depends on the business, among a number of other variables. We did not generalize PricePlans into NDT's, nor introduce a "language". I guess, from 1) above, that makes us much more meta-data than meta-behavior.
4. Separation of EntityContext from Entity. I think this is the Bridge Pattern. This separates out the generic part of each business object from its "interface". This has turned out to be very useful for recording history, but as could probably be seen from my explanation, why delegation rather than inheritance seemed better at the time of the original design (rather than just being "too heavyweight") we could never really quantify.

Argo Belgium School System by Michel Tilman

1. We try to move as much items related to a particual business case as possible out of the framework classes and into the repository: object model, application definitions, queries, views, authorizations, constraints, rules, behavior. This enables us to reduce the number of hard-coded tools to a minimum.
2. We try to push the reflective part a bit further, by including e.g. object model and meta-model in the repository. This enables us once more to re-use existing tools.
3. We put a lot of emphasis on end-user configurability, but in some cases we decided not to include additional configuration options as the features might become a bit overwhelming for some users. This is particulary the case for layout editors, as these tools are not configured applications right now, and they are the most widely used by end-users.
4. There is obviously much more emphasis on the 'computation' part in the other frameworks I saw than in ours. A question I have is whether the computation part is important, whether the recursive part is literaly what it means and if it is important, or that the two are orthogonal.
5. In the recursive structures we have in our applications there is no general theme of cascading deletes, locks, ... that applies in all cases as far as I can tell.
6. We are also converting existing database applications to our framework. There are more computations involved. They also contain many constraints (there are about 39000 lines of SQL statements involved for query screens and constraints; luckily we do not have to convert them all :) ). So far we worked on a part of object model, and are starting to work on the constraints. We are certainly going to learn a lot from this conversion.

• OOPSLA '98 MetaData Workshop
• UoI '98 MetaData Workshop
• Joe's MetaData Pages
• Joe's Home Page