Issue 6206: UML 2 Super/Metamodel/missing owners for metaclasses (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: The following types don't have obvious owners: AnyTrigger CallTrigger ChangeTrigger InformationFlow PrimitiveFunction SignalTrigger TimeTrigger Resolution: see above Revised Text: Actions taken: September 7, 2003: received issue March 8, 2005: closed issue Discussion: On the diagram in Fig. 317 “Triggers” add a metaclass BehavioredClassifier, and an ownership association from BehavioredClassifier to Trigger. Multiplicities are 0..1 at the diamond, and * at the arrow end (pointing at Trigger). The label at the arrow is ownedTrigger (this subsets ownedMember). In the association section of BehavioredClassifier (p. 383 of ad/03-08-02) add ownedTrigger: Trigger References trigger descriptions owned by a clasifier. (Specializes Namespace.ownedMember.) End of Annotations:===== To: issues@omg.org Subject: UML 2 Super/Metamodel/missing owners for metaclasses X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 09:25:44 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 09:25:47, Serialize complete at 09/07/2003 09:25:47 The following types don't have obvious owners: AnyTrigger CallTrigger ChangeTrigger InformationFlow PrimitiveFunction SignalTrigger TimeTrigger Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com To: Cc: "Branislav Selic" , thomas.weigert@motorola.com, uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Mon, 1 Dec 2003 10:10:01 -0500 X-MIMETrack: Serialize by Router on D25ML06/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 12/01/2003 10:10:04, Serialize complete at 12/01/2003 10:10:04 Thomas, I have a couple of questions/comments: Issue 6281 So to be clear, Port should NOT be a subclass of Property? Issue 6206 In order for instances of Trigger (and its subclasses), InformationFlow, and PrimitiveFunction to be owned by a Namespace, these classes must be direct/indirect subclasses of NamedElement; currently they are not. Thanks, Kenn Hussey Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Thomas Weigert" 11/29/2003 11:36 PM Please respond to thomas.weigert To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject Updated: Proposed issue resolution for common behavior and composite structure working groups Dear all, I discovered that there are many more issues assigned to these two working groups in a later version of the FTF report that I had been looking at. Thus here comes a second installment based on FTF-report-draft-031031.doc (I hope this is the latest version). These two documents include the earlier sent one, so you can just ignore that one. Please pay attention to the discussion suggested for issue 6373. This issue would best be resolved by making a change to Kernel, which unfortunately means also changing the infrastructure. I believe it does not have any significant effect on anything, but changing the infrastructure is always highly controversial. Please advise. All the best, Th. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, November 29, 2003 7:56 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: Thomas Weigert Subject: Proposed issue resolution for common behavior and composite structure working groups Dear all, please find attached two documents discussing the issues assigned to the common behavior and composite structure working group, respectively. Each document has a summary page indicating the proposed action. Most issues do not require any change, as the UML 2.0 most often has already resolved the issue. There are 2 proposed changes for common behavior and one proposed change for composite structure, all minor. Regarding common behavior there are three issues (6148, 6149, and 6150) which I propose for discussion. While they would not require any change as the solution in the document is as was intended, the issues nevertheless could be addressed: 1. 6148 and 6149 implicitly propose an alternative means of showing textually defined behavior as associated with the Behavior metaclass and making that metaclass concrete. This is as good a solution as the one currently implemented; in my opinion a matter of taste. 2. 6150 requests a notation for method which is reasonable but should be decided upon by teamwork (as nobody ever is satisfied with notation). Please provide feedback on the proposed solution and also provide input to the issues labeled as for discussion. I will propose solutions for those after I have heard from at least several others on the FTF. All the best, Th. [attachment "Composite structure issues resolution.doc" deleted by Kenneth Hussey/Ottawa/IBM] [attachment "Common behavior issues resolution.doc" deleted by Kenneth Hussey/Ottawa/IBM] From: "Thomas Weigert" To: "Kenneth Hussey" Cc: "Branislav Selic" , Subject: RE: Updated: Proposed issue resolution for common behavior and composite structure working groups Date: Mon, 1 Dec 2003 09:29:22 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Ken, thanks for your comments. Please see below... Th. -----Original Message----- From: Kenneth Hussey [mailto:khussey@ca.ibm.com] I have a couple of questions/comments: Issue 6281 So to be clear, Port should NOT be a subclass of Property? Right. The semantics of being strongly owned by the containing class is given directly in Port. The reason for not making it a property is that it behaves a little different from standard properties as for the simple kind of ports (those typed by an interface) the interface is not really the type of the instance that is created but instead, the nature of the boundary object is determined by the semantics of Port taking that type into consideration. I guess I am worried that making it a subtype of property would muddle the semantics as it introduces additional complexities. Is there a reason for why you are concerned? Issue 6206 In order for instances of Trigger (and its subclasses), InformationFlow, and PrimitiveFunction to be owned by a Namespace, these classes must be direct/indirect subclasses of NamedElement; currently they are not. You are, of course, right. These should be PackageableElements. Alternatively, every behavior that uses triggers could be made to own them which would entail changes to state machine and activity. In addition, we need then to figure out how the ports can reference something inside one of the behaviors (for ports qualified by a trigger). While nobody ever would name a trigger, making it a packageable element seems to have the least impact.... OMG Issue No: 6206 Title: UML 2 Super/Metamodel/missing owners for metaclasses Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The following types don't have obvious owners: AnyTrigger CallTrigger ChangeTrigger InformationFlow PrimitiveFunction SignalTrigger TimeTrigger Discussion: On the diagram in Fig. 317 .Triggers. add a metaclass BehavioredClassifier, and an ownership association from BehavioredClassifier to Trigger. Multiplicities are 0..1 at the diamond, and * at the arrow end (pointing at Trigger). The label at the arrow is ownedTrigger (this subsets ownedMember). In the association section of BehavioredClassifier (p. 383 of ad/03-08-02) add ownedTrigger: Trigger References trigger descriptions owned by a clasifier. (Specializes Namespace.ownedMember.) Disposition: Resolved OMG Issue No: 6206 Title: UML 2 Super/Metamodel/missing owners for metaclasses Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The following types don't have obvious owners: AnyTrigger CallTrigger ChangeTrigger InformationFlow PrimitiveFunction SignalTrigger TimeTrigger Discussion: On the diagram in Fig. 317 .Triggers. add a metaclass BehavioredClassifier, and an ownership association from BehavioredClassifier to Trigger. Multiplicities are 0..1 at the diamond, and * at the arrow end (pointing at Trigger). The label at the arrow is ownedTrigger (this subsets ownedMember). In the association section of BehavioredClassifier (p. 383 of ad/03-08-02) add ownedTrigger: Trigger References trigger descriptions owned by a clasifier. (Specializes Namespace.ownedMember.) Disposition: Resolved