Issue 13928: Section: 7/Table 7.1, 7,3,1, 7.3.2, 7.4, -- partition construct (sysml-rtf) Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com) Nature: Enhancement Severity: Significant Summary: Partition Construct. It is often convenient to partition model elements without imposing ownership or containment constraints. In particular, this partitioning construct would enable any set of named elements to be grouped based on some set of partitioning crtieria. The group of elements would be named. The could be used to name a group of classifiers, properties, instances, or any other model elements or combination of model elements without modifying where they fit within an ownership or containment hierarchy. A possible approach would be to extend this construct, which will be referred to as a Partition, from a Named Element. The Named Element could represent the client for the series of model elements that it wishes to partition. The partition could own a constraint that specifies the criteria for an element to be a client of the partition. Various notational options could be used to show the group of elements in the partition. It could be a rectangle with the stereotype <<partition> with the model elements enclosed, or it could leverage the SysML callout notation as an example. Resolution: Revised Text: Actions taken: May 9, 2009: received issue Discussion: Multiple proposals and extensive discussion on metamodel and/or diagram extensions to support a partition or grouping capability of elements occurred within both the SysML 1.2 and 1.3 RTF's. The issue is being deferred to allow further consideration in future revisions of SysML. The email archive of the RTF discussion list contains an extensive record of issues, concerns, and alternative proposals for possible ways in which the requested capability could be provided. The Deferred resolution of this issue in the SysML 1.2 RTF report also contains a proposal under consideration at that time. Disposition: Deferred End of Annotations:===== vim -r issue13928 m: webmaster@omg.org Date: 09 May 2009 16:07:18 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 7/Table 7.1, 7,3,1, 7.3.2, 7.4, FormalNumber: formal/2008-11-02 Version: 1.1 RevisionDate: 11/XX/2008 Page: 22-29 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8; OfficeLiveConnector.1.3; OfficeLivePatch.0.0) Description Partition Construct. It is often convenient to partition model elements without imposing ownership or containment constraints. In particular, this partitioning construct would enable any set of named elements to be grouped based on some set of partitioning crtieria. The group of elements would be named. The could be used to name a group of classifiers, properties, instances, or any other model elements or combination of model elements without modifying where they fit within an ownership or containment hierarchy. A possible approach would be to extend this construct, which will be referred to as a Partition, from a Named Element. The Named Element could represent the client for the series of model elements that it wishes to partition. The partition could own a constraint that specifies the criteria for an element to be a client of the partition. Various notational options could be used to show the group of elements in the partition. It could be a rectangle with the stereotype < with the model elements enclosed, or it could leverage the SysML callout notation as an example. From: webmaster@omg.org Date: 09 May 2009 16:07:18 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 7/Table 7.1, 7,3,1, 7.3.2, 7.4, FormalNumber: formal/2008-11-02 Version: 1.1 RevisionDate: 11/XX/2008 Page: 22-29 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8; OfficeLiveConnector.1.3; OfficeLivePatch.0.0) Description Partition Construct. It is often convenient to partition model elements without imposing ownership or containment constraints. In particular, this partitioning construct would enable any set of named elements to be grouped based on some set of partitioning crtieria. The group of elements would be named. The could be used to name a group of classifiers, properties, instances, or any other model elements or combination of model elements without modifying where they fit within an ownership or containment hierarchy. A possible approach would be to extend this construct, which will be referred to as a Partition, from a Named Element. The Named Element could represent the client for the series of model elements that it wishes to partition. The partition could own a constraint that specifies the criteria for an element to be a client of the partition. Various notational options could be used to show the group of elements in the partition. It could be a rectangle with the stereotype < with the model elements enclosed, or it could leverage the SysML callout notation as an example. Date: Mon, 11 May 2009 15:13:37 -0400 From: "Chonoles, Michael J" Subject: RE: issue 13928 -- SysML RTF issue To: Juergen Boldt , issues@omg.org, sysml-rtf@omg.org Cc: "Friedenthal, Sanford" Thread-Topic: issue 13928 -- SysML RTF issue Thread-Index: AcnSa526P9mbCxGkQdaC6De3GB7slQAAGlQA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 11 May 2009 19:13:56.0988 (UTC) FILETIME=[A1D0B3C0:01C9D26C] Sandy I.m not show a partition differs from a view . a collection of elements for a particular purpose, the view doesn.t own the elements in the view. What.s the gain for additional notation? (Unless you just want an option to suppress the little tab). If not every element can be placed within a view (it should be possible as they are packages), that can be fixed. Michael LMCO From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, May 11, 2009 3:01 PM To: issues@omg.org; sysml-rtf@omg.org Subject: issue 13928 -- SysML RTF issue Description Partition Construct. It is often convenient to partition model elements without imposing ownership or containment constraints. In particular, this partitioning construct would enable any set of named elements to be grouped based on some set of partitioning crtieria. The group of elements would be named. The could be used to name a group of classifiers, properties, instances, or any other model elements or combination of model elements without modifying where they fit within an ownership or containment hierarchy. A possible approach would be to extend this construct, which will be referred to as a Partition, from a Named Element. The Named Element could represent the client for the series of model elements that it wishes to partition. The partition could own a constraint that specifies the criteria for an element to be a client of the partition. Various notational options could be used to show the group of elements in the partition. It could be a rectangle with the stereotype < with the model elements enclosed, or it could leverage the SysML callout notation as an example. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Date: Mon, 11 May 2009 22:56:45 -0400 From: "Friedenthal, Sanford" Subject: RE: issue 13928 -- SysML RTF issue To: "Chonoles, Michael J" , Juergen Boldt , issues@omg.org, sysml-rtf@omg.org Thread-Topic: issue 13928 -- SysML RTF issue Thread-Index: AcnSa526P9mbCxGkQdaC6De3GB7slQAAGlQAABAhpXA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 May 2009 02:56:46.0774 (UTC) FILETIME=[49E5C560:01C9D2AD] Michael I do think the two concepts should be integrated. The partition concept is not limited to packageable elements so that it can group elements such as properties. Nor does it need to conform to a viewpoint. In essence, it is a more general concept than a view. I would expect that we would modify view so that it is based on this concept, which I previously proposed to Tim. Sandy From: Chonoles, Michael J Sent: Monday, May 11, 2009 3:14 PM To: Juergen Boldt; issues@omg.org; sysml-rtf@omg.org Cc: Friedenthal, Sanford Subject: RE: issue 13928 -- SysML RTF issue Sandy I.m not show a partition differs from a view . a collection of elements for a particular purpose, the view doesn.t own the elements in the view. What.s the gain for additional notation? (Unless you just want an option to suppress the little tab). If not every element can be placed within a view (it should be possible as they are packages), that can be fixed. Michael LMCO From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, May 11, 2009 3:01 PM To: issues@omg.org; sysml-rtf@omg.org Subject: issue 13928 -- SysML RTF issue Description Partition Construct. It is often convenient to partition model elements without imposing ownership or containment constraints. In particular, this partitioning construct would enable any set of named elements to be grouped based on some set of partitioning crtieria. The group of elements would be named. The could be used to name a group of classifiers, properties, instances, or any other model elements or combination of model elements without modifying where they fit within an ownership or containment hierarchy. A possible approach would be to extend this construct, which will be referred to as a Partition, from a Named Element. The Named Element could represent the client for the series of model elements that it wishes to partition. The partition could own a constraint that specifies the criteria for an element to be a client of the partition. Various notational options could be used to show the group of elements in the partition. It could be a rectangle with the stereotype < with the model elements enclosed, or it could leverage the SysML callout notation as an example. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: RE: Issue 13928: partition concept - block-like thing Date: Sat, 11 Jul 2009 13:27:26 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13928: partition concept - block-like thing Thread-Index: AcnQ4duZ/JcJi1KEQ7a9XBVcf54daAApy0NwAATHzLAAAK4PQAAMUyXAAC1hRCAC6iFV8AABEYpAAA+dkYAAFLyRkAAFs6EgAB4qeCAADpoFsAANZ44YAAAf5UAAG0/DgAAPkybAAAYSExAAAgoDQAAA7UUwAKnC/aAAAabcEAAy4IbwADajXEwA1g1WgAAMTgBpAABYtWAADNpITwABT3lQAAoclasACRFWUAAKm44sAAOCXTAAB1JymgAFpamgAL8RfrAAAd5lRgAAYCyAAAMiXh0Aj2744ACEnOLwAeLVmSAADVH+kAAJGxOgADXs7GAAAH9HoABdApAgAAdEgPABDC8/8AAAjNSgAEejWOAAB1OX4AAFH3pwAAAv6GAAX7KUAA== From: "Tim Weilkiens" To: "Friedenthal, Sanford" , "Alan Moore" Cc: Attached an update of the resolution that reflects Alans comments: * Partitions own the dependency relationships. * Example for showing an association as a member of a partition -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Thursday, July 09, 2009 3:35 PM To: Alan Moore; Tim Weilkiens Subject: RE: Issue 13928: partition concept - block-like thing Alan Thanks. This is a view like concept, but it enables one to include non-packageable elements and edges. It also does not impose the constraint that it conform to a viewpoint. As you would see, a View is extended from this. Bottom line capability is that this provides a notation for grouping any elements without imposing ownership. Tim, Can you address Alans comments and provide an update to the group (note that the updates reflect comments from Alan). Thx. Sandy From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Thursday, July 09, 2009 9:31 AM To: Friedenthal, Sanford Cc: Tim Weilkiens Subject: RE: Issue 13928: partition concept - block-like thing Looks a bit clunky to me . depends on how badly you want this facility I guess. I thought the whole point of view using import relationships was so that elements could become members of the view and hence be shown in diagrams representing the view using just their names. A couple of other points . can edges (association for example) be shown inside the partition symbol or just nodes? Also, it might be worth insisting that partitions own the dependencies that identify their elements, just to keep things tidy. Alan. From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Thursday, July 09, 2009 12:02 PM To: Alan Moore Cc: Tim Weilkiens Subject: FW: Issue 13928: partition concept - block-like thing Alan This proposal is for a partition which groups elements without any ownership. It can include any element including not packageable elements. Your thoughts. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Thursday, July 09, 2009 3:31 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, ok. Attached the originally resolution. I'll upload it to our wiki. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Tuesday, July 07, 2009 11:21 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim Disregard my previous comments. Somehow I missed the last section . Please reissue as you originally had it. Thanks. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, July 07, 2009 5:11 PM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, my comments on your comments. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Thursday, July 02, 2009 3:05 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim Some comments. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Thursday, July 02, 2009 5:39 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Attached you find the update of the resolution. It includes the callout notation and a note about fig b.27 and 7.3. -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Tuesday, June 30, 2009 3:15 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Ok. fair enough. You will need to define the relationship between the partition and the model element that is partitioned (i.e. <> or <>) and refer to this in the callout notation. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, June 30, 2009 9:04 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, Callout notation seems to be a better choice than my proposal for the partition notation. Good idea. In that case I don't think it increases the complexity. The callout notation is very common throughout SysML. It'll be easy for tool vendors and users to adopt the new notation. I'll change the resolution soon and send an update. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Monday, June 29, 2009 1:23 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim I recommend we not confuse activity partition with partition, since they have very different semantics. You raise a good point that we may want to see what partitions a model element is part of. If we wanted to do this, we could use something similar to what we do with callout notations and compartment notations for allocations to show what is on either end of the relationship. However, my sense is that may add complexity to our baseline and perhaps we should defer this. Your thoughts. As part of the resolution rationale, we should point out that Fig b.27 and 7.3 are now valid. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Monday, June 29, 2009 3:08 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, Thanks for the congratulations. Everybody is in a good shape besides to be tired out I hope Costa Rica was successful and achieved some more big steps forward for SysML and Systems Engineering. Figure 7.2. shows how to display the relation of a named element to a partition. The whole block is related to partion1 and partition2. The value x is related to partition1. The notation is based on the partition notation for activities. See fig. 12.58 a) in the UML 2.2 specification (or my attachment). You're right that fig B.27 isn't correct. It shows packageable elements inside the view which means they are members of the view. But views don't have members despite constraints, comments and import relationships. They import packageable elements. The same figure appears in chapter 7 as fig 7.3. The resolution for issue 13928 proposes a diagram extension that shows related elements of a partition inside the partition symbol like members. Since the view is a specialized partition this would be also valid for views. In that scenario B.27 and fig. 7.3 are correct. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Monday, June 29, 2009 2:37 AM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim Sorry for being slow to respond. First of all, CONGRATULATIONS on your new child. I hope the mother and child are doing well (along with the father). Relative to this proposal, it looks quite good, except one item I did not understand was Figure 7.2 and its caption. Can you clarify. Also, I suspect this change may impact the figure B.27 in the HSUV example that shows a view (I think currently it is incorrect since it includes packageable elements in the view). If you agree, please coordinate with Rick Steiner on this change. Thanks. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Friday, June 19, 2009 8:46 AM To: Tim Weilkiens; Rouquette, Nicolas F; Friedenthal, Sanford Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Attached you find the first version of a proposal for the simple partition construct. -------------------------------------------------------------------------------- From: Tim Weilkiens Sent: Tuesday, June 16, 2009 9:01 PM To: 'Rouquette, Nicolas F'; Friedenthal, Sanford Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sorry for being offline for a while. I had my focus on another issue: I became father again I'll prepare a proposal for the simple approach. We still should consider the other approaches. But I agree with Sandy that we need some kind of a baseline to get on the road with that topic. Thinking about the different approaches I asked myself how to define the concept of a partition. Do you have one? Is there a standardized definition somewhere? I've only found very generic definitions like "A part or section into which something has been divided." I'm looking for something more concrete. I think the simple approach is more like a group while Nicolas approach is more like a real partition. But it's more a feeling than based on some criteria. Regardless which approach we take I'm a little bit afraid that it goes beyond the scope of a RTF. It's not a bugfix, but a complete new feature. What do you think? Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, June 14, 2009 12:24 AM To: Friedenthal, Sanford; Tim Weilkiens Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: Re: Issue 13928: partition concept - block-like thing Fine with me. - Nicolas. On 6/13/09 1:55 PM, "Friedenthal, Sanford" wrote: Nicolas Good thought. I still would like Tim to propose the simpler solution if he feels it makes sense as we evaluate other alternatives in parallel. If nothing else, we can establish a simple baseline from which to evaluate the alternatives in terms of capability, ease of use, ease of implementation. Sandy From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Saturday, June 13, 2009 4:43 PM To: Friedenthal, Sanford; Tim Weilkiens Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: Re: Issue 13928: partition concept - block-like thing Hi, I.ve been ambivalent about where the discussions about the two approaches to a partition concept leave us. Tim.s approach is clearly simpler than mine but I there are problems with both. After discussing the final changes to the SysML QUD conceptual model with Roger and Hans-Peter, It occurred to me that there may be one third alternative we haven.t explored yet but seems possible: In the QUD, a user can choose a set of QuantityKinds as the base Dimensions. From there, the dimension analysis algorithm derives a dimension for all other quantities involved. Hans-Peter indicated that he believes the QUD could be easily extended to allow reasoning about Dimensions from the point of view of inducing a lattice. For example; [Front Wheel] is a more specific dimension than [Wheel] which is a more specific dimension than [Car Part]. The motivation for this comes from a suggestion Bob Rasmussen made about dimension analysis; i.e., we would like to be able to say things like: 2 [Front Wheel] + 1 [Spare Wheel] = 3 [Wheel] = 3 [Car Part]. This is particularly useful if we want to reason about the consistency of dimensions in quantities involved in constraints or other algebraic expressions. For example: [Front Wheel] + [Front Wheel] = [Front Wheel] but: [Front Wheel] + [Space Whee] = [Wheel] and: [Front Wheel] + [Wheel Hub] = [Car Part] So, the suggestion is simply to look at the problem of specifying analyzable/verifiable partitioning criteria as a kind of dimension analysis problem. My suggestion then would be to explore using the SysML QUD extended for reasoning about the relationships among dimensions as an effective way to specify and analyze partitions. - Nicolas. On 6/13/09 12:52 PM, "Friedenthal, Sanford" wrote: Tim I am going to be out of email contact beginning tomorrow AM until the end of the month. Please send any proposals for a partition to Roger if you feel we have something ready to discuss. I am hoping there is a proposal to provide a minimum capability for partitioning non packageable elements such as properties. We can decide whether it offers significant value to proceed with it or not. I would be happy to present it for you as best I can at the SysML RTF meeting on June 22. If you feel we really don.t have a minimal capability or that the minimal capability is insufficient to add value, then we can defer. Thanks for your help. Sandy From: Friedenthal, Sanford Sent: Tuesday, June 09, 2009 8:43 PM To: 'Rouquette, Nicolas F'; Tim Weilkiens; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: RE: Issue 13928: partition concept - block-like thing Tim, Nicolas Where does this leave us. I think we should work to get a basic capability in and then look at ways to improve it over time. The basic capability should be implementable within the tools constraints. I think the ideas brought forward look very interesting, but personally, I think it would be most productive to provide a simple straightforward base capability that we can start with. Of course, if the base capability is totally inadequate to provide a value add, then we should just defer until we have a more sophisticated capability. What are your thoughts on a starting capability? Does the dependency approach give us a value add or is it too limited. Can we evaluate how compelling this capability is. If not, is there a step up that leverages some of the more sophisticate approaches that Nicolas is proposing. We need to ensure it is compelling in its use, intuitive and implementable. Sandy From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, June 09, 2009 5:57 PM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, What distinguishes your use of dependency relationships for specifying a partition from other uses of dependency relationships for unrelated purposes? In other words, is there a semantics you intend to specify for the string attribute specifying the partitioning criteria? Would this semantics, if any, allow us to tell that a partition of the left wheels of the car and a partition of the right wheels of the car are disjoint partitions of the wheels of the same car and that intersection of the left wheels partition and of the front wheels partition for the same car is precisely the left-front wheel? I was hoping that the answer to these questions would involve the semantics of classifiers and classifier specialization as an effective means of denoting a subset of the extent of a classifier but it seems unlikely that we can pull this off in either approach alone. I hope that there is some clever combination of the two approaches perhaps with another trick that could get us closer to a first-class concept of a partition as a kind of classifier we can specify at M1 and reason about at M0 but the prospects for that happening seem unlikely at this time. -- Nicolas. On 6/9/09 11:30 AM, "Tim Weilkiens" wrote: Nicolas, attached you find an example of the dependency approach. Partition is simply a stereotype extending package with a string attribute for the criteria. The diagram shows two notations of the same partition. I only used presentation options that are possible with MagicDraw. It's no fake. For the real partition we need a special SysML presentation option. The partition should look like a package with it's content. Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, June 09, 2009 6:47 PM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, I recognize that my approach involves crossing M1/M2 levels for specifying the scope of a partition using an association class; i.e., I.ve used an M2 element or a Stereotype when there isn.t an M1 classifier available for typing an association end . e.g., InstanceSpecification, Property, Block, ... The point here being that this approach allows specializing the association class scope. This issue doesn.t affect the use of an association class for specifying the partition of the scope. As an association class, we can specialize a partition to denote the empty partition simply by specializing the association class where the association ends are redefined with zero multiplicity. In the context of specialization, it is legal for a specialized association class to have zero or just one association end and still comply with the constraint that an association must have at least 2 ends in the sense that an association must have 2 ends either directly or by inheritance. I haven.t seen a description of the dependency approach so I would be premature for me to comment on it. - Nicolas. On 6/9/09 5:04 AM, "Tim Weilkiens" wrote: Nicolas, Thanks for all the explanation. Now I much better understand your approach. The multibranch part/shared association in SysML isn't a n-ary association. It's more a presentation option to show different association in a tree layout. I think it is misleading that table 8.2. only shows one association name in the concrete syntax example column. From my understanding these are two associations. How could you create an empty partition? An association class requires at least two associated elements. I think the key problem is that it is not allowed to mix the metalevels. The InstanceSpecification in your example could not be part of the n-ary association. Also stereotypes are not allowed to participate in your association. Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. >With a dependency relationship, you can designate that a given type of Element is involved in a partition; >however, this approach is insufficient to address practical requirements for a partition concept in SysML: > 1. how many of each kind of elements are involved . e.g., partition 2 of the 4 wheels If I have many kinds of a element, I have properties and would include the properties by dependency relationships into the partition. > 2. how to partition elements according to their role attributed in the larger context . e.g., partition the front wheels only; leave out the rear wheels The dependency relationship can directly relate properties. Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, June 09, 2009 9:24 AM To: Friedenthal, Sanford; Tim Weilkiens; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Sandy, About n-ary associations: Indeed, I am stretching SysML 1.1 a bit. SysML is somewhat ambiguous about supporting n-ary associations of some kind. 8.3.1.3 (UML Diagram Elements not Included in SysML Block Definition Diagrams) clearly states that n-ary associations aren.t supported. Ditto for constraint [1] in 8.3.2.2 (Block). However, the notation shown in Table 8.2 for .Multibranch Part/Shared Association. clearly shows an example of a ternary association of some kind. At minimum, this is clearly in contradiction with the intent stated in 8.3.1.3. If the properties were typed by a block, this would then be inconsistent with 8.3.2.2 [1] as well.\ About the notation: There are some limitations in what I can show with MD 16.0 sp1. To show the type of an association end in MD, we have to use a note and include the .type. in the .Element Properties. shown in the note. This is awkward. About association class vs. association: An association class is an objectification of an association relationship; i.e., an instance of an association class is an object reifying an instance of an association, i.e., a link. This objectification means that an association class can participate as an association end in another association or even another association class. However, this kind of modeling is beyond the scope of what MD 16.0 sp1 currently supports as I indicated in the example where I couldn.t show the binary association between the two association classes: VehicleRequirementTestingScope and VehicleRequirementTestPartition. Note that an association class scope (e.g., VehicleRequirementTestingScope) is a neither an M1 nor an M2 level classifier because its association end classifiers can be at M1 (e.g., Wheel, Car) or M2 (e.g., Requirement, FlowPort, ...). In straddling the M1/M2 boundary, an association class scope resembles a stereotype but there are important differences between the two: an association class scope is meant to be instantiated to designate the set of instances defining the extent of a scope instance; a stereotype is instantiated as part of applying the stereotype to an instance of the metaclass it extends. In contrast, an association class partition (e.g., VehicleRequirementTestPartition) is in M1 and its association ends are also in M1 (e.g., WheelRole, FlowPortRole, etc...). The association class partition and its association end classifier roles are an M1 level normalization of the hybrid M1/M2 association class scope whose association end classifiers can be in M1 or M2 as explained above. This is important to ensure that subsetting an assciation class partition is semantically equivalent to specializing in the sense of classifier specialization in UML and SysML. Is all of this really necessary? It depends on how do we want to specify the semantics of a partition as a subset of an explicitly defined set of elements in a model. In the UML and SysML, we have powerful mechanisms to construct sets of things; however, we are much more limited in our ability to construct sets of sets; that.s where associations & association classes are very useful in that they provide a decent approximation for the notion of a set of sets as a composition of sets (i.e., the association ends) that can be subsetted by specialization. Since a partition needs to be related to the scope of the elements it is subsetting, both partition and scope must be association classes rather than regular associations. In the example, if either of VehicleRequirementTestPartition or VehicleRequirementTestingScope were plain associations, then we wouldn.t be able to unambiguously establish a binary association between them as it would be otherwise impossible to distinguish the association ends of the binary relationship from those of the n-ary associations. - Nicolas. On 6/8/09 7:43 PM, "Friedenthal, Sanford" wrote: Nicolas SysML does not currently support n-ary associations. Also, some parts of the figure are not clear to me. I am not familiar with not having a type at the end of the association such as the case with the Flow Port or constraintProperty. Also, what functionality does the association class provide over an association (i.e. do you leverage the features of the association class)? Are the comment symbols intended to be comments, or the class symbol of the n-ary association class. Sandy From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, June 08, 2009 9:57 PM To: Friedenthal, Sanford; Tim Weilkiens; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Sandy, I.ve applied the powertype approach to an expanded car example to partition items that aren.t classifiers or packageable elements (e.g., properties). See attached picture. First, a partition is a special kind of association class. An instance of an association class partition is an object reifying the extent of the partition . i.e., the slot values corresponding to the association end roles. The main benefit of this approach is that specifying a subset of a partition is logically equivalent to specializing the association class partition. By the nature of an AssociationClass, it would seem that this approach would be limited to partitioning elements of Type kind; this isn.t the case. Second, a partition only makes sense if we have a scope of elements we can partition. The attached figure shows an example of a VehicleRequirementTestingScope as an n-ary AssociationClass specifying the scope of heterogeneous kinds of elements we can include in any VechicleRequirementTestPartition, a special kind of n-ary AssociationClass whose association ends are classifier roles reifying the inclusion of an element in the partition. In this approach, powertypes are one of several mechanisms available in the UML and SysML for specializing an n-ary AssociationClass partition as an effective means for unambiguously relating different partitions whose extent can be disjoint, overlapping or wholy included in another (e.g., FrontWheelRequirementTestPartition is a subset of the VehicleRequirementTestPartition). That is, I.m advocating for taking advantage of all of the specialization machinery we have available in the UML & SysML to provide users the flexibility to specify partitions precisely and unambiguously. I do recognize that there are practical limitations to this approach, mainly due to gaps in existing tools . e.g. See the red notes in the diagram. - Nicolas. P.S. Roger . I couldn.t login on the sysml wiki to upload the example corresponding to the image: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf2:groups:partition_concept On 6/8/09 12:50 PM, "Friedenthal, Sanford" wrote: Doesn.t the powertype approach still limit the items being partitioned to be classifiers. How is it applied to properties, instance specifications, and other non-packageable elements. From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, June 08, 2009 3:39 PM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, With a dependency relationship, you can designate that a given type of Element is involved in a partition; however, this approach is insufficient to address practical requirements for a partition concept in SysML: how many of each kind of elements are involved . e.g., partition 2 of the 4 wheels how to partition elements according to their role attributed in the larger context . e.g., partition the front wheels only; leave out the rear wheels The powertype approach focuses on leveraging existing mechanisms for specifying a view language of partitions organized in a lattice. An n-ary Association represents a partition based on association ends instead of dependency relationships. An association end provides the capability to specify a cardinality restriction and individual association ends can be further partitioned by refinement . e.g., (1). Reifying the n-ary Association into a first-class n-ary AssociationClass provides a capability to organize partitions in a specialization lattice .e.g., (2). An n-ary AssociationClass as a partition construct allows specifying: the largest partition of all elements the empty partition of no elements the relationship between intermediate partitions (i.e., specialization means subsetting) the overlap amongst partitions as the overlap of their association ends The Car Example illustrates these notions: The CarDomain includes: Engine & Wheel The CarAssembly partition view defines roles the elements of the CarDomain can have in a partition: an EngineRole is a a partition classifier designating an Engine (this could be a dependency or a binary association) a WheelRole is a partition classifier designating a Wheel (ditto) a CarAssembly is an n-ary AssociationClass whose association ends are EngineRole and WheelRole. To specify sub-partitions of the CarAssembly partition context, we need a taxonomy of partition roles. This is where powertype concepts are useful to specify distinct role hierarchies, e.g.: -WheelRole = LeftWheelRole + RightWheelRole {complete, disjoint} (generalization set linked to a LeftRightRole powertype) -WheelRole = FrontWheelRole + RearWheelRole {complete, disjoint} (generalization set linked to a FrontRearRole powertype) With these role taxonomies, we can specify fine-grained partitions that can be related to other partitions unambiguously: FrontLeftWheelRole is a specialization of both LeftWheelRole & FrontWheelRole FrontRightWheelRole is a specialization of both RightWheelRole & FrontWheelRole FrontLeftWheelRole + FrontRightWheelRole = FrontWheelRole - Nicolas. On 6/8/09 6:55 AM, "Tim Weilkiens" wrote: Nicolas, > Suppose that we want to specify a partition that involves a set of classifiers and the behavioral feature parameters and activity parameters typed by any of these classifiers. I > hope you will agree that this kind of partition is not directly representable within the language All three elements are named elements. Therefore we can create a partition of named elements. The sysml view concept could create a kind of partition of packageable elements. If we change the grouping relationship from import to dependency we have a partition of named elements. Another idea is to use the dependency relationship without a package. Although most tools doesn't support it, the dependency relationship allows many clients and suppliers. A semantically problem is to answer who should be the client and who is the supplier in a partition. Such kind of ordering makes no sense to me. However the trace relationship as a standardized UML stereotype of the dependency specialization abstraction mentions "the directionality of the dependency can often be ignored". Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, June 04, 2009 9:37 AM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, This is a very good question; the short answer is yes but this requires some explanation. We need to .jump. outside the language (UML, SysML) in order to specify a concept of a partition as an arbitrary subset of uml::Element objects; i.e., an arbitrary partition of uml::Element objects is a second-order subset. A first-order subset is whatever kind of subset we can specify using the nominal structuring mechanisms available in the language, e.g.: a Namespace owns NamedElements, a Package owns PackageableElements a Classifier owns Features a BehavioralFeatures owns Parameters For these concepts, we can specify a partition by subsetting the nominal structure of the concept as specified in UML/SysML/... For example, a partition of a Namespace is a subset of Namespace::member : NamedElement[0..*] a partition of a Package is a subset of Package::packagedElement : PackageableElement[0..*] a partition of a Classifier is a subset of Classifier::feature : Feature[0..*] a partition of a BehavioralFeature is a subset of BehavioralFeature::ownedParameter : Parameter[0..*] Some subsets have no 1st order nominal representation in the uml; here are some notorious examples: an Activity does not .own. its ActivityNodes/Edges -- see: http://www.omg.org/issues/issue8668.txt there is no nominal distinction between the parameters of an Activity and non-parameter ActivityNodes; both are disjoint subsets of Activity::node : ActivityNode[0..*] which, as issue 8668 clarified, is not a composition relationship like the above examples. Suppose that we want to specify a partition that involves a set of classifiers and the behavioral feature parameters and activity parameters typed by any of these classifiers. I hope you will agree that this kind of partition is not directly representable within the language; i.e., we have to jump outside the UML in order to specify this kind of partition, e.g., with the help of an OCL constraint; in other words, an arbitrary partition is fundamentally a second-order concept for the UML. So, the trick that I.ve used is to define a convention to reify a partition as a second-order structural concept. That is, I used a .Wheel Role. as a reification of a second-order specification about the fact that our partition is referring to a particular .Wheel. which .Wheel Role. designates with the help of a directed, non-navigable association. If we need to partition things that aren.t classifiers, then we simply need to reify a second order specification that allows us to designate the things we want to include in our partition . classifiers and non-classifiers. However, the danger with this approach is that we have now opened the door for Russell.s paradox; i.e., a partition that partitions itself. To avoid Russell.s paradox, it is important to verify that the partitions form a partial ordering of subsets of the elements in the model and that this partial order has the topological structure of a lattice where each pair of element has a lower element and an upper element. I haven.t found a readable reference on the computational complexity of constructing the lattice for a partial order relation. It seems that the general problem is NP complete: http://portal.acm.org/citation.cfm?id=980030 but the problem is quite relevant to information modeling. In fact, I tried as an exercise a few years ago to design a simple but computationally efficient technique for constructing the lattice for a potentially large partial order relation in Alloy (http://osdir.com/ml/lang.alloy.general/2006-02/msg00001.html) Since then, I.ve improved on this idea quite a bit (I called it .no knock-knock jokes. when I discussed it with Dan Jackson.s students back in 2007). With recent optimizations, I can analyze various partial ordering relations in the UML metamodel with Alloy in a few seconds even though these relations can sometimes involve hundreds of tuples. The point is that if we have the right perspective for conceptualizing the notion of a partition for UML-like models, we can avoid falling into Russell.s trap. Alloy is certainly useful if used properly to do that but I consider this to be a tool to help us design better specifications, not the means by which we have to necessarily implement the spec. - Nicolas. On 6/2/09 10:37 PM, "Tim Weilkiens" wrote: Nicolas, Thanks for the clarification and the links to further study material. I'll check that. Is it possible to extend your approach somehow to include non-classifiers in partitions? I think it is important that partitions are more generic and can group more or less any model element. Maybe we need two concepts: a generic grouping mechanism and a block-based grouping mechanism. I think using blocks to group related elements is similar to create system configurations. Tim > -----Original Message----- > From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: Tuesday, June 02, 2009 8:00 AM > To: Tim Weilkiens; Friedenthal, Sanford; Russell.Peak@gatech.edu > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > Rasmussen, Robert D; conrad.bock@nist.gov; Ingham, Michel D > Subject: RE: Issue 13928: partition concept - block-like thing > > Tim, > > Yes; however, Marc and I spent several hours discussing this > example that he and Russell Peak had previously discussed as > well. Marc had a very simple illustration of the idea of a > partition with a combination of composition and aggregation > associations. However, this approach has obvious problems > since there are no constraints enforcing that the scope of a > partition specified by aggregation is in fact a subset of the > elements defined in a context by composition. > > The fundamental issue here is that the UML is a nominal > specification language: subtyping is nominal, subsetting is > nominal, redefinition is nominal -- i.e., we can only > specialize a named classifier; we can only subset a named > property, we can only redefine a named feature, etc... > > There is an excellent discussion of the difference between > nominal vs. structural subtyping in the context of the > Modelica language here: > > http://www.modelica.org/events/modelica2006/Proceedings/sessio > ns/Session3c3.pdf > > For Java, there is a proposal for integrating nominal and > structural subtyping here: > > http://www.cs.cmu.edu/~donna/public/ecoop08slides.pdf > http://www.cs.cmu.edu/~donna/public/ecoop08.pdf > > Based on these ideas, I've revised Marc's example for > partitioning different sets of wheels for a car -- eg., front > wheels vs. all 4 wheels. > > My motivation is that I want to stay within the semantics of > the UML to specify the fact that a partition is really a > subset of parts defined in a classifier context (e.g., a > structured block in SysML). > > For example, I want to make sure that a UML/SysML tool can > verify that the intersection of the "front wheels" partition > with the "left wheels" partition should be a set consisting > of just the "left front wheel". Similarly, the intersection > of the "front wheels" partition with the "right wheels" > partition should be a set consisting of just the "right front > wheel". If you were to take the union of these two sets, a > tool should be able to verify that this union is equivalent > to the subset of parts in the "front wheels" partition. > > With this guiding principle in mind, I refactored Marc > example as shown in the attached model (MD 16.0 sp1). > > - Nicolas. > > > > > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Monday, June 01, 2009 9:45 PM > > To: Rouquette, Nicolas F; Friedenthal, Sanford; > > Russell.Peak@gatech.edu > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > Rasmussen, > > Robert D; conrad.bock@nist.gov; Ingham, Michel D > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > Nicolas, > > > > If I understand your example correctly your approach limits > partitions > > to classifiers. > > An element that is part of the partition requires a generalization > > relationship. > > Is that correct? > > > > Tim > > > > > -----Original Message----- > > > From: Rouquette, Nicolas F > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > > >: Friday, May 29, 2009 9:43 PM > > > To: Tim Weilkiens; Friedenthal, Sanford; Russell.Peak@gatech.edu > > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > > >Rasmussen, Robert D; conrad.bock@nist.gov; Ingham, Michel D > > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > > > The latest version of the bundle is: > > > JPL-OMG-RFI-05-29-2009.tar Conrad's email system rejected > it because > > > it it too big (6Mb). > > > > > > This tar contains this: > > > > > > jpl-omg-rfi.mdzip > > > JPL-OMG-RFI-05-29-2009.html > > > JPL-OMG-RFI-05-29-2009_files/ > > > > > > In the MD model, navigate to the package: > > > > > > Examples::Car::4) Structural Entities & > Relationships::Alternative4 > > > > > > > > > Look at the classes: "Front Wheel" and "Rear Wheel" as > examples of > > > partitions of the subset of the wheels of a car. > > > In this example, a partition is modeled as a > specialization of the > > > set of wheels that have a role in the context of a particular car. > > > > > > What makes partitioning a non-trivial issue is that we are really > > > talking about modeling a partition as a subset > relationship between > > > a set of entities (e.g., wheels) and the set of roles (e.g., the > > > wheels of a particular car) that a subset of these > entities have for > > > another entity (e.g., a car) > > > > > > The approach here is based on the notion of UML powertype and > > > generalization set. > > > The approach is inspired, in part, based on the way Conrad Bock > > > talks about the model of composition in UML2 and in part > on equating > > > the notion of a partition as a kind of categorical relationship > > > according to Terry Halpin. > > > > > > - Nicolas. > > > > > > > -----Original Message----- > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > Sent: Friday, May 29, 2009 12:03 PM > > > > To: Rouquette, Nicolas F; Friedenthal, Sanford; > > > > Russell.Peak@gatech.edu > > > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > > > Rasmussen, > > > > Robert D; conrad.bock@nist.gov; Ingham, Michel D > > > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > > > > > Nicolas, > > > > > > > > I've received all three versions of the bundle. Are they > > > all the same? > > > > > > > > I had a look on the first one. But I couldn't find the > partition > > > > concept in your model. > > > > Which diagram/package shows your approach? > > > > > > > > Tim > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rouquette, Nicolas F > > > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > > > > > Sent: Friday, May 29, 2009 8:05 PM > > > > > To: Friedenthal, Sanford; Tim Weilkiens; > Russell.Peak@gatech.edu > > > > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > > > > > Rasmussen, Robert D; conrad.bock@nist.gov; Ingham, Michel D > > > > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > > > > > > > This is a tar file. > > > > > Does it pass through the firewalls? > > > > > > > > > > We need a shared repository instead of fighting spam filters. > > > > > > > > > > - Nicolas. > > > > > > > > > 13928_resolved_20090711_tw.doc Date: Sat, 11 Jul 2009 07:53:24 -0400 From: "Chonoles, Michael J" Subject: RE: Issue 13928: partition concept - block-like thing To: Tim Weilkiens , "Friedenthal, Sanford" , Alan Moore Cc: sysml-rtf@omg.org Thread-Topic: Issue 13928: partition concept - block-like thing Thread-Index: AcnQ4duZ/JcJi1KEQ7a9XBVcf54daAApy0NwAATHzLAAAK4PQAAMUyXAAC1hRCAC6iFV8AABEYpAAA+dkYAAFLyRkAAFs6EgAB4qeCAADpoFsAANZ44YAAAf5UAAG0/DgAAPkybAAAYSExAAAgoDQAAA7UUwAKnC/aAAAabcEAAy4IbwADajXEwA1g1WgAAMTgBpAABYtWAADNpITwABT3lQAAoclasACRFWUAAKm44sAAOCXTAAB1JymgAFpamgAL8RfrAAAd5lRgAAYCyAAAMiXh0Aj2744ACEnOLwAeLVmSAADVH+kAAJGxOgADXs7GAAAH9HoABdApAgAAdEgPABDC8/8AAAjNSgAEejWOAAB1OX4AAFH3pwAAAv6GAAX7KUAAAAyMFw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 11 Jul 2009 11:55:25.0411 (UTC) FILETIME=[7A176B30:01CA021E] Lots of questions about partitions 1) Can a partition have a sub-partition. To have practical value as an organizing and presenting approach, I believe I need to have the ability to have some multi-layered organization. If partitions can (or cannot) have sub-partitions, it needs to be clear. 2) Can a partition be owned by something else?, like a package? Are the elements in the partition, even if not owned by the partition, owned by the package? If so (or not) please make it clear a. For example, if a comment is owned by the partition, is this transititively owned by the partition.s package? b. Can partitions be not owned by anything? 3) Please also make it clear that if a element is required to be owned by something (e.g., such as a block) but is not . placing it in a partition does what. Does it automatically make it owned by the owner of the partition and allowed, or does it still make it illegal. 4) I.d prefer a non-package looking notation to more strongly indicate the lack of ownership . perhaps for example, a dashed border for a partition. 5) I.m not sure what use it is to bring it elements with the notation such as «association»Name of the Assocation. Does this mean that the partition can.t use the normal package diagram notation? i.e., showing an association between two blocks? a. Does this give us a way of bringing in a diagram into a partition/view? 6) One of the defects with view (and probably with partition) is the inability to isolate an element in context. So if a block is brought into a partition/view, it is unclear which aspects of the block is of interest. For example, if I bring in a block to a partition/view, do I need to explicitly bring in the interesting parts, all the parts, no parts..Is each composition relationship and another square box in the partition/view. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Saturday, July 11, 2009 7:27 AM To: Friedenthal, Sanford; Alan Moore Cc: sysml-rtf@omg.org Subject: RE: Issue 13928: partition concept - block-like thing Attached an update of the resolution that reflects Alans comments: * Partitions own the dependency relationships. * Example for showing an association as a member of a partition -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Thursday, July 09, 2009 3:35 PM To: Alan Moore; Tim Weilkiens Subject: RE: Issue 13928: partition concept - block-like thing Alan Thanks. This is a view like concept, but it enables one to include non-packageable elements and edges. It also does not impose the constraint that it conform to a viewpoint. As you would see, a View is extended from this. Bottom line capability is that this provides a notation for grouping any elements without imposing ownership. Tim, Can you address Alans comments and provide an update to the group (note that the updates reflect comments from Alan). Thx. Sandy From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Thursday, July 09, 2009 9:31 AM To: Friedenthal, Sanford Cc: Tim Weilkiens Subject: RE: Issue 13928: partition concept - block-like thing Looks a bit clunky to me . depends on how badly you want this facility I guess. I thought the whole point of view using import relationships was so that elements could become members of the view and hence be shown in diagrams representing the view using just their names. A couple of other points . can edges (association for example) be shown inside the partition symbol or just nodes? Also, it might be worth insisting that partitions own the dependencies that identify their elements, just to keep things tidy. Alan. From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Thursday, July 09, 2009 12:02 PM To: Alan Moore Cc: Tim Weilkiens Subject: FW: Issue 13928: partition concept - block-like thing Alan This proposal is for a partition which groups elements without any ownership. It can include any element including not packageable elements. Your thoughts. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Thursday, July 09, 2009 3:31 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, ok. Attached the originally resolution. I'll upload it to our wiki. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Tuesday, July 07, 2009 11:21 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim Disregard my previous comments. Somehow I missed the last section . Please reissue as you originally had it. Thanks. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, July 07, 2009 5:11 PM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, my comments on your comments. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Thursday, July 02, 2009 3:05 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim Some comments. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Thursday, July 02, 2009 5:39 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Attached you find the update of the resolution. It includes the callout notation and a note about fig b.27 and 7.3. -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Tuesday, June 30, 2009 3:15 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Ok. fair enough. You will need to define the relationship between the partition and the model element that is partitioned (i.e. <> or <>) and refer to this in the callout notation. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, June 30, 2009 9:04 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, Callout notation seems to be a better choice than my proposal for the partition notation. Good idea. In that case I don't think it increases the complexity. The callout notation is very common throughout SysML. It'll be easy for tool vendors and users to adopt the new notation. I'll change the resolution soon and send an update. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Monday, June 29, 2009 1:23 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim I recommend we not confuse activity partition with partition, since they have very different semantics. You raise a good point that we may want to see what partitions a model element is part of. If we wanted to do this, we could use something similar to what we do with callout notations and compartment notations for allocations to show what is on either end of the relationship. However, my sense is that may add complexity to our baseline and perhaps we should defer this. Your thoughts. As part of the resolution rationale, we should point out that Fig b.27 and 7.3 are now valid. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Monday, June 29, 2009 3:08 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, Thanks for the congratulations. Everybody is in a good shape besides to be tired out I hope Costa Rica was successful and achieved some more big steps forward for SysML and Systems Engineering. Figure 7.2. shows how to display the relation of a named element to a partition. The whole block is related to partion1 and partition2. The value x is related to partition1. The notation is based on the partition notation for activities. See fig. 12.58 a) in the UML 2.2 specification (or my attachment). You're right that fig B.27 isn't correct. It shows packageable elements inside the view which means they are members of the view. But views don't have members despite constraints, comments and import relationships. They import packageable elements. The same figure appears in chapter 7 as fig 7.3. The resolution for issue 13928 proposes a diagram extension that shows related elements of a partition inside the partition symbol like members. Since the view is a specialized partition this would be also valid for views. In that scenario B.27 and fig. 7.3 are correct. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Monday, June 29, 2009 2:37 AM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim Sorry for being slow to respond. First of all, CONGRATULATIONS on your new child. I hope the mother and child are doing well (along with the father). Relative to this proposal, it looks quite good, except one item I did not understand was Figure 7.2 and its caption. Can you clarify. Also, I suspect this change may impact the figure B.27 in the HSUV example that shows a view (I think currently it is incorrect since it includes packageable elements in the view). If you agree, please coordinate with Rick Steiner on this change. Thanks. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Friday, June 19, 2009 8:46 AM To: Tim Weilkiens; Rouquette, Nicolas F; Friedenthal, Sanford Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Attached you find the first version of a proposal for the simple partition construct. -------------------------------------------------------------------------------- From: Tim Weilkiens Sent: Tuesday, June 16, 2009 9:01 PM To: 'Rouquette, Nicolas F'; Friedenthal, Sanford Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sorry for being offline for a while. I had my focus on another issue: I became father again I'll prepare a proposal for the simple approach. We still should consider the other approaches. But I agree with Sandy that we need some kind of a baseline to get on the road with that topic. Thinking about the different approaches I asked myself how to define the concept of a partition. Do you have one? Is there a standardized definition somewhere? I've only found very generic definitions like "A part or section into which something has been divided." I'm looking for something more concrete. I think the simple approach is more like a group while Nicolas approach is more like a real partition. But it's more a feeling than based on some criteria. Regardless which approach we take I'm a little bit afraid that it goes beyond the scope of a RTF. It's not a bugfix, but a complete new feature. What do you think? Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, June 14, 2009 12:24 AM To: Friedenthal, Sanford; Tim Weilkiens Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: Re: Issue 13928: partition concept - block-like thing Fine with me. - Nicolas. On 6/13/09 1:55 PM, "Friedenthal, Sanford" wrote: Nicolas Good thought. I still would like Tim to propose the simpler solution if he feels it makes sense as we evaluate other alternatives in parallel. If nothing else, we can establish a simple baseline from which to evaluate the alternatives in terms of capability, ease of use, ease of implementation. Sandy From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Saturday, June 13, 2009 4:43 PM To: Friedenthal, Sanford; Tim Weilkiens Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: Re: Issue 13928: partition concept - block-like thing Hi, I.ve been ambivalent about where the discussions about the two approaches to a partition concept leave us. Tim.s approach is clearly simpler than mine but I there are problems with both. After discussing the final changes to the SysML QUD conceptual model with Roger and Hans-Peter, It occurred to me that there may be one third alternative we haven.t explored yet but seems possible: In the QUD, a user can choose a set of QuantityKinds as the base Dimensions. >From there, the dimension analysis algorithm derives a dimension for all other quantities involved. Hans-Peter indicated that he believes the QUD could be easily extended to allow reasoning about Dimensions from the point of view of inducing a lattice. For example; [Front Wheel] is a more specific dimension than [Wheel] which is a more specific dimension than [Car Part]. The motivation for this comes from a suggestion Bob Rasmussen made about dimension analysis; i.e., we would like to be able to say things like: 2 [Front Wheel] + 1 [Spare Wheel] = 3 [Wheel] = 3 [Car Part]. This is particularly useful if we want to reason about the consistency of dimensions in quantities involved in constraints or other algebraic expressions. For example: [Front Wheel] + [Front Wheel] = [Front Wheel] but: [Front Wheel] + [Space Whee] = [Wheel] and: [Front Wheel] + [Wheel Hub] = [Car Part] So, the suggestion is simply to look at the problem of specifying analyzable/verifiable partitioning criteria as a kind of dimension analysis problem. My suggestion then would be to explore using the SysML QUD extended for reasoning about the relationships among dimensions as an effective way to specify and analyze partitions. - Nicolas. On 6/13/09 12:52 PM, "Friedenthal, Sanford" wrote: Tim I am going to be out of email contact beginning tomorrow AM until the end of the month. Please send any proposals for a partition to Roger if you feel we have something ready to discuss. I am hoping there is a proposal to provide a minimum capability for partitioning non packageable elements such as properties. We can decide whether it offers significant value to proceed with it or not. I would be happy to present it for you as best I can at the SysML RTF meeting on June 22. If you feel we really don.t have a minimal capability or that the minimal capability is insufficient to add value, then we can defer. Thanks for your help. Sandy From: Friedenthal, Sanford Sent: Tuesday, June 09, 2009 8:43 PM To: 'Rouquette, Nicolas F'; Tim Weilkiens; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: RE: Issue 13928: partition concept - block-like thing Tim, Nicolas Where does this leave us. I think we should work to get a basic capability in and then look at ways to improve it over time. The basic capability should be implementable within the tools constraints. I think the ideas brought forward look very interesting, but personally, I think it would be most productive to provide a simple straightforward base capability that we can start with. Of course, if the base capability is totally inadequate to provide a value add, then we should just defer until we have a more sophisticated capability. What are your thoughts on a starting capability? Does the dependency approach give us a value add or is it too limited. Can we evaluate how compelling this capability is. If not, is there a step up that leverages some of the more sophisticate approaches that Nicolas is proposing. We need to ensure it is compelling in its use, intuitive and implementable. Sandy From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, June 09, 2009 5:57 PM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, What distinguishes your use of dependency relationships for specifying a partition from other uses of dependency relationships for unrelated purposes? In other words, is there a semantics you intend to specify for the string attribute specifying the partitioning criteria? Would this semantics, if any, allow us to tell that a partition of the left wheels of the car and a partition of the right wheels of the car are disjoint partitions of the wheels of the same car and that intersection of the left wheels partition and of the front wheels partition for the same car is precisely the left-front wheel? I was hoping that the answer to these questions would involve the semantics of classifiers and classifier specialization as an effective means of denoting a subset of the extent of a classifier but it seems unlikely that we can pull this off in either approach alone. I hope that there is some clever combination of the two approaches perhaps with another trick that could get us closer to a first-class concept of a partition as a kind of classifier we can specify at M1 and reason about at M0 but the prospects for that happening seem unlikely at this time. -- Nicolas. On 6/9/09 11:30 AM, "Tim Weilkiens" wrote: Nicolas, attached you find an example of the dependency approach. Partition is simply a stereotype extending package with a string attribute for the criteria. The diagram shows two notations of the same partition. I only used presentation options that are possible with MagicDraw. It's no fake. For the real partition we need a special SysML presentation option. The partition should look like a package with it's content. Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, June 09, 2009 6:47 PM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, I recognize that my approach involves crossing M1/M2 levels for specifying the scope of a partition using an association class; i.e., I.ve used an M2 element or a Stereotype when there isn.t an M1 classifier available for typing an association end . e.g., InstanceSpecification, Property, Block, ... The point here being that this approach allows specializing the association class scope. This issue doesn.t affect the use of an association class for specifying the partition of the scope. As an association class, we can specialize a partition to denote the empty partition simply by specializing the association class where the association ends are redefined with zero multiplicity. In the context of specialization, it is legal for a specialized association class to have zero or just one association end and still comply with the constraint that an association must have at least 2 ends in the sense that an association must have 2 ends either directly or by inheritance. I haven.t seen a description of the dependency approach so I would be premature for me to comment on it. - Nicolas. On 6/9/09 5:04 AM, "Tim Weilkiens" wrote: Nicolas, Thanks for all the explanation. Now I much better understand your approach. The multibranch part/shared association in SysML isn't a n-ary association. It's more a presentation option to show different association in a tree layout. I think it is misleading that table 8.2. only shows one association name in the concrete syntax example column. From my understanding these are two associations. How could you create an empty partition? An association class requires at least two associated elements. I think the key problem is that it is not allowed to mix the metalevels. The InstanceSpecification in your example could not be part of the n-ary association. Also stereotypes are not allowed to participate in your association. Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. >With a dependency relationship, you can designate that a given type of Element is involved in a partition; >however, this approach is insufficient to address practical requirements for a partition concept in SysML: > 1. how many of each kind of elements are involved . e.g., partition 2 of the 4 wheels If I have many kinds of a element, I have properties and would include the properties by dependency relationships into the partition. > 2. how to partition elements according to their role attributed in the larger context . e.g., partition the front wheels only; leave out the rear wheels The dependency relationship can directly relate properties. Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, June 09, 2009 9:24 AM To: Friedenthal, Sanford; Tim Weilkiens; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Sandy, About n-ary associations: Indeed, I am stretching SysML 1.1 a bit. SysML is somewhat ambiguous about supporting n-ary associations of some kind. 8.3.1.3 (UML Diagram Elements not Included in SysML Block Definition Diagrams) clearly states that n-ary associations aren.t supported. Ditto for constraint [1] in 8.3.2.2 (Block). However, the notation shown in Table 8.2 for .Multibranch Part/Shared Association. clearly shows an example of a ternary association of some kind. At minimum, this is clearly in contradiction with the intent stated in 8.3.1.3. If the properties were typed by a block, this would then be inconsistent with 8.3.2.2 [1] as well.\ About the notation: There are some limitations in what I can show with MD 16.0 sp1. To show the type of an association end in MD, we have to use a note and include the .type. in the .Element Properties. shown in the note. This is awkward. About association class vs. association: An association class is an objectification of an association relationship; i.e., an instance of an association class is an object reifying an instance of an association, i.e., a link. This objectification means that an association class can participate as an association end in another association or even another association class. However, this kind of modeling is beyond the scope of what MD 16.0 sp1 currently supports as I indicated in the example where I couldn.t show the binary association between the two association classes: VehicleRequirementTestingScope and VehicleRequirementTestPartition. Note that an association class scope (e.g., VehicleRequirementTestingScope) is a neither an M1 nor an M2 level classifier because its association end classifiers can be at M1 (e.g., Wheel, Car) or M2 (e.g., Requirement, FlowPort, ...). In straddling the M1/M2 boundary, an association class scope resembles a stereotype but there are important differences between the two: an association class scope is meant to be instantiated to designate the set of instances defining the extent of a scope instance; a stereotype is instantiated as part of applying the stereotype to an instance of the metaclass it extends. In contrast, an association class partition (e.g., VehicleRequirementTestPartition) is in M1 and its association ends are also in M1 (e.g., WheelRole, FlowPortRole, etc...). The association class partition and its association end classifier roles are an M1 level normalization of the hybrid M1/M2 association class scope whose association end classifiers can be in M1 or M2 as explained above. This is important to ensure that subsetting an assciation class partition is semantically equivalent to specializing in the sense of classifier specialization in UML and SysML. Is all of this really necessary? It depends on how do we want to specify the semantics of a partition as a subset of an explicitly defined set of elements in a model. In the UML and SysML, we have powerful mechanisms to construct sets of things; however, we are much more limited in our ability to construct sets of sets; that.s where associations & association classes are very useful in that they provide a decent approximation for the notion of a set of sets as a composition of sets (i.e., the association ends) that can be subsetted by specialization. Since a partition needs to be related to the scope of the elements it is subsetting, both partition and scope must be association classes rather than regular associations. In the example, if either of VehicleRequirementTestPartition or VehicleRequirementTestingScope were plain associations, then we wouldn.t be able to unambiguously establish a binary association between them as it would be otherwise impossible to distinguish the association ends of the binary relationship from those of the n-ary associations. - Nicolas. On 6/8/09 7:43 PM, "Friedenthal, Sanford" wrote: Nicolas SysML does not currently support n-ary associations. Also, some parts of the figure are not clear to me. I am not familiar with not having a type at the end of the association such as the case with the Flow Port or constraintProperty. Also, what functionality does the association class provide over an association (i.e. do you leverage the features of the association class)? Are the comment symbols intended to be comments, or the class symbol of the n-ary association class. Sandy From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, June 08, 2009 9:57 PM To: Friedenthal, Sanford; Tim Weilkiens; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Sandy, I.ve applied the powertype approach to an expanded car example to partition items that aren.t classifiers or packageable elements (e.g., properties). See attached picture. First, a partition is a special kind of association class. An instance of an association class partition is an object reifying the extent of the partition . i.e., the slot values corresponding to the association end roles. The main benefit of this approach is that specifying a subset of a partition is logically equivalent to specializing the association class partition. By the nature of an AssociationClass, it would seem that this approach would be limited to partitioning elements of Type kind; this isn.t the case. Second, a partition only makes sense if we have a scope of elements we can partition. The attached figure shows an example of a VehicleRequirementTestingScope as an n-ary AssociationClass specifying the scope of heterogeneous kinds of elements we can include in any VechicleRequirementTestPartition, a special kind of n-ary AssociationClass whose association ends are classifier roles reifying the inclusion of an element in the partition. In this approach, powertypes are one of several mechanisms available in the UML and SysML for specializing an n-ary AssociationClass partition as an effective means for unambiguously relating different partitions whose extent can be disjoint, overlapping or wholy included in another (e.g., FrontWheelRequirementTestPartition is a subset of the VehicleRequirementTestPartition). That is, I.m advocating for taking advantage of all of the specialization machinery we have available in the UML & SysML to provide users the flexibility to specify partitions precisely and unambiguously. I do recognize that there are practical limitations to this approach, mainly due to gaps in existing tools . e.g. See the red notes in the diagram. - Nicolas. P.S. Roger . I couldn.t login on the sysml wiki to upload the example corresponding to the image: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf2:groups:partition_concept On 6/8/09 12:50 PM, "Friedenthal, Sanford" wrote: Doesn.t the powertype approach still limit the items being partitioned to be classifiers. How is it applied to properties, instance specifications, and other non-packageable elements. From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, June 08, 2009 3:39 PM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, With a dependency relationship, you can designate that a given type of Element is involved in a partition; however, this approach is insufficient to address practical requirements for a partition concept in SysML: how many of each kind of elements are involved . e.g., partition 2 of the 4 wheels how to partition elements according to their role attributed in the larger context . e.g., partition the front wheels only; leave out the rear wheels The powertype approach focuses on leveraging existing mechanisms for specifying a view language of partitions organized in a lattice. An n-ary Association represents a partition based on association ends instead of dependency relationships. An association end provides the capability to specify a cardinality restriction and individual association ends can be further partitioned by refinement . e.g., (1). Reifying the n-ary Association into a first-class n-ary AssociationClass provides a capability to organize partitions in a specialization lattice .e.g., (2). An n-ary AssociationClass as a partition construct allows specifying: the largest partition of all elements the empty partition of no elements the relationship between intermediate partitions (i.e., specialization means subsetting) the overlap amongst partitions as the overlap of their association ends The Car Example illustrates these notions: The CarDomain includes: Engine & Wheel The CarAssembly partition view defines roles the elements of the CarDomain can have in a partition: an EngineRole is a a partition classifier designating an Engine (this could be a dependency or a binary association) a WheelRole is a partition classifier designating a Wheel (ditto) a CarAssembly is an n-ary AssociationClass whose association ends are EngineRole and WheelRole. To specify sub-partitions of the CarAssembly partition context, we need a taxonomy of partition roles. This is where powertype concepts are useful to specify distinct role hierarchies, e.g.: -WheelRole = LeftWheelRole + RightWheelRole {complete, disjoint} (generalization set linked to a LeftRightRole powertype) -WheelRole = FrontWheelRole + RearWheelRole {complete, disjoint} (generalization set linked to a FrontRearRole powertype) With these role taxonomies, we can specify fine-grained partitions that can be related to other partitions unambiguously: FrontLeftWheelRole is a specialization of both LeftWheelRole & FrontWheelRole FrontRightWheelRole is a specialization of both RightWheelRole & FrontWheelRole FrontLeftWheelRole + FrontRightWheelRole = FrontWheelRole - Nicolas. On 6/8/09 6:55 AM, "Tim Weilkiens" wrote: Nicolas, > Suppose that we want to specify a partition that involves a set of classifiers and the behavioral feature parameters and activity parameters typed by any of these classifiers. I > hope you will agree that this kind of partition is not directly representable within the language All three elements are named elements. Therefore we can create a partition of named elements. The sysml view concept could create a kind of partition of packageable elements. If we change the grouping relationship from import to dependency we have a partition of named elements. Another idea is to use the dependency relationship without a package. Although most tools doesn't support it, the dependency relationship allows many clients and suppliers. A semantically problem is to answer who should be the client and who is the supplier in a partition. Such kind of ordering makes no sense to me. However the trace relationship as a standardized UML stereotype of the dependency specialization abstraction mentions "the directionality of the dependency can often be ignored". Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, June 04, 2009 9:37 AM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, This is a very good question; the short answer is yes but this requires some explanation. We need to .jump. outside the language (UML, SysML) in order to specify a concept of a partition as an arbitrary subset of uml::Element objects; i.e., an arbitrary partition of uml::Element objects is a second-order subset. A first-order subset is whatever kind of subset we can specify using the nominal structuring mechanisms available in the language, e.g.: a Namespace owns NamedElements, a Package owns PackageableElements a Classifier owns Features a BehavioralFeatures owns Parameters For these concepts, we can specify a partition by subsetting the nominal structure of the concept as specified in UML/SysML/... For example, a partition of a Namespace is a subset of Namespace::member : NamedElement[0..*] a partition of a Package is a subset of Package::packagedElement : PackageableElement[0..*] a partition of a Classifier is a subset of Classifier::feature : Feature[0..*] a partition of a BehavioralFeature is a subset of BehavioralFeature::ownedParameter : Parameter[0..*] Some subsets have no 1st order nominal representation in the uml; here are some notorious examples: an Activity does not .own. its ActivityNodes/Edges -- see: http://www.omg.org/issues/issue8668.txt there is no nominal distinction between the parameters of an Activity and non-parameter ActivityNodes; both are disjoint subsets of Activity::node : ActivityNode[0..*] which, as issue 8668 clarified, is not a composition relationship like the above examples. Suppose that we want to specify a partition that involves a set of classifiers and the behavioral feature parameters and activity parameters typed by any of these classifiers. I hope you will agree that this kind of partition is not directly representable within the language; i.e., we have to jump outside the UML in order to specify this kind of partition, e.g., with the help of an OCL constraint; in other words, an arbitrary partition is fundamentally a second-order concept for the UML. So, the trick that I.ve used is to define a convention to reify a partition as a second-order structural concept. That is, I used a .Wheel Role. as a reification of a second-order specification about the fact that our partition is referring to a particular .Wheel. which .Wheel Role. designates with the help of a directed, non-navigable association. If we need to partition things that aren.t classifiers, then we simply need to reify a second order specification that allows us to designate the things we want to include in our partition . classifiers and non-classifiers. However, the danger with this approach is that we have now opened the door for Russell.s paradox; i.e., a partition that partitions itself. To avoid Russell.s paradox, it is important to verify that the partitions form a partial ordering of subsets of the elements in the model and that this partial order has the topological structure of a lattice where each pair of element has a lower element and an upper element. I haven.t found a readable reference on the computational complexity of constructing the lattice for a partial order relation. It seems that the general problem is NP complete: http://portal.acm.org/citation.cfm?id=980030 but the problem is quite relevant to information modeling. In fact, I tried as an exercise a few years ago to design a simple but computationally efficient technique for constructing the lattice for a potentially large partial order relation in Alloy (http://osdir.com/ml/lang.alloy.general/2006-02/msg00001.html) Since then, I.ve improved on this idea quite a bit (I called it .no knock-knock jokes. when I discussed it with Dan Jackson.s students back in 2007). With recent optimizations, I can analyze various partial ordering relations in the UML metamodel with Alloy in a few seconds even though these relations can sometimes involve hundreds of tuples. The point is that if we have the right perspective for conceptualizing the notion of a partition for UML-like models, we can avoid falling into Russell.s trap. Alloy is certainly useful if used properly to do that but I consider this to be a tool to help us design better specifications, not the means by which we have to necessarily implement the spec. - Nicolas. On 6/2/09 10:37 PM, "Tim Weilkiens" wrote: Nicolas, Thanks for the clarification and the links to further study material. I'll check that. Is it possible to extend your approach somehow to include non-classifiers in partitions? I think it is important that partitions are more generic and can group more or less any model element. Maybe we need two concepts: a generic grouping mechanism and a block-based grouping mechanism. I think using blocks to group related elements is similar to create system configurations. Tim > -----Original Message----- > From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: Tuesday, June 02, 2009 8:00 AM > To: Tim Weilkiens; Friedenthal, Sanford; Russell.Peak@gatech.edu > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > Rasmussen, Robert D; conrad.bock@nist.gov; Ingham, Michel D > Subject: RE: Issue 13928: partition concept - block-like thing > > Tim, > > Yes; however, Marc and I spent several hours discussing this > example that he and Russell Peak had previously discussed as > well. Marc had a very simple illustration of the idea of a > partition with a combination of composition and aggregation > associations. However, this approach has obvious problems > since there are no constraints enforcing that the scope of a > partition specified by aggregation is in fact a subset of the > elements defined in a context by composition. > > The fundamental issue here is that the UML is a nominal > specification language: subtyping is nominal, subsetting is > nominal, redefinition is nominal -- i.e., we can only > specialize a named classifier; we can only subset a named > property, we can only redefine a named feature, etc... > > There is an excellent discussion of the difference between > nominal vs. structural subtyping in the context of the > Modelica language here: > > http://www.modelica.org/events/modelica2006/Proceedings/sessio > ns/Session3c3.pdf > > For Java, there is a proposal for integrating nominal and > structural subtyping here: > > http://www.cs.cmu.edu/~donna/public/ecoop08slides.pdf > http://www.cs.cmu.edu/~donna/public/ecoop08.pdf > > Based on these ideas, I've revised Marc's example for > partitioning different sets of wheels for a car -- eg., front > wheels vs. all 4 wheels. > > My motivation is that I want to stay within the semantics of > the UML to specify the fact that a partition is really a > subset of parts defined in a classifier context (e.g., a > structured block in SysML). > > For example, I want to make sure that a UML/SysML tool can > verify that the intersection of the "front wheels" partition > with the "left wheels" partition should be a set consisting > of just the "left front wheel". Similarly, the intersection > of the "front wheels" partition with the "right wheels" > partition should be a set consisting of just the "right front > wheel". If you were to take the union of these two sets, a > tool should be able to verify that this union is equivalent > to the subset of parts in the "front wheels" partition. > > With this guiding principle in mind, I refactored Marc > example as shown in the attached model (MD 16.0 sp1). > > - Nicolas. > > > > > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Monday, June 01, 2009 9:45 PM > > To: Rouquette, Nicolas F; Friedenthal, Sanford; > > Russell.Peak@gatech.edu > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > Rasmussen, > > Robert D; conrad.bock@nist.gov; Ingham, Michel D > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > Nicolas, > > > > If I understand your example correctly your approach limits > partitions > > to classifiers. > > An element that is part of the partition requires a generalization > > relationship. > > Is that correct? > > > > Tim > > > > > -----Original Message----- > > > From: Rouquette, Nicolas F > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > > >: Friday, May 29, 2009 9:43 PM > > > To: Tim Weilkiens; Friedenthal, Sanford; Russell.Peak@gatech.edu > > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > > >Rasmussen, Robert D; conrad.bock@nist.gov; Ingham, Michel D > > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > > > The latest version of the bundle is: > > > JPL-OMG-RFI-05-29-2009.tar Conrad's email system rejected > it because > > > it it too big (6Mb). > > > > > > This tar contains this: > > > > > > jpl-omg-rfi.mdzip > > > JPL-OMG-RFI-05-29-2009.html > > > JPL-OMG-RFI-05-29-2009_files/ > > > > > > In the MD model, navigate to the package: > > > > > > Examples::Car::4) Structural Entities & > Relationships::Alternative4 > > > > > > > > > Look at the classes: "Front Wheel" and "Rear Wheel" as > examples of > > > partitions of the subset of the wheels of a car. > > > In this example, a partition is modeled as a > specialization of the > > > set of wheels that have a role in the context of a particular car. > > > > > > What makes partitioning a non-trivial issue is that we are really > > > talking about modeling a partition as a subset > relationship between > > > a set of entities (e.g., wheels) and the set of roles (e.g., the > > > wheels of a particular car) that a subset of these > entities have for > > > another entity (e.g., a car) > > > > > > The approach here is based on the notion of UML powertype and > > > generalization set. > > > The approach is inspired, in part, based on the way Conrad Bock > > > talks about the model of composition in UML2 and in part > on equating > > > the notion of a partition as a kind of categorical relationship > > > according to Terry Halpin. > > > > > > - Nicolas. > > > > > > > -----Original Message----- > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > Sent: Friday, May 29, 2009 12:03 PM > > > > To: Rouquette, Nicolas F; Friedenthal, Sanford; > > > > Russell.Peak@gatech.edu > > > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > > > Rasmussen, > > > > Robert D; conrad.bock@nist.gov; Ingham, Michel D > > > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > > > > > Nicolas, > > > > > > > > I've received all three versions of the bundle. Are they > > > all the same? > > > > > > > > I had a look on the first one. But I couldn't find the > partition > > > > concept in your model. > > > > Which diagram/package shows your approach? > > > > > > > > Tim > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rouquette, Nicolas F > > > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > > > > > Sent: Friday, May 29, 2009 8:05 PM > > > > > To: Friedenthal, Sanford; Tim Weilkiens; > Russell.Peak@gatech.edu > > > > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > > > > > Rasmussen, Robert D; conrad.bock@nist.gov; Ingham, Michel D > > > > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > > > > > > > This is a tar file. > > > > > Does it pass through the firewalls? > > > > > > > > > > We need a shared repository instead of fighting spam filters. > > > > > > > > > > - Nicolas. > > > > > > > > > Date: Sat, 11 Jul 2009 08:10:09 -0400 From: "Friedenthal, Sanford" Subject: RE: Issue 13928: partition concept - block-like thing To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , Alan Moore Thread-Topic: Issue 13928: partition concept - block-like thing Thread-Index: AcnQ4duZ/JcJi1KEQ7a9XBVcf54daAApy0NwAATHzLAAAK4PQAAMUyXAAC1hRCAC6iFV8AABEYpAAA+dkYAAFLyRkAAFs6EgAB4qeCAADpoFsAANZ44YAAAf5UAAG0/DgAAPkybAAAYSExAAAgoDQAAA7UUwAKnC/aAAAabcEAAy4IbwADajXEwA1g1WgAAMTgBpAABYtWAADNpITwABT3lQAAoclasACRFWUAAKm44sAAOCXTAAB1JymgAFpamgAL8RfrAAAd5lRgAAYCyAAAMiXh0Aj2744ACEnOLwAeLVmSAADVH+kAAJGxOgADXs7GAAAH9HoABdApAgAAdEgPABDC8/8AAAjNSgAEejWOAAB1OX4AAFH3pwAAAv6GAAX7KUAAAAyMFwAADnCYA= Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Michael My responses below. Tim Feel free to modify. Sandy From: Chonoles, Michael J Sent: Saturday, July 11, 2009 7:53 AM To: Tim Weilkiens; Friedenthal, Sanford; Alan Moore Cc: sysml-rtf@omg.org Subject: RE: Issue 13928: partition concept - block-like thing Lots of questions about partitions 1) Can a partition have a sub-partition. To have practical value as an organizing and presenting approach, I believe I need to have the ability to have some multi-layered organization. If partitions can (or cannot) have sub-partitions, it needs to be clear. [sf] A partition is like any other model element, so yes a partition can be dependent on a subpartition. This should be added to the proposed resolution. 2) Can a partition be owned by something else?, like a package? Are the elements in the partition, even if not owned by the partition, owned by the package? If so (or not) please make it clear a. For example, if a comment is owned by the partition, is this transititively owned by the partition.s package? b. Can partitions be not owned by anything? [sf] The ownership is not modified by the partition. That is the fundamental assertion. The model element in the partition retains its original ownership. 3) Please also make it clear that if a element is required to be owned by something (e.g., such as a block) but is not . placing it in a partition does what. Does it automatically make it owned by the owner of the partition and allowed, or does it still make it illegal. [sf] Refer to above. 4) I.d prefer a non-package looking notation to more strongly indicate the lack of ownership . perhaps for example, a dashed border for a partition. [sf] Good idea. Suggest we change the notation as indicated. 5) I.m not sure what use it is to bring it elements with the notation such as «association»Name of the Assocation. Does this mean that the partition can.t use the normal package diagram notation? i.e., showing an association between two blocks? [sf] The intent was to make provisons to show individual elements that are not nodes, but there is nothing to preclude the blocks coming into the partition if that is the intent. a. Does this give us a way of bringing in a diagram into a partition/view? [sf] The model element that represents the diagram frame can be part of the partition. 6) One of the defects with view (and probably with partition) is the inability to isolate an element in context. So if a block is brought into a partition/view, it is unclear which aspects of the block is of interest. For example, if I bring in a block to a partition/view, do I need to explicitly bring in the interesting parts, all the parts, no parts..Is each composition relationship and another square box in the partition/view. [sf] It is a dependency relationship. If you are dependent on a block, you are implicitly dependent on the features of the block. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Saturday, July 11, 2009 7:27 AM To: Friedenthal, Sanford; Alan Moore Cc: sysml-rtf@omg.org Subject: RE: Issue 13928: partition concept - block-like thing Attached an update of the resolution that reflects Alans comments: * Partitions own the dependency relationships. * Example for showing an association as a member of a partition -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Thursday, July 09, 2009 3:35 PM To: Alan Moore; Tim Weilkiens Subject: RE: Issue 13928: partition concept - block-like thing Alan Thanks. This is a view like concept, but it enables one to include non-packageable elements and edges. It also does not impose the constraint that it conform to a viewpoint. As you would see, a View is extended from this. Bottom line capability is that this provides a notation for grouping any elements without imposing ownership. Tim, Can you address Alans comments and provide an update to the group (note that the updates reflect comments from Alan). Thx. Sandy From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Thursday, July 09, 2009 9:31 AM To: Friedenthal, Sanford Cc: Tim Weilkiens Subject: RE: Issue 13928: partition concept - block-like thing Looks a bit clunky to me . depends on how badly you want this facility I guess. I thought the whole point of view using import relationships was so that elements could become members of the view and hence be shown in diagrams representing the view using just their names. A couple of other points . can edges (association for example) be shown inside the partition symbol or just nodes? Also, it might be worth insisting that partitions own the dependencies that identify their elements, just to keep things tidy. Alan. From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Thursday, July 09, 2009 12:02 PM To: Alan Moore Cc: Tim Weilkiens Subject: FW: Issue 13928: partition concept - block-like thing Alan This proposal is for a partition which groups elements without any ownership. It can include any element including not packageable elements. Your thoughts. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Thursday, July 09, 2009 3:31 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, ok. Attached the originally resolution. I'll upload it to our wiki. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Tuesday, July 07, 2009 11:21 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim Disregard my previous comments. Somehow I missed the last section . Please reissue as you originally had it. Thanks. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, July 07, 2009 5:11 PM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, my comments on your comments. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Thursday, July 02, 2009 3:05 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim Some comments. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Thursday, July 02, 2009 5:39 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Attached you find the update of the resolution. It includes the callout notation and a note about fig b.27 and 7.3. -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Tuesday, June 30, 2009 3:15 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Ok. fair enough. You will need to define the relationship between the partition and the model element that is partitioned (i.e. <> or <>) and refer to this in the callout notation. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, June 30, 2009 9:04 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, Callout notation seems to be a better choice than my proposal for the partition notation. Good idea. In that case I don't think it increases the complexity. The callout notation is very common throughout SysML. It'll be easy for tool vendors and users to adopt the new notation. I'll change the resolution soon and send an update. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Monday, June 29, 2009 1:23 PM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim I recommend we not confuse activity partition with partition, since they have very different semantics. You raise a good point that we may want to see what partitions a model element is part of. If we wanted to do this, we could use something similar to what we do with callout notations and compartment notations for allocations to show what is on either end of the relationship. However, my sense is that may add complexity to our baseline and perhaps we should defer this. Your thoughts. As part of the resolution rationale, we should point out that Fig b.27 and 7.3 are now valid. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Monday, June 29, 2009 3:08 AM To: Friedenthal, Sanford; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sandy, Thanks for the congratulations. Everybody is in a good shape besides to be tired out I hope Costa Rica was successful and achieved some more big steps forward for SysML and Systems Engineering. Figure 7.2. shows how to display the relation of a named element to a partition. The whole block is related to partion1 and partition2. The value x is related to partition1. The notation is based on the partition notation for activities. See fig. 12.58 a) in the UML 2.2 specification (or my attachment). You're right that fig B.27 isn't correct. It shows packageable elements inside the view which means they are members of the view. But views don't have members despite constraints, comments and import relationships. They import packageable elements. The same figure appears in chapter 7 as fig 7.3. The resolution for issue 13928 proposes a diagram extension that shows related elements of a partition inside the partition symbol like members. Since the view is a specialized partition this would be also valid for views. In that scenario B.27 and fig. 7.3 are correct. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Monday, June 29, 2009 2:37 AM To: Tim Weilkiens; Rouquette, Nicolas F Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Tim Sorry for being slow to respond. First of all, CONGRATULATIONS on your new child. I hope the mother and child are doing well (along with the father). Relative to this proposal, it looks quite good, except one item I did not understand was Figure 7.2 and its caption. Can you clarify. Also, I suspect this change may impact the figure B.27 in the HSUV example that shows a view (I think currently it is incorrect since it includes packageable elements in the view). If you agree, please coordinate with Rick Steiner on this change. Thanks. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Friday, June 19, 2009 8:46 AM To: Tim Weilkiens; Rouquette, Nicolas F; Friedenthal, Sanford Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Attached you find the first version of a proposal for the simple partition construct. -------------------------------------------------------------------------------- From: Tim Weilkiens Sent: Tuesday, June 16, 2009 9:01 PM To: 'Rouquette, Nicolas F'; Friedenthal, Sanford Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: RE: Issue 13928: partition concept - block-like thing Sorry for being offline for a while. I had my focus on another issue: I became father again I'll prepare a proposal for the simple approach. We still should consider the other approaches. But I agree with Sandy that we need some kind of a baseline to get on the road with that topic. Thinking about the different approaches I asked myself how to define the concept of a partition. Do you have one? Is there a standardized definition somewhere? I've only found very generic definitions like "A part or section into which something has been divided." I'm looking for something more concrete. I think the simple approach is more like a group while Nicolas approach is more like a real partition. But it's more a feeling than based on some criteria. Regardless which approach we take I'm a little bit afraid that it goes beyond the scope of a RTF. It's not a bugfix, but a complete new feature. What do you think? Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, June 14, 2009 12:24 AM To: Friedenthal, Sanford; Tim Weilkiens Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: Re: Issue 13928: partition concept - block-like thing Fine with me. - Nicolas. On 6/13/09 1:55 PM, "Friedenthal, Sanford" wrote: Nicolas Good thought. I still would like Tim to propose the simpler solution if he feels it makes sense as we evaluate other alternatives in parallel. If nothing else, we can establish a simple baseline from which to evaluate the alternatives in terms of capability, ease of use, ease of implementation. Sandy From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Saturday, June 13, 2009 4:43 PM To: Friedenthal, Sanford; Tim Weilkiens Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D; Russell Peak; Hans-Peter.de.Koning@esa.int; ESPINOZA Huascar 218344 Subject: Re: Issue 13928: partition concept - block-like thing Hi, I.ve been ambivalent about where the discussions about the two approaches to a partition concept leave us. Tim.s approach is clearly simpler than mine but I there are problems with both. After discussing the final changes to the SysML QUD conceptual model with Roger and Hans-Peter, It occurred to me that there may be one third alternative we haven.t explored yet but seems possible: In the QUD, a user can choose a set of QuantityKinds as the base Dimensions. >From there, the dimension analysis algorithm derives a dimension for all other quantities involved. Hans-Peter indicated that he believes the QUD could be easily extended to allow reasoning about Dimensions from the point of view of inducing a lattice. For example; [Front Wheel] is a more specific dimension than [Wheel] which is a more specific dimension than [Car Part]. The motivation for this comes from a suggestion Bob Rasmussen made about dimension analysis; i.e., we would like to be able to say things like: 2 [Front Wheel] + 1 [Spare Wheel] = 3 [Wheel] = 3 [Car Part]. This is particularly useful if we want to reason about the consistency of dimensions in quantities involved in constraints or other algebraic expressions. For example: [Front Wheel] + [Front Wheel] = [Front Wheel] but: [Front Wheel] + [Space Whee] = [Wheel] and: [Front Wheel] + [Wheel Hub] = [Car Part] So, the suggestion is simply to look at the problem of specifying analyzable/verifiable partitioning criteria as a kind of dimension analysis problem. My suggestion then would be to explore using the SysML QUD extended for reasoning about the relationships among dimensions as an effective way to specify and analyze partitions. - Nicolas. On 6/13/09 12:52 PM, "Friedenthal, Sanford" wrote: Tim I am going to be out of email contact beginning tomorrow AM until the end of the month. Please send any proposals for a partition to Roger if you feel we have something ready to discuss. I am hoping there is a proposal to provide a minimum capability for partitioning non packageable elements such as properties. We can decide whether it offers significant value to proceed with it or not. I would be happy to present it for you as best I can at the SysML RTF meeting on June 22. If you feel we really don.t have a minimal capability or that the minimal capability is insufficient to add value, then we can defer. Thanks for your help. Sandy From: Friedenthal, Sanford Sent: Tuesday, June 09, 2009 8:43 PM To: 'Rouquette, Nicolas F'; Tim Weilkiens; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: RE: Issue 13928: partition concept - block-like thing Tim, Nicolas Where does this leave us. I think we should work to get a basic capability in and then look at ways to improve it over time. The basic capability should be implementable within the tools constraints. I think the ideas brought forward look very interesting, but personally, I think it would be most productive to provide a simple straightforward base capability that we can start with. Of course, if the base capability is totally inadequate to provide a value add, then we should just defer until we have a more sophisticated capability. What are your thoughts on a starting capability? Does the dependency approach give us a value add or is it too limited. Can we evaluate how compelling this capability is. If not, is there a step up that leverages some of the more sophisticate approaches that Nicolas is proposing. We need to ensure it is compelling in its use, intuitive and implementable. Sandy From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, June 09, 2009 5:57 PM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, What distinguishes your use of dependency relationships for specifying a partition from other uses of dependency relationships for unrelated purposes? In other words, is there a semantics you intend to specify for the string attribute specifying the partitioning criteria? Would this semantics, if any, allow us to tell that a partition of the left wheels of the car and a partition of the right wheels of the car are disjoint partitions of the wheels of the same car and that intersection of the left wheels partition and of the front wheels partition for the same car is precisely the left-front wheel? I was hoping that the answer to these questions would involve the semantics of classifiers and classifier specialization as an effective means of denoting a subset of the extent of a classifier but it seems unlikely that we can pull this off in either approach alone. I hope that there is some clever combination of the two approaches perhaps with another trick that could get us closer to a first-class concept of a partition as a kind of classifier we can specify at M1 and reason about at M0 but the prospects for that happening seem unlikely at this time. -- Nicolas. On 6/9/09 11:30 AM, "Tim Weilkiens" wrote: Nicolas, attached you find an example of the dependency approach. Partition is simply a stereotype extending package with a string attribute for the criteria. The diagram shows two notations of the same partition. I only used presentation options that are possible with MagicDraw. It's no fake. For the real partition we need a special SysML presentation option. The partition should look like a package with it's content. Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, June 09, 2009 6:47 PM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, I recognize that my approach involves crossing M1/M2 levels for specifying the scope of a partition using an association class; i.e., I.ve used an M2 element or a Stereotype when there isn.t an M1 classifier available for typing an association end . e.g., InstanceSpecification, Property, Block, ... The point here being that this approach allows specializing the association class scope. This issue doesn.t affect the use of an association class for specifying the partition of the scope. As an association class, we can specialize a partition to denote the empty partition simply by specializing the association class where the association ends are redefined with zero multiplicity. In the context of specialization, it is legal for a specialized association class to have zero or just one association end and still comply with the constraint that an association must have at least 2 ends in the sense that an association must have 2 ends either directly or by inheritance. I haven.t seen a description of the dependency approach so I would be premature for me to comment on it. - Nicolas. On 6/9/09 5:04 AM, "Tim Weilkiens" wrote: Nicolas, Thanks for all the explanation. Now I much better understand your approach. The multibranch part/shared association in SysML isn't a n-ary association. It's more a presentation option to show different association in a tree layout. I think it is misleading that table 8.2. only shows one association name in the concrete syntax example column. From my understanding these are two associations. How could you create an empty partition? An association class requires at least two associated elements. I think the key problem is that it is not allowed to mix the metalevels. The InstanceSpecification in your example could not be part of the n-ary association. Also stereotypes are not allowed to participate in your association. Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. >With a dependency relationship, you can designate that a given type of Element is involved in a partition; >however, this approach is insufficient to address practical requirements for a partition concept in SysML: > 1. how many of each kind of elements are involved . e.g., partition 2 of the 4 wheels If I have many kinds of a element, I have properties and would include the properties by dependency relationships into the partition. > 2. how to partition elements according to their role attributed in the larger context . e.g., partition the front wheels only; leave out the rear wheels The dependency relationship can directly relate properties. Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, June 09, 2009 9:24 AM To: Friedenthal, Sanford; Tim Weilkiens; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Sandy, About n-ary associations: Indeed, I am stretching SysML 1.1 a bit. SysML is somewhat ambiguous about supporting n-ary associations of some kind. 8.3.1.3 (UML Diagram Elements not Included in SysML Block Definition Diagrams) clearly states that n-ary associations aren.t supported. Ditto for constraint [1] in 8.3.2.2 (Block). However, the notation shown in Table 8.2 for .Multibranch Part/Shared Association. clearly shows an example of a ternary association of some kind. At minimum, this is clearly in contradiction with the intent stated in 8.3.1.3. If the properties were typed by a block, this would then be inconsistent with 8.3.2.2 [1] as well.\ About the notation: There are some limitations in what I can show with MD 16.0 sp1. To show the type of an association end in MD, we have to use a note and include the .type. in the .Element Properties. shown in the note. This is awkward. About association class vs. association: An association class is an objectification of an association relationship; i.e., an instance of an association class is an object reifying an instance of an association, i.e., a link. This objectification means that an association class can participate as an association end in another association or even another association class. However, this kind of modeling is beyond the scope of what MD 16.0 sp1 currently supports as I indicated in the example where I couldn.t show the binary association between the two association classes: VehicleRequirementTestingScope and VehicleRequirementTestPartition. Note that an association class scope (e.g., VehicleRequirementTestingScope) is a neither an M1 nor an M2 level classifier because its association end classifiers can be at M1 (e.g., Wheel, Car) or M2 (e.g., Requirement, FlowPort, ...). In straddling the M1/M2 boundary, an association class scope resembles a stereotype but there are important differences between the two: an association class scope is meant to be instantiated to designate the set of instances defining the extent of a scope instance; a stereotype is instantiated as part of applying the stereotype to an instance of the metaclass it extends. In contrast, an association class partition (e.g., VehicleRequirementTestPartition) is in M1 and its association ends are also in M1 (e.g., WheelRole, FlowPortRole, etc...). The association class partition and its association end classifier roles are an M1 level normalization of the hybrid M1/M2 association class scope whose association end classifiers can be in M1 or M2 as explained above. This is important to ensure that subsetting an assciation class partition is semantically equivalent to specializing in the sense of classifier specialization in UML and SysML. Is all of this really necessary? It depends on how do we want to specify the semantics of a partition as a subset of an explicitly defined set of elements in a model. In the UML and SysML, we have powerful mechanisms to construct sets of things; however, we are much more limited in our ability to construct sets of sets; that.s where associations & association classes are very useful in that they provide a decent approximation for the notion of a set of sets as a composition of sets (i.e., the association ends) that can be subsetted by specialization. Since a partition needs to be related to the scope of the elements it is subsetting, both partition and scope must be association classes rather than regular associations. In the example, if either of VehicleRequirementTestPartition or VehicleRequirementTestingScope were plain associations, then we wouldn.t be able to unambiguously establish a binary association between them as it would be otherwise impossible to distinguish the association ends of the binary relationship from those of the n-ary associations. - Nicolas. On 6/8/09 7:43 PM, "Friedenthal, Sanford" wrote: Nicolas SysML does not currently support n-ary associations. Also, some parts of the figure are not clear to me. I am not familiar with not having a type at the end of the association such as the case with the Flow Port or constraintProperty. Also, what functionality does the association class provide over an association (i.e. do you leverage the features of the association class)? Are the comment symbols intended to be comments, or the class symbol of the n-ary association class. Sandy From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, June 08, 2009 9:57 PM To: Friedenthal, Sanford; Tim Weilkiens; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Sandy, I.ve applied the powertype approach to an expanded car example to partition items that aren.t classifiers or packageable elements (e.g., properties). See attached picture. First, a partition is a special kind of association class. An instance of an association class partition is an object reifying the extent of the partition . i.e., the slot values corresponding to the association end roles. The main benefit of this approach is that specifying a subset of a partition is logically equivalent to specializing the association class partition. By the nature of an AssociationClass, it would seem that this approach would be limited to partitioning elements of Type kind; this isn.t the case. Second, a partition only makes sense if we have a scope of elements we can partition. The attached figure shows an example of a VehicleRequirementTestingScope as an n-ary AssociationClass specifying the scope of heterogeneous kinds of elements we can include in any VechicleRequirementTestPartition, a special kind of n-ary AssociationClass whose association ends are classifier roles reifying the inclusion of an element in the partition. In this approach, powertypes are one of several mechanisms available in the UML and SysML for specializing an n-ary AssociationClass partition as an effective means for unambiguously relating different partitions whose extent can be disjoint, overlapping or wholy included in another (e.g., FrontWheelRequirementTestPartition is a subset of the VehicleRequirementTestPartition). That is, I.m advocating for taking advantage of all of the specialization machinery we have available in the UML & SysML to provide users the flexibility to specify partitions precisely and unambiguously. I do recognize that there are practical limitations to this approach, mainly due to gaps in existing tools . e.g. See the red notes in the diagram. - Nicolas. P.S. Roger . I couldn.t login on the sysml wiki to upload the example corresponding to the image: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf2:groups:partition_concept On 6/8/09 12:50 PM, "Friedenthal, Sanford" wrote: Doesn.t the powertype approach still limit the items being partitioned to be classifiers. How is it applied to properties, instance specifications, and other non-packageable elements. From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, June 08, 2009 3:39 PM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, With a dependency relationship, you can designate that a given type of Element is involved in a partition; however, this approach is insufficient to address practical requirements for a partition concept in SysML: how many of each kind of elements are involved . e.g., partition 2 of the 4 wheels how to partition elements according to their role attributed in the larger context . e.g., partition the front wheels only; leave out the rear wheels The powertype approach focuses on leveraging existing mechanisms for specifying a view language of partitions organized in a lattice. An n-ary Association represents a partition based on association ends instead of dependency relationships. An association end provides the capability to specify a cardinality restriction and individual association ends can be further partitioned by refinement . e.g., (1). Reifying the n-ary Association into a first-class n-ary AssociationClass provides a capability to organize partitions in a specialization lattice .e.g., (2). An n-ary AssociationClass as a partition construct allows specifying: the largest partition of all elements the empty partition of no elements the relationship between intermediate partitions (i.e., specialization means subsetting) the overlap amongst partitions as the overlap of their association ends The Car Example illustrates these notions: The CarDomain includes: Engine & Wheel The CarAssembly partition view defines roles the elements of the CarDomain can have in a partition: an EngineRole is a a partition classifier designating an Engine (this could be a dependency or a binary association) a WheelRole is a partition classifier designating a Wheel (ditto) a CarAssembly is an n-ary AssociationClass whose association ends are EngineRole and WheelRole. To specify sub-partitions of the CarAssembly partition context, we need a taxonomy of partition roles. This is where powertype concepts are useful to specify distinct role hierarchies, e.g.: -WheelRole = LeftWheelRole + RightWheelRole {complete, disjoint} (generalization set linked to a LeftRightRole powertype) -WheelRole = FrontWheelRole + RearWheelRole {complete, disjoint} (generalization set linked to a FrontRearRole powertype) With these role taxonomies, we can specify fine-grained partitions that can be related to other partitions unambiguously: FrontLeftWheelRole is a specialization of both LeftWheelRole & FrontWheelRole FrontRightWheelRole is a specialization of both RightWheelRole & FrontWheelRole FrontLeftWheelRole + FrontRightWheelRole = FrontWheelRole - Nicolas. On 6/8/09 6:55 AM, "Tim Weilkiens" wrote: Nicolas, > Suppose that we want to specify a partition that involves a set of classifiers and the behavioral feature parameters and activity parameters typed by any of these classifiers. I > hope you will agree that this kind of partition is not directly representable within the language All three elements are named elements. Therefore we can create a partition of named elements. The sysml view concept could create a kind of partition of packageable elements. If we change the grouping relationship from import to dependency we have a partition of named elements. Another idea is to use the dependency relationship without a package. Although most tools doesn't support it, the dependency relationship allows many clients and suppliers. A semantically problem is to answer who should be the client and who is the supplier in a partition. Such kind of ordering makes no sense to me. However the trace relationship as a standardized UML stereotype of the dependency specialization abstraction mentions "the directionality of the dependency can often be ignored". Tim -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, June 04, 2009 9:37 AM To: Tim Weilkiens; Friedenthal, Sanford; Russell Peak Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; Rasmussen, Robert D; Conrad Bock; Ingham, Michel D Subject: Re: Issue 13928: partition concept - block-like thing Tim, This is a very good question; the short answer is yes but this requires some explanation. We need to .jump. outside the language (UML, SysML) in order to specify a concept of a partition as an arbitrary subset of uml::Element objects; i.e., an arbitrary partition of uml::Element objects is a second-order subset. A first-order subset is whatever kind of subset we can specify using the nominal structuring mechanisms available in the language, e.g.: a Namespace owns NamedElements, a Package owns PackageableElements a Classifier owns Features a BehavioralFeatures owns Parameters For these concepts, we can specify a partition by subsetting the nominal structure of the concept as specified in UML/SysML/... For example, a partition of a Namespace is a subset of Namespace::member : NamedElement[0..*] a partition of a Package is a subset of Package::packagedElement : PackageableElement[0..*] a partition of a Classifier is a subset of Classifier::feature : Feature[0..*] a partition of a BehavioralFeature is a subset of BehavioralFeature::ownedParameter : Parameter[0..*] Some subsets have no 1st order nominal representation in the uml; here are some notorious examples: an Activity does not .own. its ActivityNodes/Edges -- see: http://www.omg.org/issues/issue8668.txt there is no nominal distinction between the parameters of an Activity and non-parameter ActivityNodes; both are disjoint subsets of Activity::node : ActivityNode[0..*] which, as issue 8668 clarified, is not a composition relationship like the above examples. Suppose that we want to specify a partition that involves a set of classifiers and the behavioral feature parameters and activity parameters typed by any of these classifiers. I hope you will agree that this kind of partition is not directly representable within the language; i.e., we have to jump outside the UML in order to specify this kind of partition, e.g., with the help of an OCL constraint; in other words, an arbitrary partition is fundamentally a second-order concept for the UML. So, the trick that I.ve used is to define a convention to reify a partition as a second-order structural concept. That is, I used a .Wheel Role. as a reification of a second-order specification about the fact that our partition is referring to a particular .Wheel. which .Wheel Role. designates with the help of a directed, non-navigable association. If we need to partition things that aren.t classifiers, then we simply need to reify a second order specification that allows us to designate the things we want to include in our partition . classifiers and non-classifiers. However, the danger with this approach is that we have now opened the door for Russell.s paradox; i.e., a partition that partitions itself. To avoid Russell.s paradox, it is important to verify that the partitions form a partial ordering of subsets of the elements in the model and that this partial order has the topological structure of a lattice where each pair of element has a lower element and an upper element. I haven.t found a readable reference on the computational complexity of constructing the lattice for a partial order relation. It seems that the general problem is NP complete: http://portal.acm.org/citation.cfm?id=980030 but the problem is quite relevant to information modeling. In fact, I tried as an exercise a few years ago to design a simple but computationally efficient technique for constructing the lattice for a potentially large partial order relation in Alloy (http://osdir.com/ml/lang.alloy.general/2006-02/msg00001.html) Since then, I.ve improved on this idea quite a bit (I called it .no knock-knock jokes. when I discussed it with Dan Jackson.s students back in 2007). With recent optimizations, I can analyze various partial ordering relations in the UML metamodel with Alloy in a few seconds even though these relations can sometimes involve hundreds of tuples. The point is that if we have the right perspective for conceptualizing the notion of a partition for UML-like models, we can avoid falling into Russell.s trap. Alloy is certainly useful if used properly to do that but I consider this to be a tool to help us design better specifications, not the means by which we have to necessarily implement the spec. - Nicolas. On 6/2/09 10:37 PM, "Tim Weilkiens" wrote: Nicolas, Thanks for the clarification and the links to further study material. I'll check that. Is it possible to extend your approach somehow to include non-classifiers in partitions? I think it is important that partitions are more generic and can group more or less any model element. Maybe we need two concepts: a generic grouping mechanism and a block-based grouping mechanism. I think using blocks to group related elements is similar to create system configurations. Tim > -----Original Message----- > From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: Tuesday, June 02, 2009 8:00 AM > To: Tim Weilkiens; Friedenthal, Sanford; Russell.Peak@gatech.edu > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > Rasmussen, Robert D; conrad.bock@nist.gov; Ingham, Michel D > Subject: RE: Issue 13928: partition concept - block-like thing > > Tim, > > Yes; however, Marc and I spent several hours discussing this > example that he and Russell Peak had previously discussed as > well. Marc had a very simple illustration of the idea of a > partition with a combination of composition and aggregation > associations. However, this approach has obvious problems > since there are no constraints enforcing that the scope of a > partition specified by aggregation is in fact a subset of the > elements defined in a context by composition. > > The fundamental issue here is that the UML is a nominal > specification language: subtyping is nominal, subsetting is > nominal, redefinition is nominal -- i.e., we can only > specialize a named classifier; we can only subset a named > property, we can only redefine a named feature, etc... > > There is an excellent discussion of the difference between > nominal vs. structural subtyping in the context of the > Modelica language here: > > http://www.modelica.org/events/modelica2006/Proceedings/sessio > ns/Session3c3.pdf > > For Java, there is a proposal for integrating nominal and > structural subtyping here: > > http://www.cs.cmu.edu/~donna/public/ecoop08slides.pdf > http://www.cs.cmu.edu/~donna/public/ecoop08.pdf > > Based on these ideas, I've revised Marc's example for > partitioning different sets of wheels for a car -- eg., front > wheels vs. all 4 wheels. > > My motivation is that I want to stay within the semantics of > the UML to specify the fact that a partition is really a > subset of parts defined in a classifier context (e.g., a > structured block in SysML). > > For example, I want to make sure that a UML/SysML tool can > verify that the intersection of the "front wheels" partition > with the "left wheels" partition should be a set consisting > of just the "left front wheel". Similarly, the intersection > of the "front wheels" partition with the "right wheels" > partition should be a set consisting of just the "right front > wheel". If you were to take the union of these two sets, a > tool should be able to verify that this union is equivalent > to the subset of parts in the "front wheels" partition. > > With this guiding principle in mind, I refactored Marc > example as shown in the attached model (MD 16.0 sp1). > > - Nicolas. > > > > > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Monday, June 01, 2009 9:45 PM > > To: Rouquette, Nicolas F; Friedenthal, Sanford; > > Russell.Peak@gatech.edu > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > Rasmussen, > > Robert D; conrad.bock@nist.gov; Ingham, Michel D > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > Nicolas, > > > > If I understand your example correctly your approach limits > partitions > > to classifiers. > > An element that is part of the partition requires a generalization > > relationship. > > Is that correct? > > > > Tim > > > > > -----Original Message----- > > > From: Rouquette, Nicolas F > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > > >: Friday, May 29, 2009 9:43 PM > > > To: Tim Weilkiens; Friedenthal, Sanford; Russell.Peak@gatech.edu > > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > > >Rasmussen, Robert D; conrad.bock@nist.gov; Ingham, Michel D > > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > > > The latest version of the bundle is: > > > JPL-OMG-RFI-05-29-2009.tar Conrad's email system rejected > it because > > > it it too big (6Mb). > > > > > > This tar contains this: > > > > > > jpl-omg-rfi.mdzip > > > JPL-OMG-RFI-05-29-2009.html > > > JPL-OMG-RFI-05-29-2009_files/ > > > > > > In the MD model, navigate to the package: > > > > > > Examples::Car::4) Structural Entities & > Relationships::Alternative4 > > > > > > > > > Look at the classes: "Front Wheel" and "Rear Wheel" as > examples of > > > partitions of the subset of the wheels of a car. > > > In this example, a partition is modeled as a > specialization of the > > > set of wheels that have a role in the context of a particular car. > > > > > > What makes partitioning a non-trivial issue is that we are really > > > talking about modeling a partition as a subset > relationship between > > > a set of entities (e.g., wheels) and the set of roles (e.g., the > > > wheels of a particular car) that a subset of these > entities have for > > > another entity (e.g., a car) > > > > > > The approach here is based on the notion of UML powertype and > > > generalization set. > > > The approach is inspired, in part, based on the way Conrad Bock > > > talks about the model of composition in UML2 and in part > on equating > > > the notion of a partition as a kind of categorical relationship > > > according to Terry Halpin. > > > > > > - Nicolas. > > > > > > > -----Original Message----- > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > Sent: Friday, May 29, 2009 12:03 PM > > > > To: Rouquette, Nicolas F; Friedenthal, Sanford; > > > > Russell.Peak@gatech.edu > > > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > > > Rasmussen, > > > > Robert D; conrad.bock@nist.gov; Ingham, Michel D > > > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > > > > > Nicolas, > > > > > > > > I've received all three versions of the bundle. Are they > > > all the same? > > > > > > > > I had a look on the first one. But I couldn't find the > partition > > > > concept in your model. > > > > Which diagram/package shows your approach? > > > > > > > > Tim > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rouquette, Nicolas F > > > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > > > > > Sent: Friday, May 29, 2009 8:05 PM > > > > > To: Friedenthal, Sanford; Tim Weilkiens; > Russell.Peak@gatech.edu > > > > > Cc: Burkhart Roger M; Sarrel, Marc A; Delp, Christopher L; > > > > > Rasmussen, Robert D; conrad.bock@nist.gov; Ingham, Michel D > > > > > Subject: RE: Issue 13928: partition concept - block-like thing > > > > > > > > > > This is a tar file. > > > > > Does it pass through the firewalls? > > > > > > > > > > We need a shared repository instead of fighting spam filters. > > > > > > > > > > - Nicolas. > > > > > > > > > Subject: RE: Issue 13928: partition concept - block-like thing Date: Sat, 11 Jul 2009 22:47:21 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13928: partition concept - block-like thing Thread-Index: AcnQ4duZ/JcJi1KEQ7a9XBVcf54daAApy0NwAATHzLAAAK4PQAAMUyXAAC1hRCAC6iFV8AABEYpAAA+dkYAAFLyRkAAFs6EgAB4qeCAADpoFsAANZ44YAAAf5UAAG0/DgAAPkybAAAYSExAAAgoDQAAA7UUwAKnC/aAAAabcEAAy4IbwADajXEwA1g1WgAAMTgBpAABYtWAADNpITwABT3lQAAoclasACRFWUAAKm44sAAOCXTAAB1JymgAFpamgAL8RfrAAAd5lRgAAYCyAAAMiXh0Aj2744ACEnOLwAeLVmSAADVH+kAAJGxOgADXs7GAAAH9HoABdApAgAAdEgPABDC8/8AAAjNSgAEejWOAAB1OX4AAFH3pwAAAv6GAAX7KUAAAAyMFwAADnCYAAEhlaYA== From: "BERNARD, Yves" To: "Friedenthal, Sanford" , "Chonoles, Michael J" , "Tim Weilkiens" Cc: , "Alan Moore" X-OriginalArrivalTime: 11 Jul 2009 20:47:21.0659 (UTC) FILETIME=[C9A860B0:01CA0268] Hello, 1. As "part" is already used in the specification to described owned properties of a block, i suggest to use "memberOf" rather than "partOf" for the property of the PartitionRelated stereotype. More, it would conform with the description provided in §7.3.2.2 Partition 2. There is a problem with the numbering of the paragraphs (7.3.1.1, 7.3.2.2 and 7.3.2.2 ! ) Yves Date: Sat, 11 Jul 2009 19:39:48 -0400 From: "Chonoles, Michael J" Subject: RE: Issue 13928: partition concept - block-like thing To: "Friedenthal, Sanford" , Tim Weilkiens Cc: sysml-rtf@omg.org, Alan Moore Thread-Topic: Issue 13928: partition concept - block-like thing Thread-Index: AcnQ4duZ/JcJi1KEQ7a9XBVcf54daAApy0NwAATHzLAAAK4PQAAMUyXAAC1hRCAC6iFV8AABEYpAAA+dkYAAFLyRkAAFs6EgAB4qeCAADpoFsAANZ44YAAAf5UAAG0/DgAAPkybAAAYSExAAAgoDQAAA7UUwAKnC/aAAAabcEAAy4IbwADajXEwA1g1WgAAMTgBpAABYtWAADNpITwABT3lQAAoclasACRFWUAAKm44sAAOCXTAAB1JymgAFpamgAL8RfrAAAd5lRgAAYCyAAAMiXh0Aj2744ACEnOLwAeLVmSAADVH+kAAJGxOgADXs7GAAAH9HoABdApAgAAdEgPABDC8/8AAAjNSgAEejWOAAB1OX4AAFH3pwAAAv6GAAX7KUAAAAyMFwAADnCYAAGDgMQA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 11 Jul 2009 23:42:11.0976 (UTC) FILETIME=[365FB880:01CA0281] Thanks, that helps. I.ll have to see the reformulation to be clear. mjc From: Friedenthal, Sanford Sent: Saturday, July 11, 2009 8:10 AM To: Chonoles, Michael J; Tim Weilkiens Cc: sysml-rtf@omg.org; Alan Moore Subject: RE: Issue 13928: partition concept - block-like thing Michael My responses below. Tim Feel free to modify. Sandy Subject: RE: Issue 13928: partition concept - block-like thing Date: Sun, 12 Jul 2009 13:57:44 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13928: partition concept - block-like thing Thread-Index: AcnQ4duZ/JcJi1KEQ7a9XBVcf54daAApy0NwAATHzLAAAK4PQAAMUyXAAC1hRCAC6iFV8AABEYpAAA+dkYAAFLyRkAAFs6EgAB4qeCAADpoFsAANZ44YAAAf5UAAG0/DgAAPkybAAAYSExAAAgoDQAAA7UUwAKnC/aAAAabcEAAy4IbwADajXEwA1g1WgAAMTgBpAABYtWAADNpITwABT3lQAAoclasACRFWUAAKm44sAAOCXTAAB1JymgAFpamgAL8RfrAAAd5lRgAAYCyAAAMiXh0Aj2744ACEnOLwAeLVmSAADVH+kAAJGxOgADXs7GAAAH9HoABdApAgAAdEgPABDC8/8AAAjNSgAEejWOAAB1OX4AAFH3pwAAAv6GAAX7KUAAAAyMFwAADnCYAAGDgMQAAZyMQg From: "Tim Weilkiens" To: "Chonoles, Michael J" , "Friedenthal, Sanford" Cc: , "Alan Moore" Sandy, I agree with your comments. Attached you find an update of the proposal. I've changed the notation of the partition from the package symbol to a dashed package symbol. A dashed rectangle leads to the problem where to place the name of the partition. A package symbol shows a group with ownership, a partition shows a group without ownership. I agree with Yves that partOf is misleading. As Sandy already mentioned memberOf has the similar problem. I named it elementOf in the new proposal. I also updated the numbering as indicated by Yves. Tim Subject: RE: Issue 13928: partition concept - block-like thing Date: Sun, 12 Jul 2009 15:31:14 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13928: partition concept - block-like thing Thread-Index: AcnQ4duZ/JcJi1KEQ7a9XBVcf54daAApy0NwAATHzLAAAK4PQAAMUyXAAC1hRCAC6iFV8AABEYpAAA+dkYAAFLyRkAAFs6EgAB4qeCAADpoFsAANZ44YAAAf5UAAG0/DgAAPkybAAAYSExAAAgoDQAAA7UUwAKnC/aAAAabcEAAy4IbwADajXEwA1g1WgAAMTgBpAABYtWAADNpITwABT3lQAAoclasACRFWUAAKm44sAAOCXTAAB1JymgAFpamgAL8RfrAAAd5lRgAAYCyAAAMiXh0Aj2744ACEnOLwAeLVmSAADVH+kAAJGxOgADXs7GAAAH9HoABdApAgAAdEgPABDC8/8AAAjNSgAEejWOAAB1OX4AAFH3pwAAAv6GAAX7KUAAAAyMFwAADnCYAAGDgMQAAZyMQgAANIkkA= From: "BERNARD, Yves" To: "Tim Weilkiens" , "Chonoles, Michael J" , "Friedenthal, Sanford" Cc: , "Alan Moore" X-OriginalArrivalTime: 12 Jul 2009 13:31:16.0031 (UTC) FILETIME=[082424F0:01CA02F5] OK, "elementOf" is fine ! ;o) Thanks Tim. Yves -----Message d'origine----- De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé : dimanche 12 juillet 2009 13:58 Ą : Chonoles, Michael J; Friedenthal, Sanford Cc : sysml-rtf@omg.org; Alan Moore Objet : RE: Issue 13928: partition concept - block-like thing Sandy, I agree with your comments. Attached you find an update of the proposal. I've changed the notation of the partition from the package symbol to a dashed package symbol. A dashed rectangle leads to the problem where to place the name of the partition. A package symbol shows a group with ownership, a partition shows a group without ownership. I agree with Yves that partOf is misleading. As Sandy already mentioned memberOf has the similar problem. I named it elementOf in the new proposal. I also updated the numbering as indicated by Yves. Tim Date: Tue, 14 Jul 2009 21:48:51 -0400 From: "Chonoles, Michael J" Subject: RE: 13928-Parition To: "Friedenthal, Sanford" , David Price , Allison Barnard Feeney , Eldad Palachi Cc: sysml-rtf@omg.org, Burkhart Roger M Thread-Topic: 13928-Parition Thread-Index: AcoEdsUEhONYglldSji6F3kmAbhyDQAQvzvwAASpJlAABe9l4AACWIZw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 15 Jul 2009 01:56:33.0807 (UTC) FILETIME=[7AD6C1F0:01CA04EF] I certainly agree with the need for partitions, just I.m wondering how they would work in practice. For example in the spec we have a View in Figure 7.3. Does this View meet the definition for it to be subtype of Partition . In specific in the top of the view is an actor, a use case, and a communication (a type of association) between them. Is that the correct format for showing the communication or do I need to indicate the communication as a stereotyped box? You may need to establish that «View»s also use dashed packages. Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 8:57 PM To: Chonoles, Michael J; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: Comments on Proposed Resolution to 14041-Profile Diagram, 14043-Namespace, 13928-Parition Michael Thanks for the comments. Regarding the profile diagram, I agree with the motivation to align SysML and UML. It is a tradeoff between the value achieved from the shared Profile Diagram (vs using a Package Diagram) vs the negative value of adding a diagram. I weight the two criteria a bit different than you do for this particular example. Let.s get inputs from others as well, including the vendors. Regarding the value of the partition, It provides a general purpose capability to represent a group of things based on any criteria you choose without imposing any ownership. It also is a lighter weight form of grouping than for example a generalization set, which would require me to create a superclass (and only applies to classifiers). An simple example may be to group things according to their geographic location, such as a set of parts in an ibd that are associated with a particular region. I can simply enclose these elements in the partition. I would encourage others to provide other compelling examples related to temporal, spatial, organizational responsibility, and other types of partitioning criteria. Sandy From: Chonoles, Michael J Sent: Tuesday, July 14, 2009 6:14 PM To: Friedenthal, Sanford; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: Comments on Proposed Resolution to 14041-Profile Diagram, 14043-Namespace, 13928-Parition Sandy et al Issue 14041 Profile Diagram While I disagree with you and isn.t that what voting is for?) Doing nothing is not really an acceptable solution. If our intention is to not have this diagram, there are several places where we should be saying that the Profile diagram is not included. As to reasons why having the Profile diagram would be useful: Anytime SysML and UML disagree about the name of an item or the rules to enforce for an item, We: 1) Introduce the possibility that that compliant tools will need to act differently for UML vs SysML. This increases the potential confusion for users and adds to the complexity of the tools. 2) Makes it very difficult for a tool to bring in the SysML profile in a .non-strict. way. In such as case (as with NoMagic and others), what should a diagram of profile elements be called? The UML rules and SysML rules would then be in conflict. In general we should making the differences in important things, where System Engineers really do things differently than UML users. This particular change only impacts profile modelers . a special class of modelers who are not typically SystemEngineers and who would probably appreciate only one way of doing it. Issue 14043 Namespace URI Yes, Roger, please change the last words to Resolved as Sandy suggested. The TBD was there to encourage review Sandy Issue 13928 Partition I.m still confused about Partition. The words all make sense, I just don.t see what the value is. If have three blocks with an association between two of them. It appears the Partition (and the View) would need four dependency relationships (one to each block and one to the association. And if I open the Partition / View. I would see the four rectangles (one for the association). And how does this help anyone? Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 5:16 PM To: Chonoles, Michael J; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: Comments on Proposed Resolution to 14041-Profile Diagram, 14032-AP233, 14042 Namespace for Profile, 14041- Conj Flow Port - Update in Draft Ballot 3 Eldad, Michael, David/Allison I have the following comments on your proposed resolutions. Eldad Issue 14043: Conjugate Flow Ports In Fig 9.1, there is a cursor arrow that should be removed. Michael Issue 14041 Profile Diagram I disagree with adding the Profile Diagram to SysML per the proposed resolution to issue 14041. I think this adds an additional diagram which is primarily a constrained version of a package diagram. It is not clear that it adds any specific value to the language. I do understand this is the direction of UML, but it is not apparent to me that this would necessarily cause a problem with UML compatibility. The XMI is the same and the representation is the same, but we don.t proliferate new diagram kinds for their own sake. I propose a resolution of Closed/No change. Issue 14042 Namespace for Profile Disposition should be changed from TBD to Resolved at the bottom of the page. David, Allison Issue 14032: AP233 Update Please consider the following updates to the proposed resolution of Issue 14032. From: D.4.1 Scope of AP233 Figure D-1 illustrates the overlaps in technical content between AP233 and SysML. The exchange of data needed to recreate diagrams is explicitly out of scope for AP233. To: D.4.1 Scope of AP233 AP233 is not a graphical modeling language, but specifies a neutral file exchange format to support the exchange of data between Engineering Tools that generate or consume systems engineering data. Figure D-1 illustrates the overlaps between the types of data that can be exchanged by a tool that supports the AP233 file exchange format, and the type of data that is generated or consumed by a SysML modeling tool. In general, there is considerable overlap indicating the potential support that AP233 can provide as a data exchange standard for SysML modeling tools. From: D.4.4 SysML-AP233 Mapping A formal mapping between SysML and AP233 is being developed and will be standardized within the OMG. The mapping is being developed jointly between the ISO AP233 team, the OMG Systems Engineering Domain Special Interest Group and the INCOSE Model Driven System Design group. The date for the initial publication of the core mappings for Block structures, Requirements, Activities and State Machines is September 2009. Progress may be followed on the OMG SysML Portal at http://www.omgwiki.org/OMGSysML/doku.php. The mapping is a specification for SysML and other tool vendors to implement so that their tools can import from and export to AP233 data exchange files. AP233 usage is aimed primarily at scenarios where SysML data is fed to downstream applications such as those used in manufacturing, life cycle management or systems maintenance. To: D.4.4 SysML-AP233 Mapping A formal and standardized mapping between SysML and AP233 is being developed within the OMG. The mapping is a specification for SysML and other tool vendors to implement so that their tools can import from and export to AP233 data exchange files. AP233 usage is aimed primarily at scenarios where SysML data is fed to downstream applications such as those used in manufacturing, life cycle management or systems maintenance. Additional information can be found at the OMG SysML Portal at http://www.omgwiki.org/OMGSysML/doku.php. Sandy From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Tuesday, July 14, 2009 7:32 AM To: sysml-rtf@omg.org Subject: partial draft of Ballot 3 available for discussion A partial draft of proposed issue resolutions for Ballot 3 is available on the wiki page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf2:ballot_3 (also available through the Ballot 3 link on the home page). As stated on this page, "This is a partial draft version of Ballot 3, which is being made available so discussion on its draft resolutions can occur. Additional resolutions are still being added to this ballot. The remaining issues will be added before final discussion and voting periods are set." This ballot includes drafts of some major proposed resolutions, as discussed in meetings and additional working groups over the past several months, including a proposal for Flow Port Decomposition (13178), a Partition Construct to group model elements (11823), and a MarkupString for requirements text and other uses (13939). Proposals for Quantities, Units, Dimensions, and Values are in final stages of drafting and will also be added to this ballot. Because this ballot includes some of the major proposed resolutions for the SysML 1.2 RTF, everyone on the RTF is encouraged to review and discuss them on the mailing list as well as upcoming telecons. --Roger Date: Tue, 14 Jul 2009 22:02:46 -0400 From: "Friedenthal, Sanford" Subject: RE: 13928-Parition To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , Burkhart Roger M Thread-Topic: 13928-Parition Thread-Index: AcoEdsUEhONYglldSji6F3kmAbhyDQAQvzvwAASpJlAABe9l4AACWIZwAABmjKA= Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Michael Yes. The View in Fig 7.3 meets the need to be a subtype of partition. The communication is not shown as a stereotyped box. It is just part of the view. I do agree that the View should be in a dashed package symbol. Tim I agree with Michael that the notation for all Views in the spec should be changed including in the diagram elements table, usage examples, sample problem in the annex, etc.. We may also want to include the text below to the description. .A partition is a lighter weight form of grouping than a generalization set, which would require a superclass and only can apply to classifiers. . .A simple example may be to group things according to their geographic location, such as a set of parts in an ibd that are associated with a particular region.. Sandy From: Chonoles, Michael J Sent: Tuesday, July 14, 2009 9:49 PM To: Friedenthal, Sanford; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: 13928-Parition I certainly agree with the need for partitions, just I.m wondering how they would work in practice. For example in the spec we have a View in Figure 7.3. Does this View meet the definition for it to be subtype of Partition . In specific in the top of the view is an actor, a use case, and a communication (a type of association) between them. Is that the correct format for showing the communication or do I need to indicate the communication as a stereotyped box? You may need to establish that «View»s also use dashed packages. Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 8:57 PM To: Chonoles, Michael J; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: Comments on Proposed Resolution to 14041-Profile Diagram, 14043-Namespace, 13928-Parition Michael Thanks for the comments. Regarding the profile diagram, I agree with the motivation to align SysML and UML. It is a tradeoff between the value achieved from the shared Profile Diagram (vs using a Package Diagram) vs the negative value of adding a diagram. I weight the two criteria a bit different than you do for this particular example. Let.s get inputs from others as well, including the vendors. Regarding the value of the partition, It provides a general purpose capability to represent a group of things based on any criteria you choose without imposing any ownership. It also is a lighter weight form of grouping than for example a generalization set, which would require me to create a superclass (and only applies to classifiers). An simple example may be to group things according to their geographic location, such as a set of parts in an ibd that are associated with a particular region. I can simply enclose these elements in the partition. I would encourage others to provide other compelling examples related to temporal, spatial, organizational responsibility, and other types of partitioning criteria. Sandy From: Chonoles, Michael J Sent: Tuesday, July 14, 2009 6:14 PM To: Friedenthal, Sanford; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: Comments on Proposed Resolution to 14041-Profile Diagram, 14043-Namespace, 13928-Parition Sandy et al Issue 14041 Profile Diagram While I disagree with you and isn.t that what voting is for?) Doing nothing is not really an acceptable solution. If our intention is to not have this diagram, there are several places where we should be saying that the Profile diagram is not included. As to reasons why having the Profile diagram would be useful: Anytime SysML and UML disagree about the name of an item or the rules to enforce for an item, We: 1) Introduce the possibility that that compliant tools will need to act differently for UML vs SysML. This increases the potential confusion for users and adds to the complexity of the tools. 2) Makes it very difficult for a tool to bring in the SysML profile in a .non-strict. way. In such as case (as with NoMagic and others), what should a diagram of profile elements be called? The UML rules and SysML rules would then be in conflict. In general we should making the differences in important things, where System Engineers really do things differently than UML users. This particular change only impacts profile modelers . a special class of modelers who are not typically SystemEngineers and who would probably appreciate only one way of doing it. Issue 14043 Namespace URI Yes, Roger, please change the last words to Resolved as Sandy suggested. The TBD was there to encourage review Sandy Issue 13928 Partition I.m still confused about Partition. The words all make sense, I just don.t see what the value is. If have three blocks with an association between two of them. It appears the Partition (and the View) would need four dependency relationships (one to each block and one to the association. And if I open the Partition / View. I would see the four rectangles (one for the association). And how does this help anyone? Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 5:16 PM To: Chonoles, Michael J; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: Comments on Proposed Resolution to 14041-Profile Diagram, 14032-AP233, 14042 Namespace for Profile, 14041- Conj Flow Port - Update in Draft Ballot 3 Eldad, Michael, David/Allison I have the following comments on your proposed resolutions. Eldad Issue 14043: Conjugate Flow Ports In Fig 9.1, there is a cursor arrow that should be removed. Michael Issue 14041 Profile Diagram I disagree with adding the Profile Diagram to SysML per the proposed resolution to issue 14041. I think this adds an additional diagram which is primarily a constrained version of a package diagram. It is not clear that it adds any specific value to the language. I do understand this is the direction of UML, but it is not apparent to me that this would necessarily cause a problem with UML compatibility. The XMI is the same and the representation is the same, but we don.t proliferate new diagram kinds for their own sake. I propose a resolution of Closed/No change. Issue 14042 Namespace for Profile Disposition should be changed from TBD to Resolved at the bottom of the page. David, Allison Issue 14032: AP233 Update Please consider the following updates to the proposed resolution of Issue 14032. From: D.4.1 Scope of AP233 Figure D-1 illustrates the overlaps in technical content between AP233 and SysML. The exchange of data needed to recreate diagrams is explicitly out of scope for AP233. To: D.4.1 Scope of AP233 AP233 is not a graphical modeling language, but specifies a neutral file exchange format to support the exchange of data between Engineering Tools that generate or consume systems engineering data. Figure D-1 illustrates the overlaps between the types of data that can be exchanged by a tool that supports the AP233 file exchange format, and the type of data that is generated or consumed by a SysML modeling tool. In general, there is considerable overlap indicating the potential support that AP233 can provide as a data exchange standard for SysML modeling tools. From: D.4.4 SysML-AP233 Mapping A formal mapping between SysML and AP233 is being developed and will be standardized within the OMG. The mapping is being developed jointly between the ISO AP233 team, the OMG Systems Engineering Domain Special Interest Group and the INCOSE Model Driven System Design group. The date for the initial publication of the core mappings for Block structures, Requirements, Activities and State Machines is September 2009. Progress may be followed on the OMG SysML Portal at http://www.omgwiki.org/OMGSysML/doku.php. The mapping is a specification for SysML and other tool vendors to implement so that their tools can import from and export to AP233 data exchange files. AP233 usage is aimed primarily at scenarios where SysML data is fed to downstream applications such as those used in manufacturing, life cycle management or systems maintenance. To: D.4.4 SysML-AP233 Mapping A formal and standardized mapping between SysML and AP233 is being developed within the OMG. The mapping is a specification for SysML and other tool vendors to implement so that their tools can import from and export to AP233 data exchange files. AP233 usage is aimed primarily at scenarios where SysML data is fed to downstream applications such as those used in manufacturing, life cycle management or systems maintenance. Additional information can be found at the OMG SysML Portal at http://www.omgwiki.org/OMGSysML/doku.php. Sandy From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Tuesday, July 14, 2009 7:32 AM To: sysml-rtf@omg.org Subject: partial draft of Ballot 3 available for discussion A partial draft of proposed issue resolutions for Ballot 3 is available on the wiki page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf2:ballot_3 (also available through the Ballot 3 link on the home page). As stated on this page, "This is a partial draft version of Ballot 3, which is being made available so discussion on its draft resolutions can occur. Additional resolutions are still being added to this ballot. The remaining issues will be added before final discussion and voting periods are set." This ballot includes drafts of some major proposed resolutions, as discussed in meetings and additional working groups over the past several months, including a proposal for Flow Port Decomposition (13178), a Partition Construct to group model elements (11823), and a MarkupString for requirements text and other uses (13939). Proposals for Quantities, Units, Dimensions, and Values are in final stages of drafting and will also be added to this ballot. Because this ballot includes some of the major proposed resolutions for the SysML 1.2 RTF, everyone on the RTF is encouraged to review and discuss them on the mailing list as well as upcoming telecons. --Roger Date: Tue, 14 Jul 2009 22:27:57 -0400 From: "Chonoles, Michael J" Subject: RE: 13928-Parition To: "Friedenthal, Sanford" , Tim Weilkiens Cc: sysml-rtf@omg.org, Burkhart Roger M Thread-Topic: 13928-Parition Thread-Index: AcoEdsUEhONYglldSji6F3kmAbhyDQAQvzvwAASpJlAABe9l4AACWIZwAABmjKAAAFBLAA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 15 Jul 2009 02:29:54.0031 (UTC) FILETIME=[2310B7F0:01CA04F4] I.m sorry; then if it is legal to draw them in diagrammatic form, I have fewer objections. It was not clear from the partition documentation. I have a feeling that it will still open us up to lots of questions, where we.ve not been clear. One possible use of partitions is to indicate architectural layers . producing a sort of traditional layered/partitioned block diagram (not SysML blocks). Is there any way of showing dependencies among partitions . where the application layer partition depends on the middleware partition, and the application layer partition has peer-to-peer relationship among it.s sub partitions. In any case, I withdraw my objections to 13928, just looking for clarifications. Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 10:03 PM To: Chonoles, Michael J; Tim Weilkiens Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: 13928-Parition Michael Yes. The View in Fig 7.3 meets the need to be a subtype of partition. The communication is not shown as a stereotyped box. It is just part of the view. I do agree that the View should be in a dashed package symbol. Tim I agree with Michael that the notation for all Views in the spec should be changed including in the diagram elements table, usage examples, sample problem in the annex, etc.. We may also want to include the text below to the description. .A partition is a lighter weight form of grouping than a generalization set, which would require a superclass and only can apply to classifiers. . .A simple example may be to group things according to their geographic location, such as a set of parts in an ibd that are associated with a particular region.. Sandy From: Chonoles, Michael J Sent: Tuesday, July 14, 2009 9:49 PM To: Friedenthal, Sanford; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: 13928-Parition I certainly agree with the need for partitions, just I.m wondering how they would work in practice. For example in the spec we have a View in Figure 7.3. Does this View meet the definition for it to be subtype of Partition . In specific in the top of the view is an actor, a use case, and a communication (a type of association) between them. Is that the correct format for showing the communication or do I need to indicate the communication as a stereotyped box? You may need to establish that «View»s also use dashed packages. Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 8:57 PM To: Chonoles, Michael J; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: Comments on Proposed Resolution to 14041-Profile Diagram, 14043-Namespace, 13928-Parition Michael Thanks for the comments. Regarding the profile diagram, I agree with the motivation to align SysML and UML. It is a tradeoff between the value achieved from the shared Profile Diagram (vs using a Package Diagram) vs the negative value of adding a diagram. I weight the two criteria a bit different than you do for this particular example. Let.s get inputs from others as well, including the vendors. Regarding the value of the partition, It provides a general purpose capability to represent a group of things based on any criteria you choose without imposing any ownership. It also is a lighter weight form of grouping than for example a generalization set, which would require me to create a superclass (and only applies to classifiers). An simple example may be to group things according to their geographic location, such as a set of parts in an ibd that are associated with a particular region. I can simply enclose these elements in the partition. I would encourage others to provide other compelling examples related to temporal, spatial, organizational responsibility, and other types of partitioning criteria. Sandy From: Chonoles, Michael J Sent: Tuesday, July 14, 2009 6:14 PM To: Friedenthal, Sanford; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: Comments on Proposed Resolution to 14041-Profile Diagram, 14043-Namespace, 13928-Parition Sandy et al Issue 14041 Profile Diagram While I disagree with you and isn.t that what voting is for?) Doing nothing is not really an acceptable solution. If our intention is to not have this diagram, there are several places where we should be saying that the Profile diagram is not included. As to reasons why having the Profile diagram would be useful: Anytime SysML and UML disagree about the name of an item or the rules to enforce for an item, We: 1) Introduce the possibility that that compliant tools will need to act differently for UML vs SysML. This increases the potential confusion for users and adds to the complexity of the tools. 2) Makes it very difficult for a tool to bring in the SysML profile in a .non-strict. way. In such as case (as with NoMagic and others), what should a diagram of profile elements be called? The UML rules and SysML rules would then be in conflict. In general we should making the differences in important things, where System Engineers really do things differently than UML users. This particular change only impacts profile modelers . a special class of modelers who are not typically SystemEngineers and who would probably appreciate only one way of doing it. Issue 14043 Namespace URI Yes, Roger, please change the last words to Resolved as Sandy suggested. The TBD was there to encourage review Sandy Issue 13928 Partition I.m still confused about Partition. The words all make sense, I just don.t see what the value is. If have three blocks with an association between two of them. It appears the Partition (and the View) would need four dependency relationships (one to each block and one to the association. And if I open the Partition / View. I would see the four rectangles (one for the association). And how does this help anyone? Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 5:16 PM To: Chonoles, Michael J; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: Comments on Proposed Resolution to 14041-Profile Diagram, 14032-AP233, 14042 Namespace for Profile, 14041- Conj Flow Port - Update in Draft Ballot 3 Eldad, Michael, David/Allison I have the following comments on your proposed resolutions. Eldad Issue 14043: Conjugate Flow Ports In Fig 9.1, there is a cursor arrow that should be removed. Michael Issue 14041 Profile Diagram I disagree with adding the Profile Diagram to SysML per the proposed resolution to issue 14041. I think this adds an additional diagram which is primarily a constrained version of a package diagram. It is not clear that it adds any specific value to the language. I do understand this is the direction of UML, but it is not apparent to me that this would necessarily cause a problem with UML compatibility. The XMI is the same and the representation is the same, but we don.t proliferate new diagram kinds for their own sake. I propose a resolution of Closed/No change. Issue 14042 Namespace for Profile Disposition should be changed from TBD to Resolved at the bottom of the page. David, Allison Issue 14032: AP233 Update Please consider the following updates to the proposed resolution of Issue 14032. From: D.4.1 Scope of AP233 Figure D-1 illustrates the overlaps in technical content between AP233 and SysML. The exchange of data needed to recreate diagrams is explicitly out of scope for AP233. To: D.4.1 Scope of AP233 AP233 is not a graphical modeling language, but specifies a neutral file exchange format to support the exchange of data between Engineering Tools that generate or consume systems engineering data. Figure D-1 illustrates the overlaps between the types of data that can be exchanged by a tool that supports the AP233 file exchange format, and the type of data that is generated or consumed by a SysML modeling tool. In general, there is considerable overlap indicating the potential support that AP233 can provide as a data exchange standard for SysML modeling tools. From: D.4.4 SysML-AP233 Mapping A formal mapping between SysML and AP233 is being developed and will be standardized within the OMG. The mapping is being developed jointly between the ISO AP233 team, the OMG Systems Engineering Domain Special Interest Group and the INCOSE Model Driven System Design group. The date for the initial publication of the core mappings for Block structures, Requirements, Activities and State Machines is September 2009. Progress may be followed on the OMG SysML Portal at http://www.omgwiki.org/OMGSysML/doku.php. The mapping is a specification for SysML and other tool vendors to implement so that their tools can import from and export to AP233 data exchange files. AP233 usage is aimed primarily at scenarios where SysML data is fed to downstream applications such as those used in manufacturing, life cycle management or systems maintenance. To: D.4.4 SysML-AP233 Mapping A formal and standardized mapping between SysML and AP233 is being developed within the OMG. The mapping is a specification for SysML and other tool vendors to implement so that their tools can import from and export to AP233 data exchange files. AP233 usage is aimed primarily at scenarios where SysML data is fed to downstream applications such as those used in manufacturing, life cycle management or systems maintenance. Additional information can be found at the OMG SysML Portal at http://www.omgwiki.org/OMGSysML/doku.php. Sandy From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Tuesday, July 14, 2009 7:32 AM To: sysml-rtf@omg.org Subject: partial draft of Ballot 3 available for discussion A partial draft of proposed issue resolutions for Ballot 3 is available on the wiki page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf2:ballot_3 (also available through the Ballot 3 link on the home page). As stated on this page, "This is a partial draft version of Ballot 3, which is being made available so discussion on its draft resolutions can occur. Additional resolutions are still being added to this ballot. The remaining issues will be added before final discussion and voting periods are set." This ballot includes drafts of some major proposed resolutions, as discussed in meetings and additional working groups over the past several months, including a proposal for Flow Port Decomposition (13178), a Partition Construct to group model elements (11823), and a MarkupString for requirements text and other uses (13939). Proposals for Quantities, Units, Dimensions, and Values are in final stages of drafting and will also be added to this ballot. Because this ballot includes some of the major proposed resolutions for the SysML 1.2 RTF, everyone on the RTF is encouraged to review and discuss them on the mailing list as well as upcoming telecons. --Roger Date: Tue, 14 Jul 2009 23:10:50 -0400 From: "Friedenthal, Sanford" Subject: RE: 13928-Parition To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , Burkhart Roger M Thread-Topic: 13928-Parition Thread-Index: AcoEdsUEhONYglldSji6F3kmAbhyDQAQvzvwAASpJlAABe9l4AACWIZwAABmjKAAAFBLAAACQ+8w Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Points well taken. One could certainly have sub partitions be defining the dependency relationship between the client and supplier partitions, where the supplier is the sub-partition. Pier level partitions could be shown in a package, but would not have a dependency relationship between them. From: Chonoles, Michael J Sent: Tuesday, July 14, 2009 10:28 PM To: Friedenthal, Sanford; Tim Weilkiens Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: 13928-Parition I.m sorry; then if it is legal to draw them in diagrammatic form, I have fewer objections. It was not clear from the partition documentation. I have a feeling that it will still open us up to lots of questions, where we.ve not been clear. One possible use of partitions is to indicate architectural layers . producing a sort of traditional layered/partitioned block diagram (not SysML blocks). Is there any way of showing dependencies among partitions . where the application layer partition depends on the middleware partition, and the application layer partition has peer-to-peer relationship among it.s sub partitions. In any case, I withdraw my objections to 13928, just looking for clarifications. Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 10:03 PM To: Chonoles, Michael J; Tim Weilkiens Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: 13928-Parition Michael Yes. The View in Fig 7.3 meets the need to be a subtype of partition. The communication is not shown as a stereotyped box. It is just part of the view. I do agree that the View should be in a dashed package symbol. Tim I agree with Michael that the notation for all Views in the spec should be changed including in the diagram elements table, usage examples, sample problem in the annex, etc.. We may also want to include the text below to the description. .A partition is a lighter weight form of grouping than a generalization set, which would require a superclass and only can apply to classifiers. . .A simple example may be to group things according to their geographic location, such as a set of parts in an ibd that are associated with a particular region.. Sandy From: Chonoles, Michael J Sent: Tuesday, July 14, 2009 9:49 PM To: Friedenthal, Sanford; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: 13928-Parition I certainly agree with the need for partitions, just I.m wondering how they would work in practice. For example in the spec we have a View in Figure 7.3. Does this View meet the definition for it to be subtype of Partition . In specific in the top of the view is an actor, a use case, and a communication (a type of association) between them. Is that the correct format for showing the communication or do I need to indicate the communication as a stereotyped box? You may need to establish that «View»s also use dashed packages. Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 8:57 PM To: Chonoles, Michael J; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: Comments on Proposed Resolution to 14041-Profile Diagram, 14043-Namespace, 13928-Parition Michael Thanks for the comments. Regarding the profile diagram, I agree with the motivation to align SysML and UML. It is a tradeoff between the value achieved from the shared Profile Diagram (vs using a Package Diagram) vs the negative value of adding a diagram. I weight the two criteria a bit different than you do for this particular example. Let.s get inputs from others as well, including the vendors. Regarding the value of the partition, It provides a general purpose capability to represent a group of things based on any criteria you choose without imposing any ownership. It also is a lighter weight form of grouping than for example a generalization set, which would require me to create a superclass (and only applies to classifiers). An simple example may be to group things according to their geographic location, such as a set of parts in an ibd that are associated with a particular region. I can simply enclose these elements in the partition. I would encourage others to provide other compelling examples related to temporal, spatial, organizational responsibility, and other types of partitioning criteria. Sandy From: Chonoles, Michael J Sent: Tuesday, July 14, 2009 6:14 PM To: Friedenthal, Sanford; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: Comments on Proposed Resolution to 14041-Profile Diagram, 14043-Namespace, 13928-Parition Sandy et al Issue 14041 Profile Diagram While I disagree with you and isn.t that what voting is for?) Doing nothing is not really an acceptable solution. If our intention is to not have this diagram, there are several places where we should be saying that the Profile diagram is not included. As to reasons why having the Profile diagram would be useful: Anytime SysML and UML disagree about the name of an item or the rules to enforce for an item, We: 1) Introduce the possibility that that compliant tools will need to act differently for UML vs SysML. This increases the potential confusion for users and adds to the complexity of the tools. 2) Makes it very difficult for a tool to bring in the SysML profile in a .non-strict. way. In such as case (as with NoMagic and others), what should a diagram of profile elements be called? The UML rules and SysML rules would then be in conflict. In general we should making the differences in important things, where System Engineers really do things differently than UML users. This particular change only impacts profile modelers . a special class of modelers who are not typically SystemEngineers and who would probably appreciate only one way of doing it. Issue 14043 Namespace URI Yes, Roger, please change the last words to Resolved as Sandy suggested. The TBD was there to encourage review Sandy Issue 13928 Partition I.m still confused about Partition. The words all make sense, I just don.t see what the value is. If have three blocks with an association between two of them. It appears the Partition (and the View) would need four dependency relationships (one to each block and one to the association. And if I open the Partition / View. I would see the four rectangles (one for the association). And how does this help anyone? Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 5:16 PM To: Chonoles, Michael J; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: Comments on Proposed Resolution to 14041-Profile Diagram, 14032-AP233, 14042 Namespace for Profile, 14041- Conj Flow Port - Update in Draft Ballot 3 Eldad, Michael, David/Allison I have the following comments on your proposed resolutions. Eldad Issue 14043: Conjugate Flow Ports In Fig 9.1, there is a cursor arrow that should be removed. Michael Issue 14041 Profile Diagram I disagree with adding the Profile Diagram to SysML per the proposed resolution to issue 14041. I think this adds an additional diagram which is primarily a constrained version of a package diagram. It is not clear that it adds any specific value to the language. I do understand this is the direction of UML, but it is not apparent to me that this would necessarily cause a problem with UML compatibility. The XMI is the same and the representation is the same, but we don.t proliferate new diagram kinds for their own sake. I propose a resolution of Closed/No change. Issue 14042 Namespace for Profile Disposition should be changed from TBD to Resolved at the bottom of the page. David, Allison Issue 14032: AP233 Update Please consider the following updates to the proposed resolution of Issue 14032. From: D.4.1 Scope of AP233 Figure D-1 illustrates the overlaps in technical content between AP233 and SysML. The exchange of data needed to recreate diagrams is explicitly out of scope for AP233. To: D.4.1 Scope of AP233 AP233 is not a graphical modeling language, but specifies a neutral file exchange format to support the exchange of data between Engineering Tools that generate or consume systems engineering data. Figure D-1 illustrates the overlaps between the types of data that can be exchanged by a tool that supports the AP233 file exchange format, and the type of data that is generated or consumed by a SysML modeling tool. In general, there is considerable overlap indicating the potential support that AP233 can provide as a data exchange standard for SysML modeling tools. From: D.4.4 SysML-AP233 Mapping A formal mapping between SysML and AP233 is being developed and will be standardized within the OMG. The mapping is being developed jointly between the ISO AP233 team, the OMG Systems Engineering Domain Special Interest Group and the INCOSE Model Driven System Design group. The date for the initial publication of the core mappings for Block structures, Requirements, Activities and State Machines is September 2009. Progress may be followed on the OMG SysML Portal at http://www.omgwiki.org/OMGSysML/doku.php. The mapping is a specification for SysML and other tool vendors to implement so that their tools can import from and export to AP233 data exchange files. AP233 usage is aimed primarily at scenarios where SysML data is fed to downstream applications such as those used in manufacturing, life cycle management or systems maintenance. To: D.4.4 SysML-AP233 Mapping A formal and standardized mapping between SysML and AP233 is being developed within the OMG. The mapping is a specification for SysML and other tool vendors to implement so that their tools can import from and export to AP233 data exchange files. AP233 usage is aimed primarily at scenarios where SysML data is fed to downstream applications such as those used in manufacturing, life cycle management or systems maintenance. Additional information can be found at the OMG SysML Portal at http://www.omgwiki.org/OMGSysML/doku.php. Sandy From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Tuesday, July 14, 2009 7:32 AM To: sysml-rtf@omg.org Subject: partial draft of Ballot 3 available for discussion A partial draft of proposed issue resolutions for Ballot 3 is available on the wiki page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf2:ballot_3 (also available through the Ballot 3 link on the home page). As stated on this page, "This is a partial draft version of Ballot 3, which is being made available so discussion on its draft resolutions can occur. Additional resolutions are still being added to this ballot. The remaining issues will be added before final discussion and voting periods are set." This ballot includes drafts of some major proposed resolutions, as discussed in meetings and additional working groups over the past several months, including a proposal for Flow Port Decomposition (13178), a Partition Construct to group model elements (11823), and a MarkupString for requirements text and other uses (13939). Proposals for Quantities, Units, Dimensions, and Values are in final stages of drafting and will also be added to this ballot. Because this ballot includes some of the major proposed resolutions for the SysML 1.2 RTF, everyone on the RTF is encouraged to review and discuss them on the mailing list as well as upcoming telecons. --Roger DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=3zFtLQsQh5Htdk49M4vC3mzg9EwQQwMheZMzqi0RgPE=; b=p+Svt9mC6+bZ1DKo4sfpv2CFxepst8R6p0U2kz81ZS4UewVxJGvCexNO9NG3KgI9aY LSoeC+zREDVqPy1NKHuLW5IvwMgFUKixDyR8mNpbbSbvJVlLivCid2aom5TmzdeXsZuA +nD2xKwPyWAjBv2Lb8P/kmvP+iRQvQpv7qflk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=lM+pXjgmPdb8N6X1bigi9/njwEOSZdNBn4b+tHZWJpNuIlfQBt4qSYFOziktTYj6Mi bGwX30+eciPSOltPnyTMg0D1tVlWqgTFVgRqVONBuHHZzG4SeDdCMwlsKNdW+cGh5EGd 04MIyvDL7JvGvCy02i0h9vkpa2WLnSXQkLaHE= Sender: lonniev@gmail.com Date: Tue, 14 Jul 2009 21:14:38 -0600 X-Google-Sender-Auth: bea61b19106b321f Subject: Re: 13928-Parition From: Lonnie VanZandt To: "Friedenthal, Sanford" Cc: "Chonoles, Michael J" , Tim Weilkiens , "sysml-rtf@omg.org" , Burkhart Roger M Clarification please: does the term "partition" mean a virtual container much like a View? Can an element be a member of multiple "partitions" while remaining the child of only one Package? If so, I find the choice of the term to be awkward because I interpret "partition" to be a disjoint subset of a larger set. Quoting wiktionary: partition (plural partitions) An action which divides a thing into parts, or separates one thing from another ... ... ... ... (set theory) A collection of non-empty, disjoint subsets of a set whose union is the set itself (i.e. all elements of the set are contained in exactly one of the subsets). Given this definition, if the goal is to represent a virtual namespace which associates many-to-many with elements, then perhaps a term such as "group", "set", or "collection" would be better. I believe it to be true that we all understand that membership in a group, set, or collection does not implicitly preclude membership in any other group, set, or collection... Date: Tue, 14 Jul 2009 23:29:21 -0400 From: "Friedenthal, Sanford" Subject: RE: 13928-Parition To: Lonnie VanZandt , Tim Weilkiens Cc: "Chonoles, Michael J" , "sysml-rtf@omg.org" , Burkhart Roger M Thread-Topic: 13928-Parition Thread-Index: AcoE+zah4b0/o/AETmyC4QvcTKIKQQAACvYw Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Lonnie Good point. I like your alternatives for partition including "group", "set", or "collection". I tend to think set may be overloaded, so I suggest we go with .group. or .collection. would be better. Tim As of now, there are two recommended changes to the proposal. 1) Change name of partition to group or collection. My preference is collection unless someone feels has a strong case for group. 2) Represent View in new dashed notation wherever it appears in the spec. Can you make these changes? THESE ARE GREAT INPUTS. Sandy From: lonniev@gmail.com [mailto:lonniev@gmail.com] On Behalf Of Lonnie VanZandt Sent: Tuesday, July 14, 2009 11:15 PM To: Friedenthal, Sanford Cc: Chonoles, Michael J; Tim Weilkiens; sysml-rtf@omg.org; Burkhart Roger M Subject: Re: 13928-Parition Clarification please: does the term "partition" mean a virtual container much like a View? Can an element be a member of multiple "partitions" while remaining the child of only one Package? If so, I find the choice of the term to be awkward because I interpret "partition" to be a disjoint subset of a larger set. Quoting wiktionary: partition (plural partitions) An action which divides a thing into parts, or separates one thing from another ... ... ... ... (set theory) A collection of non-empty, disjoint subsets of a set whose union is the set itself (i.e. all elements of the set are contained in exactly one of the subsets). Given this definition, if the goal is to represent a virtual namespace which associates many-to-many with elements, then perhaps a term such as "group", "set", or "collection" would be better. I believe it to be true that we all understand that membership in a group, set, or collection does not implicitly preclude membership in any other group, set, or collection... X-WSS-ID: 0KMT0N2-05-NRR-02 X-M-MSG: From: Burkhart Roger M To: "Friedenthal, Sanford" , "Chonoles, Michael J" , Tim Weilkiens CC: "sysml-rtf@omg.org" Date: Tue, 14 Jul 2009 22:35:28 -0500 Subject: RE: 13928-Parition Thread-Topic: 13928-Parition Thread-Index: AcoEdsUEhONYglldSji6F3kmAbhyDQAQvzvwAASpJlAABe9l4AACWIZwAABmjKAAA1CtAA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Since we already have «view» and «partition» keywords to distinguish these stereotypes of Package, I'd prefer that we not add the burden of a new dashed-outline package symbol on existing implementations. Does the dashed-outline package symbol communicate anything that the stereotype keyword does not already indicate? --Roger -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Tuesday, July 14, 2009 9:03 PM To: Chonoles, Michael J; Tim Weilkiens Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: 13928-Parition Michael Yes. The View in Fig 7.3 meets the need to be a subtype of partition. The communication is not shown as a stereotyped box. It is just part of the view. I do agree that the View should be in a dashed package symbol. Tim I agree with Michael that the notation for all Views in the spec should be changed including in the diagram elements table, usage examples, sample problem in the annex, etc.. We may also want to include the text below to the description. .A partition is a lighter weight form of grouping than a generalization set, which would require a superclass and only can apply to classifiers. . .A simple example may be to group things according to their geographic location, such as a set of parts in an ibd that are associated with a particular region.. Sandy From: Chonoles, Michael J Sent: Tuesday, July 14, 2009 9:49 PM To: Friedenthal, Sanford; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: 13928-Parition I certainly agree with the need for partitions, just I.m wondering how they would work in practice. For example in the spec we have a View in Figure 7.3. Does this View meet the definition for it to be subtype of Partition . In specific in the top of the view is an actor, a use case, and a communication (a type of association) between them. Is that the correct format for showing the communication or do I need to indicate the communication as a stereotyped box? You may need to establish that «View»s also use dashed packages. Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 8:57 PM To: Chonoles, Michael J; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: Comments on Proposed Resolution to 14041-Profile Diagram, 14043-Namespace, 13928-Parition Michael Thanks for the comments. Regarding the profile diagram, I agree with the motivation to align SysML and UML. It is a tradeoff between the value achieved from the shared Profile Diagram (vs using a Package Diagram) vs the negative value of adding a diagram. I weight the two criteria a bit different than you do for this particular example. Let.s get inputs from others as well, including the vendors. Regarding the value of the partition, It provides a general purpose capability to represent a group of things based on any criteria you choose without imposing any ownership. It also is a lighter weight form of grouping than for example a generalization set, which would require me to create a superclass (and only applies to classifiers). An simple example may be to group things according to their geographic location, such as a set of parts in an ibd that are associated with a particular region. I can simply enclose these elements in the partition. I would encourage others to provide other compelling examples related to temporal, spatial, organizational responsibility, and other types of partitioning criteria. Sandy From: Chonoles, Michael J Sent: Tuesday, July 14, 2009 6:14 PM To: Friedenthal, Sanford; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: RE: Comments on Proposed Resolution to 14041-Profile Diagram, 14043-Namespace, 13928-Parition Sandy et al Issue 14041 Profile Diagram While I disagree with you and isn.t that what voting is for?) Doing nothing is not really an acceptable solution. If our intention is to not have this diagram, there are several places where we should be saying that the Profile diagram is not included. As to reasons why having the Profile diagram would be useful: Anytime SysML and UML disagree about the name of an item or the rules to enforce for an item, We: 1) Introduce the possibility that that compliant tools will need to act differently for UML vs SysML. This increases the potential confusion for users and adds to the complexity of the tools. 2) Makes it very difficult for a tool to bring in the SysML profile in a .non-strict. way. In such as case (as with NoMagic and others), what should a diagram of profile elements be called? The UML rules and SysML rules would then be in conflict. In general we should making the differences in important things, where System Engineers really do things differently than UML users. This particular change only impacts profile modelers . a special class of modelers who are not typically SystemEngineers and who would probably appreciate only one way of doing it. Issue 14043 Namespace URI Yes, Roger, please change the last words to Resolved as Sandy suggested. The TBD was there to encourage review Sandy Issue 13928 Partition I.m still confused about Partition. The words all make sense, I just don.t see what the value is. If have three blocks with an association between two of them. It appears the Partition (and the View) would need four dependency relationships (one to each block and one to the association. And if I open the Partition / View. I would see the four rectangles (one for the association). And how does this help anyone? Michael From: Friedenthal, Sanford Sent: Tuesday, July 14, 2009 5:16 PM To: Chonoles, Michael J; David Price; Allison Barnard Feeney; Eldad Palachi Cc: sysml-rtf@omg.org; Burkhart Roger M Subject: Comments on Proposed Resolution to 14041-Profile Diagram, 14032-AP233, 14042 Namespace for Profile, 14041- Conj Flow Port - Update in Draft Ballot 3 Eldad, Michael, David/Allison I have the following comments on your proposed resolutions. Eldad Issue 14043: Conjugate Flow Ports Date: Fri, 08 Apr 2011 11:40:36 +0200 From: Julio Medina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 To: "BERNARD, Yves" CC: Pete Rivett , Sanford Friedenthal , "Rouquette, Nicolas F (313K)" , Eldad Palachi , Ed Seidewitz , "Chonoles, Michael J" , Sysml-Rtf Subject: Re: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements--> a slightlydifferent approach X-OriginalArrivalTime: 08 Apr 2011 09:40:54.0350 (UTC) FILETIME=[0E163EE0:01CBF5D1] X-imss-version: 2.054 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:6.5.1024(18060.006) X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:2 S:2 R:2 (0.0000 0.0000) Hi Yves, hi all I have tried to get in tune with the ongoing trends in this topic by reading all the messages in the discussion, but I may have skipped some comments and hence I apologize in advance if this has been already discussed... anyway I think regarding the original issue, the original resolution was quite good. Though, I suggest a small change that may help significantly to address most of the issues arisen later. The idea is to have a way to package references to model elements. Then way not creating formally a "reference" to a model element. This means to have the model element equivalent to a pointer. The good construct for this is the one selected by Yves: the constraint. Then, any package or alike (including views) may collect those pointers using the desired criteria. The ElementGroup can then be not necessary but if it results necessary or useful to have a grouping mechanism constrained to hold only pointers, and expressing in it the rules (constraints) for such grouping, then a property of the stereotype (if used to extend package) or the constraint itself may hold it. I started making the modifications to the resolution but I'd prefer to have your views about this idea before launching it as a formal proposal. Cheers, Julio El 08/04/2011 8:28, BERNARD, Yves escribió: Pete, I agree that this proposal is not a perfect answer to the need and I'm open to any other proposal which doesn't twist the semantics of the element(s) on which it is based on. If you have a better one, please contribute, but for now I'm not convinced that we can build something consistent based on the Package's semantics. Yves -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: jeudi 7 avril 2011 17:26 To: BERNARD, Yves; Sanford Friedenthal; Rouquette, Nicolas F (313K) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Sysml-Rtf Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements it implies that the elementA conforms to the criterion {is b}. This is not intuitive and is not what people would expect from nested groups. And moreover seems totally non-useful. People will expect to be able to nest Groups in the same way they can nest Packages but without the exclusivity. Even in the common case of no criteria (i.e. all {true}) people would expect 'member of group' to be transitive and for the ability to apply operations to 'all members' to include members of nested groups. This is a significant flaw with this proposal: it does not meet the requirement of being able to nest groups in a useful way. Pete -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, April 07, 2011 8:43 AM To: Sanford Friedenthal; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; Pete Rivett; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, See my answers below. Yves -----Original Message----- From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 7 avril 2011 14:57 To: BERNARD, Yves; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Pete Rivett'; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Yves Please clarify the following. " the group A, as a whole and not its members one by one, shall conform to the criteria defined for the group B" How does a group conform without its members conforming? [BERNARD, Yves] An ElementGroup is an entity which is "more" than the union of its members. It means that a group has its own properties which are independent of the properties of its members. For instance an ElementGroup has a criterion, thus I can defined an ElementGroup of ElementGroups with the following criterion: {has a criterion expressed in OCL} Let's use the example you began below. Assume: an Element Group A with criterion {is a} an Element Group B with criterion {is b} an Element Group C with criterion {is a and is b} Note: Members of C are a subset of Members of A and B [BERNARD, Yves] Keep in mind that ElementGroups are prescriptive and not descriptive. Saying that the criterion of A is {is a} doesn't implies that all the elements that conform to this criterion are members of A. It just means that members of A have to conform to this constraint. Then depending on what elements you actually put in the group A (on your own decision) it can gather all of them, only a part or none (the group may be empty). It's the same for group B and group C. Therefore, depending on how you build these groups your assertion: "Members of C are a subset of Members of A and B" can be true or false. If an Element Group A is a member of Element Group B, Does this imply Members of Group B are the same as members of Group C. I know you are saying the answer is no, but what does it imply about the members of B. [BERNARD, Yves] Indeed, it does not imply anything about members of B. The constraints applicable to member of B are defined by the criterion of B only and not by the members we define for this group (prescriptive vs descriptive). On the contrary, it implies that the elementA conforms to the criterion {is b}. Example: Element Group A criterion {is blue} Element Group B criterion {is square} Element Group C criteria {is blue and is square} [BERNARD, Yves] In this context you can have, for instance: A={blue_square}, B={red_square, yellow_square}, C={blue_square} but you cannot add A (nor C) as a member of B (B={red_square, yellow_square, A}) because A is not "square" (it's only an ElementGroup which has no shape property). Sandy -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, April 07, 2011 6:02 AM To: Sanford Friedenthal; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Pete Rivett'; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, Nicolas, I have been monopolized by other tasks since I've reopen the discussion on issue #13928 and I've not been able to react to the all the mails which have been exchanged. Sorry for that. 1. About semantics of an element group => This is a point I would like to underline once again because it has implications on other issues we are discussing. According to the "constraint-based" implementation ElementGroups are prescriptive. That is: adding an element in a group also add it the constraint to conform to the group criterion. 2. About subgroups / nesting groups => The current resolution proposal says nothing about this. The point is that specifying that an element group A is member of another element group B does not mean that A is a subset of B but that the group A, as a whole and not its members one by one, shall conforms to the criteria defined for the group B. In other words, for element groups the "is a member of" relationship is no transitive. This is a consequence of the semantics point discussed above. Specifying a subset of an elements group shall be achieved by defining a more constraining criterion. For if B is a group with the criterion {is blue}, I can define C, a subset of B with the following criterion: {is square AND is member of group B}. 3. About the element group notation The above has implications on the possible notations. Indeed, it is not possible to use the "region-like" notation as a Venn diagram to show the subset C inside B. Such a representation corresponds to a membership and not to an inclusion. Therefore it could be confusing. My feeling is that, as Sandy pointed out, the call-out (anchor) notation is more reliable and, in addition, is already available in the tools. Moreover the call-out notation is compatible with any kind of symbols including boxes, icons, links and text strings. I agree we have to improve the resolution on this point. Yves -----Original Message----- From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: mercredi 6 avril 2011 21:08 To: 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Pete Rivett'; 'Sysml-Rtf'; BERNARD, Yves Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Nicolas Thanks for the update. Perhaps Yves can provide a response to your issue. I would think we could always use the anchor notation to connect the Element Group to the members of the group, including other Element Groups, without ambiguity. Sandy -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 06, 2011 2:30 PM To: Friedenthal, Sanford (3101-Affiliate) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Pete Rivett; Sysml-Rtf; BERNARD, Yves Subject: Re: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, Upon closer reflection, I retract from this<> Package idea. However, the notation for<> Constraint is insufficiently specified in the resolution. In principle, this grouping construct is sufficiently expressive to represent elements anywhere in the ownership hierarchy of a model grouped in ways that one could represent in a Venn diagram. However, the notation does not discuss this adequately, not enough to clearly convey what must be done to support showing groups in sysml diagrams. SImple cases would help: - group with 1 subgroup - group with 2 disjoint subgroups - group with 2 overlapping subgroups - 3 levels of nested groups Issues include: - some elements can be in a group but there may be no diagrammatic notation for them -- e.g., ValueSpecifications are typically shown in text, not in diagrams but they can be designated to be in the scope of a group! - need for adding adequate qualification to show the elements in the scope of a group when the element itself does not have a notion of qualified name (e.g., comment) - groups of relations -- we can designate a relation to be in a group but how do we show this? These notation issues are a consequence of the scope decision (2.1) that allows anything to be grouped. - Nicolas. On Apr 6, 2011, at 10:27 AM, Sanford Friedenthal wrote: Nicolas I understand the distinction using packages to nest Element Groups without imposing any ownership on the elements of the group. I don't appreciate the motivation. Since an Element Group can include a member that is another Element Group, do we really need the nesting capability. Isn't the constrained element sufficient to establish this nesting relationship between one Element Group that is a member of another Element Group. Alternatively, can we create another relationship such as a dependency that shows that one Element Group depends on the other Element Group to reflect this nesting. We would specify that this relationship is automatically derived when one Element Group is a member of another Element Group. Sandy -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 06, 2011 1:06 PM To: Friedenthal, Sanford (3101-Affiliate) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Pete Rivett; Sysml-Rtf; BERNARD, Yves Subject: Re: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, On Apr 6, 2011, at 8:44 AM, Sanford Friedenthal wrote: Nicolas Can you clarify your proposal "The combination of a mechanism for (2.2) -- e.g., UML::Constraint -- and for (2.3) -- e.g., UM::Package -- is not ideal but I think that we can make it work reasonably well given the limitations we have from UML2.4." Are you saying that packages would be used to contain nested Element Groups that are defined by constraints? Yes. A<> Package specifies a group -- i.e., (2.3) An <> Constraint specifies the elements that are in the scope of a<> Package group -- i.e, (2.2) Can an Element Group defined by a constraint include another Element Group as a member? Isn't this a way to nest Element Groups, without imposing ownership? Yes. Yves' proposal does not address (2.3) because an<> Constraint is a PackageableElement, it cannot have nested <> Constraints! The<> Package construct addresses (2.3) because we can nest a<> Package P2 as a subgroup of another<> Package P1; i.e., P1::P2 is nested within P1. Note that the package nesting is only for the groups (ie., <> Package), not for the elements that are grouped! In particular, the ownership of elements in a given group -- i.e., <>Constraint::constrainedElement : Element[*] -- is not affected by the nested ownership of their groups -- i.e., <> Package::nestedPackage : Package[*] - Nicolas. Sandy -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 06, 2011 11:30 AM To: Friedenthal, Sanford (3101-Affiliate) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Pete Rivett; Sysml-Rtf; BERNARD, Yves Subject: Re: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, Requirement (2) below is the most challenging aspect of this issue: 2) Ability to group all elements including non-packageable elements. There are two concerns involved in this requirement: 2.1) What is the scope of element metaclasses that can be grouped? 2.2) What is the *single* mechanism we use for grouping elements within the metaclass scope? 2.3) How is the group itself specified such that we can support logical nesting of groups? It's important to acknowledge that (2.1) strongly restricts the options available for (2.2) if (2.1) = UML::PackageableElement pro: options for (2.2) include: UML::Element/PackageImport, UML::Dependency, UML::Constraint con: we can't group elements that are not a kind of UML::PackagelableElement such as UML::Feature -- e.g., UML::Attribute, UML::Operation. if (2.1) = UML::NamedElement pro: options for (2.2) include UML::Dependency, UML::Constraint con: we can't group elements that are not a kind of UML::NamedElement such as UML::Comment. if (2.1) = UML::Element pro: we can group anything con: only one option for (2.2): UML::Constraint Sandy's requirement (2) is vague about (2.1) Yves' proposed resolution satisfies (2.1) in the broadest sense but it is really about (2.2) = UML::Constraint. We need to clarify (2.1). The missing piece is (2.3), for which I proposed using UML::Package as a mechanism for modeling a group and for nesting groups. The combination of a mechanism for (2.2) -- e.g., UML::Constraint -- and for (2.3) -- e.g., UM::Package -- is not ideal but I think that we can make it work reasonably well given the limitations we have from UML2.4. Of course, this issue should be addressed in a UML RTF but given that the UML RTF is currently focused on the UML Simplification RFP, there is obviously no short-term option other than making the best we can with what we've got (i.e., UML2.4). - Nicolas. On Apr 6, 2011, at 7:29 AM, Sanford Friedenthal wrote: Eldad The only other approach we have is the one that Yves has prepared, which seems to handle the notational aspects better. Other requirements include: 5) An Element Group can have a member that is another Element Group. 6) An element can belong to more than one Element Group. -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Wednesday, April 06, 2011 9:39 AM To: Sanford Friedenthal Cc: 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Pete Rivett'; 'Sysml-Rtf'; 'BERNARD, Yves' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, I proposed to have stereotyped dependencies owned by a package. So to meet requirement 2 I just specify the dependencies to the non-packageable elements. For requirement 3, this is more tricky, I will probably end up showing a package with dashed boxes where each box represent the stereotyped dependency. This box should have a label that indicates the name of the element the stereotyped dependency points to. I can prepare an example if needed, but I am not "locked" on my proposal (i.e. I am open to other suggestions too) Eldad From: "Sanford Friedenthal" To: Eldad Palachi/Haifa/IBM@IBMIL Cc: "'Ed Seidewitz'", "'Chonoles, Michael J'", "'Pete Rivett'" , "'Sysml-Rtf'", "'BERNARD, Yves'" Date: 04/06/2011 03:57 PM Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Eldad This item could arguably be part of UML and not SysML. There have been other cases where we initiated something in SysML and they ultimately incorporated into UML. Conjugate ports and Real data type are examples. If that occurs, we can remove from SysML but we don't want to be dependent on UML adopting this feature. I suspect in any case, this would not be high on their agenda, but it is important to Systems Engr. I don't understand how hyperlinks address the ability to provide element groups as we have identified below. In your proposal, I assume the stereotyped package is dependent on each element of the group? How does a stereotyped dependency address the requirements below. If so, I am not sure it can address reqts 2 and 3 below. A good test case might be to represent an Element Group on an ibd with a set of parts that are considered to be the electrical parts or some other type of parts. Show how this would work. 1) Group not take ownership. 2) Ability to group all elements including non-packageable elements. 3) Notation considerations described below with closed boundary around selected items as part of existing diagram. 4) Defining criteria for membership in the group. -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Wednesday, April 06, 2011 2:50 AM To: Sanford Friedenthal Cc: 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Pete Rivett'; 'Sysml-Rtf'; 'BERNARD, Yves' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, A dependency can point to anything and the package does not own the element a dependency targets. I am not locked on my proposal though - I simply don't like this one and I share some of Pete's concerns. I think we need to support a notion of hyperlinks (as I think several tools already have) and once we have that we can easily have groups. I am wondering if this issue should not be addressed in UML rather than be specific to SysML (I think the discussion between Pete and Nicolas leads to this conclusion) If we implement the special notation and support the notion of groups in Rhapsody, we will probably make it available for UML too as well as any other profile or DSL - so for us it would be better not to have it as a SysML specific mechanism. Eldad From: "Sanford Friedenthal" To: "'BERNARD, Yves'", Eldad Palachi/Haifa/IBM@IBMIL Cc: "'Ed Seidewitz'", "'Chonoles, Michael J'", "'Pete Rivett'" , "'Sysml-Rtf'" Date: 04/05/2011 08:29 PM Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Eldad A couple of items regarding why we selected the use of constraint vs package for element group. Ownership vs group. Packages own the elements and Yves described this issue previously. Ability to group non-packageable elements. We need to be able to group elements that are not packagable elements such as parts. Notation considerations. We want to be able to show a boundary around a group of elements on any diagram. A package is not an effective way to do this. We need a closed boundary that does not interfere with the rest of the diagram. On a separate point, you raised the question about the distinction between view and element group. Part of the distinction relates to the items above, but as Alan suggested, we still should explore whether we can combine the view concept with the element group concept. One suggestion was that one is the subclass of the other. Sandy -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, April 05, 2011 11:17 AM To: Eldad Palachi Cc: 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Pete Rivett'; Sanford Friedenthal; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Eldad, See below. Yves -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: mardi 5 avril 2011 16:33 To: BERNARD, Yves Cc: 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Pete Rivett'; Sanford Friedenthal; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Yves, My alternative is to have a stereotyped dependency between a package and any kind of named model element so the package can be used for the grouping. These relations can be represented as boxes with dashed lines inside the package. We can also add a stereotype for a package to indicate it is a group of elements (although I don't think this is really necessary). The advantages are: 1. Tools already use packages for model organization and we also use package diagram for that. So it is easier to show the groups in the browser of the tool. [BERNARD, Yves] Packages are used for model organization through their containment capability (i.e. their ownedElement property). This is not this aspect that would be used for grouping element according to your proposal, and then I don't see what could be reused by the tools. 2. No mixing with constraints a-priori - but we can add constraints to the package to indicate the elements need to adhere to some constraint. [BERNARD, Yves] The issue explicitly requires the ability to specify a criterion, cf. also my previous mail about this point. 3. We can add other elements to the package (as owned elements) if we want - for example a package can group some elements and also own a use case as an indication that this group of element is somehow associated with the use case or we can have this package own some diagrams related to the elements being grouped. [BERNARD, Yves] The semantics of ownership is strong and is not appropriate to specify a vague relationship between an element (a use case in your example) and a group of elements. Therefore, my feeling is that the very semantics of the Package would not be used for that purpose either. Eldad From: "BERNARD, Yves" To: Eldad Palachi/Haifa/IBM@IBMIL Cc: "'Ed Seidewitz'", "'Chonoles, Michael J'", "'Pete Rivett'" , Sanford Friedenthal , "'Sysml-Rtf'" Date: 04/05/2011 03:30 PM Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements I'm not sure of that. In most cases we have to provide a justification or a rationale for any decision we make. If we choose to group some elements together rather than with some others it's because we have a reason for that. This reason is the criterion it is sometime formally specified sometimes not but it exists. The proposed implementation is semantically consistent with that. In addition, thanks to the opaque expression that one can used to specify the criterion any level of formalism can be used. What is the alternative you're thinking about? Yves -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: mardi 5 avril 2011 13:09 To: BERNARD, Yves Cc: 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Pete Rivett'; Sanford Friedenthal; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Yves, My feeling is that most of the times people (or at least some users) will just want to group things and only in special cases they will write a significant criteria - such users will ask tools to put {true} as default, but then tools would have to make a special case for such constraints (initializing the constraint in a special way). I would prefer to avoid this by separating the grouping from the constraints the group members need to adhere to. Eldad From: "BERNARD, Yves" To: Eldad Palachi/Haifa/IBM@IBMIL Cc: "'Ed Seidewitz'", "'Chonoles, Michael J'", "'Pete Rivett'" , Sanford Friedenthal , "'Sysml-Rtf'" Date: 04/05/2011 12:47 PM Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Eldad, It's already the case since the criterion can be always "true", cf. my answer to Sandy. There are examples, too. Yves -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: mardi 5 avril 2011 11:34 To: BERNARD, Yves Cc: 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Pete Rivett'; Sanford Friedenthal; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements OK - but why do we need this criteria mixed with the grouping? I guess I need an example that demonstrates a clear advantage of having the criteria instead of just having a group. Bare in mind we can always have a group first and then assign a constraint on that group which might be imposed on all the participating elements. This way I can group with or without constraint criteria. Eldad From: "BERNARD, Yves" To: Eldad Palachi/Haifa/IBM@IBMIL Cc: "'Ed Seidewitz'" , "'Chonoles, Michael J'", "'Pete Rivett'" , Sanford Friedenthal , "'Sysml-Rtf'" Date: 04/05/2011 11:20 AM Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Eldad, There is a misunderstanding here. As described in the resolution an ElementGroup is purely prescriptive: it's a constraint and its works as any other constraint. The grouping criterion is arbitrary and specified using the "specification" property of the Constraint metaclass, using OCL or any other language, including natural ones. It is the responsibility of the modeler to ensure that: * the criterion is well-formed * the grouped elements are actually able to meet the criterion No automated construction is required. That's what we mean by "light weight mechanism". My point was that for the purpose of creating collections of elements automatically based on a given criteria we don't need something new: OCL queries are fine and it is not the purpose of ElementGroups. Yves -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: mardi 5 avril 2011 09:55 To: BERNARD, Yves Cc: 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Pete Rivett'; Sanford Friedenthal; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements This mix is very confusing to me: on one hand the user can simply put elements in group by associating them with a constraint (using constrainedElement:Elemet[*]), on the other hand, there is a criteria (in OCL?) the element needs to satisfy in order to be included in the group and furthermore there is an expectation for tools to be able to create such groups by using the criteria. This sounds too complicated. Let's separate by having simple groups (without criteria) from tools capability to query elements or check if certain elements satisfy criteria. Eldad From: "BERNARD, Yves" To: Sanford Friedenthal , "'Chonoles, Michael J'", "'Sysml-Rtf'" Cc: "'Ed Seidewitz'" , "'Pete Rivett'" Date: 04/05/2011 10:38 AM Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Michael, 1. I agree with Sandy: the specification property of the Constraint metaclass has the multiplicity of [1]. 2. As defined, the group specification is one constraint but the constraint specification (i.e. the criteria) may perfectly combine several Boolean expressions using Boolean operators like AND, OR, etc... 3. In other words, your point is whether a group is descriptive or prescriptive. According to the general semantic of the Constraint metaclass it is prescriptive. Cf. UML §7.3.10, Semantics sub-clause: "A constraint is an assertion that indicates a restriction that must be satisfied by a correct design of the system". I will make it more explicit in the resolution. For descriptive purpose we can rely on mechanisms such as OCL queries. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: lundi 4 avril 2011 17:05 To: 'Chonoles, Michael J'; BERNARD, Yves; 'Sysml-Rtf' Cc: 'Ed Seidewitz'; 'Pete Rivett' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Michael 1. The constraint is necessary. It provides the means to specify the criteria to identify which elements are members of the element group. 2. The group can have more than one constraint. A criteria can include whatever is desired to specify membership in the group. 3. The notation allows you to identify the members of the group manually that satisfy the criteria. The tool should check to see if the constraint is satisfied. A query can also be performed to automatically select the members of the group based on whether they satisfy the criteria for membership. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Monday, April 04, 2011 10:24 AM To: Sanford Friedenthal; 'BERNARD, Yves'; 'Sysml-Rtf' Cc: 'Ed Seidewitz'; 'Pete Rivett' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Still a bit confused on the element group as it related to the constraint. 1) Is the constraint necessary? 2) Can the group have more than one constraint? 3) Does the constraint essentially select all elements that conform to be group members? a. In this case, what happens if the constraint prohibits membership to an element explicitly included diagrammatically? b. Else, does the constraint just impose an additional limitation on the explicitly included members? I can see good need for both types of constraints. (membership defining and additionally constraining). Can we allow for both in some way? Please give an example with meaningful criteria for both. Michael Jesse Chonoles LMCO From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Monday, April 04, 2011 9:20 AM To: 'BERNARD, Yves'; 'Sysml-Rtf' Cc: 'Ed Seidewitz'; 'Pete Rivett' Subject: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Yves Very good. A few comments below. Please include in 7.3.2.2 that an Element Group can have a name even though it is apparent since it is a named element. The symbol that the constraint is referred to is called a note in the text. Is that the proper term or should it be constraint node? Is there any ambiguity or issue with nested elements within the element group. For example, if I add a property to the element group, does this imply anything about the property owner? Should we specify what the criterion means if none is defined (i.e. default criteria)? Can we include an example problem with a meaningful criterion. Sandy From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, April 04, 2011 4:20 AM To: Sysml-Rtf (sysml-rtf@omg.org) Cc: Ed Seidewitz; Pete Rivett Subject: [SysML v1.3 RTF] #13928 : Groups of elements The resolution to the issue #13928 initially named "Partition construct" is ready for discussion. We plan to add it in one of the ballots for SysML 1.3. The last version of the resolution is attached. I'm waiting for your comments/remarks. Thanks. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. ubject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Date: Fri, 8 Apr 2011 09:10:56 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Thread-Index: Acv0iJ68G08nF28ZSx2Bm9noRyA8HgABSIeQABxgNhAAEfsbAAAE1ZOAAACeGlAAAN8kAAAWBMVAABBR9JA= From: "Pete Rivett" To: "BERNARD, Yves" , "Sanford Friedenthal" , "Rouquette, Nicolas F (313K)" Cc: "Eldad Palachi" , "Ed Seidewitz" , "Chonoles, Michael J" , "Sysml-Rtf" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p38G78EM023918 Point 1: a) I don't see why you think a Constraint is needed to specify the meaning of a Group. In many cases a name or description/comment is sufficient and in fact more expressive: you cannot use a Constraint to express the purpose or usage of the Group. The major point though is that a Package can also have a Constraint which could apply to the members so this is not a differentiation between the options: I don't understand why you would need a constraint 'for each member'. b) Just because the group members are not owned elements of the package does not stop the relationship being transitive. It's easy to define the OCL derivation for this. And, most importantly, you don't have the problem of distinguishing constrained elements from nested groups. Point 4: If someone runs a 'model validation check ' (that many UML tools have) that loops through each element checking its constraints then it's the Elements not the Group that will be reported as in error. In fact the Groups (which are themselves Constraints) won't be individually checked at all. This is entirely the opposite behavior to what's needed: using Packages for Groups and having the constraints on the Package (testing the used Elements) will report the Group as being in error - which I think is a lot more useful and practical. Point 7: I'm not particularly pushing it but the GeneralizationSet based solution would not be as you describe: you would use a subclass to represent the Group itself and the superclass would represent the partition set as a whole. E.g. the superclass might be Color and the subclasses/groups might be Yellow Objects, Blues Objects etc. Another partition set and superclass might be Shape with subclasses Square Objects, Round Objects etc. Each subclass would have a Constraint. The actual elements would be related to the Groups/subclass using a Dependency - so could be any NamedElement. Pete -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 08, 2011 6:05 AM To: Sanford Friedenthal; Pete Rivett; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, Pete, Julio, I try to gather my answer to your points. 1. About a Package-based solution Grouping elements without specifying the meaning of that group is not a very useful capability to me. I believe we need to specify the criterion in most cases, even if it is not on a formal way. Therefore specifying the constraint for that purpose would imply to do the job twice: once to assign each member to the group and once again to assign the constraint to each member. Moreover I don't see how such groups could "naturally" be nested since their members would not be owned elements. Therefore you get the same issue about transitivity. 2. About constraining a constraint ConstrainedElement is the ordered set of Elements "required to evaluate the constraint specification". Thus a constraint A constraining a constraint B has a specification referring to B itself and not the constrained elements referenced by B (that's why the ElementGroup based on Constraint cannot be transitive) 3. About the "pointer" mechanism I'm not sure to have a good understanding of Julio's proposal. Is it to use constraints as element pointers (one constraint = one pointer to one element?) and then to group those pointers in a package? The concept of pointer is fine because you can define as many pointers as you need to the same element. However I'm not sure than the constraint would be the best choice for an implementation. Indeed, a pointer is not a constraint on the pointed element and then the constraint specification would never be used. Therefore the semantics of the Constraint would not be respected. A Comment would be better in that regards but it is not a packageable element. 4. About managing criterion violation (Constraint-based solution) When the criterion of the group is violated it's up to you to decide whether you fix it by removing the element from the group (i.e. removing it from the constrainedElement property of the constraint) or modify the element to conform to the constraint. Neither the resolution nor the spec imposes anything in this regard. 5. About Membership transitivity I agree with this expectation too. Sandy proposal has to be studied but for sure the Constrained-based solution is not efficient with regards to this requirement but, as discussed above, the package-based solution doesn't seem better. 6. About dealing with membership and ownership I agree with Sandy: a constraint applies to the constrainedElements and not a priori to the elements they may own. 7. About a GereralizationSet-based solution Using Generalization sets would imply to give a common ancestor to all the members of the group and moreover to restrict this capability to classifier, excluding properties, among others. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Pete Rivett , Sanford Friedenthal , "Rouquette, Nicolas F (313K)" CC: Eldad Palachi , Ed Seidewitz , "Chonoles, Michael J" , Sysml-Rtf Date: Mon, 11 Apr 2011 13:06:29 +0200 Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Thread-Topic: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Thread-Index: Acv0iJ68G08nF28ZSx2Bm9noRyA8HgABSIeQABxgNhAAEfsbAAAE1ZOAAACeGlAAAN8kAAAWBMVAABBR9JAAjCeDkA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p3BB3i6S027656 Pete, Thanks. See my answers below. -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: vendredi 8 avril 2011 18:11 To: BERNARD, Yves; Sanford Friedenthal; Rouquette, Nicolas F (313K) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Sysml-Rtf Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Point 1: a) I don't see why you think a Constraint is needed to specify the meaning of a Group. In many cases a name or description/comment is sufficient and in fact more expressive: you cannot use a Constraint to express the purpose or usage of the Group. [BERNARD, Yves] UML states that the specification of a constraint must evaluate to a Boolean value and that the constrainedElement property designates the element referenced by this specification. As long as it is possible to describe a group while conforming to these rules, nothing precludes using a constraint for that purpose, cf. the example I gave in a previous mail. The major point though is that a Package can also have a Constraint which could apply to the members so this is not a differentiation between the options: I don't understand why you would need a constraint 'for each member'. [BERNARD, Yves] The package owning the constraint defines the context the constraint by derivation, but how to specify the constrainedElement property which is not derived? My understanding is that you shall specify the constrained elements one by one. b) Just because the group members are not owned elements of the package does not stop the relationship being transitive. It's easy to define the OCL derivation for this. [BERNARD, Yves] I was understanding that "naturally" was meaning "without any addition". And, most importantly, you don't have the problem of distinguishing constrained elements from nested groups. [BERNARD, Yves] I agree. Point 4: If someone runs a 'model validation check ' (that many UML tools have) that loops through each element checking its constraints then it's the Elements not the Group that will be reported as in error. In fact the Groups (which are themselves Constraints) won't be individually checked at all. This is entirely the opposite behavior to what's needed: using Packages for Groups and having the constraints on the Package (testing the used Elements) will report the Group as being in error - which I think is a lot more useful and practical. [BERNARD, Yves] I disagree there. Model checkers check model elements. Constraints are model elements and then should be checked also. Moreover, constrained elements have no visibility on the constraints referencing. Therefore, the constraint will be reported violated, not the element. Point 7: I'm not particularly pushing it but the GeneralizationSet based solution would not be as you describe: you would use a subclass to represent the Group itself and the superclass would represent the partition set as a whole. E.g. the superclass might be Color and the subclasses/groups might be Yellow Objects, Blues Objects etc. Another partition set and superclass might be Shape with subclasses Square Objects, Round Objects etc. Each subclass would have a Constraint. The actual elements would be related to the Groups/subclass using a Dependency - so could be any NamedElement. [BERNARD, Yves] I remember a "class-based solution" was discussing at the beginning but it has not been retained. I will try to retrieve the arguments. Pete -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 08, 2011 6:05 AM To: Sanford Friedenthal; Pete Rivett; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, Pete, Julio, I try to gather my answer to your points. 1. About a Package-based solution Grouping elements without specifying the meaning of that group is not a very useful capability to me. I believe we need to specify the criterion in most cases, even if it is not on a formal way. Therefore specifying the constraint for that purpose would imply to do the job twice: once to assign each member to the group and once again to assign the constraint to each member. Moreover I don't see how such groups could "naturally" be nested since their members would not be owned elements. Therefore you get the same issue about transitivity. 2. About constraining a constraint ConstrainedElement is the ordered set of Elements "required to evaluate the constraint specification". Thus a constraint A constraining a constraint B has a specification referring to B itself and not the constrained elements referenced by B (that's why the ElementGroup based on Constraint cannot be transitive) 3. About the "pointer" mechanism I'm not sure to have a good understanding of Julio's proposal. Is it to use constraints as element pointers (one constraint = one pointer to one element?) and then to group those pointers in a package? The concept of pointer is fine because you can define as many pointers as you need to the same element. However I'm not sure than the constraint would be the best choice for an implementation. Indeed, a pointer is not a constraint on the pointed element and then the constraint specification would never be used. Therefore the semantics of the Constraint would not be respected. A Comment would be better in that regards but it is not a packageable element. 4. About managing criterion violation (Constraint-based solution) When the criterion of the group is violated it's up to you to decide whether you fix it by removing the element from the group (i.e. removing it from the constrainedElement property of the constraint) or modify the element to conform to the constraint. Neither the resolution nor the spec imposes anything in this regard. 5. About Membership transitivity I agree with this expectation too. Sandy proposal has to be studied but for sure the Constrained-based solution is not efficient with regards to this requirement but, as discussed above, the package-based solution doesn't seem better. 6. About dealing with membership and ownership I agree with Sandy: a constraint applies to the constrainedElements and not a priori to the elements they may own. 7. About a GereralizationSet-based solution Using Generalization sets would imply to give a common ancestor to all the members of the group and moreover to restrict this capability to classifier, excluding properties, among others. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Sanford Friedenthal , "'Pete Rivett'" , "'Rouquette, Nicolas F (313K)'" CC: "'Eldad Palachi'" , "'Ed Seidewitz'" , "'Chonoles, Michael J'" , "'Sysml-Rtf'" , "'Burkhart Roger M'" Date: Mon, 11 Apr 2011 16:03:58 +0200 Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Thread-Topic: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Thread-Index: Acv0iJ68G08nF28ZSx2Bm9noRyA8HgABSIeQABxgNhAAEfsbAAAE1ZOAAACeGlAAAN8kAAAWBMVAABBR9JAAjCeDkAAHYb5gAAItLOA= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p3BE0Xwv017914 Sandy, I can make it on Thursday but it could help to go further by mail before this telecom. Yves -----Original Message----- From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: lundi 11 avril 2011 14:59 To: BERNARD, Yves; 'Pete Rivett'; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Sysml-Rtf'; 'Burkhart Roger M' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Yves, Pete Perhaps it would make sense to discuss the issues on a telecom. Roger is hosting the weekly SysML RTF telecom this Thursday at 10:00, and perhaps we could allocate some time to this item. We would need to confirm with Roger if you are interested. Sandy -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, April 11, 2011 7:06 AM To: Pete Rivett; Sanford Friedenthal; Rouquette, Nicolas F (313K) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Sysml-Rtf Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Pete, Thanks. See my answers below. -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: vendredi 8 avril 2011 18:11 To: BERNARD, Yves; Sanford Friedenthal; Rouquette, Nicolas F (313K) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Sysml-Rtf Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Point 1: a) I don't see why you think a Constraint is needed to specify the meaning of a Group. In many cases a name or description/comment is sufficient and in fact more expressive: you cannot use a Constraint to express the purpose or usage of the Group. [BERNARD, Yves] UML states that the specification of a constraint must evaluate to a Boolean value and that the constrainedElement property designates the element referenced by this specification. As long as it is possible to describe a group while conforming to these rules, nothing precludes using a constraint for that purpose, cf. the example I gave in a previous mail. The major point though is that a Package can also have a Constraint which could apply to the members so this is not a differentiation between the options: I don't understand why you would need a constraint 'for each member'. [BERNARD, Yves] The package owning the constraint defines the context the constraint by derivation, but how to specify the constrainedElement property which is not derived? My understanding is that you shall specify the constrained elements one by one. b) Just because the group members are not owned elements of the package does not stop the relationship being transitive. It's easy to define the OCL derivation for this. [BERNARD, Yves] I was understanding that "naturally" was meaning "without any addition". And, most importantly, you don't have the problem of distinguishing constrained elements from nested groups. [BERNARD, Yves] I agree. Point 4: If someone runs a 'model validation check ' (that many UML tools have) that loops through each element checking its constraints then it's the Elements not the Group that will be reported as in error. In fact the Groups (which are themselves Constraints) won't be individually checked at all. This is entirely the opposite behavior to what's needed: using Packages for Groups and having the constraints on the Package (testing the used Elements) will report the Group as being in error - which I think is a lot more useful and practical. [BERNARD, Yves] I disagree there. Model checkers check model elements. Constraints are model elements and then should be checked also. Moreover, constrained elements have no visibility on the constraints referencing. Therefore, the constraint will be reported violated, not the element. Point 7: I'm not particularly pushing it but the GeneralizationSet based solution would not be as you describe: you would use a subclass to represent the Group itself and the superclass would represent the partition set as a whole. E.g. the superclass might be Color and the subclasses/groups might be Yellow Objects, Blues Objects etc. Another partition set and superclass might be Shape with subclasses Square Objects, Round Objects etc. Each subclass would have a Constraint. The actual elements would be related to the Groups/subclass using a Dependency - so could be any NamedElement. [BERNARD, Yves] I remember a "class-based solution" was discussing at the beginning but it has not been retained. I will try to retrieve the arguments. Pete -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 08, 2011 6:05 AM To: Sanford Friedenthal; Pete Rivett; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, Pete, Julio, I try to gather my answer to your points. 1. About a Package-based solution Grouping elements without specifying the meaning of that group is not a very useful capability to me. I believe we need to specify the criterion in most cases, even if it is not on a formal way. Therefore specifying the constraint for that purpose would imply to do the job twice: once to assign each member to the group and once again to assign the constraint to each member. Moreover I don't see how such groups could "naturally" be nested since their members would not be owned elements. Therefore you get the same issue about transitivity. 2. About constraining a constraint ConstrainedElement is the ordered set of Elements "required to evaluate the constraint specification". Thus a constraint A constraining a constraint B has a specification referring to B itself and not the constrained elements referenced by B (that's why the ElementGroup based on Constraint cannot be transitive) 3. About the "pointer" mechanism I'm not sure to have a good understanding of Julio's proposal. Is it to use constraints as element pointers (one constraint = one pointer to one element?) and then to group those pointers in a package? The concept of pointer is fine because you can define as many pointers as you need to the same element. However I'm not sure than the constraint would be the best choice for an implementation. Indeed, a pointer is not a constraint on the pointed element and then the constraint specification would never be used. Therefore the semantics of the Constraint would not be respected. A Comment would be better in that regards but it is not a packageable element. 4. About managing criterion violation (Constraint-based solution) When the criterion of the group is violated it's up to you to decide whether you fix it by removing the element from the group (i.e. removing it from the constrainedElement property of the constraint) or modify the element to conform to the constraint. Neither the resolution nor the spec imposes anything in this regard. 5. About Membership transitivity I agree with this expectation too. Sandy proposal has to be studied but for sure the Constrained-based solution is not efficient with regards to this requirement but, as discussed above, the package-based solution doesn't seem better. 6. About dealing with membership and ownership I agree with Sandy: a constraint applies to the constrainedElements and not a priori to the elements they may own. 7. About a GereralizationSet-based solution Using Generalization sets would imply to give a common ancestor to all the members of the group and moreover to restrict this capability to classifier, excluding properties, among others. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=RfbZ2/+p8KJA14C0say7mENkaPcpkUQf4LReX5rS3yo=; b=SLfBs9eBGSB8fvi+ZGcJQhtJw7tYltTRgio88eQtQ0LZ8jxItLkajF638fb2doMoeP IbOdjXojypkv4QOumQ0HOBnAl+8gMbnF6zDjEgCqvA0BOm76HddC4Bda+uYR09wY8JGe /XoyYQs3iFMTmfDsu3XAXjoY6NI9zahfrH67w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=hyf/2k6yN77HSqip7sjdu0HzE8URgCxD3ZoFFgqRUUbjpt5uZnGjwzDfI79mtC/ZhP Rhl5SPYKdhn+Dl904Th0kWt43Vbux9FQSdpBAKBeQx+AkuQXdsQNcEx4nMdIGYiCo/cK 3VXqeamCNKWD3A1+mfpivfMGBmCy3kvaemwUw= From: "Sanford Friedenthal" To: "'BERNARD, Yves'" , "'Pete Rivett'" , "'Rouquette, Nicolas F \(313K\)'" Cc: "'Eldad Palachi'" , "'Ed Seidewitz'" , "'Chonoles, Michael J'" , "'Sysml-Rtf'" , "'Burkhart Roger M'" Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Date: Mon, 11 Apr 2011 11:06:23 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acv0iJ68G08nF28ZSx2Bm9noRyA8HgABSIeQABxgNhAAEfsbAAAE1ZOAAACeGlAAAN8kAAAWBMVAABBR9JAAjCeDkAAHYb5gAAItLOAAAXd3sA== Yves Sounds good. Please continue the email. In the MIWG telecom today, Pete said he could join in on the SysML RTF telecom this Thursday morning at 10:00 ET. Roger Please add the Element Group proposal to the RTF discussion agenda this Thursday and invite Pete to the telecom. Thanks. Sandy -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, April 11, 2011 10:04 AM To: Sanford Friedenthal; 'Pete Rivett'; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Sysml-Rtf'; 'Burkhart Roger M' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, I can make it on Thursday but it could help to go further by mail before this telecom. Yves -----Original Message----- From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: lundi 11 avril 2011 14:59 To: BERNARD, Yves; 'Pete Rivett'; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Sysml-Rtf'; 'Burkhart Roger M' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Yves, Pete Perhaps it would make sense to discuss the issues on a telecom. Roger is hosting the weekly SysML RTF telecom this Thursday at 10:00, and perhaps we could allocate some time to this item. We would need to confirm with Roger if you are interested. Sandy -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, April 11, 2011 7:06 AM To: Pete Rivett; Sanford Friedenthal; Rouquette, Nicolas F (313K) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Sysml-Rtf Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Pete, Thanks. See my answers below. -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: vendredi 8 avril 2011 18:11 To: BERNARD, Yves; Sanford Friedenthal; Rouquette, Nicolas F (313K) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Sysml-Rtf Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Point 1: a) I don't see why you think a Constraint is needed to specify the meaning of a Group. In many cases a name or description/comment is sufficient and in fact more expressive: you cannot use a Constraint to express the purpose or usage of the Group. [BERNARD, Yves] UML states that the specification of a constraint must evaluate to a Boolean value and that the constrainedElement property designates the element referenced by this specification. As long as it is possible to describe a group while conforming to these rules, nothing precludes using a constraint for that purpose, cf. the example I gave in a previous mail. The major point though is that a Package can also have a Constraint which could apply to the members so this is not a differentiation between the options: I don't understand why you would need a constraint 'for each member'. [BERNARD, Yves] The package owning the constraint defines the context the constraint by derivation, but how to specify the constrainedElement property which is not derived? My understanding is that you shall specify the constrained elements one by one. b) Just because the group members are not owned elements of the package does not stop the relationship being transitive. It's easy to define the OCL derivation for this. [BERNARD, Yves] I was understanding that "naturally" was meaning "without any addition". And, most importantly, you don't have the problem of distinguishing constrained elements from nested groups. [BERNARD, Yves] I agree. Point 4: If someone runs a 'model validation check ' (that many UML tools have) that loops through each element checking its constraints then it's the Elements not the Group that will be reported as in error. In fact the Groups (which are themselves Constraints) won't be individually checked at all. This is entirely the opposite behavior to what's needed: using Packages for Groups and having the constraints on the Package (testing the used Elements) will report the Group as being in error - which I think is a lot more useful and practical. [BERNARD, Yves] I disagree there. Model checkers check model elements. Constraints are model elements and then should be checked also. Moreover, constrained elements have no visibility on the constraints referencing. Therefore, the constraint will be reported violated, not the element. Point 7: I'm not particularly pushing it but the GeneralizationSet based solution would not be as you describe: you would use a subclass to represent the Group itself and the superclass would represent the partition set as a whole. E.g. the superclass might be Color and the subclasses/groups might be Yellow Objects, Blues Objects etc. Another partition set and superclass might be Shape with subclasses Square Objects, Round Objects etc. Each subclass would have a Constraint. The actual elements would be related to the Groups/subclass using a Dependency - so could be any NamedElement. [BERNARD, Yves] I remember a "class-based solution" was discussing at the beginning but it has not been retained. I will try to retrieve the arguments. Pete -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 08, 2011 6:05 AM To: Sanford Friedenthal; Pete Rivett; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, Pete, Julio, I try to gather my answer to your points. 1. About a Package-based solution Grouping elements without specifying the meaning of that group is not a very useful capability to me. I believe we need to specify the criterion in most cases, even if it is not on a formal way. Therefore specifying the constraint for that purpose would imply to do the job twice: once to assign each member to the group and once again to assign the constraint to each member. Moreover I don't see how such groups could "naturally" be nested since their members would not be owned elements. Therefore you get the same issue about transitivity. 2. About constraining a constraint ConstrainedElement is the ordered set of Elements "required to evaluate the constraint specification". Thus a constraint A constraining a constraint B has a specification referring to B itself and not the constrained elements referenced by B (that's why the ElementGroup based on Constraint cannot be transitive) 3. About the "pointer" mechanism I'm not sure to have a good understanding of Julio's proposal. Is it to use constraints as element pointers (one constraint = one pointer to one element?) and then to group those pointers in a package? The concept of pointer is fine because you can define as many pointers as you need to the same element. However I'm not sure than the constraint would be the best choice for an implementation. Indeed, a pointer is not a constraint on the pointed element and then the constraint specification would never be used. Therefore the semantics of the Constraint would not be respected. A Comment would be better in that regards but it is not a packageable element. 4. About managing criterion violation (Constraint-based solution) When the criterion of the group is violated it's up to you to decide whether you fix it by removing the element from the group (i.e. removing it from the constrainedElement property of the constraint) or modify the element to conform to the constraint. Neither the resolution nor the spec imposes anything in this regard. 5. About Membership transitivity I agree with this expectation too. Sandy proposal has to be studied but for sure the Constrained-based solution is not efficient with regards to this requirement but, as discussed above, the package-based solution doesn't seem better. 6. About dealing with membership and ownership I agree with Sandy: a constraint applies to the constrainedElements and not a priori to the elements they may own. 7. About a GereralizationSet-based solution Using Generalization sets would imply to give a common ancestor to all the members of the group and moreover to restrict this capability to classifier, excluding properties, among others. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Date: Mon, 11 Apr 2011 08:29:51 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Thread-Index: Acv0iJ68G08nF28ZSx2Bm9noRyA8HgABSIeQABxgNhAAEfsbAAAE1ZOAAACeGlAAAN8kAAAWBMVAABBR9JAAjCeDkAAJ+LKw From: "Pete Rivett" To: "BERNARD, Yves" , "Sanford Friedenthal" , "Rouquette, Nicolas F (313K)" Cc: "Eldad Palachi" , "Ed Seidewitz" , "Chonoles, Michael J" , "Sysml-Rtf" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p3BFPtUZ029620 See [PJR] below. -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, April 11, 2011 4:06 AM To: Pete Rivett; Sanford Friedenthal; Rouquette, Nicolas F (313K) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Sysml-Rtf Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Pete, Thanks. See my answers below. -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: vendredi 8 avril 2011 18:11 To: BERNARD, Yves; Sanford Friedenthal; Rouquette, Nicolas F (313K) Cc: Eldad Palachi; Ed Seidewitz; Chonoles, Michael J; Sysml-Rtf Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Point 1: a) I don't see why you think a Constraint is needed to specify the meaning of a Group. In many cases a name or description/comment is sufficient and in fact more expressive: you cannot use a Constraint to express the purpose or usage of the Group. [BERNARD, Yves] UML states that the specification of a constraint must evaluate to a Boolean value and that the constrainedElement property designates the element referenced by this specification. As long as it is possible to describe a group while conforming to these rules, nothing precludes using a constraint for that purpose, cf. the example I gave in a previous mail. [PJR] You do not address my point of how a Boolean expression is used to convey 'meaning' The major point though is that a Package can also have a Constraint which could apply to the members so this is not a differentiation between the options: I don't understand why you would need a constraint 'for each member'. [BERNARD, Yves] The package owning the constraint defines the context the constraint by derivation, but how to specify the constrainedElement property which is not derived? My understanding is that you shall specify the constrained elements one by one. [PJR] The Package itself would be the single constrainedElement: the constraint would express that each used element satisfies a certain condition. b) Just because the group members are not owned elements of the package does not stop the relationship being transitive. It's easy to define the OCL derivation for this. [BERNARD, Yves] I was understanding that "naturally" was meaning "without any addition". And, most importantly, you don't have the problem of distinguishing constrained elements from nested groups. [BERNARD, Yves] I agree. Point 4: If someone runs a 'model validation check ' (that many UML tools have) that loops through each element checking its constraints then it's the Elements not the Group that will be reported as in error. In fact the Groups (which are themselves Constraints) won't be individually checked at all. This is entirely the opposite behavior to what's needed: using Packages for Groups and having the constraints on the Package (testing the used Elements) will report the Group as being in error - which I think is a lot more useful and practical. [BERNARD, Yves] I disagree there. Model checkers check model elements. Constraints are model elements and then should be checked also. Moreover, constrained elements have no visibility on the constraints referencing. Therefore, the constraint will be reported violated, not the element. [PJR] this does not make sense to me, but I'll have to defer to the vendors who have implemented such checking in their tools. Point 7: I'm not particularly pushing it but the GeneralizationSet based solution would not be as you describe: you would use a subclass to represent the Group itself and the superclass would represent the partition set as a whole. E.g. the superclass might be Color and the subclasses/groups might be Yellow Objects, Blues Objects etc. Another partition set and superclass might be Shape with subclasses Square Objects, Round Objects etc. Each subclass would have a Constraint. The actual elements would be related to the Groups/subclass using a Dependency - so could be any NamedElement. [BERNARD, Yves] I remember a "class-based solution" was discussing at the beginning but it has not been retained. I will try to retrieve the arguments. Pete -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 08, 2011 6:05 AM To: Sanford Friedenthal; Pete Rivett; 'Rouquette, Nicolas F (313K)' Cc: 'Eldad Palachi'; 'Ed Seidewitz'; 'Chonoles, Michael J'; 'Sysml-Rtf' Subject: RE: Ex: RE: [SysML v1.3 RTF] #13928 : Groups of elements Sandy, Pete, Julio, I try to gather my answer to your points. 1. About a Package-based solution Grouping elements without specifying the meaning of that group is not a very useful capability to me. I believe we need to specify the criterion in most cases, even if it is not on a formal way. Therefore specifying the constraint for that purpose would imply to do the job twice: once to assign each member to the group and once again to assign the constraint to each member. Moreover I don't see how such groups could "naturally" be nested since their members would not be owned elements. Therefore you get the same issue about transitivity. 2. About constraining a constraint ConstrainedElement is the ordered set of Elements "required to evaluate the constraint specification". Thus a constraint A constraining a constraint B has a specification referring to B itself and not the constrained elements referenced by B (that's why the ElementGroup based on Constraint cannot be transitive) 3. About the "pointer" mechanism I'm not sure to have a good understanding of Julio's proposal. Is it to use constraints as element pointers (one constraint = one pointer to one element?) and then to group those pointers in a package? The concept of pointer is fine because you can define as many pointers as you need to the same element. However I'm not sure than the constraint would be the best choice for an implementation. Indeed, a pointer is not a constraint on the pointed element and then the constraint specification would never be used. Therefore the semantics of the Constraint would not be respected. A Comment would be better in that regards but it is not a packageable element. 4. About managing criterion violation (Constraint-based solution) When the criterion of the group is violated it's up to you to decide whether you fix it by removing the element from the group (i.e. removing it from the constrainedElement property of the constraint) or modify the element to conform to the constraint. Neither the resolution nor the spec imposes anything in this regard. 5. About Membership transitivity I agree with this expectation too. Sandy proposal has to be studied but for sure the Constrained-based solution is not efficient with regards to this requirement but, as discussed above, the package-based solution doesn't seem better. 6. About dealing with membership and ownership I agree with Sandy: a constraint applies to the constrainedElements and not a priori to the elements they may own. 7. About a GereralizationSet-based solution Using Generalization sets would imply to give a common ancestor to all the members of the group and moreover to restrict this capability to classifier, excluding properties, among others. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: Issue 13928 about groups X-KeepSent: 08237A5F:0C90F6FB-C225786C:0038E7A4; type=4; name=$KeepSent To: sysml-rtf@omg.org, Sandy Friedenthal (safriedenthal@gmail.com) X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009 From: Eldad Palachi Date: Fri, 8 Apr 2011 13:48:48 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5.1FP4|July 25, 2010) at 08/04/2011 13:48:56 Sandy, Yves, all, Apart from the on going technical discussion which seems to be going in various directions, there is a tool implementation perspective I would like to raise. The resolution currently proposed and the special notation required in the issue means that tools cannot rely on their profiling mechanisms, in other words, there will be a need to write specialized code to support this notion of groups especially if tools are expected to really leverage the readability of models using this concept. We already have ports and flows that would require specialized implementation, especially if a tools need to give it some meaning for execution or analysis. While ports and flows issues address SysML capability to describe interfaces, the groups issue is about model management or readability of models, which is important but less significant in my opinion. Therefore, I think that one complex issue that requires special coding in the tools is enough for one RTF and I propose to defer the grouping issues to another RTF or "bump it up" to UML. Of course, I support to continue the on-going discussion, but I really think that having another issue that requires special coding in tools would further delay the acceptance of SysML 1.3 by tools. In general, I think that other than ports and flows, the rest of the RTF 1,3 issue resolutions should not "push the boundary" (as Roger says) of an RTF. Eldad Subject: Issue 13928 about groups X-KeepSent: 08237A5F:0C90F6FB-C225786C:0038E7A4; type=4; name=$KeepSent To: sysml-rtf@omg.org, Sandy Friedenthal (safriedenthal@gmail.com) X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009 From: Eldad Palachi Date: Fri, 8 Apr 2011 13:48:48 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5.1FP4|July 25, 2010) at 08/04/2011 13:48:56 Sandy, Yves, all, Apart from the on going technical discussion which seems to be going in various directions, there is a tool implementation perspective I would like to raise. The resolution currently proposed and the special notation required in the issue means that tools cannot rely on their profiling mechanisms, in other words, there will be a need to write specialized code to support this notion of groups especially if tools are expected to really leverage the readability of models using this concept. We already have ports and flows that would require specialized implementation, especially if a tools need to give it some meaning for execution or analysis. While ports and flows issues address SysML capability to describe interfaces, the groups issue is about model management or readability of models, which is important but less significant in my opinion. Therefore, I think that one complex issue that requires special coding in the tools is enough for one RTF and I propose to defer the grouping issues to another RTF or "bump it up" to UML. Of course, I support to continue the on-going discussion, but I really think that having another issue that requires special coding in tools would further delay the acceptance of SysML 1.3 by tools. In general, I think that other than ports and flows, the rest of the RTF 1,3 issue resolutions should not "push the boundary" (as Roger says) of an RTF. Eldad From: "BERNARD, Yves" To: Sanford Friedenthal , "'Eldad Palachi'" , "sysml-rtf@omg.org" , "\"'Sandy Friedenthal'\"@omg.org" <"'Sandy Friedenthal'"@omg.org> Date: Fri, 8 Apr 2011 15:11:48 +0200 Subject: RE: Issue 13928 about groups Thread-Topic: Issue 13928 about groups Thread-Index: Acv12o0m7KvMPh8DS5q0m6RaBFcVMAAEQHNQAACJL/A= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p38D7rEM001665 Eldad, I fully agree with Sandy and I would confirm that the callout notation of the resolution fully comply with the current standard notation of a Constraint. Yves -----Original Message----- From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: vendredi 8 avril 2011 14:56 To: 'Eldad Palachi'; sysml-rtf@omg.org; "'Sandy Friedenthal'"@omg.org Subject: RE: Issue 13928 about groups Eldad I appreciate the tool vendor and other concerns regarding the scope of changes for a particular revision. Clearly, ports and flows is a significant update for v1.3. I do think we should move ahead to try to address this issue, and we can make a decision once we have a solution as to whether it would fit in 1.3 from a timing and scope perspective. It may turn out the changes are not that significant. For example, if we leveraged the callout notation, then this may not introduce a substantial change from a tooling perspective relative to the current capability. I also would like to noted that this capability may be very significant for end users in systems engineering. In particular, we often see many different types of partitioning that engineers want to create and communicate. We want to facilitate this capability and minimize their impact on the model structure. Sandy -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Friday, April 08, 2011 6:49 AM To: sysml-rtf@omg.org; Sandy Friedenthal Subject: Issue 13928 about groups Sandy, Yves, all, Apart from the on going technical discussion which seems to be going in various directions, there is a tool implementation perspective I would like to raise. The resolution currently proposed and the special notation required in the issue means that tools cannot rely on their profiling mechanisms, in other words, there will be a need to write specialized code to support this notion of groups especially if tools are expected to really leverage the readability of models using this concept. We already have ports and flows that would require specialized implementation, especially if a tools need to give it some meaning for execution or analysis. While ports and flows issues address SysML capability to describe interfaces, the groups issue is about model management or readability of models, which is important but less significant in my opinion. Therefore, I think that one complex issue that requires special coding in the tools is enough for one RTF and I propose to defer the grouping issues to another RTF or "bump it up" to UML. Of course, I support to continue the on-going discussion, but I really think that having another issue that requires special coding in tools would further delay the acceptance of SysML 1.3 by tools. In general, I think that other than ports and flows, the rest of the RTF 1,3 issue resolutions should not "push the boundary" (as Roger says) of an RTF. Eldad This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: Issue 13928 about groups X-KeepSent: 4AF7FCB5:966A059A-C225786C:004F11D2; type=4; name=$KeepSent To: "BERNARD, Yves" , Sanford Friedenthal Cc: "sysml-rtf@omg.org" , "\"'Sandy Friedenthal'\"@omg.org" <"'Sandy Friedenthal'"@omg.org> X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009 From: Eldad Palachi Date: Fri, 8 Apr 2011 17:34:02 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5.1FP4|July 25, 2010) at 08/04/2011 17:34:13 Yes, but not the other type of notation. I am good with the proposal to define a solution first and then discuss if this falls into the RTF scope or not - just wanted to raise this aspect as well. Eldad From: "BERNARD, Yves" To: Sanford Friedenthal , Eldad Palachi/Haifa/IBM@IBMIL, "sysml-rtf@omg.org" , "\"'Sandy Friedenthal'\"@omg.org" <"'Sandy Friedenthal'"@omg.org> Date: 04/08/2011 04:11 PM Subject: RE: Issue 13928 about groups Eldad, I fully agree with Sandy and I would confirm that the callout notation of the resolution fully comply with the current standard notation of a Constraint. Yves -----Original Message----- From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: vendredi 8 avril 2011 14:56 To: 'Eldad Palachi'; sysml-rtf@omg.org; "'Sandy Friedenthal'"@omg.org Subject: RE: Issue 13928 about groups Eldad I appreciate the tool vendor and other concerns regarding the scope of changes for a particular revision. Clearly, ports and flows is a significant update for v1.3. I do think we should move ahead to try to address this issue, and we can make a decision once we have a solution as to whether it would fit in 1.3 from a timing and scope perspective. It may turn out the changes are not that significant. For example, if we leveraged the callout notation, then this may not introduce a substantial change from a tooling perspective relative to the current capability. I also would like to noted that this capability may be very significant for end users in systems engineering. In particular, we often see many different types of partitioning that engineers want to create and communicate. We want to facilitate this capability and minimize their impact on the model structure. Sandy -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Friday, April 08, 2011 6:49 AM To: sysml-rtf@omg.org; Sandy Friedenthal Subject: Issue 13928 about groups Sandy, Yves, all, Apart from the on going technical discussion which seems to be going in various directions, there is a tool implementation perspective I would like to raise. The resolution currently proposed and the special notation required in the issue means that tools cannot rely on their profiling mechanisms, in other words, there will be a need to write specialized code to support this notion of groups especially if tools are expected to really leverage the readability of models using this concept. We already have ports and flows that would require specialized implementation, especially if a tools need to give it some meaning for execution or analysis. While ports and flows issues address SysML capability to describe interfaces, the groups issue is about model management or readability of models, which is important but less significant in my opinion. Therefore, I think that one complex issue that requires special coding in the tools is enough for one RTF and I propose to defer the grouping issues to another RTF or "bump it up" to UML. Of course, I support to continue the on-going discussion, but I really think that having another issue that requires special coding in tools would further delay the acceptance of SysML 1.3 by tools. In general, I think that other than ports and flows, the rest of the RTF 1,3 issue resolutions should not "push the boundary" (as Roger says) of an RTF. Eldad This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. :wq :wq DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=+yONf2hcq+9a4FsO4MI3xvdDulSZYueJ4ucrifEjT74=; b=CKV31RkaesCbirGfpUrKMwIgPqBEHDQnRP8xm8BpqC3P8grRknKkUn/Y5dNUsnttMe G4I4eEEoLTs7YcEXKsFZmbhZM5ncmpldS99kFVnLenkg0FMijKVCXdDnQvx8gYWpRnER IV9hd3HBnXjwr3z9NE1frL536YAyydV1MEtxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=VxpQPhSgK7+uyu9uMEmWzNb6eVFxogrtOEM1i6T+8BmEzyFcEbHW2BHNu+ycpRbHTn czL1wxdFYhEeAI7Utsm5vjAdXz0Ejmj4cSJdKbQuCjIMb7ffdJ1YJ+UufVqbgFqU1TYt QkKTzcRXB9wRnJy1D7HFv2xGIj8dQSuesnA34= From: "Sanford Friedenthal" To: "'BERNARD, Yves'" Cc: "'Ed Seidewitz'" , "'Sysml-Rtf'" , "'Pete Rivett'" , "'Rouquette, Nicolas F \(313K\)'" , "'Eldad Palachi'" , "'Julio Medina'" Subject: RE: [SysML #13928 WG] Wiki page created Date: Mon, 25 Apr 2011 17:39:36 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwBBHRalJ9mZkfKSAy0GL/yWNP8ggCjI9YA Yves This looks like an excellent capture of the requirements, issues, and proposals. We can return to this issue shortly, but we will probably put our immediate attention on finishing up P&F and on cleaning up the RTF issue backlog. Thanks again. All, Please review and comment on your proposal so we have a solid baseline for future discussion. Thanks. Sandy From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 22, 2011 11:47 AM To: Sanford Friedenthal; 'Pete Rivett'; 'Rouquette, Nicolas F (313K)'; 'Eldad Palachi'; Julio Medina Cc: 'Ed Seidewitz'; 'Sysml-Rtf' Subject: [SysML #13928 WG] Wiki page created I have created a wiki page for this workgroup: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf3:groups:issue_13928_wg A first deck of slides has been uploaded there with a summary of our exchanges. Feel free to amend. You are of course invited to provide further contributions. Based on our last exchanges on this topic, I.ve derived a list of members. If others are interested, please let me know. Thanks. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: Re: [SysML #13928 WG] Wiki page created X-KeepSent: 32CE4A88:38077DC1-C225787E:001EB1EE; type=4; name=$KeepSent To: "BERNARD, Yves" Cc: "'Ed Seidewitz'" , Julio Medina , "'Rouquette, Nicolas F (313K)'" , "'Pete Rivett'" , Sanford Friedenthal , "'Sysml-Rtf'" X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009 From: Eldad Palachi Date: Tue, 26 Apr 2011 08:36:46 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5.2FP1|November 29, 2010) at 26/04/2011 08:36:55 Hi Yves, Thanks. I added one proposal slide for consideration. Eldad (See attached file: issue_13928_grouping_elements_110426.ppt) From: "BERNARD, Yves" To: Sanford Friedenthal , "'Pete Rivett'" , "'Rouquette, Nicolas F (313K)'" , Eldad Palachi/Haifa/IBM@IBMIL, Julio Medina Cc: "'Ed Seidewitz'" , "'Sysml-Rtf'" Date: 04/22/2011 06:48 PM Subject: [SysML #13928 WG] Wiki page created I have created a wiki page for this workgroup: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf3:groups:issue_13928_wg A first deck of slides has been uploaded there with a summary of our exchanges. Feel free to amend. You are of course invited to provide further contributions. Based on our last exchanges on this topic, Iāve derived a list of members. If others are interested, please let me know. Thanks. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. issue_13928_grouping_elements_110426.ppt From: "BERNARD, Yves" To: Eldad Palachi CC: "'Ed Seidewitz'" , Julio Medina , "'Rouquette, Nicolas F (313K)'" , "'Pete Rivett'" , Sanford Friedenthal , "'Sysml-Rtf'" Date: Tue, 3 May 2011 17:12:50 +0200 Subject: RE: [SysML #13928 WG] Wiki page created Thread-Topic: [SysML #13928 WG] Wiki page created Thread-Index: AcwD0/RSpv7EEZfEShWiN8Viq5kGagFzR3vg Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id p43F7xu1012316 Eldad, Thanks. I've updated the slide deck with your proposal. I will upload the new version tomorrow morning, Toulouse time ;o) Yves -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: mardi 26 avril 2011 07:37 To: BERNARD, Yves Cc: 'Ed Seidewitz'; Julio Medina; 'Rouquette, Nicolas F (313K)'; 'Pete Rivett'; Sanford Friedenthal; 'Sysml-Rtf' Subject: Re: [SysML #13928 WG] Wiki page created Hi Yves, Thanks. I added one proposal slide for consideration. Eldad (See attached file: issue_13928_grouping_elements_110426.ppt) From: "BERNARD, Yves" To: Sanford Friedenthal , "'Pete Rivett'" , "'Rouquette, Nicolas F (313K)'" , Eldad Palachi/Haifa/IBM@IBMIL, Julio Medina Cc: "'Ed Seidewitz'" , "'Sysml-Rtf'" Date: 04/22/2011 06:48 PM Subject: [SysML #13928 WG] Wiki page created I have created a wiki page for this workgroup: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf3:groups:issue_13928_wg A first deck of slides has been uploaded there with a summary of our exchanges. Feel free to amend. You are of course invited to provide further contributions. Based on our last exchanges on this topic, Iāve derived a list of members. If others are interested, please let me know. Thanks. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: "Sysml-Rtf (sysml-rtf@omg.org)" Date: Thu, 28 Jul 2011 15:33:26 +0200 Subject: [SysML v1.3 RTF] Ballot6: #13928 Thread-Topic: [SysML v1.3 RTF] Ballot6: #13928 Thread-Index: AcxNKu4TnDKkIPO1RQ6VGhn/9G5kqA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US The discussion of #13928 could also consider the material which have been made available on the wiki (http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf3:groups:issue_13928_wg) and which summarizes the requirements, all the proposals, the related discussions and open points. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.