The MONDO Approach to: Extending Model Functionality
Mark L. Fussell
fussellm at alumni.caltech.edu
Mon Dec 1 14:20:39 GMT 1997
The MONDO Approach to: Extending Model Functionality
Problem
=======
How can we extend the functionality of our information and information
model without becoming language specific?
Although information can be interpreted and implemented in many ways,
frequently we will want to provide possible implementations so
applications can automatically extend their capabilities in interesting
new ways.
Forces
======
If we put the implementation into the information we will make the
information less general. If we provide no implementation (when we have
one) we make the information less knowledgeable and capable than we could
have.
MONDO Approach
==============
Describe implementation details in the same knowledge form as all our
other information and loosely associate/link Classes to Types through
possible Implementations.
We can represent a Java class as (the MONDO recipe in OML):
<JavaClass
name = "COM.chimu.kernel.basicTypes.Period"
version = "v0.1"
vmRequired = "1.1"
description = "This is a simple Period which uses java.util.Dates as
its start and end values"
bytecodes = <Binary encoding=hex [[cafebabe...2000a]]>
>
This is readable to both Java and non-Java systems. A non-Java system
may not understand the bytecodes, but it can understand everything else
and work with the information usefully.
Next we can associate this class with a particular Type in our model.
<Implementation
type = <TypeReference name="Period">
language = "Java"
class = <ClassReference name= "COM.chimu.kernel.primitives.Period">
>
The loose association is (relatively) complete, and a particular program
can decide whether it can use and wants to use a Java implementation of
the Type Period. It can also check whether the VM level is acceptable.
We can similarly provide a Smalltalk or ".dll" implementation (assuming
we can move the ".dll" around).
None of this had any effect on our original instance and model:
<Period
start = <Date iso="1997-10-01">
end = <Date>
>
<Model types=(
//...
<Type
name = "Period"
description = "A range of dates"
properties = (
<Property name="start" type=<TypeReference name="Date"> >
<Property name="end" type=<TypeReference name="Date"> >
)
constructors = (
<Constructor ("start" "end")>
)
>
//...
)>
So they still describe "pure" general knowledge and we can still use them
independently of all the language-localized implementations.
Tradeoffs
=========
Generally, it is a win-win situation. Implementation can be reasoned
about and chosen without directly coupling it into the information
itself. The architecture itself is also no more complicated, but only
has new objects and classes to represent implementation information. A
negative might be the added complexity of the:
instance--[interpretation]--model--[implementation]--classes
associations, but the complexity can be selected as needed. Another
negative might be the required based functionality of an ObjectBuilder,
but generally ObjectBuilders must be able to simply model (e.g. as an
object with properties) anything they can not understand in more detail.
See
===
The MONDO Design addition on "Modeling and Implementing, Objects and
Recipes".
http://www.chimu.com/projects/mondo/design/index.html#additions
--Mark
mark.fussell at chimu.com
i ChiMu Corporation Architectures for Information
h M info at chimu.com Object-Oriented Information Systems
C u www.chimu.com Architecture, Frameworks, and Mentoring
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list