Issue 6356: Ports as properties (uml2-superstructure-ftf) Source: Deere & Company (Mr. Roger Burkhart, burkhartrogerm(at)johndeere.com) Nature: Revision Severity: Significant Summary: Ports should be properties (better yet parts), to participate in composite association when desired. Resolution: see above Revised Text: Actions taken: October 20, 2003: received issue March 8, 2005: closed issue Discussion: Discussion: The issue suggests that ports be considered subtypes of Property. After discussions in the FTF, it was agreed to make this change to support the dynamic creation of ports (and possibly, their destruction during the life of the owning classifier). Consequentially, the following changes to the specification of port (relative to ptc/03-08- 02) are suggested: In Figure 97 “The Port metaclass” on p.154, delete the inheritance from StructuralFeature, but add the inheritance from Property. Delete the inheritance from ConnectableElement. Change the text on EncapsulatedClassifier.ownedPort to “subsets ownedAttribute”. The modified diagram is shown below. StructuredClassifier (from InternalStructures) Property (from InternalStructures) ConnectorEnd 0..1 +partWithPort Interface (from Interfaces) Port isBehavior : Boolean = false isService : Boolean = true * * +redefinedPort {subsets redefinedElement} * * +/required * * +/provided EncapsulatedClassifier * 0..1 +ownedPort {subsets ownedAttribute} {subsets redefinitionContext} Property (from InternalStructures) In Section 9.3.11, “Ports (from Ports)” make the following changes: Change the first sentence after the heading to “A port is a property of a classifier…”. In the constraint section, delete constraint [1] and renumber the following constraint from [2] to [1]. Add the following new constraints: [2] Port.aggregation must be composite. [3] When a port is destroyed, all connectors attached to this port will be destroyed also. [4] A defaultValue for port cannot be specified when the type of the Port is an Interface. In section 9.3.7. “ConnectorEnd (from InternalStructures, Ports)” add an additional constraint [3] The property held in self.partWithPort must not be a Port. End of Annotations:===== me: Roger Burkehart Company: John Deere mailFrom: burkhartrogerm@johndeere.com Nature: Revision Severity: Significant Subject: Ports as properties Ports should be properties (better yet parts), to participate in composite association when desired. From: "Moore, Alan" To: "'thomas.weigert@motorola.com'" , Branislav Selic , uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Date: Tue, 2 Dec 2003 08:20:33 -0000 X-Mailer: Internet Mail Service (5.5.2653.19) Thomas, Comments on your resolutions: 6251: I can't see how the metamodel (even with associated text) prohibits the case I outlined - in fact I'm not clear that encaspsulation of parts is enforced. Could you give me a reference (page, figure ...) please. 6316: My concern about behaviour ports is how can the port, via the behaviour of its type, forward signals to its parent, when they have no reference to their parent. I thought that at least if the port could participate in an association to its parent (I assume the other end of the association that allows the parent to contain the port) then it could have a property that referenced its parent. I also assume that this works for other types of requests, not just signals. 6356: Surely if port was a subtype of property then they could participate in composite associations (see my comment on 6316 above). Regards, Alan -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 30 November 2003 04:36 To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: thomas.weigert@motorola.com 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. OMG Issue No: 6356 Title: Ports as properties Source: Deere & Company (Mr. Roger Burkhart, burkhartrogerm@johndeere.com) Summary: Ports should be properties (better yet parts), to participate in composite association when desired. Discussion: Duplicate of 62816251. (By the way, there is no metaclass "part"; parts are properties that a classifier owns by composition.) Ports cannot participate in composite associations as they are already strongly owned by their classifier. [Conrad: Didn't follow this. Elements that are strongly owned can still participate in associations can't they? Some might find it overly restrictive that the association ends for ports would need to be strongly owned, but that can be taken as a separate issue.] OMG Issue No: 6356 Title: Ports as properties Source: Deere & Company (Mr. Roger Burkhart, burkhartrogerm@johndeere.com) Summary: Ports should be properties (better yet parts), to participate in composite association when desired. Discussion: The differentiating semantic aspect of Property is that they represent locations (referred to as slots in the instance model) which may hold values, such that these values may be placed in that slot during run-time, they may be deleted from the slot, or may be changed. The two kinds of properties are attribute and association end. For either, their use in a model is assign values to them, operate on these values, etc. This is not the characteristics of a port. A port is created when an object is created, it cannot be deleted or changed to another port. It represents the point of interaction between the object and its environment (or its parts). While the distinction between Property and StructuralFeature is not as crisp in the specification text as hinted at above (e.g., a StructuralFeature mistakenly duplicates the metaattribute "isReadOnly" from Property which implies that the values in the slot can be modified if the attribute is false, and there are a number of actions provided in the action model which read, set, or delete values held in slots, albeit there are no structural features other than Properties that could be so manipulated and links, inconsistently, can only be manipulated when identified by properties), there is an intuitively clear difference between an attribute (or association end) and a port. Ports are thus not modeled as subclasses of Property, as ports cannot be manipulated during the life of the object. However, the issue does point to that the current model does not allow to specify the instance of the type of a complex port that is created when the object is created. In section 9.3.11. .Port. of ptc/03-08-02, on p.168 add in the associations section: defaultValue: ValueSpecification [0..1] A ValueSpecification that is evaluated to give the value for the interaction point represented by the Port when an object of the owning Classifier is instantiated. Subsets Element::ownedElement. Add a corresponding association to the abstract syntax in Figure 97. Add to the Constraints section:s [3] A defaultValue can be specified only when the type of the Port is not an Interface. In the third paragraph of the Semantics section, add before the fourth sentence: If a defaultValue was specified, this defaultValue is evaluated when an instance of the object of the owning Classifier is instantiated. The evaluated default is then held in the slot specified by the Port. Constraint [1] of the constraint section is slightly confusing in that it speaks of a port being modified, rather than the interaction points specified by the port. Change constraint [1] to [1] The instances specified by a port cannot be created, modified, or destroyed except as part of the creation or destruction of the instance of the owning classifier. 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. From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , "Thomas Weigert" , Subject: RE: ,cb cs, Proposed issues for 15 Date: Wed, 19 May 2004 10:06:02 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, some comments below... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, May 19, 2004 9:04 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs, Proposed issues for 15 Thomas, In response to your e-mail: > 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. The existing specification did not say that ports cannot be dynamically created. This is my objection. Actually, the existing specification has precisely this constraint. Thus you are requesting a change in functionality from the FAS. > 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). Unfortunately, this is something I missed in the original spec, so I think this constraint should be removed. See the paragraph above... > 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. In UML-RT a port really is a kind of attribute with some additional specializations (i.e., it can be connected, it is used for communications). However, my understanding was that, because ports are not attributes in SDL, we had to go through the complication that distinguishes between a structural feature and a property. Fair enough, we want to support the SDL model, but we must not exclude the other proven models. Bran, I really would prefer if you were not to through out such unfounded comments. There appears to be a pattern that whenever you don't have an argument you say "oh well, we had to do it this way because of SDL." Every time you have said this so far it was wrong, as it is this time. You might as well use a real argument. To answer your SDL ad hominem argument: There are no ports in SDL, but a similar concept, called gates. SDL ports do not have a dynamic semantics but express merely constraints on types. Everything there is in the UML port concept going beyond the type constraints have been added for ROOM compatibility, and you know there is quite a lot: in particular their instance nature in the semantic domain, their ability to have classes as types and thus define complicated behavior in addition to forwarding semantics, behavior ports, service ports, basically everything that is complicated about ports. I spent a lot of effort making sure that ROOM is addressed, even though I have never in real life seen a need for these features. It is really annoying to hear you spouting off incorrect comments about why something is done in the specification the way it is. I would ask that you stick to facts, if possible. > 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! First, these are methodological arguments and I would prefer to stay away from those as much as possible. No one can win such an argument. Here is another one of those "when in doubt confuse the discussion" points. There is nothing methodological about the above. Type constraints and type safety are the basic philosophy underpinning ports. You don't want these, you don't have ports, but a different concept. (What the point of such a concept would be I don't know.) A methodological issue is forcing a particular usage of a concept (such as saying a class can only have seven attributes, or saying that there should only be aggregation but no composition, etc.). 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. You were part of the original discussions with Dave Garland; clearly this is a basic assumption also in ACME which we agreed to adopt as the guiding domain model, based on your suggestion. Second, you are assuming a more general model of port dynamics than the one that is in UML-RT. In UML-RT there simply is a "lazy evaluation" approach to ports: ports are created only if and when they are needed, up to the upper multiplicity bound. From a static analysis point of view (which is where your arguments come from) these dynamics of ports are irrelevant. The port will be there when it is needed. You can view this as merely as a run-time optimization -- except that your explicit statement that all ports are created when the container is created make that sound like an illegal thing to do. That is my objection. So basically we agree. A port is there when it is needed, in other words, you could not have a communication where the port is not there, albeit the class declared that this contract would be supported. This is precisely what the suggested constraints say. Remember, the UML model is a specification language; implementations may do many things to make it more efficient. For example, in most cases, ports would not be really there as instances anyway. This is true throughout the specification: There certainly will not in general be a thread for every active class, albeit the specification says so. The whole point of modeling is to specify the system. The constraint is that the resulting system has to behave as specified. As you would not be able to tell, as external observer, when the ports were created, the implementation as described by you is correct. Anybody who criticizes this has not even understood what modeling is all about. All that said, if you can suggest a way of constraining the model such that "ports are there when they are needed" as you said, I'd be glad to move to that version. I don't think it is wise to just relax this constraint wily-Nelly. Actually, although I am not asking for this, it is something that should not be disallowed. In the brave new world of service-oriented architectures it is quite possible that new ports (including new types) will be created and destroyed. However, I agree that this is tricky stuff and that we need not deal with that in this version of UML, but we should not put impediments on that now. We cannot design the UML to cater to any future language. We will have to change, as new concepts are discovered. If we prepare for any eventuality, we will never have anything... To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, "Thomas Weigert" , 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: Wed, 19 May 2004 11:57:09 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/19/2004 11:57:11, Serialize complete at 05/19/2004 11:57:11 Thomas, I apologize if some of the things I said annoyed you -- they were most definitely not intended to do that. I may indeed have a faulty memory of what happened, so I will no longer quote any history in subsequent discussions. I also very much appreciate the work you have done in accommodating UML-RT in the composite structure model even though you personally never saw the need for some of its features. Here is my constructive suggestion for how to move forward on resolving issues 6356 and 6429: Please remove constraint [1] on Port. Also, in your proposed resolutions to these issues, avoid any statements to the effect that all ports need to be created when their containing object is created. This approach has the advantage that it supports both the dynamic and static model of ports. Regards, Bran "Thomas Weigert" 05/19/2004 11:06 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "Thomas Weigert" , Subject RE: ,cb cs, Proposed issues for 15 Bran, some comments below... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, May 19, 2004 9:04 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs, Proposed issues for 15 Thomas, In response to your e-mail: > 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. The existing specification did not say that ports cannot be dynamically created. This is my objection. Actually, the existing specification has precisely this constraint. Thus you are requesting a change in functionality from the FAS. > 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). Unfortunately, this is something I missed in the original spec, so I think this constraint should be removed. See the paragraph above... > 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. In UML-RT a port really is a kind of attribute with some additional specializations (i.e., it can be connected, it is used for communications). However, my understanding was that, because ports are not attributes in SDL, we had to go through the complication that distinguishes between a structural feature and a property. Fair enough, we want to support the SDL model, but we must not exclude the other proven models. Bran, I really would prefer if you were not to through out such unfounded comments. There appears to be a pattern that whenever you don't have an argument you say "oh well, we had to do it this way because of SDL." Every time you have said this so far it was wrong, as it is this time. You might as well use a real argument. To answer your SDL ad hominem argument: There are no ports in SDL, but a similar concept, called gates. SDL ports do not have a dynamic semantics but express merely constraints on types. Everything there is in the UML port concept going beyond the type constraints have been added for ROOM compatibility, and you know there is quite a lot: in particular their instance nature in the semantic domain, their ability to have classes as types and thus define complicated behavior in addition to forwarding semantics, behavior ports, service ports, basically everything that is complicated about ports. I spent a lot of effort making sure that ROOM is addressed, even though I have never in real life seen a need for these features. It is really annoying to hear you spouting off incorrect comments about why something is done in the specification the way it is. I would ask that you stick to facts, if possible. > 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! First, these are methodological arguments and I would prefer to stay away from those as much as possible. No one can win such an argument. Here is another one of those "when in doubt confuse the discussion" points. There is nothing methodological about the above. Type constraints and type safety are the basic philosophy underpinning ports. You don't want these, you don't have ports, but a different concept. (What the point of such a concept would be I don't know.) A methodological issue is forcing a particular usage of a concept (such as saying a class can only have seven attributes, or saying that there should only be aggregation but no composition, etc.). 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. You were part of the original discussions with Dave Garland; clearly this is a basic assumption also in ACME which we agreed to adopt as the guiding domain model, based on your suggestion. Second, you are assuming a more general model of port dynamics than the one that is in UML-RT. In UML-RT there simply is a "lazy evaluation" approach to ports: ports are created only if and when they are needed, up to the upper multiplicity bound. From a static analysis point of view (which is where your arguments come from) these dynamics of ports are irrelevant. The port will be there when it is needed. You can view this as merely as a run-time optimization -- except that your explicit statement that all ports are created when the container is created make that sound like an illegal thing to do. That is my objection. So basically we agree. A port is there when it is needed, in other words, you could not have a communication where the port is not there, albeit the class declared that this contract would be supported. This is precisely what the suggested constraints say. Remember, the UML model is a specification language; implementations may do many things to make it more efficient. For example, in most cases, ports would not be really there as instances anyway. This is true throughout the specification: There certainly will not in general be a thread for every active class, albeit the specification says so. The whole point of modeling is to specify the system. The constraint is that the resulting system has to behave as specified. As you would not be able to tell, as external observer, when the ports were created, the implementation as described by you is correct. Anybody who criticizes this has not even understood what modeling is all about. All that said, if you can suggest a way of constraining the model such that "ports are there when they are needed" as you said, I'd be glad to move to that version. I don't think it is wise to just relax this constraint wily-Nelly. Actually, although I am not asking for this, it is something that should not be disallowed. In the brave new world of service-oriented architectures it is quite possible that new ports (including new types) will be created and destroyed. However, I agree that this is tricky stuff and that we need not deal with that in this version of UML, but we should not put impediments on that now. We cannot design the UML to cater to any future language. We will have to change, as new concepts are discovered. If we prepare for any eventuality, we will never have anything... Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 May 2004 21:34:42 -0700 To: UML Superstructure FTF , MOF UML Infrastructure FTF From: Joaquin Miller 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 From: "Thomas Weigert" To: "Joaquin Miller" , "UML Superstructure FTF" , "MOF UML Infrastructure FTF" Subject: RE: ,cb, ,cs, Issues 6356 6429 Date: Wed, 19 May 2004 00:41:47 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) 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 > > To: "Thomas Weigert" Cc: "Joaquin Miller" , "MOF UML Infrastructure FTF" , "UML Superstructure FTF" Subject: RE: ,cb, ,cs, Issues 6356 6429 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 19 May 2004 10:33:07 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/19/2004 10:33:11, Serialize complete at 05/19/2004 10:33:11 Thomas: You said: > 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. My point is that the spec explicitly states that this is not valid. If we remove such statements, we will eliminate any further discussions about whether something is merely a "real-life" issue or a semantic one and without doing any damage to the current capabilities. You know how some people are literal minded when it comes to standards. If I tell them that my implementation uses lazy port creation, they will go to the spec and tell me that my implementation is not conformant (or, a less scrupulous competitor might make that claim). And, finally, Joaquin's example is precisely the kind of thing I see coming on the horizon. So, we should not preclude i. From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , "Thomas Weigert" , Subject: RE: ,cb cs, Proposed issues for 15 Date: Wed, 19 May 2004 11:13:16 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Thanks Bran. Regarding your constructive suggestion, I think we need to put a little more effort in it. The constraint must say something to the effect that the port will be there before communication is attempted. E.g., we might want to tie it to the creation of the connector. (i.e., no port, no connector, which makes sense anyway, as where would the connector connect to?). The contract aspect of the port cannot fall by the wayside. By the way, if we add dynamic creation (personally I think this is against the spirit of modeling as I said earlier and confusing modeling with coding) we should make a port a property with the appropriate constraints. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, May 19, 2004 10:57 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs, Proposed issues for 15 Thomas, I apologize if some of the things I said annoyed you -- they were most definitely not intended to do that. I may indeed have a faulty memory of what happened, so I will no longer quote any history in subsequent discussions. I also very much appreciate the work you have done in accommodating UML-RT in the composite structure model even though you personally never saw the need for some of its features. Here is my constructive suggestion for how to move forward on resolving issues 6356 and 6429: Please remove constraint [1] on Port. Also, in your proposed resolutions to these issues, avoid any statements to the effect that all ports need to be created when their containing object is created. This approach has the advantage that it supports both the dynamic and static model of ports. Regards, Bran "Thomas Weigert" 05/19/2004 11:06 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "Thomas Weigert" , Subject RE: ,cb cs, Proposed issues for 15 Bran, some comments below... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, May 19, 2004 9:04 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs, Proposed issues for 15 Thomas, In response to your e-mail: > 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. The existing specification did not say that ports cannot be dynamically created. This is my objection. Actually, the existing specification has precisely this constraint. Thus you are requesting a change in functionality from the FAS. > 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). Unfortunately, this is something I missed in the original spec, so I think this constraint should be removed. See the paragraph above... > 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. In UML-RT a port really is a kind of attribute with some additional specializations (i.e., it can be connected, it is used for communications). However, my understanding was that, because ports are not attributes in SDL, we had to go through the complication that distinguishes between a structural feature and a property. Fair enough, we want to support the SDL model, but we must not exclude the other proven models. Bran, I really would prefer if you were not to through out such unfounded comments. There appears to be a pattern that whenever you don't have an argument you say "oh well, we had to do it this way because of SDL." Every time you have said this so far it was wrong, as it is this time. You might as well use a real argument. To answer your SDL ad hominem argument: There are no ports in SDL, but a similar concept, called gates. SDL ports do not have a dynamic semantics but express merely constraints on types. Everything there is in the UML port concept going beyond the type constraints have been added for ROOM compatibility, and you know there is quite a lot: in particular their instance nature in the semantic domain, their ability to have classes as types and thus define complicated behavior in addition to forwarding semantics, behavior ports, service ports, basically everything that is complicated about ports. I spent a lot of effort making sure that ROOM is addressed, even though I have never in real life seen a need for these features. It is really annoying to hear you spouting off incorrect comments about why something is done in the specification the way it is. I would ask that you stick to facts, if possible. > 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! First, these are methodological arguments and I would prefer to stay away from those as much as possible. No one can win such an argument. Here is another one of those "when in doubt confuse the discussion" points. There is nothing methodological about the above. Type constraints and type safety are the basic philosophy underpinning ports. You don't want these, you don't have ports, but a different concept. (What the point of such a concept would be I don't know.) A methodological issue is forcing a particular usage of a concept (such as saying a class can only have seven attributes, or saying that there should only be aggregation but no composition, etc.). 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. You were part of the original discussions with Dave Garland; clearly this is a basic assumption also in ACME which we agreed to adopt as the guiding domain model, based on your suggestion. Second, you are assuming a more general model of port dynamics than the one that is in UML-RT. In UML-RT there simply is a "lazy evaluation" approach to ports: ports are created only if and when they are needed, up to the upper multiplicity bound. From a static analysis point of view (which is where your arguments come from) these dynamics of ports are irrelevant. The port will be there when it is needed. You can view this as merely as a run-time optimization -- except that your explicit statement that all ports are created when the container is created make that sound like an illegal thing to do. That is my objection. So basically we agree. A port is there when it is needed, in other words, you could not have a communication where the port is not there, albeit the class declared that this contract would be supported. This is precisely what the suggested constraints say. Remember, the UML model is a specification language; implementations may do many things to make it more efficient. For example, in most cases, ports would not be really there as instances anyway. This is true throughout the specification: There certainly will not in general be a thread for every active class, albeit the specification says so. The whole point of modeling is to specify the system. The constraint is that the resulting system has to behave as specified. As you would not be able to tell, as external observer, when the ports were created, the implementation as described by you is correct. Anybody who criticizes this has not even understood what modeling is all about. All that said, if you can suggest a way of constraining the model such that "ports are there when they are needed" as you said, I'd be glad to move to that version. I don't think it is wise to just relax this constraint wily-Nelly. Actually, although I am not asking for this, it is something that should not be disallowed. In the brave new world of service-oriented architectures it is quite possible that new ports (including new types) will be created and destroyed. However, I agree that this is tricky stuff and that we need not deal with that in this version of UML, but we should not put impediments on that now. We cannot design the UML to cater to any future language. We will have to change, as new concepts are discovered. If we prepare for any eventuality, we will never have anything... Bran 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. > > 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 > > 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 To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, "Thomas Weigert" , 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: Thu, 20 May 2004 07:35:45 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/20/2004 07:35:52, Serialize complete at 05/20/2004 07:35:52 Thomas, > Regarding your constructive suggestion, I think we need to put a > little more effort in it. The constraint must say something to the > effect that the port will be there before communication is > attempted. E.g., we might want to tie it to the creation of the > connector. (i.e., no port, no connector, which makes sense anyway, > as where would the connector connect to?). > > The contract aspect of the port cannot fall by the wayside. By the > way, if we add dynamic creation (personally I think this is against > the spirit of modeling as I said earlier and confusing modeling with > coding) we should make a port a property with the appropriate constraints. As Joaquin's example points out, this is more than an implementation issues, so please stop saying that. My experience with architectural modeling bears this out: there is major need to be able to model dynamic architectures -- especially since the Internet and service-oriented architectures are highly dynamic contexts. And, very current. Your argument that this weakens the "contract aspect" of ports sounds rather tenuous to me. A port still clearly defines what its contractual assumptions are, whether it is created dynamically or statically. (BTW, some of the things in UML-RT that may have seemed "unnecessary" to you (your words, not mine), such as plug-in slots, are precisely for dealing with dynamically established architectures, without sacrificing the contractual aspects of ports and connectors.) My advice is that we do not try to finesse this complex issue too much. Let's just make sure that we leave room for dynamic systems by removing constaint [1]. Thanks...Bran > To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, "Thomas Weigert" , 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: Wed, 26 May 2004 18:46:28 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/26/2004 18:46:40, Serialize complete at 05/26/2004 18:46:40 Thomas, In your proposed resolution to issue 6356, there is the following statement: In section 9.3.11. â..Portâ.ť of ptc/03-08-02, on p.168 add in the associations section: However, this is not followed by the text that I imagine is to be inserted. Can you please add this text to the resolution? Also, please note that the resolution to issue 6373, this one will first have to be proposed to the MOF/Infra FTF and, if passed, approved by the Super FTF in a subsequent ballot. Thanks, Bran "Thomas Weigert" 05/23/2004 09:21 PM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "Thomas Weigert" , Subject RE: ,cb cs, Proposed issues for 15 Please find attached an updated proposal, taking into account the discussion of the topic "Ports as parts". I have put together a solution that models ports as parts, as requested. There was a ripple effect forcing the change of several other issues, which luckily enough all are proposed for this ballot. Further, I realized that the constraint in 6251 must also reference ports. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, May 20, 2004 6:36 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs, Proposed issues for 15 Thomas, > Regarding your constructive suggestion, I think we need to put a > little more effort in it. The constraint must say something to the > effect that the port will be there before communication is > attempted. E.g., we might want to tie it to the creation of the > connector. (i.e., no port, no connector, which makes sense anyway, > as where would the connector connect to?). > > The contract aspect of the port cannot fall by the wayside. By the > way, if we add dynamic creation (personally I think this is against > the spirit of modeling as I said earlier and confusing modeling with > coding) we should make a port a property with the appropriate constraints. As Joaquin's example points out, this is more than an implementation issues, so please stop saying that. My experience with architectural modeling bears this out: there is major need to be able to model dynamic architectures -- especially since the Internet and service-oriented architectures are highly dynamic contexts. And, very current. Your argument that this weakens the "contract aspect" of ports sounds rather tenuous to me. A port still clearly defines what its contractual assumptions are, whether it is created dynamically or statically. (BTW, some of the things in UML-RT that may have seemed "unnecessary" to you (your words, not mine), such as plug-in slots, are precisely for dealing with dynamically established architectures, without sacrificing the contractual aspects of ports and connectors.) My advice is that we do not try to finesse this complex issue too much. Let's just make sure that we leave room for dynamic systems by removing constaint [1]. Thanks...Bran [attachment "Comp struc + com beh issues 15 done v2.doc" deleted by Branislav Selic/Ottawa/IBM] From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , "Thomas Weigert" , Subject: RE: ,cb cs, Proposed issues for 15 Date: Thu, 27 May 2004 10:51:28 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)  Bran, will check and email tonight. On 6373, I don't understand why the order has to be first infra then super. We can also make our needs known to infra, don't we? The problem is that from the infra point of view there is no need to make this change if you look at infrastructure in isolation. It is languages that reuse the infra structure (such as the UML) that need this kind of change. So we should send a message to infra that we need this change. I suggest we run this through our process first. Thanks, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, May 26, 2004 5:46 PM To: Thomas Weigert Cc: mu2i-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs, Proposed issues for 15 Thomas, In your proposed resolution to issue 6356, there is the following statement: In section 9.3.11. â..Portâ.ť of ptc/03-08-02, on p.168 add in the associations section: However, this is not followed by the text that I imagine is to be inserted. Can you please add this text to the resolution? Also, please note that the resolution to issue 6373, this one will first have to be proposed to the MOF/Infra FTF and, if passed, approved by the Super FTF in a subsequent ballot. Thanks, Bran "Thomas Weigert" 05/23/2004 09:21 PM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "Thomas Weigert" , Subject RE: ,cb cs, Proposed issues for 15 Please find attached an updated proposal, taking into account the discussion of the topic "Ports as parts". I have put together a solution that models ports as parts, as requested. There was a ripple effect forcing the change of several other issues, which luckily enough all are proposed for this ballot. Further, I realized that the constraint in 6251 must also reference ports. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, May 20, 2004 6:36 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs, Proposed issues for 15 Thomas, > Regarding your constructive suggestion, I think we need to put a > little more effort in it. The constraint must say something to the > effect that the port will be there before communication is > attempted. E.g., we might want to tie it to the creation of the > connector. (i.e., no port, no connector, which makes sense anyway, > as where would the connector connect to?). > > The contract aspect of the port cannot fall by the wayside. By the > way, if we add dynamic creation (personally I think this is against > the spirit of modeling as I said earlier and confusing modeling with > coding) we should make a port a property with the appropriate constraints. As Joaquin's example points out, this is more than an implementation issues, so please stop saying that. My experience with architectural modeling bears this out: there is major need to be able to model dynamic architectures -- especially since the Internet and service-oriented architectures are highly dynamic contexts. And, very current. Your argument that this weakens the "contract aspect" of ports sounds rather tenuous to me. A port still clearly defines what its contractual assumptions are, whether it is created dynamically or statically. (BTW, some of the things in UML-RT that may have seemed "unnecessary" to you (your words, not mine), such as plug-in slots, are precisely for dealing with dynamically established architectures, without sacrificing the contractual aspects of ports and connectors.) My advice is that we do not try to finesse this complex issue too much. Let's just make sure that we leave room for dynamic systems by removing constaint [1]. Thanks...Bran [attachment "Comp struc + com beh issues 15 done v2.doc" deleted by Branislav Selic/Ottawa/IBM] Disposition: Duplicate