Re: Sets and bags / Identity of a link



Date view Thread view Subject view Author view

stuart kent (stuart@mclellankent.com)
Wed, 24 Jan 2001 12:35:18 +0000


Arend Thanks for identifying the options. Here's a little further thinking on the topic. Let's start with your option 3d: > 3d. An association is an arbitrary list-valued object function. Actually I would say an association end is one of these. An association is a pair of association ends with an appropriate constraint that enforces bidirectionality. But I think you can be more general than this. An association is a pair of association ends, each comprising a query and cardinality constraint, where a query may have arguments and return a single value or collection of values. If the query does not return a collection, then the cardinaility constraint can be 1 or 0..1. (I realise that one could treat a single value as a singleton set, and this might simplify things. I have heard arguments from formalists for both positions.) Probably an association can only have a query with arguments at one end (the query at the other must not have arguments). This case would correspond to the UML qualified association. If both queries have arguments, I'm not sure one could come up with an appropriate bi-directionality constraint. Classes can have queries which are not part of assocations. The queries for are class are the union of these and the appropriate queries from associations referencing the class. A unidirectional association is just a single association end (query + cardinility constraint). One could lose the cardinility constraints as these could always be expressed using a general constraint language. One might also consider having other kinds of collection e.g. trees, graphs, etc. The semantics for this can then be modelled in a number of different ways. Probably I would have queries denoting values or collections of values, and associations denoting sets of links, where a link is a tuple of values (note one has to take account of queries with arguments). The denotations for queries involved in associations would be calculated from the set of links corresponding to that association. In other words I would model both views and provide constraints that ensure those views are kept in step. One can then go on to define certain kinds of association which further constrain the nature of the queries from which it constructed. One of these will be where both queries have no arguments and return a set of values. If you know your association is of this kind, then you should know how to simplify its semantics to object tuples, and that you know that transforming this kind of association into a form suitable for model checking which assumes the object tuple semantics will be a safe thing to do. I can imagine other tools (e.g. tools that allow me to view elements of the semantic domain - i.e. example states of the system - using a pictorial notation such as object diagrams) which would allow me to interchange between the different views. The modeler could choose the view(s) that he/she prefers to work with. In case your wondering why such tools might be useful, it is easier to explain an example to a customer (here is a situation with these three outstanding reservations, these two cars are out on rent, etc.) than to explain a model which captures all possible behaviours. Indeed, I find that to explain a model I have to talk about examples of states that are accepted or not by the model. expressions which return bags useful, and, because sometimes I wish to have associations which are derived (to save writing long navigation expressions) I would like to have associations made up of queries that return bags. Also, one thing that annoys me about UML 1.x and UML tools is that attributes, methods that are queries and ends of associations are all treated as completely different, and can not be interchanged as I think one should be able to do. This also makes OCL more complicated than it needs to be, as it must treat attributes, methods that are queries and ends of associations as separate distinct things. On the other hand, it is worth noting that when producing an detailed design model close to the implementation (one that code could be easily generated from), it is necessary to make distinctions between queries that are calculated (and perhaps have bodies which indiacte how they are calculated), those that are stored (no body, though possibly an intial value), those that are private, and so on. However, I think these extend and specialise the model suggested above - they don't conflict with it. Finally, with the UML 2.0 effort there is a chance that some things can get changed, so discussion on these topics is not wasted. Stuart -- ukc home - http://www.cs.ukc.ac.uk/people/staff/sjhk puml group - http://www.puml.org/


Date view Thread view Subject view Author view