Issue 8168: Figure 89 on page 158 is incorrect (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: ptc/04-10-02: Figure 89 on page 158 is incorrect: the delegation connector on the left seems to be pointing the wrong way. More generally, it is not clear why an arrow is required on delegation connectors, since they are automatically implied when a port is connected to a part or a port on a part. The arrow can be misleading since some may interpret incorrectly it as a restriction on the direction of data flow. Note that the table 5 on page 166 does not show the arrow notation nor does table 7. Finally, the title of table 5 should say: "graphic paths" instead of "graphic nodes" Resolution: The first part refers to figure 8.12. The "more generally" part applies to figure 8.16 and the associated text. Delegation connectors do not need any special notation other than that defined for connectors in general in table 9.2. The third aspect of this issue is a duplicate of 12236, already resolved. Revised Text: Insert the following paragraph before the paragraph above 8.12 that starts with the words "Interfaces that are exposed …": "If the parts have simple ports (ports with a single required or provided interface), then ball-and-socket notation can be used to represent connectors between those ports, and normal connector notation for assembly or delegation may be shown connected to the ball or socket symbol rather than to the port symbol itself. If a part has no ports, or complex ports, the notation for connector wiring is as specified in Clause Composite Structures. " Replace Figure 8.12, and its caption, by this: Figure 8.12 - An internal or white-box view of the internal structure of a component that contains other components with simple ports as parts of its internal assembly. Replace the paragraph immediately above 8.16 with this: "A delegation connector is notated as a Connector from the delegating Port to the handling Port or Part. If the delegation is handled by a simple Port, then the connector may optionally be shown connected to the single lollipop or socket as illustrated by figure 8.12." Replace the top part of 8.16 with this: This also resolves issues 9807 and 12241 and some of 8900. Disposition: Resolved OMG Issue No: 8249 Title: Section: 12.3.33 Source: U. S. Geological Survey (Jane Messenger, jmessenger@usgs.gov) Summary: Add OCL notation to constraint. Correct multiplicity of association interrutingEdge:ActivityEdge[0..*] so that fig. 194 and text agree. Typos - Change 2nd sent. of 2nd para in sub-section Semantics to "...and the token arrives at the target even is an interruption occurs... . " - Under sub-section Presentation Option, spell zigzag as one word, not two. Resolution: The OCL issue is covered by Issue 6346. The wording in UML 2.2 is already correct ("..even if an interruption occurs…"). However, zigzag should, indeed, be one word. Revised Text: In Section 12.3.33, under Presentation Option, change "zig zag" to "zigzag". Disposition: Resolved Actions taken: January 28, 2005: received issue April 26, 2010: closed issue April 26, 2010: closed issue April 26, 2010: closed issue Discussion: End of Annotations:===== ubject: UML 2 Super/Components/delegation connector incorrect X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 28 Jan 2005 12:40:13 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 01/28/2005 12:40:15, Serialize complete at 01/28/2005 12:40:15 ptc/04-10-02: Figure 89 on page 158 is incorrect: the delegation connector on the left seems to be pointing the wrong way. More generally, it is not clear why an arrow is required on delegation connectors, since they are automatically implied when a port is connected to a part or a port on a part. The arrow can be misleading since some may interpret incorrectly it as a restriction on the direction of data flow. Note that the table 5 on page 166 does not show the arrow notation nor does table 7. Finally, the title of table 5 should say: "graphic paths" instead of "graphic nodes" Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 X-Authentication-Warning: banginis.nomagic.com: www-data set sender to nerijus@nomagic.com using -f Date: Thu, 7 May 2009 23:33:27 +0300 (EEST) Subject: ballot 6 : comments on issue 8168 From: "Nerijus Jankevicius" To: uml2-rtf@omg.org User-Agent: SquirrelMail/1.5.2 [SVN] X-Virus-Scanned: ClamAV 0.94.2/9342/Thu May 7 20:33:10 2009 on banginis.nomagic.com X-Virus-Status: Clean Steve, .If the parts have simple ports (ports with a single required or provided interface), then ball-and-socket notation can be used to represent connectors between those ports, and normal connector notation for assembly or delegation may be shown connected to the ball or socket symbol rather than to the port symbol itself.. this text is misleading, as ball-in-socket notation is not used on delegation connector ; assembly connector can't be connected directly to ball or socket symbol also. BTW, connector attached directly to ball or socket symbol is a new and pretty complex notation. Why do we need this? I see expensive changes in current implementations and would vote NO for whole resolution which in fact must solve direction notation problem only(remove it), no more. This change is out of 8168 scope. Also, does text mean that ball-and-socket can be used with simple ports only? The text in the spec before figure 8.17 says opposite : .When this notation is used to connect .complex. ports that are typed by multiple provided and/or required interfaces, the various interfaces are listed as an ordered set, designated with {provided} or {required} if needed. . How it looks like? (out of 8168 scope) Nerijus DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=flgYuaZp4i3LIlbKm/6MDAKkSC2OU2eyiaEZd0ewKSU=; b=sd818c0T7kt9PLSN74ZmGTApIMBZCOedlpYw1unGaeW8/7EwoQiavsJ2NoWM2CacMW ZZACIY9tvhyrXWk9aIyUC13ShjQ3ptAkhVPPyEwZumNBKFcmrB6ycxigOxIS6PDduA0y x1yMCiSXxTz7Mxm8d9bioCWG8qlXkc0F1DmMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SXz/iczKSc7A6fDe3qHPYjam8fy6QaqpH5PsKw/O13IzZ5/Ul1PIh7AvTx564LS7TB YbgmFb7EPlJ/vOKnIIgWkVw1GJOsn5pRbeVE8Z9T0folEU57FutOdSxIVjfAw9uYw98q y1t5x1w8OoCTeicxvVAtG8v6UxbyVt7NLNrHo= Date: Fri, 8 May 2009 07:28:37 -0400 Subject: Re: ballot 6 : comments on issue 8168 From: Bran Selic To: Nerijus Jankevicius Cc: uml2-rtf@omg.org I have resisted this ball-in-socket notation from the day it was proposed. As we can see it is merely the source of problems and confusion but adds no value. I still recommend getting rid of it. removing its should not have any impact on existing models since each ball-in-socket connection can be automatically replaced by an equivalent connector line. Cheers...Bran On Thu, May 7, 2009 at 4:33 PM, Nerijus Jankevicius wrote: Steve, .If the parts have simple ports (ports with a single required or provided interface), then ball-and-socket notation can be used to represent connectors between those ports, and normal connector notation for assembly or delegation may be shown connected to the ball or socket symbol rather than to the port symbol itself.. this text is misleading, as ball-in-socket notation is not used on delegation connector ; assembly connector can't be connected directly to ball or socket symbol also. BTW, connector attached directly to ball or socket symbol is a new and pretty complex notation. Why do we need this? I see expensive changes in current implementations and would vote NO for whole resolution which in fact must solve direction notation problem only(remove it), no more. This change is out of 8168 scope. Also, does text mean that ball-and-socket can be used with simple ports only? The text in the spec before figure 8.17 says opposite : .When this notation is used to connect .complex. ports that are typed by multiple provided and/or required interfaces, the various interfaces are listed as an ordered set, designated with {provided} or {required} if needed. . How it looks like? (out of 8168 scope) Nerijus From: Steve Cook To: Bran Selic , Nerijus Jankevicius CC: "uml2-rtf@omg.org" Date: Fri, 8 May 2009 12:58:21 +0100 Subject: RE: ballot 6 : comments on issue 8168 Thread-Topic: ballot 6 : comments on issue 8168 Thread-Index: AcnP0KfYXQNgA4+oQ92OidtZ5H8vlwAArNEA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Bran I would appreciate it if you would bear in mind that I have based this set of interlocked proposals, which have taken me several days, on the result of the earlier informal doodle poll in which the clear majority was for retaining the notation but restricting it to simple ports. Reopening that discussion at this stage does not appear at all constructive to me. Thanks -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 08 May 2009 12:29 To: Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: Re: ballot 6 : comments on issue 8168 I have resisted this ball-in-socket notation from the day it was proposed. As we can see it is merely the source of problems and confusion but adds no value. I still recommend getting rid of it. removing its should not have any impact on existing models since each ball-in-socket connection can be automatically replaced by an equivalent connector line. Cheers...Bran On Thu, May 7, 2009 at 4:33 PM, Nerijus Jankevicius wrote: Steve, .If the parts have simple ports (ports with a single required or provided interface), then ball-and-socket notation can be used to represent connectors between those ports, and normal connector notation for assembly or delegation may be shown connected to the ball or socket symbol rather than to the port symbol itself.. this text is misleading, as ball-in-socket notation is not used on delegation connector ; assembly connector can't be connected directly to ball or socket symbol also. BTW, connector attached directly to ball or socket symbol is a new and pretty complex notation. Why do we need this? I see expensive changes in current implementations and would vote NO for whole resolution which in fact must solve direction notation problem only(remove it), no more. This change is out of 8168 scope. Also, does text mean that ball-and-socket can be used with simple ports only? The text in the spec before figure 8.17 says opposite : .When this notation is used to connect .complex. ports that are typed by multiple provided and/or required interfaces, the various interfaces are listed as an ordered set, designated with {provided} or {required} if needed. . How it looks like? (out of 8168 scope) Nerijus DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=CLN76KO472fx+2ar8pN8XtwXRi0t/x/aeL24BRv+1M8=; b=RjAJyMemjQeKhtuNg6KgTxiCgn82NR64siK/E3Qp7I8v5pkFpuvfYuC83LSF1fbUxE L2RvVFmc3BSYoUKrvTotcqEHIloGVjCfAwuhLvSs6nqa4g8rzgrgAwlBlMabxXG4B6pC DTqUhyCS/GPSxrD4isa+Z2jAGBbqbrMAqI3W8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uktxoZ/w8fbPtTaSGnIwcrfAlrC06unMxk/liJTZTC0DzwUn5Lz+WUSdv1akjsD91I uNuODcOqA1kCBsriPalnaVjedS3eJEVctY9lzGjKwzRXMKQPuK8WjC3lgXOYIJlO6X1E 6KAy8zDPOIdHEuToYc5mOIHfIfzbSqJ7kkWtA= Date: Fri, 8 May 2009 08:01:57 -0400 Subject: Re: ballot 6 : comments on issue 8168 From: Bran Selic To: Steve Cook Cc: Nerijus Jankevicius , "uml2-rtf@omg.org" Steve, My apologies for not being clear. I do think that we should work on getting rid of that notation as a long-term strategic item. In other words it is an input for the UML 3.0 RFI. I did not mean it as something to be resolved by the RTF. Cheers...Bran On Fri, May 8, 2009 at 7:58 AM, Steve Cook wrote: Bran I would appreciate it if you would bear in mind that I have based this set of interlocked proposals, which have taken me several days, on the result of the earlier informal doodle poll in which the clear majority was for retaining the notation but restricting it to simple ports. Reopening that discussion at this stage does not appear at all constructive to me. Thanks -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 08 May 2009 12:29 To: Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: Re: ballot 6 : comments on issue 8168 I have resisted this ball-in-socket notation from the day it was proposed. As we can see it is merely the source of problems and confusion but adds no value. I still recommend getting rid of it. removing its should not have any impact on existing models since each ball-in-socket connection can be automatically replaced by an equivalent connector line. Cheers...Bran On Thu, May 7, 2009 at 4:33 PM, Nerijus Jankevicius wrote: Steve, .If the parts have simple ports (ports with a single required or provided interface), then ball-and-socket notation can be used to represent connectors between those ports, and normal connector notation for assembly or delegation may be shown connected to the ball or socket symbol rather than to the port symbol itself.. this text is misleading, as ball-in-socket notation is not used on delegation connector ; assembly connector can't be connected directly to ball or socket symbol also. BTW, connector attached directly to ball or socket symbol is a new and pretty complex notation. Why do we need this? I see expensive changes in current implementations and would vote NO for whole resolution which in fact must solve direction notation problem only(remove it), no more. This change is out of 8168 scope. Also, does text mean that ball-and-socket can be used with simple ports only? The text in the spec before figure 8.17 says opposite : .When this notation is used to connect .complex. ports that are typed by multiple provided and/or required interfaces, the various interfaces are listed as an ordered set, designated with {provided} or {required} if needed. . How it looks like? (out of 8168 scope) Nerijus From: Steve Cook To: Bran Selic CC: Nerijus Jankevicius , "uml2-rtf@omg.org" Date: Fri, 8 May 2009 13:07:00 +0100 Subject: RE: ballot 6 : comments on issue 8168 Thread-Topic: ballot 6 : comments on issue 8168 Thread-Index: AcnP1M8pMxDYrTGhSPK2iJs2/f18FAAACYpw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Bran, many thanks for the clarification. Hopefully you will be submitting a detailed response to the Future Development of UML RFI. Thanks -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 08 May 2009 13:02 To: Steve Cook Cc: Nerijus Jankevicius; uml2-rtf@omg.org Subject: Re: ballot 6 : comments on issue 8168 Steve, My apologies for not being clear. I do think that we should work on getting rid of that notation as a long-term strategic item. In other words it is an input for the UML 3.0 RFI. I did not mean it as something to be resolved by the RTF. Cheers...Bran On Fri, May 8, 2009 at 7:58 AM, Steve Cook wrote: Bran I would appreciate it if you would bear in mind that I have based this set of interlocked proposals, which have taken me several days, on the result of the earlier informal doodle poll in which the clear majority was for retaining the notation but restricting it to simple ports. Reopening that discussion at this stage does not appear at all constructive to me. Thanks -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 08 May 2009 12:29 To: Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: Re: ballot 6 : comments on issue 8168 I have resisted this ball-in-socket notation from the day it was proposed. As we can see it is merely the source of problems and confusion but adds no value. I still recommend getting rid of it. removing its should not have any impact on existing models since each ball-in-socket connection can be automatically replaced by an equivalent connector line. Cheers...Bran On Thu, May 7, 2009 at 4:33 PM, Nerijus Jankevicius wrote: Steve, .If the parts have simple ports (ports with a single required or provided interface), then ball-and-socket notation can be used to represent connectors between those ports, and normal connector notation for assembly or delegation may be shown connected to the ball or socket symbol rather than to the port symbol itself.. this text is misleading, as ball-in-socket notation is not used on delegation connector ; assembly connector can't be connected directly to ball or socket symbol also. BTW, connector attached directly to ball or socket symbol is a new and pretty complex notation. Why do we need this? I see expensive changes in current implementations and would vote NO for whole resolution which in fact must solve direction notation problem only(remove it), no more. This change is out of 8168 scope. Also, does text mean that ball-and-socket can be used with simple ports only? The text in the spec before figure 8.17 says opposite : .When this notation is used to connect .complex. ports that are typed by multiple provided and/or required interfaces, the various interfaces are listed as an ordered set, designated with {provided} or {required} if needed. . How it looks like? (out of 8168 scope) Nerijus From: Steve Cook To: Nerijus Jankevicius , "uml2-rtf@omg.org" Date: Fri, 8 May 2009 15:58:31 +0100 Subject: RE: ballot 6 : comments on issue 8168 Thread-Topic: ballot 6 : comments on issue 8168 Thread-Index: AcnPU6FzlHsLQS2iTAG06JNGVtKh4AAmWeuQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n48F0V5s016206 Nerijus In answer to >BTW, connector attached directly to ball or socket symbol is a new and >pretty complex notation. Why do we need this? I see expensive changes in >current implementations and would vote NO for whole resolution which in >fact must solve direction notation problem only(remove it), no more. This >change is out of 8168 scope. I must disagree. The issue complains that an arrowhead is shown on a delegation connector, and the connector is clearly shown in the existing figure 8.12. All I did was remove the arrowhead and clarify the mapping. -- Steve -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 May 2009 21:33 To: uml2-rtf@omg.org Subject: ballot 6 : comments on issue 8168 Steve, "If the parts have simple ports (ports with a single required or provided interface), then ball-and-socket notation can be used to represent connectors between those ports, and normal connector notation for assembly or delegation may be shown connected to the ball or socket symbol rather than to the port symbol itself." this text is misleading, as ball-in-socket notation is not used on delegation connector ; assembly connector can't be connected directly to ball or socket symbol also. BTW, connector attached directly to ball or socket symbol is a new and pretty complex notation. Why do we need this? I see expensive changes in current implementations and would vote NO for whole resolution which in fact must solve direction notation problem only(remove it), no more. This change is out of 8168 scope. Also, does text mean that ball-and-socket can be used with simple ports only? The text in the spec before figure 8.17 says opposite : "When this notation is used to connect "complex" ports that are typed by multiple provided and/or required interfaces, the various interfaces are listed as an ordered set, designated with {provided} or {required} if needed. " How it looks like? (out of 8168 scope) Nerijus X-Trusted-NM: yes From: "Nerijus Jankevicius" To: Subject: Re: ballot 6 : comments on issue 8168 Date: Fri, 8 May 2009 18:12:26 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Steve, Agree, you just removed arrows (and keywords) from 8.12 sample. But, this sample was interpreted as "weird and wrong sample" before, which could be ignored, but now, you added description for "connector attached directly to ball or socket symbol" as normative standard notation and it becomes problematic. So, by adding this notation explanation you did introduced new notation and this is out of "direction issue" scope. I think so. Nerijus ----- Original Message ----- From: "Steve Cook" To: "Nerijus Jankevicius" ; Sent: Friday, May 08, 2009 5:58 PM Subject: RE: ballot 6 : comments on issue 8168 Nerijus In answer to BTW, connector attached directly to ball or socket symbol is a new and pretty complex notation. Why do we need this? I see expensive changes in current implementations and would vote NO for whole resolution which in fact must solve direction notation problem only(remove it), no more. This change is out of 8168 scope. I must disagree. The issue complains that an arrowhead is shown on a delegation connector, and the connector is clearly shown in the existing figure 8.12. All I did was remove the arrowhead and clarify the mapping. -- Steve -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 May 2009 21:33 To: uml2-rtf@omg.org Subject: ballot 6 : comments on issue 8168 Steve, "If the parts have simple ports (ports with a single required or provided interface), then ball-and-socket notation can be used to represent connectors between those ports, and normal connector notation for assembly or delegation may be shown connected to the ball or socket symbol rather than to the port symbol itself." this text is misleading, as ball-in-socket notation is not used on delegation connector ; assembly connector can't be connected directly to ball or socket symbol also. BTW, connector attached directly to ball or socket symbol is a new and pretty complex notation. Why do we need this? I see expensive changes in current implementations and would vote NO for whole resolution which in fact must solve direction notation problem only(remove it), no more. This change is out of 8168 scope. Also, does text mean that ball-and-socket can be used with simple ports only? The text in the spec before figure 8.17 says opposite : "When this notation is used to connect "complex" ports that are typed by multiple provided and/or required interfaces, the various interfaces are listed as an ordered set, designated with {provided} or {required} if needed. " How it looks like? (out of 8168 scope) Nerijus To: uml2-rtf@omg.org Subject: Ballot 6 X-KeepSent: E6F14668:5C2A5379-852575B0:004FEB59; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Fri, 8 May 2009 11:18:49 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 05/08/2009 09:18:51, Serialize complete at 05/08/2009 09:18:51 Issue 7247 through a delegation connector from a Port to contained Parts whose type is a Component or simple Class. --> through a delegation connector from a Port to contained Parts with compatible type. Issue 7349 An Interface isn't a connectable element and therefore cannot be the source or target of a delegation connector. 3] If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port. --> 3] If a delegation connector is defined between a source ConnectableElement and a target Connectable, then the target ConnectableElement type must support a signature compatible subset of Operations of the source ConnectableElement type. Issue 7364: Under 8.1, I think it is a mistake to apply contract Behaviors to a Connector to determine the valid interaction pattern. It is the ports that should define this so the expected interactions are followed regardless of the specific connector between them. SoaML clarifies this. But the RTF needn't fix this, we can get it in an RFP. Issue 8168: The same ball and socket notation for complex ports or classes should also apply to dependency wires, not just connectors. The should be treated exactly the same. Figure 8.12 appears wrong. The Delegation connectors are missing arrow heads, and the one from Account appears to be connected to the socket instead of the port. I don't recall any ball and socket notation for delegation connectors, since there's only one ball or one socket. Issue 8705 This section in the spec is confusing realization with composite structure. Figure 8.10 uses realization to indicate what Customer needs to be implemented. This should be shown with either usage dependencies or parts in the composite structure of Customer. Realization should mean that the realizing classifier provides an implementation of all the features of the realized classifier - often an Interface or <> Component, with perhaps some additional features required to do so. We should not mix realization and composite structure or usage dependencies. This creates enormous confusion for components and results in poor realization semantics. Issue 8900 Figure 8.15 should include the classifier the composite structure is contained in. Otherwise this diagram is not a valid diagram and results in confusion between class-level dependency wiring (where a package is the container) and instance level connector wiring. Issue 9464 â..A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the componentâ..s parts. It represents the forwarding of signals (operation requests and events): a signal that arrives at a port that has a delegation connector to one or more parts or ports on parts will be passed on to those targets for handling. --> â..A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the componentâ..s parts. It represents the forwarding of events (operation requests and events): a signal that arrives at a port that has a delegation connector to one or more parts or ports on parts will be passed on to those targets for handling. A signal isn't an event, signals are carried on SignalEvents. Issue 12985, 13146 Is also confusing realization with composite structure similar to 8705. A component should not provide an interface of its realizing class. This allows a realizing class to have interfaces needed for the realization, but not exposed to the component being realized. Having /provided be derived from the realizingClassifiers seems to turn realization upside down. This completely breaks the relationship between <> Component and <>Component. A realizing classifier should be expected to provide all the structure and behavior of the <> components it realizes, and perhaps have additional structure and behavior necessary for its particular means of realizing that specification. Composite structure and usage dependencies should be completely independent of the concept of realization. Issue 12833 Needs to be updated to include the OCL for allApplicableStereotyes query operation. Ed? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 e-mail: bselic@ca.ibm.com