Thomas Baar (*baar@ira.uka.de*)

*Wed, 05 Sep 2001 17:30:08 +0200*

**Next message:**Ralf Kutsche: "Call for Papers FASE 2002 - Fundamental Approaches to Software Engineering"**Previous message:**Arend Rensink: "FMOODS 2002 -- deadline extension: 19 sept"

Hello, after reading the Initial Submission for OCL2.0 (see www.klasse.nl/ocl/subm-intro.html). I have some remarks concerning the finiteness of models stipulated by the proposed semantics. Consider as a first example the diagram ---------------- 1 succ | ListElem |<-----------| | pos : int | | | |------------| --------------- (just one class ListElem with attribute pos and self-association succ of multiplicity 1). There are plenty of finite interpretations (see Sect. 5.1.2) satisfying all constraints expressed in that diagram (e.g. two objects LE1, LE2 each linking to the other). But there is no such (non-empty) finite interpretation, if we also have the constraint context ListElem inv succ.pos = self.pos + 1 The proposed semantics defined in the submission implies, that the above UML diagram plus the constraint is as useless as, for example, the constraint 8 < 3; both specifications don't have a satisfying interpretation. But why should UML prevent us from talking -- at the conceptional level -- about infinite structures? Once we have accepted UML/OCL to be a specification language we also have to admit that talking about infinite structures is reasonable in many cases. I would say almost every successful abstract concept of computer science (e.g. Turing machines, abstract data types, logic, ...) does not care about finiteness (one reason they are called 'abstract'). I have even found a variation of the above diagram in the submission, section 3.2, figure 3.1 (at first glance, the diagrams differ but the core of the problem remains). Conceptionally, figure 3.1 is supposed to express (as far as I understand it) that for each Classifier there exist corresponding CollectionType, SetType, SequenceType, BagType. Thus, multiplicity 4 would be more appropriate for the association role collectionTypes what results in the following diagram: Classifier ----------------------| /_\ | | 4 | CollectionType -------------------| /_\ collectionTypes | | |---------------|-----------------| SetType SequenceType BagType However, assuming collection types to be not cyclic, multiplicity 4 would imply all satisfying interpretations to be infinite and, thus, non-existent iff only finite structures are allowed.(This is the similarity to the ListElem example; all satisfying interpretations must be infinite.) The technique to 'convert infinite into finite interpretations' is to set the multiplicity of collectionTypes to an optional value (sth that includes 0) as 0..4 in the submission. As a drawback of this solution one has to recognize that this UML model has satisfying interpretations in which, for instance, 'Integer' is a classifier but the corresponding settype 'Set(Integer)' does not exist. The point I want to make is that we sacrifice expressive power needed to design intuitive UML models in order to fit the UML models into a requirement labeled 'finiteness'. As a consequence, every modeler must use an optional multiplicity in each Composite-like UML model and if he or she forgets to do so the whole UML model becomes meaningless (due to the absense of any satisfying interpretations). This even seems to have happened in figure 3.7 for association between 'OCLExpression' and 'LetExpression'; the direction of the association does not help (formally) since it does not have a special semantics. I suggest to allow infinite interpretations to be (legal) snapshots of a system (cmp. Def 5.12). One can argue, that a UML model should be implementable and able to be run on a real computer with a restricted amount of memory. In my opinion, however, this argument is misleading. Every real computer has its own concrete bounds of memory, but in a UML model we can use soft bounds (e.g. the multiplicity 1..n means arbitrary many). Thus, to make sure that a UML model D is implemented on computer C correctly, we have to use special techniques solving the limited-resource-problem anyway. Best regards, Thomas -- Thomas Baar University of Karlsruhe http://i11www.ira.uka.de/~baar

**Next message:**Ralf Kutsche: "Call for Papers FASE 2002 - Fundamental Approaches to Software Engineering"**Previous message:**Arend Rensink: "FMOODS 2002 -- deadline extension: 19 sept"