|
|
Meeting Minutes
June 2005:
From Domain Specific Visual Modeling to
Domain Specific Visual Metamodeling
Discussed the need for multiple visual notations at the metamodeling level.
Currently, metamodeling tools support multiple visual formalisms at the modeling level through metamodeling.
However, at the metamodeling level, only a single formalism (and the associated visual-notation) are supported :
e.g: ER for Atom3 and Class Diagrams for GME.
In order to support true end-user programmability, the modeling environment needs to support the use of multiple
visual formalisms at the metamodeling level as well. How can these be assigned a meaningful semantics??
Is there a point in doing this? Why is this useful?
These innocent questions led (as usual) to some wicked questions ...
How the Activity of Modeling differs from Traditional Programming
The problem seemed apparently clearer with traditional programming languages. Why? The simplicity is due to the fact that all programs
(models of traditional programming languages) are assigned only an operational semantics by immediately mapping on to a model of computation.
The "meaning" of a program is never discussed, it is only assigned meaning in so far as specifying "how to run it".
"what happens when you run it" is anybody's guess.
The need for Prototypes
Thus, we are given a running system, which is, by virtue of the fact that it is running, is a model of computation, and we use this to simulate new systems that
offer a different interface to this same system. In this manner, all traditional languages are implicitly prototype based, in that all programs
are a specialization of the prototypical computational process that is always in execution. What the process is doing
is beyond the scope of the programming language. It only specifies how the process being modeled by the program can be constructed by
specializing the prototypical computational process.
Parallels to Constructivism
This is also the essence of a constructivist model of the universe. What constructivists say, is that
since we know that "what something is" cannot be formally specified in a complete and consistent way
for all things (a la Godel), we instead content ourselves with specifying "how something can be constructed"
as a reasonable approximation for "what something is".
Fundamental Axiom of Modeling?
As modelers, however, we would like (preferably without trespassing any theoretical limits) for the "meaning" of a model to be formally specified.
And what is the meaning of this? This means we try and establish an equivalence between the model and another model for which the meaning
is agreed upoun by a majority of us (a denotational semantics), possibly practioners of some common art (domain experts). Thus, we are not saying that the meaning
of a model is specified, but that the equivalence of meaning with respect to another model is specified.
Domain Specificity and the Fundamental Axiom of Modeling?
The usefulness of a denotational semantics is thus incumbent upoun the existence of a core set of models whose meaning is
well defined, to the extent that it is agreed upoun by a large number of people.
The Fundamental Axiom of Metamodeling?
This brings us, naturally to the next question. Assuming that this core set exists for each domain, how do we represent the models
in the core set themselves? We have postponed the question of assigning meaning to the models so far, and we cannot postpone it any further.
At this point,
we resort to the prototypical computation and specialize it to create the core set models.
We must remember, however, that using the prototypical computation to create the core set models doesn't give them meaning.
It does not specify what they "are". This meaning exists only in the mind of the modelers. What the system facilitates,
is merely the mechanism to create objects whose behaviour simulates the objects in the mind of the modelers.
Thus the fundamental axiom of metamodeling can be simply stated thus:
The problem of representing the core set using a formal axiomatic system is, at best, intractable, and at worst, undecidable.
However, systems can be created to make it easier for outside observers of the system to deduce the intended meaning of the core set and to use this information to make design decisions
Implications for the Requirements Engineering of a Metamodeling Tool.
It can thus be argued that
the core activity of modeling is to create systems with which the "common core" models can be created, transformed, specialized, composed/reused
and most importantly, reasoned about. The features that support the ability to reason about the system are most valuable because
of the fundamental axiom of metamodeling: the meaning of the core set is unspecifiable. Thus, there is always a possibility of discovering
new properties of the represented system using the representation. The virtue of the modeling system lies in the operations
it supports to enable the modeler to discover these features, and to create representations of the new features discovered, and
so on and so forth, ad infinitum.
The Case for Domain Specific Visual Metamodeling.
What are the operations a tool needs to support to make it easier to reason about representations? The answer is obvious: it depends
on the domain. Take the case of audio signal processing - one of the class-objects in the core-set is the hierarchical signal flow graph class.
This class-object (call it TSignalFlow) represents a very large set of objects. The core activity of an audio signal processing expert is to identify subsets of this
class that are useful for particular signal processing tasks. E.g: low pass filters, high pass filters, band pass filters. Even more interesting
are custom filters designed, for example to boost a particular frequency range for some give room.
How do audio signal processing experts arrive at these filter graphs?
They know properties that are true of all filter graphs ( the properties of TSignalFlow class object).
They know ways of transforming one useful signal flow graph in ways to produce another useful signal flow graph
(sequences of TSignalFlow::operations that result in new members of TSignalFlow that satisfy certain properties).
They know ways of generalizing what they have learnt from one experiment on a particular signal flow graph to establish
a property satisfied by a whole sub-class of flow graphs.
This act of creating a new subset (of non-trivial size) that is known to be useful is the fundamental act of metamodeling.
Going back to the example of signal flow graphs, this would, for example, be the creation of a formalism + visual environment
for editing models of reverberation that was itself specified using a pattern language for specifying a set of models of signal flow.
which are a subset of the entire set of signal flow graphs.
Generalizing the syntax of the Metamodeling Formalism.
Given that the fundamental activity of metamodeling involves reasoning about large, complex sets, and creating new large, complex, subsets
of the sets being reasoned about, can we arrive at a common core of "operations on types" that are tailored for the specific purpose of
facilitating "thought experiments" on the type? This is consistent with the larger of goals of modeling and simulation in general, which
is of complementing thought experiments and reasoning with simulation.
This is also consistent with the freedom that traditional programming languages gave us by allowing us to
make up for our disability to say "what something is" precisely, with our ability to construct an object,
and generalizes this notion to the realm of types, where we can make up for our disability to define a sub-type in it's entirety
by using a computer augmented deductive system to construct the sub-type (sub set) incrementally so as to satisfy all the properties
that we would like it to posses.
Interaction with Sets
A first take on the operations that a visual metamodeling environment needs to support to ease the creation of subsets
is to define how the modeler can interact with a class-object (set). The details of the visual interaction with the set
is left as part of the metamodel of the domain, but they must support the basic operations.
To be continued in July 2005 ...
|