**From:** Bernd Westphal (*Bernd.Westphal@Informatik.Uni-Oldenburg.DE*)

**Date:** Tue 17 Sep 2002 - 10:56:11 BST

**Next message:**Joaquin Miller: "Re: Denotation, Meaning (and Humble Pie)"**Previous message:**Ulf Schuenemann: "Re: Denotation, Meaning (and Humble Pie) (was Re: [wg@2uworks.org])"**In reply to:**Ulf Schuenemann: "Re: Denotation, Meaning (and Humble Pie) (was Re: [wg@2uworks.org])"

Moin. The diagrams are great and help a lot for clarification. I basically agree with their definition of concepts, but perhaps it helps to make them even more explicit. First, the function definition diagram should take into account that a model usually models a set of systems and may even model no system if it contains contradictory specifications: models represents means Model(-el.) -------------> \powerset System(-el.) M |------------> { s \in System(-el.) | s fulfills M } Now it needs to be defined when "s fulfills M" holds ('fulfills', since M is a specification which communicates to the designer/programmer which systems are acceptable). "s fulfills M" is defined by mathematics. From the designers/programmers point of view, a system s may be seen as a piece of code in some programming language. To decide whether s fulfills M, the formal meaning (or math-model) of s is taken and checked whether it lies in the set of acceptable math-models denoted by the OO-Model: OO-Model - - - - - - - - - - - - - - - - - - - - - - -> System (-el.) ----------------> Math-Model <---------------- (-el.) ^ formal meaning (-el.) formal meaning | denotes? ^ | interpreted-as | | | Diagram(-el.) ----------------' denotes Note the following changes to Ulf's really nice drawing: the arrow from OO-Model to System is dashed since this is the function to be defined and the arrow from System to Math-Model is reversed. And -- just to name it -- there's one important difference between styrofoam-and-paper models of buildings and software systems: dynamics. Thus a Math-Model of an OO-System is usually a trace, i.e. a sequence of snapshots starting from a particular initial state where two subsequent snapshots are related by the OO-Model, for example the changes in values of object attributes between two snapshots can correspond to taking a transition in a state-machine in the model. The domain where the snapshots are taken from is defined by the static part of the OO-Model, it is the set of all object "diagrams" which adhere to the class "diagrams". Now the formal meaning of an OO-Model is the set of all traces allowed by the constraints and state-machines etc. in the OO-Model. The formal-meaning of an OO-Model without any constraints on dynamics (i.e. without any state- machines) is the set of all traces of snapshots, the formal-meaning of an OO-Model with contradictory constraints is the empty set. Joaquin wanted to have Objects and Classes in the same model or even the same diagram. The examples for situations where this makes sense looked to me like they were meant to specify those initial states. I.e. the designer wants to say: "Initially there are two objects of class C, they live on Node1 and Node2 and they are free to create new objects of classes D and E". This would best be solved by drawing an object diagram stereotyped as `initial state'. An invariant over the runtime like "there is always an object of class C on each of Node1 and Node2" can be expressed by an object diagram stereotyped as `invariant over time'. To express formally that the initial two Cs should live forever might require some temporal logic on object diagrams (or within OCL). Schoen'n Gruss Bernd PS: Again thanks for bringing this discussion to a greater audience! Ulf Schuenemann wrote: > > 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. > > > > > To remove yourself from this list please mail puml-list-request@cs.york.ac.uk > with a message containing the word "unsubscribe". > >

**Next message:**Joaquin Miller: "Re: Denotation, Meaning (and Humble Pie)"**Previous message:**Ulf Schuenemann: "Re: Denotation, Meaning (and Humble Pie) (was Re: [wg@2uworks.org])"**In reply to:**Ulf Schuenemann: "Re: Denotation, Meaning (and Humble Pie) (was Re: [wg@2uworks.org])"