Issue 6102: Pins owned twice (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: Pins are owned twice: by activities and actions Resolution: Revised Text: Actions taken: August 30, 2003: received issue March 9, 2005: closed issue Discussion: Pins are owned only by actions, not activities, per figures 176 and 178. Strongly composed objects can only be owned once. Disposition: Closed no change End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Pins owned twice Pins are owned twice: by activities and actions. OMG Issue No: 6102 Title: Pins owned twice Source: Kabira Technologies, Inc.NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Pins are owned twice: by activities and actions Discussion: In Figure 178, p. 270, change the multiplicities of the association between Action and OutputPin and between Action and InputPin on the Action end to "0..1". [Conrad: ActivityNodes are not necessarily owned by Activities (see figure 176), so perhaps this can be closed with no change. Seems like pins can always be owned by actions, doesn't it? If the above change is made, we'll need to explain what owns pins when, and also give the edits for the multiplicities in the metaclass entry for Action. Bran needs a complete specification of the changes. My suggestion: Close with no Change. Reason: Pins are owned only by actions, not activities, per figure2 176, 178.] Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 04 Jan 2004 11:59:34 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,gi, ,av, resolution text--issue 6102 as an example I suggest that, when we close an issue with no change, we be careful to explain why no change is made. This issue provides an example. Some might place the example on the borderline between adequate and not; i'd say we can do better by our customers. OMG Issue No: 6102 Title: Pins owned twice Summary: Pins are owned twice: by activities and actions Discussion: Pins are owned only by actions, not activities, per figures 176 and 178. Strongly composed objects can only be owned once. Disposition: Closed no change In ptc/03-08-02, Figure 176 shows aPin is black diamonded by anActivity and Figure 178 shows anInputPin is black diamonded by anAction and anOutputPin is black diamonded by anAction; all these associations subset ownedElement, so i suppose they mean: is owned by. The figures suggest that "Pins are owned twice: by activities and actions." I'm sure there is a perfectly clear explanation. But the Discussion is too terse to be clear. At first glance, "Pins are owned only by actions" in the Discussion appears to be contradicted by Figure 176. That figure is explicit that aPin may be owned by anActivity. Of course, that figure also tells us it is possible that there might be aPin that is not owned by anActivity. And Figure 178 tells us every one is owned by anAction. 12.3.37 says "Associations None." Of course, that is not correct, but maybe it is in accordance with the style adopted for the specification. There is nothing in 12.3.37 that says aPin may not be owned by anActivity. The innocent implementer might read Figure 176 as allowing that. Of course, it is forbidden by Figure 178. When we close no change, let's try to have the database include an explanation that makes perfectly clear the reason there is no change. Maybe the Discussion should be something more like: Discussion: Pins are owned only by actions, not activities, per figures 176 and 178. Figure 176 allows pins to be owned by activities, but figure 178 requires that every pin be owned by an action. Strongly composed objects can only be owned once, so all pins are owned by an action, and none by an activity. Instead of no change, we might instead add a bit of text to the specification, for folks who miss or misread the diagrams. =============================== The above is an example for this message. The message is: let's try to make sure the reason for the disposition is perfectly clear in the database. And when we want to make no substantive change, let's consider editing the specification text to add clarity. Many no change issues are the result of likely and understandable misreadings of the specification. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Disposition: Resolved