Mike Brough (firstname.lastname@example.org)
Mon, 24 Jan 2000 13:56:57 +0000
I think that this kind of discussion (which I found a clear resume of the issues) clarifies why there is a need to define the underlying virtual machine that UML is assumed to run in. That (I believe) is the concern of the work going on in the action language proposals. [Though I would have preferred to have 'deconflated' the issue of virtual machine and the language itself - the action language will be defined semantically, of course, independently of syntax.] Some of the current problems arise out of the underlying paradigm assumed by the original developers of UML (imho). There was a wish to 'integrate' the disparate graphical (largely) notations, used for modelling different aspects of object requirements, implementation, and deployment. This parallels the work that went on in the early 1980s on process+data system development methods ('Yourdon', IE, ...). By about 1984, it was realised that trying to tie down the semantics of diagrams by reference to the diagrams themselves was not very productive. But it took some time before the underlying 'pencil and paper' modelling paradim was dropped. [The YSM definition work, in which I was involved 1988-90, regarded the model views as being derived from an 'internal model', which was the thing that needed to have its semantics fixed.] I believe that O-O modelling has been suffering the same paradigm problem. We know that an instance of an association type will sometimes be created by an object (of a given type), as part of the response to dealing with an external event. We may wish to: 1. specify how and when this occurs (i.e. unambiguously specify the actions of objects, of given type) 2. visualise the interactions between objects, when instances of an association occur, ... These are two different types of question. If we move away from a pencil and paper modelling paradigm, these wishes are met by two different types of view: overviews (typically graphic); specification views (typically algebraic, textual, ...); if supported by a CASE tool (as we could assume all model-based approaches would be), this would be supported by 'emulation views'. These different types of view are supported by appropriate abstractions of types of fact that need to be considered by the system modeller/developer. These abstractions 'live' in the internal model. In the problem under discussion, we (I assume) are concerned with what (and when) causes instances of particular associations to be set up. This will be in response to an event, ... This should be modelled abstractly; any views can then be derived from this internal abstraction. This is the 'internal model paradigm' (as I call it). In my opinion, there is still a lot of implicit pencil and paper paradigm around (e.g. the discussion of diagram annotations). If you are still here, thanks for bearing with me! Mike Brough As the VM needs to be able to create instances of associations, any proposed action language needs to provide some kind of (API) operation to do this. Gonzalo Genova wrote: > John Daniels wrote: > > These changes in life state are derivable from the detailed interaction > among the Objects, they are provided as notational conveniences. > > So... how do you express in a "detailed interaction among the Objects" that > a new link has been established, in order that you can derive those changes > in life state? The question recurs. You suggest I should use annotations, or > OCL, but this is as much as saying UML cannot express by itself the > establishing of a link. > > On the other side, in the same UML notation guide section on Collaboration > Diagrams it says: > 3.73.1 During the execution of an interaction some Objects and Links are > created and some are destroyed. The creation and destruction of elements can > be marked. > 3.73.5 Creation or destruction indicators map either into CreateActions, > DestroyActions, or TerminateActions in the corresponding ClassifierRoles. > > And in UML Semantics we find: > 2.9 A create action is an action resulting in the creation of an instance of > some classifier. In the metamodel the CreateAction is an Action. The > Classifier to be instantiated is designated by the instantiation association > of the CreateAction. > > (quotes from OMG Unified Modeling Language Specification, Version 1.3, June > 1999) > > But note that a create action is not applicable to links, since both > Association and Classifier are subclasses of GeneralizableElement, but > Association is not a subclass of Classifier (UML Semantics, Fig. 2-6: Core > Package-Relationships; Fig. 2-15: Common Behavior-Actions). > > So... how is a link created between two object instances? Do we need in the > metamodel a new kind of Action which will be responsible of this task? > Should this new metaclass LinkAction be associated twice with the metaclass > Classifier, or only once with the metaclass Association? > > Gonzalo > > To remove yourself from this list please mail email@example.com > with a message containing the word "unsubscribe".