Issue 6177: UML 2 Super/Metamodel::BasicBehaviors/package merge issue (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: Package BasicBehaviors merges Kernel, but has associations like :Behavior[0..1] -->parameter:Kernel::Parameter[0..*] instead of :Behavior[0..1] -->parameter:Parameter[0..*] implying the parameter property type after the merge is to the Kernel::Parameter superclass, not the Parameter that was merged into BasicBehaviors. Is this the intention? Or should BasicBehaviors have redefined Parameter too? Looks like there are a number of these in the model where the type in the merging package was dragged into the class diagram from the merged package instead of creating a new merging type. If these types should be the merging type, then the model should be corrected. Or there needs to be clarification in package merge that the merging type is always used, regardless of what is specified in the model Resolution: Revised Text: Actions taken: September 7, 2003: received issue March 9, 2005: closed issue Discussion: According to the instructions of defining packages, when a metaclass C was used in a package P but not modified in P, where C was defined in Q and P merges Q, the class Q::C is used. This style is used throughout the specification. Disposition: Closed, no change End of Annotations:===== To: issues@omg.org Subject: UML 2 Super/Metamodel::BasicBehaviors/package merge issue X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 08:38:53 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 08:38:56, Serialize complete at 09/07/2003 08:38:56 Package BasicBehaviors merges Kernel, but has associations like :Behavior[0..1] -->parameter:Kernel::Parameter[0..*] instead of :Behavior[0..1] -->parameter:Parameter[0..*] implying the parameter property type after the merge is to the Kernel::Parameter superclass, not the Parameter that was merged into BasicBehaviors. Is this the intention? Or should BasicBehaviors have redefined Parameter too? Looks like there are a number of these in the model where the type in the merging package was dragged into the class diagram from the merged package instead of creating a new merging type. If these types should be the merging type, then the model should be corrected. Or there needs to be clarification in package merge that the merging type is always used, regardless of what is specified in the model. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 To: weigert@comcast.net Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Straw poll ballot on compliance merge resolution directions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 20 Feb 2004 10:16:27 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/20/2004 10:16:29, Serialize complete at 02/20/2004 10:16:29 Hi Thomas, here are some explanations for your questions: > 1. In (2), re issue 6177, it is said "Organize the document > exclusively by packages and sub-packages corresponding to different > modeling capabilities". I don't understand what the clause > "corresponding to different modeling capabilities" implies. By different "capabilities" we mean the individual and distinct formalisms that exist in UML, specifically things such as: state machines, activity modeling, interactions, actions, etc. We used to call these things "sub-language stacks" in the U2P at one time. > 2. In (5), on compliance points, is the only difference between > option 1 and option 2 the introduction of L0? I assume that the > paragraph starting with "Tool vendors can:" including the 3 bullets > would apply to both options, right? Yes. That is the only difference. In a sense the two options are compatible in the sense that option 1 is a superset of option 2. Hope this clarifies it. Thanks...Bran e-mail: bselic@ca.ibm.com OMG Issue No: 6177 Title: UML 2 Super/Metamodel::BasicBehaviors/package merge issue Source: Bran Selic, IBM (bselic@ca.ibm.com) Summary: Package BasicBehaviors merges Kernel, but has associations like :Behavior[0..1] -->parameter:Kernel::Parameter[0..*] instead of :Behavior[0..1] -->parameter:Parameter[0..*] implying the parameter property type after the merge is to the Kernel::Parameter superclass, not the Parameter that was merged into BasicBehaviors. Is this the intention? Or should BasicBehaviors have redefined Parameter too? Looks like there are a number of these in the model where the type in the merging package was dragged into the class diagram from the merged package instead of creating a new merging type. If these types should be the merging type, then the model should be corrected. Or there needs to be clarification in package merge that the merging type is always used, regardless of what is specified in the model Discussion: According to the instructions of defining packages, when a metaclass C was used in a package P but not modified in P, where C was defined in Q and P merges Q, the class Q::C is used. This style is used throughout the specification. Disposition: Closed, no change