From: Ulf Schuenemann (email@example.com)
Date: Mon 16 Sep 2002 - 20:04:24 BST
Hello everybody, I enjoyed following this discussion about the meaning of meaning, denotation, representation, model, etc. which are very versatile words. Let me throw in my $.02 worth before the discussion is over. (1) An object-oriented model is not a physical thing. It is the model of an existing/being-developed/hypothesized real system - the two share some relevant quantitative/qualitative properties, but not all properties. An certain elements of the model will model, or represent (as Joaquin said), certain elements of the system (and their environs). models represents means Model(-el.) -------------> System(-el.) This relation is the one which analysts / modelers are most interested in, so that to them, models _mean_ systems. [There are other cominations too: a styrofoam-and-paper object (physical) may model a building (physical), and Claudia Schiffer (just bec. Jean brought her up) may be the model of some (girl's) beauty ideal, ie. of an abstraction.] (2) Now, being a non-physical/abstract/conceptual thing, the model has to be represented somehow in order to be able to deal with it. This is done by expressing it in some modeling notation, usually diagrammatical. expresses models represents represents means means Diagram(-el.) -------------> Model(-el.) -------------> System(-el.) [syntactic [abstract [physical domain] domain] domain] Cf. the expression[syntax] : sense[abstract] : denotation[physical] triade. Designers of a modeling language and those trying to clarify its meaning have to be concerned, among others, about this relation. To them, a diagram elements _means_ a model element. (The UM*L* spec avoids 'means' and similar words by talking of diagram elements 'mapping' to model elements.) For the user of a modeling language - the analyst/modeler - it is ok not to care about the notational layer and freely point to a class symbol and say "this _is_ a class" (not: this expresses a class) "and it models/represents/means this-and-that in the system." (3) However, mapping diagram elements to model elements is not the ultimate end, since the prospective language user also wants to know what to model by these model elements. (The modeler who introduced a model element to model something may know what that element models, but how can others know?) Problem is, designers of a modeling language can only talk very generally about systems and thus give only a rather vague meaning to the elements of the abstract domain of models (and thus, ultimately, a vague meaning to the notation). Here, standard approaches developed for calculi, programming languages, etc. can help by providing mathematical models of data and computation. These model structure and behavior of systems, just what object-oriented models do. Since mathematical objects never refer to unique physical objects (cf. Frege/Russell's? denotation of "2" as the collection of all sets of two physical things), mathematicians might prefer to say that their mathematical objects are abstractions, not models, of systems. models/represents/means OO-Model ---------------------------------------------> System (-el.) ----------------> Math-Model ----------------> (-el.) ^ formal meaning (-el.) model-of | denotes? ^ abstraction-of | interpreted-as | | | Diagram(-el.) ----------------' denotes One can now define a mapping f (the "interpretation function" - Joaquin) from oo-models to mathematical objects (of a certain domain). For the modeling language designer f is the way how he gets the meaning of his oo-models defined. So one might call f the 'formal meaning', while f . model-of specifies the meaning which the modeler needs to use oo-models for modeling. For the modeler, f is not _the_ meaning but a clarification, which elucidates to him what oo-models actual mean, ie., how they model systems. IMHO it would be wrong to talk of "de-notation" in either case because what it gives meaning to is not a notation (syntactic domain). It is the explanation of one abstract domain in terms of another. Hence it is rather a kind of translation (at the semantic, not syntactic level). The translation also enables a new account of the meaning of the _diagrams_. "Denotation" is a better fit for this mapping from diagrams to math. objects (expresses . f). I hope this makes any sense. Meaning-of-meaning discussions always get confusing so easily... Regards, Ulf PS. Ad Tony's 'denotes': Traditionally it is the symbols which denote, or refer to, some thing which is therefore called the symbol's meaning. Now in Tony's example "let [[p]] denote the meaning of program p" 'denote' seems to go in the reverse direction. But everything is fine if one reads this as a declaration about the "[[.]]" notation: Let us use the notation (symbol) "[[p]]" to refer to (to denote) the p's meaning/denotation = what p denotes/means ... and let us reserve the notation "p" to refer to p as a syntactic entity, a symbol.