Issue 6429: Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity (uml2-superstructure-ftf) Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com) Nature: Uncategorized Issue Severity: Summary: Issue: Re the definition of Port in Chapter 3, Composite Structures, third paragraph of the Notation section, which starts on page 142: This paragraph discusses how to notate the multiplicity of a Port (last line of p. 142), referring to Figure 3-35 on page 143. However, the semantics of Port multiplicity do not appear to be spelled out. Recommendation: Define the semantics of the multiplicity of a Port. Resolution: Revised Text: Actions taken: November 4, 2003: received issue March 9, 2005: closed issue Discussion: The semantics of the multiplicity of a port is inherited from the semantics of structural feature and property. Disposition: Closed, no change End of Annotations:===== m: "David S. Frankel" To: Subject: UML2 super/ad-03-04-01 Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity Date: Tue, 4 Nov 2003 17:42:25 -0800 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Issue: Re the definition of Port in Chapter 3, Composite Structures, third paragraph of the Notation section, which starts on page 142: This paragraph discusses how to notate the multiplicity of a Port (last line of p. 142), referring to Figure 3-35 on page 143. However, the semantics of Port multiplicity do not appear to be spelled out. Recommendation: Define the semantics of the multiplicity of a Port. ================================================================= David S. Frankel David Frankel Consulting Email: df@DavidFrankelConsulting.com Web: www.DavidFrankelConsulting.com Tel: +1 530 893-1100 Fax: +1 530 893-1153 David Frankel's MDA book: www.DavidFrankelConsulting.com/book.htm OMG Issue No: 6429 Title: Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity Source: David Frankel Consulting (Mr. David S. Frankel, df@davidfrankelconsulting.com) Summary: Issue: Re the definition of Port in Chapter 3, Composite Structures, third paragraph of the Notation section, which starts on page 142: This paragraph discusses how to notate the multiplicity of a Port (last line of p. 142), referring to Figure 3-35 on page 143. However, the semantics of Port multiplicity do not appear to be spelled out. Recommendation: Define the semantics of the multiplicity of a Port. Discussion: The semantics of the multiplicity of a port is inherited from the semantics of structural feature. However, for additional clarification, change the second sentence in the semantics section for port, section 9.3.11, p.168 of ptc/03-08-02, to the following (adding a third sentence): When an instance of a classifier is created, instances corresponding to each of its ports are created and held in the slots specified by the ports. The number of instances created and held in each slot is determined by its multiplicity. In addition, the multiplicity of a port is fixed. Add a clarifying constraint (the order of this constraint and the constraint introduced in 6356 is irrelevant). [3] The lower and upper bounds of the multiplicity for a Port are equal. Disposition: Resolved To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,cb cs, Proposed issues for 15 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 18 May 2004 06:35:06 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/18/2004 06:35:11, Serialize complete at 05/18/2004 06:35:11 Thomas, Some feedback on your proposed resolutions: 6356 - please see my comment regarding 6429, which introduces unacceptable constraints (at least unacceptable to IBM because it removes an important capability of the current model). At the very least, the explanation of what a port is tha tis included in the resolution should be modified (we've had this discussion before: a UML-RT port is actually a property that takes up a slot). Perhaps we can deal with this by having a subtype of port which is also a subtype of Property? 6373 - your resolution is, in effect, calling for a change of the infrastructure. Given the dependency structure, this resolution will first have to be approved by the infrastructure FTF. So, you should first submit to that FTF (you may have to raise an issue to deal with only the infrastructure part, though). 6429 - I disagree with this proposed resolution since it opens up major scalability problems and limits the modeling power of ports. It is extremely useful to allow ports to be created dynamically as needed. In our experience, people often configure a maximum number of ports using worst-case numbers (e.g., I have seen designs that had port multiplicities that ranged in the hundreds and even thousands). In practice, it is typically the case that a much smaller number is actually needed. Therefore, I suggest that the resolution should (a) remove the statement that all ports are created when the object is created and (b) allow lower multiplicity bounds to be different from upper bounds. The semantics of these bounds are the same as for parts: the lower bound specifies the number that are created when the containing object is created and the upper is a maximum. This is a more general approach to the problem that leaves open the possibility of both dynamic and statically configured port multiplicities. Bran "Thomas Weigert" 05/16/2004 02:29 PM To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject ,cb cs, Proposed issues for 15 Dear all, attached please find a set of proposed issues for Ballot 15. I would like to draw special attention to 6373. This issue resolution also affects the infrastructure, so a corresponding resolution (with different wording, as the changes would be spread over several packages) has to be floated there. An issue that highlights the problem in the infrastructure has been submitted. Please provide feedback to improve these resolutions. Thanks, Th. [attachment "Comp struc + com beh issues 15 done v1.doc" deleted by Branislav Selic/Ottawa/IBM] From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , Subject: RE: ,cb cs, Proposed issues for 15 Date: Tue, 18 May 2004 17:38:42 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, thanks for the feedback. Let me comment on the two issues below: I am somewhat surprised by your comment. First a minor thing re 6356: The solution does not remove or change anything from what was in the existing specification. i) the port does specify a slot in which instances are held, as for any structural feature (this is as you describe for UML-RT). ii) in the FAS a port is constraint to be created when the owning instance is created. The constraint [1] suggested in this resolution is just clearer on that it is the instances specified by the port, not the port that is created (this is obvious but it does not hurt to be precise). When you say, "in UML-RT a port is actually a property that takes up a slot", thus the second part is true also in UML. The question is more, what is really meant by the first part, a port being a property. Maybe you could list out what you can and cannot do to a port in UML-RT, as opposed to an attribute. 6429 is, of course, related to the same issue, whether you can create ports during the lifetime of the system. Here is where I am surprised by your suggestion. A port describes the "contracts" that a classifier enters regarding its instances: It describes what services the classifier offers to the environment, i.e., what receptions and operations the classifier commits its instances to handle. Further, it describes what the classifier expects from its environment. If we allowed ports to be created or destroyed during the lifetime of the instance, this would amount to changing these contracts. What meaning would there be to a contract if you would not know whether you can count on it? Imagine that a classifier has several ports, each specifying that the classifier will handle some signal. Now imagine the classifier is created without any ports. What does that do to this promise? E.g., these ports delegate to parts, suddenly the instance would not handle any of the signals its classifier promised that it would handle. There would be no meaning at all to the commitment made by the classifier. We might as well not have ports, if you cannot count on them! Similarly with the destruction of ports during the lifetime of the classifier. In either way, you change the externally committed services you are able to handle, after the fact! This is akin to the behavior of the classifier changing during run-time, or the interfaces of the classifier changing during run-time. Surely you would not argue that it should be possible to remove during the run-time of the system the interfaces that a classifier realizes? This is precisely what you do when you add or destroy a port. Actually, I think you are merely suggesting to allow additions to sets of ports, but this amounts to the same thing (as you can start with a multiplicity of 0). Further, how would such work together with connectors? Frankly, I cannot imagine that you would want this capability, so I probably am missing something here. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, May 18, 2004 5:35 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cb cs, Proposed issues for 15 Thomas, Some feedback on your proposed resolutions: 6356 - please see my comment regarding 6429, which introduces unacceptable constraints (at least unacceptable to IBM because it removes an important capability of the current model). At the very least, the explanation of what a port is tha tis included in the resolution should be modified (we've had this discussion before: a UML-RT port is actually a property that takes up a slot). Perhaps we can deal with this by having a subtype of port which is also a subtype of Property? 6429 - I disagree with this proposed resolution since it opens up major scalability problems and limits the modeling power of ports. It is extremely useful to allow ports to be created dynamically as needed. In our experience, people often configure a maximum number of ports using worst-case numbers (e.g., I have seen designs that had port multiplicities that ranged in the hundreds and even thousands). In practice, it is typically the case that a much smaller number is actually needed. Therefore, I suggest that the resolution should (a) remove the statement that all ports are created when the object is created and (b) allow lower multiplicity bounds to be different from upper bounds. The semantics of these bounds are the same as for parts: the lower bound specifies the number that are created when the containing object is created and the upper is a maximum. This is a more general approach to the problem that leaves open the possibility of both dynamic and statically configured port multiplicities. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 May 2004 15:10:27 -0700 To: UML Superstructure FTF , MOF UML Infrastructure FTF From: Joaquin Miller Subject: ,cb, ,cs, Issues 6356 6429 We are told "A port ... of a classifier ... specifies a distinct interaction point between that classifier and its environment." I read that to mean that a port specifies a type of distinct interaction point between and instance of a classifier and the environment of that instance. If that is wrong, then this message is probably not worth reading. The port concept in the literature has the type constraints on the communication as its defining characteristics. Please refer to the rich body on architectural modeling languages. [Consider] ... the original discussions with Dave Garlan; clearly this is a basic assumption also in ACME which we agreed to adopt as the guiding domain model... Having the defining characteristic of a port be the type constraint on the communication is excellent. That ought to be the case with UML 2 and, i take it, is the case. There is no call to change that. But, here is what Mary Shaw and Dave Garlan wrote back in '95 at 7.1.3 Problems with Existing [Architectural Description] Languages: "most module interconnection schemes allow only static configurations: dynamic reconfiguration is not generally supported. More recently, systems have been designed specifically to support dynamic reconfiguration." [ Just so you, dear reader, will know where i am coming from: Once all the types have been specified (classes, parts, ports, connectors, ...) we have what we need to specify an actual system. But we can't specify that system using only types. An actual system is made up of individuals. The architecture of any system consists of specific individuals, which the UML 2 spec calls 'instances.' To specify that architecture, UML 2 provides instance specifications. (Example: The system consists of, first--two servers of type A, one primary and one standby, connected in this way, second--a single ... connected to ... by a connector of this type ... , third-- ... )] We asked of UML 1, whether objects (UML 1 for instance specification of a class) could have interfaces. The answer, no, has been repeated for UML 2. But UML 2 has ports, and instance specifications of a class ("objects" to the relaxed) can have instance specifications of ports. So the UML 2 specification of the architecture of a system can use instance specifications of ports. It can use instance specifications of connectors to connect the instance specifications of ports. The type system constrains the types of instance specification of port that an instance specification of a structured class can have and the types of instance specifications of connectors that can be used to connect the instance specification of ports of each type. It will be nice and clean if all the architecture use cases can be satisfied with those elements. Here is why i feel i would rather not use the following technique: Personally, I think that the request should be phrased not as creating a port in the UML sense but as a request to set up a certain protocol or interaction sequence. Before this request the classifier will refuse this interaction, afterwards it will obey some protocol. Now we can think how we would model this in UML. I think that there are multiple ways of doing this, depending on where you want to express the protocol. This could be inside the port (using a class as its type) or in the classifier behavior. In practice I have seen more of the latter, but the former is fine as well. It's good to consider the establishing behavior at the beginning of a use of an instance of a port. And it is necessary to have one or more ways to specify the protocol to be followed in the use of a certain type of port. But, I'd feel better with one protocol per type of port.* ** That would be a very clear, clean, and concise language for the "component," port, connector style described by Shaw and Garlan. And, it will be swell if the configuration of instances of ports can change during operation. That makes it clean and straightforward to model systems in which there are such configuration changes. Cordially, Joaquin * Or one set of protocols per port, the particular protocol to be selected during establishing behavior. Example: choice of one of several secure session protocols. But, a clean, straightforward, small set of protocols: allowing a grab bag of protocols defeats the typing system. ** Of course, it will be useful to use, in a more abstract model, a port that is a composition of distinct ports appearing in a more detailed model, or a port that hides the particular protocol used. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 May 2004 21:29:09 -0700 To: UML Superstructure FTF , MOF UML Infrastructure FTF From: Joaquin Miller Subject: RE: ,cb, ,cs, Issues 6356 6429 Thanks for the prompt answer, Thomas. It is too early in the century to expect our modelling language(s) to be settled, as they are in other disciplines, which have had a century or several millennia to shake down. So it may be that this time we won't answer two objections i will raise here. 1. Requiring an arbitrary but fixed number of standby ports is, to put the best face on it, inelegant. 2. (I did not make this explicit in the use case; i apologize.) It is necessary to record the registration of connection points (BoNY has authorization from FRB to use an additional connection point) and to record the times of establishment and termination of connections at a given connection point (establishment includes both scheduled establishment and restart, termination includes both explicit termination and failure). This requires in the model a distinction between two items, which i'm calling connection point and connection. In ODP terms, i'm distinguishing a) a liaison that enables connections of a certain type from b) a liaison that establishes a connection of that type, enabling communication. http://www.joaquin.net/ODP/Part2/13.html#13.2.4 (also 2-13.2.1, 2-13.2.2, 2-13.2.3, and 2-13.2.5) Cordially, Joaquin At 10:41 PM 5/18/2004, Thomas Weigert wrote: Joaquin, in your use case, we could make the following change: Rather than saying "connection point" say "connection", as the requirement seems to merely state that the transmission is through a unique and sometimes new "channel". To model this in UML as per FAS, you would have the model of the bank, with its connections, but some of these ports are not wired up by channels. When you are speaking of opening a new connection point, I would speak of creating a connection between your transaction client and the bank at a previously unused port. Now somebody might say, "Isn't that inefficient having all this potential objects around in the port slots?" to which I would respond that we are just talking about a modeling abstraction. In real life, this as any other concept, may be implemented in many different ways as long as they behave as specified in the standard. What is important about ports, I think, is that they establish a contract that the object will not violate. Not having a port to provide a promised service would lead to violation of the contract. By definition that is not the behavior of a structured classifier with ports. Th. > -----Original Message----- > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > Sent: Tuesday, May 18, 2004 11:35 PM > To: UML Superstructure FTF; MOF UML Infrastructure FTF > Subject: RE: ,cb, ,cs, Issues 6356 6429 > > > I can see from the e-mail exchanges that i don't know what a port is. So > i'd like to simply present a use case. > Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 May 2004 21:29:09 -0700 To: UML Superstructure FTF , MOF UML Infrastructure FTF From: Joaquin Miller Subject: RE: ,cb, ,cs, Issues 6356 6429 Thanks for the prompt answer, Thomas. It is too early in the century to expect our modelling language(s) to be settled, as they are in other disciplines, which have had a century or several millennia to shake down. So it may be that this time we won't answer two objections i will raise here. 1. Requiring an arbitrary but fixed number of standby ports is, to put the best face on it, inelegant. 2. (I did not make this explicit in the use case; i apologize.) It is necessary to record the registration of connection points (BoNY has authorization from FRB to use an additional connection point) and to record the times of establishment and termination of connections at a given connection point (establishment includes both scheduled establishment and restart, termination includes both explicit termination and failure). This requires in the model a distinction between two items, which i'm calling connection point and connection. In ODP terms, i'm distinguishing a) a liaison that enables connections of a certain type from b) a liaison that establishes a connection of that type, enabling communication. http://www.joaquin.net/ODP/Part2/13.html#13.2.4 (also 2-13.2.1, 2-13.2.2, 2-13.2.3, and 2-13.2.5) Cordially, Joaquin At 10:41 PM 5/18/2004, Thomas Weigert wrote: Joaquin, in your use case, we could make the following change: Rather than saying "connection point" say "connection", as the requirement seems to merely state that the transmission is through a unique and sometimes new "channel". To model this in UML as per FAS, you would have the model of the bank, with its connections, but some of these ports are not wired up by channels. When you are speaking of opening a new connection point, I would speak of creating a connection between your transaction client and the bank at a previously unused port. Now somebody might say, "Isn't that inefficient having all this potential objects around in the port slots?" to which I would respond that we are just talking about a modeling abstraction. In real life, this as any other concept, may be implemented in many different ways as long as they behave as specified in the standard. What is important about ports, I think, is that they establish a contract that the object will not violate. Not having a port to provide a promised service would lead to violation of the contract. By definition that is not the behavior of a structured classifier with ports. Th. > -----Original Message----- > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > Sent: Tuesday, May 18, 2004 11:35 PM > To: UML Superstructure FTF; MOF UML Infrastructure FTF > Subject: RE: ,cb, ,cs, Issues 6356 6429 > > > I can see from the e-mail exchanges that i don't know what a port is. So > i'd like to simply present a use case. > > The Bank of New York has a number of connection points for communication > with the Federal Reserve Bank of New York. Some of these > connection points > are of the exact same type. There is more than one of that type, > in order > to provide capacity and redundancy. In the current system, the number of > these connection points of the same type is fixed, and the > connections are > hard wired. The technology in current use requires addition of hardware > and cable to add a connection point. > > To increase reliability and other qualities, a new design provides for > addition of connection points during operation. Available technology > enables dynamic addition of connection points. Regulations require that > BoNY record, for each business transaction, the connection point used for > that transaction. The application protocol requires that the same > connection point be used for all elements of a given business transaction. > > The use case is for a variable number of connection points, each > identified, which number can be changed during operation. > > ..................... > > (Having learned that Interface is not available to meet this > requirement, i > understood that Port was intended for this job. Perhaps that is > wrong. If > so, is there a third Element that can do the job?) > > Cordially, > > Joaquin > > Subject: RE: ,cb, ,cs, Issues 6356 6429 Date: Thu, 20 May 2004 15:05:48 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cb, ,cs, Issues 6356 6429 Thread-Index: AcQ9ZAdPP4qTCJvRQN66zGjAUeIDDQBUViCQ From: "Pidcock, Woody" To: "Thomas Weigert" , "Joaquin Miller" , "UML Superstructure FTF" , "MOF UML Infrastructure FTF" X-OriginalArrivalTime: 20 May 2004 22:05:49.0249 (UTC) FILETIME=[9BD31B10:01C43EB6] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4KM8eun031153 I suggest language I have heard David Garlan use, namely, Components and Connectors. Ports sit on Components and Roles sit at the ends of Connectors. When these get linked up, the components play the roles identified for connectors and connectors attach to the ports on components. -woody -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, May 18, 2004 10:42 PM To: Joaquin Miller; UML Superstructure FTF; MOF UML Infrastructure FTF Subject: RE: ,cb, ,cs, Issues 6356 6429 Joaquin, in your use case, we could make the following change: Rather than saying "connection point" say "connection", as the requirement seems to merely state that the transmission is through a unique and sometimes new "channel". To model this in UML as per FAS, you would have the model of the bank, with its connections, but some of these ports are not wired up by channels. When you are speaking of opening a new connection point, I would speak of creating a connection between your transaction client and the bank at a previously unused port. Now somebody might say, "Isn't that inefficient having all this potential objects around in the port slots?" to which I would respond that we are just talking about a modeling abstraction. In real life, this as any other concept, may be implemented in many different ways as long as they behave as specified in the standard. What is important about ports, I think, is that they establish a contract that the object will not violate. Not having a port to provide a promised service would lead to violation of the contract. By definition that is not the behavior of a structured classifier with ports. Th. > -----Original Message----- > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > Sent: Tuesday, May 18, 2004 11:35 PM > To: UML Superstructure FTF; MOF UML Infrastructure FTF > Subject: RE: ,cb, ,cs, Issues 6356 6429 > > > I can see from the e-mail exchanges that i don't know what a port is. > So i'd like to simply present a use case. > > The Bank of New York has a number of connection points for > communication with the Federal Reserve Bank of New York. Some of > these connection points are of the exact same type. There is more > than one of that type, in order > to provide capacity and redundancy. In the current system, the number of > these connection points of the same type is fixed, and the > connections are > hard wired. The technology in current use requires addition of hardware > and cable to add a connection point. > > To increase reliability and other qualities, a new design provides for > addition of connection points during operation. Available technology > enables dynamic addition of connection points. Regulations require > that BoNY record, for each business transaction, the connection point > used for that transaction. The application protocol requires that the > same connection point be used for all elements of a given business > transaction. > > The use case is for a variable number of connection points, each > identified, which number can be changed during operation. > > ..................... > > (Having learned that Interface is not available to meet this > requirement, i understood that Port was intended for this job. > Perhaps that is wrong. If > so, is there a third Element that can do the job?) > > Cordially, > > Joaquin > >Subject: ,cl,Proposed resolution for issue 6469 Date: Sat, 22 May 2004 16:57:16 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl,Proposed resolution for issue 6469 Thread-Index: AcRAWIGUbdZYf2TCQb2CIMDutvq/Gw== From: "Tolbert, Doug M" To: , X-OriginalArrivalTime: 22 May 2004 23:57:17.0487 (UTC) FILETIME=[8326BBF0:01C44058] OMG Issue No: 6469 Title: Section 7.3.5 PackageImport Source: BAE Systems-Mission Solutions (Mr. James D. Baker, james.d.baker@baesystems.com) Summary: This section is unique because it does not have a Notation section like all of the others Discussion: Section 7.3.5, page 38, of the UML2 Superstructure FAS (ptc/03-08-02) and the corresponding section 11.6.5, page 145, of the UML2 Infrastructure FAS (ptc/03-09-15) both contain Notation sections. The text in the Superstructure document has an identical paragraph in the Infrastructure text. The Notation section in the Infrastructure document contains an additional paragraph that does not appear in Superstructure document. This paragraph is related to the subject of issue 6168 and will be dealt with in the resolution of that issue. Disposition: Closed, no change To: "Tolbert, Doug M" , Pete.Rivett@adaptive.com Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,cl,Proposed resolution for issue 6469 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 24 May 2004 06:20:41 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/24/2004 06:20:45, Serialize complete at 05/24/2004 06:20:45 Thanks for the resolutions, Doug. Please note that these are resolutions that have to be voted on by the MOF/Infra FTF first and then endorsed by the Super FTF. Several weeks ago, I posted 4 resolutions to the Infra FTF and we will need to set up a ballot. Pete and Steve, andy chance that you can do this soon? Thanks, Bran "Tolbert, Doug M" 05/22/2004 07:57 PM To , cc Subject ,cl,Proposed resolution for issue 6469 OMG Issue No: 6469 Title: Section 7.3.5 PackageImport Source: BAE Systems-Mission Solutions (Mr. James D. Baker, james.d.baker@baesystems.com) Summary: This section is unique because it does not have a Notation section like all of the others Discussion: Section 7.3.5, page 38, of the UML2 Superstructure FAS (ptc/03-08-02) and the corresponding section 11.6.5, page 145, of the UML2 Infrastructure FAS (ptc/03-09-15) both contain Notation sections. The text in the Superstructure document has an identical paragraph in the Infrastructure text. The Notation section in the Infrastructure document contains an additional paragraph that does not appear in Superstructure document. This paragraph is related to the subject of issue 6168 and will be dealt with in the resolution of that issue. Disposition: Closed, no change ================================================================= Subject: RE: Revised ballot 15: Please vote Date: Fri, 11 Jun 2004 17:05:56 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised ballot 15: Please vote Thread-Index: AcRI+4zDEWWOXOPUTC2n2Bp3ivY8gwG8Rnzg From: "Pete Rivett" To: "Branislav Selic" , Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i5BL1Wun004651 Adaptive votes YES to all the issues in Ballot 15 except Issue 6351 and 6429. The 'realizations' in Issue 6351 seem quite at variance with the concept of Realization defined in 7.14.6 - even to the extent of the 'direction' being the wrong way round. The discussion of 6429 only trivially addresses the question and even then adds nothing to the specification to clarify. Minor points: - it seems to me that 6210 should really be Closed No Change (which is what was done for 6148 likewise addressed by an existing resolution) or Duplicate. - 6251 should be clearer about where the change is being made. - 6280 is a shared issue and should now be voted on by Infra - 6280 adds the constraint " [3] Stereotype names should not clash with keyword names for the extended model element." However what we do not yet have is a clear statement of the latter (keywords). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, June 03, 2004 12:35 AM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Revised ballot 15: Please vote With due apologies to all, here is a revised version of ballot 15. (Since no one has voted on it yet, I assume that this rather late revision is acceptable. Still, such late changes will not be the rule in future ballots.) The following changes were made: (1) the resolution to issue 6149 has been removed from the ballot by Thomas since it is coupled to the resolution of issue 7335. (2) the resolution to issue 6280 was added since it was accidentally omitted from the ballot. Regards, Bran