MetaData Pattern Mining Workshop 1998
"Differences Between the Systems"
Ralph E. Johnson & Joseph W. Yoder
University of Illinois at Urbana-Champaign • Department of Computer
1304 W. Springfield Ave. • Urbana IL 61801-2987
firstname.lastname@example.org • email@example.com
(217) 244-0093 • (217) 244-4695
The last day of the workshop Ralph asked each one of the architects to name a
few aspects which made their systems different from the rest. Besides the
problem domain and the corresponding requirements the following will
outline what they authors see as the differences.
Hartford Insurance Company Framework Framework by Jeff Oakes
- 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
- I also saw your framework as having more developed view customization
services, that you had reflexively developed as well.
- 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.
- 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
- 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.
- 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.
- 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.
- 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
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
Joseph W. Yoder
Last modified: Fri July 27 15:01:21 CDT 1998