Issue 10090: BMM: UML Associations (bmm-ftf) Source: Inferware (Mr. John Hall, john.hall@modelsys.com johnhallms@hotmail.com) Nature: Uncategorized Issue Severity: Summary: The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases "is" or "has" has been omitted). These have been preserved in the proposed interim specification with the concepts catalog in SBVR Structured English. In the UML class model developed for the RFC submission, the verb phrases were added to associations as "ends" (role names). There are two small problems: · In many cases they read well as verb-oriented role names but in some cases they do not. · They have been placed on the association connectors at the wrong ends - normally a role name is placed at the line end where the class that plays the role is connected. For example, in the fragment below: Vision is made operative by mission, and amplified by goal. The roles read intuitively with the "clockwise" convention, but reading a UML class model correctly should not depend on positioning. Proposal 1) Move the association phrases to the appropriate ends of association lines for them to be role names, e.g. 2) In the UML class model, replace verb-oriented role names with noun-oriented names, if the reading of the model would be improved. For example, replace "goal amplifies vision" with "goal [has the role] amplifier of vision" 3) Where there are necessities in the Concepts Catalog that constrain cardinality, show them explicitly on the UML class model. For example, "mission makes at most one vision operative", "goal amplifies at most one vision". 4) Create a mapping of the fact types in the Concepts Catalog to the associations in the UML class model. Resolution: To be discussed Revised Text: Not yet decided Disposition: Open Resolution: see dtc/2007-08-06 for details http://www.omg.org/cgi-bin/doc?dtc/2007-08-06 Revised Text: Actions taken: August 7, 2006: received issue October 28, 2008: closed issue Discussion: End of Annotations:===== s is issue # 10090 From: John Hall see attached, file will also be posted in FTF issues directory which is located at ftp://ftp.omg.org/pub/bmm-ftf/issues BMM: UML Associations The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases "is" or "has" has been omitted). These have been preserved in the proposed interim specification with the concepts catalog in SBVR Structured English. In the UML class model developed for the RFC submission, the verb phrases were added to associations as "ends" (role names). There are two small problems: · In many cases they read well as verb-oriented role names but in some cases they do not. · They have been placed on the association connectors at the wrong ends - normally a role name is placed at the line end where the class that plays the role is connected. For example, in the fragment below: Vision is made operative by mission, and amplified by goal. The roles read intuitively with the "clockwise" convention, but reading a UML class model correctly should not depend on positioning. Proposal 1) Move the association phrases to the appropriate ends of association lines for them to be role names, e.g. 2) In the UML class model, replace verb-oriented role names with noun-oriented names, if the reading of the model would be improved. For example, replace "goal amplifies vision" with "goal [has the role] amplifier of vision" 3) Where there are necessities in the Concepts Catalog that constrain cardinality, show them explicitly on the UML class model. For example, "mission makes at most one vision operative", "goal amplifies at most one vision". 4) Create a mapping of the fact types in the Concepts Catalog to the associations in the UML class model. Resolution: To be discussed Revised Text: Not yet decided Disposition: Open Date: Tue, 29 Aug 2006 10:01:36 +0200 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: Juergen Boldt Cc: issues@omg.org, bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE Hello all, Attached are two documents: - A simplified proposal for resolution of issue 10090 so that it deals only with presentation. Any changes to role names should be handled as a separate issue, aster we have dealt with some other issues, including 10093 and 10114 - A new version of chapter 8, with the UML fragment diagrams updated Would all BMM FTF members please vote by end of September 1 on the following: 1) Chapter 8 of the adopted specification should be replaced by the new version with the updated UML fragment diagrams, and the overview of the UML class model in Chapter 7 updated to be consistent with the chapter 8 diagrams. 2) If the BMM FTF votes for an interim specification to be published (see Issue 10094), this change should be included in it. Best wishes, John Juergen Boldt wrote: This is issue # 10090 From: John Hall see attached, file will also be posted in FTF issues directory which is located at ftp://ftp.omg.org/pub/bmm-ftf/issues BMM: UML Associations The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases "is" or "has" has been omitted). These have been preserved in the proposed interim specification with the concepts catalog in SBVR Structured English. In the UML class model developed for the RFC submission, the verb phrases were added to associations as "ends" (role names). There are two small problems: · In many cases they read well as verb-oriented role names but in some cases they do not. · They have been placed on the association connectors at the wrong ends - normally a role name is placed at the line end where the class that plays the role is connected. For example, in the fragment below: Vision is made operative by mission, and amplified by goal. The roles read intuitively with the "clockwise" convention, but reading a UML class model correctly should not depend on positioning. Proposal 1) Move the association phrases to the appropriate ends of association lines for them to be role names, e.g. 2) In the UML class model, replace verb-oriented role names with noun-oriented names, if the reading of the model would be improved. For example, replace "goal amplifies vision" with "goal [has the role] amplifier of vision" 3) Where there are necessities in the Concepts Catalog that constrain cardinality, show them explicitly on the UML class model. For example, "mission makes at most one vision operative", "goal amplifies at most one vision". 4) Create a mapping of the fact types in the Concepts Catalog to the associations in the UML class model. Resolution: To be discussed Revised Text: Not yet decided Disposition: Open -------------------------------------------------------------------------------- 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 BMM Issue 10090 UML Associations.doc BMM_8_UML_diagrams.pdf Disposition: Open OMG Issue No: 10090 Title: BMM: UML Associations Source: John Hall, Business Rules Group John Hall Summary: The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases .is. or .has. has been omitted). These have been preserved in the proposed interim specification with the concepts catalog in SBVR Structured English. In the UML class model developed for the RFC submission, the verb phrases were added to associations as .ends. (role names). There are two small problems: · They have been placed on the association connectors at the wrong ends - normally a role name is placed at the line end where the class that plays the role is connected. · In many cases they read well as verb-oriented role names but in some cases they do not. For example, in the fragment below: Vision is made operative by mission, and amplified by goal. The roles read intuitively with the .clockwise. convention, but reading a UML class model correctly should not depend on positioning. Resolution: 1) Move the association phrases to the appropriate ends of association lines for them to be role names, e.g. 2) Where there are necessities in the Concepts Catalog that constrain cardinality, show them explicitly on the UML class model. For example, .mission makes at most one vision operative., .goal amplifies at most one vision.. 3) Deal with .verb-oriented. role names as a separate issue Revised Text: Replace chapter 8 of the FAS with the content of the attached document .BMM_8_UML_diagrams.pdf. Update the BMM overview UML model in chapter 7 of the FAS to be consistent with the updated diagrams in chapter 8. Disposition: Open From: "Markus Schacher" To: Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE - ballot number Date: Thu, 31 Aug 2006 14:53:48 +0200 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbLcJAKXcF4rPj/Rdeif4JO/xtSLABi10og KnowGravity votes YES for 1) and 2) on BMM ballot 2. Regards, Markus Schacher KnowBody -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Dienstag, 29. August 2006 15:42 To: john.hall@modelsys.com Cc: Juergen Boldt; issues@omg.org; bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE - ballot number Hello all, Following Pete Rivett's advice about issue 1094 and ballot numbers, I'll assign the ballot number "BMM ballot 2" to the request for a vote on Issue 1090 Regards, John John Hall wrote: Hello all, Attached are two documents: - A simplified proposal for resolution of issue 10090 so that it deals only with presentation. Any changes to role names should be handled as a separate issue, aster we have dealt with some other issues, including 10093 and 10114 - A new version of chapter 8, with the UML fragment diagrams updated Would all BMM FTF members please vote by end of September 1 on the following: 1) Chapter 8 of the adopted specification should be replaced by the new version with the updated UML fragment diagrams, and the overview of the UML class model in Chapter 7 updated to be consistent with the chapter 8 diagrams. 2) If the BMM FTF votes for an interim specification to be published (see Issue 10094), this change should be included in it. Best wishes, John Juergen Boldt wrote: This is issue # 10090 From: John Hall see attached, file will also be posted in FTF issues directory which is located at ftp://ftp.omg.org/pub/bmm-ftf/issues BMM: UML Associations The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases "is" or "has" has been omitted). These have been preserved in the proposed interim specification with the concepts catalog in SBVR Structured English. In the UML class model developed for the RFC submission, the verb phrases were added to associations as "ends" (role names). There are two small problems: · In many cases they read well as verb-oriented role names but in some cases they do not. · They have been placed on the association connectors at the wrong ends - normally a role name is placed at the line end where the class that plays the role is connected. For example, in the fragment below: Vision is made operative by mission, and amplified by goal. The roles read intuitively with the "clockwise" convention, but reading a UML class model correctly should not depend on positioning. Proposal 1) Move the association phrases to the appropriate ends of association lines for them to be role names, e.g. 2) In the UML class model, replace verb-oriented role names with noun-oriented names, if the reading of the model would be improved. For example, replace "goal amplifies vision" with "goal [has the role] amplifier of vision" 3) Where there are necessities in the Concepts Catalog that constrain cardinality, show them explicitly on the UML class model. For example, "mission makes at most one vision operative", "goal amplifies at most one vision". 4) Create a mapping of the fact types in the Concepts Catalog to the associations in the UML class model. Resolution: To be discussed Revised Text: Not yet decided Disposition: Open -------------------------------------------------------------------------------- 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 10090 -- BMM FTF issue - CALL FOR VOTE Date: Fri, 1 Sep 2006 03:16:43 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 10090 -- BMM FTF issue - CALL FOR VOTE Thread-Index: AcbLQY+LHxf/tt4cQn+hqbx9hC3iPACJvDjg From: "Pete Rivett" To: Cc: I must confess that I have a real mental block on this: the verb phrases are so unlike roles that I have genuine trouble understanding whether the swapping of names on ends makes more sense than the original. If anything I'm inclined to think not. For example the proposal, in Figure 8.8, there is a proposed property directive::governed_by. This seems the wrong way round: I would expect to see course_of_action::governed_by which is a property that would return the things that the course of action is governed by (i.e. directives). What's the reason for putting off the renaming of roles? Pete -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Tuesday, August 29, 2006 9:02 AM To: Juergen Boldt Cc: issues@omg.org; bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE Hello all, Attached are two documents: - A simplified proposal for resolution of issue 10090 so that it deals only with presentation. Any changes to role names should be handled as a separate issue, aster we have dealt with some other issues, including 10093 and 10114 - A new version of chapter 8, with the UML fragment diagrams updated Would all BMM FTF members please vote by end of September 1 on the following: 1) Chapter 8 of the adopted specification should be replaced by the new version with the updated UML fragment diagrams, and the overview of the UML class model in Chapter 7 updated to be consistent with the chapter 8 diagrams. 2) If the BMM FTF votes for an interim specification to be published (see Issue 10094), this change should be included in it. Best wishes, John Juergen Boldt wrote: This is issue # 10090 From: John Hall see attached, file will also be posted in FTF issues directory which is located at ftp://ftp.omg.org/pub/bmm-ftf/issues BMM: UML Associations The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases "is" or "has" has been omitted). These have been preserved in the proposed interim specification with the concepts catalog in SBVR Structured English. In the UML class model developed for the RFC submission, the verb phrases were added to associations as "ends" (role names). There are two small problems: · In many cases they read well as verb-oriented role names but in some cases they do not. · They have been placed on the association connectors at the wrong ends - normally a role name is placed at the line end where the class that plays the role is connected. For example, in the fragment below: Vision is made operative by mission, and amplified by goal. The roles read intuitively with the "clockwise" convention, but reading a UML class model correctly should not depend on positioning. Proposal 1) Move the association phrases to the appropriate ends of association lines for them to be role names, e.g. 2) In the UML class model, replace verb-oriented role names with noun-oriented names, if the reading of the model would be improved. For example, replace "goal amplifies vision" with "goal [has the role] amplifier of vision" 3) Where there are necessities in the Concepts Catalog that constrain cardinality, show them explicitly on the UML class model. For example, "mission makes at most one vision operative", "goal amplifies at most one vision". 4) Create a mapping of the fact types in the Concepts Catalog to the associations in the UML class model. Resolution: To be discussed Revised Text: Not yet decided Disposition: Open -------------------------------------------------------------------------------- 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 10090 -- BMM FTF issue - CALL FOR VOTE Date: Fri, 1 Sep 2006 12:25:42 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 10090 -- BMM FTF issue - CALL FOR VOTE Thread-Index: AcbLQY+LHxf/tt4cQn+hqbx9hC3iPACJvDjgABHjQAA= From: "LONJON Antoine" To: "Pete Rivett" , Cc: Pete, I think I am in close agreement with you. I usually prefer role names. But we have two main issues here: 1. A practical issue: the search for accurate role names is a hard job. We don't have time to do it 2. A conceptual issue: the relation between role names and verbalization of fact-types (assocations) is not well defined, neither in UML, nor in SBVR. But as SBVR is vocabulary based, verbalization is needed for structured english; and structured English is key for communication with the business community. As a compromise, we should fix this role/verb in the context of an issue Antoine -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, September 01, 2006 12:17 PM To: john.hall@modelsys.com Cc: bmm-ftf@omg.org Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE I must confess that I have a real mental block on this: the verb phrases are so unlike roles that I have genuine trouble understanding whether the swapping of names on ends makes more sense than the original. If anything I'm inclined to think not. For example the proposal, in Figure 8.8, there is a proposed property directive::governed_by. This seems the wrong way round: I would expect to see course_of_action::governed_by which is a property that would return the things that the course of action is governed by (i.e. directives). What's the reason for putting off the renaming of roles? Pete -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Tuesday, August 29, 2006 9:02 AM To: Juergen Boldt Cc: issues@omg.org; bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE Hello all, Attached are two documents: - A simplified proposal for resolution of issue 10090 so that it deals only with presentation. Any changes to role names should be handled as a separate issue, aster we have dealt with some other issues, including 10093 and 10114 - A new version of chapter 8, with the UML fragment diagrams updated Would all BMM FTF members please vote by end of September 1 on the following: 1) Chapter 8 of the adopted specification should be replaced by the new version with the updated UML fragment diagrams, and the overview of the UML class model in Chapter 7 updated to be consistent with the chapter 8 diagrams. 2) If the BMM FTF votes for an interim specification to be published (see Issue 10094), this change should be included in it. Best wishes, John Juergen Boldt wrote: This is issue # 10090 From: John Hall see attached, file will also be posted in FTF issues directory which is located at ftp://ftp.omg.org/pub/bmm-ftf/issues BMM: UML Associations The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases "is" or "has" has been omitted). These have been preserved in the proposed interim specification with the concepts catalog in SBVR Structured English. In the UML class model developed for the RFC submission, the verb phrases were added to associations as "ends" (role names). There are two small problems: · In many cases they read well as verb-oriented role names but in some cases they do not. · They have been placed on the association connectors at the wrong ends - normally a role name is placed at the line end where the class that plays the role is connected. For example, in the fragment below: Vision is made operative by mission, and amplified by goal. The roles read intuitively with the "clockwise" convention, but reading a UML class model correctly should not depend on positioning. Proposal 1) Move the association phrases to the appropriate ends of association lines for them to be role names, e.g. 2) In the UML class model, replace verb-oriented role names with noun-oriented names, if the reading of the model would be improved. For example, replace "goal amplifies vision" with "goal [has the role] amplifier of vision" 3) Where there are necessities in the Concepts Catalog that constrain cardinality, show them explicitly on the UML class model. For example, "mission makes at most one vision operative", "goal amplifies at most one vision". 4) Create a mapping of the fact types in the Concepts Catalog to the associations in the UML class model. Resolution: To be discussed Revised Text: Not yet decided Disposition: Open -------------------------------------------------------------------------------- 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 **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE Date: Fri, 1 Sep 2006 03:28:45 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 10090 -- BMM FTF issue - CALL FOR VOTE Thread-Index: AcbLQY+LHxf/tt4cQn+hqbx9hC3iPACJvDjgABHjQAAAAEfFcA== From: "Pete Rivett" To: "LONJON Antoine" , Cc: Reasonable points, Antoine. Do you agree with me though that the current use of names (in the FAS) makes more sense than in this proposed resolution - as per my example? So that the only thing to change at this stage is the multiplicities? Pete -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Friday, September 01, 2006 11:26 AM To: Pete Rivett; john.hall@modelsys.com Cc: bmm-ftf@omg.org Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE Pete, I think I am in close agreement with you. I usually prefer role names. But we have two main issues here: 1. A practical issue: the search for accurate role names is a hard job. We don't have time to do it 2. A conceptual issue: the relation between role names and verbalization of fact-types (assocations) is not well defined, neither in UML, nor in SBVR. But as SBVR is vocabulary based, verbalization is needed for structured english; and structured English is key for communication with the business community. As a compromise, we should fix this role/verb in the context of an issue Antoine -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, September 01, 2006 12:17 PM To: john.hall@modelsys.com Cc: bmm-ftf@omg.org Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE I must confess that I have a real mental block on this: the verb phrases are so unlike roles that I have genuine trouble understanding whether the swapping of names on ends makes more sense than the original. If anything I'm inclined to think not. For example the proposal, in Figure 8.8, there is a proposed property directive::governed_by. This seems the wrong way round: I would expect to see course_of_action::governed_by which is a property that would return the things that the course of action is governed by (i.e. directives). What's the reason for putting off the renaming of roles? Pete -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Tuesday, August 29, 2006 9:02 AM To: Juergen Boldt Cc: issues@omg.org; bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE Hello all, Attached are two documents: - A simplified proposal for resolution of issue 10090 so that it deals only with presentation. Any changes to role names should be handled as a separate issue, aster we have dealt with some other issues, including 10093 and 10114 - A new version of chapter 8, with the UML fragment diagrams updated Would all BMM FTF members please vote by end of September 1 on the following: 1) Chapter 8 of the adopted specification should be replaced by the new version with the updated UML fragment diagrams, and the overview of the UML class model in Chapter 7 updated to be consistent with the chapter 8 diagrams. 2) If the BMM FTF votes for an interim specification to be published (see Issue 10094), this change should be included in it. Best wishes, John Juergen Boldt wrote: This is issue # 10090 From: John Hall see attached, file will also be posted in FTF issues directory which is located at ftp://ftp.omg.org/pub/bmm-ftf/issues BMM: UML Associations The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases "is" or "has" has been omitted). These have been preserved in the proposed interim specification with the concepts catalog in SBVR Structured English. In the UML class model developed for the RFC submission, the verb phrases were added to associations as "ends" (role names). There are two small problems: · In many cases they read well as verb-oriented role names but in some cases they do not. · They have been placed on the association connectors at the wrong ends - normally a role name is placed at the line end where the class that plays the role is connected. For example, in the fragment below: Vision is made operative by mission, and amplified by goal. The roles read intuitively with the "clockwise" convention, but reading a UML class model correctly should not depend on positioning. Proposal 1) Move the association phrases to the appropriate ends of association lines for them to be role names, e.g. 2) In the UML class model, replace verb-oriented role names with noun-oriented names, if the reading of the model would be improved. For example, replace "goal amplifies vision" with "goal [has the role] amplifier of vision" 3) Where there are necessities in the Concepts Catalog that constrain cardinality, show them explicitly on the UML class model. For example, "mission makes at most one vision operative", "goal amplifies at most one vision". 4) Create a mapping of the fact types in the Concepts Catalog to the associations in the UML class model. Resolution: To be discussed Revised Text: Not yet decided Disposition: Open -------------------------------------------------------------------------------- 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 **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE Date: Fri, 1 Sep 2006 12:32:11 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 10090 -- BMM FTF issue - CALL FOR VOTE Thread-Index: AcbLQY+LHxf/tt4cQn+hqbx9hC3iPACJvDjgABHjQAAAAEfFcAAAHIeg From: "LONJON Antoine" To: "Pete Rivett" , Cc: yes, I agree. -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, September 01, 2006 12:29 PM To: LONJON Antoine; john.hall@modelsys.com Cc: bmm-ftf@omg.org Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE Reasonable points, Antoine. Do you agree with me though that the current use of names (in the FAS) makes more sense than in this proposed resolution - as per my example? So that the only thing to change at this stage is the multiplicities? Pete -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Friday, September 01, 2006 11:26 AM To: Pete Rivett; john.hall@modelsys.com Cc: bmm-ftf@omg.org Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE Pete, I think I am in close agreement with you. I usually prefer role names. But we have two main issues here: 1. A practical issue: the search for accurate role names is a hard job. We don't have time to do it 2. A conceptual issue: the relation between role names and verbalization of fact-types (assocations) is not well defined, neither in UML, nor in SBVR. But as SBVR is vocabulary based, verbalization is needed for structured english; and structured English is key for communication with the business community. As a compromise, we should fix this role/verb in the context of an issue Antoine -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, September 01, 2006 12:17 PM To: john.hall@modelsys.com Cc: bmm-ftf@omg.org Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE I must confess that I have a real mental block on this: the verb phrases are so unlike roles that I have genuine trouble understanding whether the swapping of names on ends makes more sense than the original. If anything I'm inclined to think not. For example the proposal, in Figure 8.8, there is a proposed property directive::governed_by. This seems the wrong way round: I would expect to see course_of_action::governed_by which is a property that would return the things that the course of action is governed by (i.e. directives). What's the reason for putting off the renaming of roles? Pete -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Tuesday, August 29, 2006 9:02 AM To: Juergen Boldt Cc: issues@omg.org; bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE Hello all, Attached are two documents: - A simplified proposal for resolution of issue 10090 so that it deals only with presentation. Any changes to role names should be handled as a separate issue, aster we have dealt with some other issues, including 10093 and 10114 - A new version of chapter 8, with the UML fragment diagrams updated Would all BMM FTF members please vote by end of September 1 on the following: 1) Chapter 8 of the adopted specification should be replaced by the new version with the updated UML fragment diagrams, and the overview of the UML class model in Chapter 7 updated to be consistent with the chapter 8 diagrams. 2) If the BMM FTF votes for an interim specification to be published (see Issue 10094), this change should be included in it. Best wishes, John Juergen Boldt wrote: This is issue # 10090 From: John Hall see attached, file will also be posted in FTF issues directory which is located at ftp://ftp.omg.org/pub/bmm-ftf/issues BMM: UML Associations The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases "is" or "has" has been omitted). These have been preserved in the proposed interim specification with the concepts catalog in SBVR Structured English. In the UML class model developed for the RFC submission, the verb phrases were added to associations as "ends" (role names). There are two small problems: · In many cases they read well as verb-oriented role names but in some cases they do not. · They have been placed on the association connectors at the wrong ends - normally a role name is placed at the line end where the class that plays the role is connected. For example, in the fragment below: Vision is made operative by mission, and amplified by goal. The roles read intuitively with the "clockwise" convention, but reading a UML class model correctly should not depend on positioning. Proposal 1) Move the association phrases to the appropriate ends of association lines for them to be role names, e.g. 2) In the UML class model, replace verb-oriented role names with noun-oriented names, if the reading of the model would be improved. For example, replace "goal amplifies vision" with "goal [has the role] amplifier of vision" 3) Where there are necessities in the Concepts Catalog that constrain cardinality, show them explicitly on the UML class model. For example, "mission makes at most one vision operative", "goal amplifies at most one vision". 4) Create a mapping of the fact types in the Concepts Catalog to the associations in the UML class model. Resolution: To be discussed Revised Text: Not yet decided Disposition: Open -------------------------------------------------------------------------------- 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 **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Date: Fri, 01 Sep 2006 16:42:09 +0200 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: LONJON Antoine Cc: Pete Rivett , bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE Pete, Antoine, I don't understand this discussion, unless I have misunderstood how role names should be placed on UML class models. I thought that a role name was to be placed on the end of the association line closest to the class that plays the role. So, in figure 8.8, course_of_action plays the role of "being governed by directive", and directive plays the role of "governing course_of_action". If (as I think should happen in the near future) we adopted noun-oriented role names, then the role name for course_of_action could be "governed" and he role name of directive could be "governor". Or they could be respectively, "subject" and "ruler" . If we used gerunds instead of nouns they could be "being governed by" and "governing". The semantics would be the same, the role names would be in the same positions in the diagram. Only the terms used for the role names would have changed. Regards, John LONJON Antoine wrote: yes, I agree. -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, September 01, 2006 12:29 PM To: LONJON Antoine; john.hall@modelsys.com Cc: bmm-ftf@omg.org Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE Reasonable points, Antoine. Do you agree with me though that the current use of names (in the FAS) makes more sense than in this proposed resolution - as per my example? So that the only thing to change at this stage is the multiplicities? Pete -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Friday, September 01, 2006 11:26 AM To: Pete Rivett; john.hall@modelsys.com Cc: bmm-ftf@omg.org Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE Pete, I think I am in close agreement with you. I usually prefer role names. But we have two main issues here: 1. A practical issue: the search for accurate role names is a hard job. We don't have time to do it 2. A conceptual issue: the relation between role names and verbalization of fact-types (assocations) is not well defined, neither in UML, nor in SBVR. But as SBVR is vocabulary based, verbalization is needed for structured english; and structured English is key for communication with the business community. As a compromise, we should fix this role/verb in the context of an issue Antoine -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, September 01, 2006 12:17 PM To: john.hall@modelsys.com Cc: bmm-ftf@omg.org Subject: RE: issue 10090 -- BMM FTF issue - CALL FOR VOTE I must confess that I have a real mental block on this: the verb phrases are so unlike roles that I have genuine trouble understanding whether the swapping of names on ends makes more sense than the original. If anything I'm inclined to think not. For example the proposal, in Figure 8.8, there is a proposed property directive::governed_by. This seems the wrong way round: I would expect to see course_of_action::governed_by which is a property that would return the things that the course of action is governed by (i.e. directives). What's the reason for putting off the renaming of roles? Pete -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Tuesday, August 29, 2006 9:02 AM To: Juergen Boldt Cc: issues@omg.org; bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE Hello all, Attached are two documents: - A simplified proposal for resolution of issue 10090 so that it deals only with presentation. Any changes to role names should be handled as a separate issue, aster we have dealt with some other issues, including 10093 and 10114 - A new version of chapter 8, with the UML fragment diagrams updated Would all BMM FTF members please vote by end of September 1 on the following: 1) Chapter 8 of the adopted specification should be replaced by the new version with the updated UML fragment diagrams, and the overview of the UML class model in Chapter 7 updated to be consistent with the chapter 8 diagrams. 2) If the BMM FTF votes for an interim specification to be published (see Issue 10094), this change should be included in it. Best wishes, John Juergen Boldt wrote: This is issue # 10090 From: John Hall see attached, file will also be posted in FTF issues directory which is located at ftp://ftp.omg.org/pub/bmm-ftf/issues BMM: UML Associations The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases "is" or "has" has been omitted). These have been preserved in the proposed interim specification with the concepts catalog in SBVR Structured English. In the UML class model developed for the RFC submission, the verb phrases were added to associations as "ends" (role names). There are two small problems: · In many cases they read well as verb-oriented role names but in some cases they do not. · They have been placed on the association connectors at the wrong ends - normally a role name is placed at the line end where the class that plays the role is connected. For example, in the fragment below: Vision is made operative by mission, and amplified by goal. The roles read intuitively with the "clockwise" convention, but reading a UML class model correctly should not depend on positioning. Proposal 1) Move the association phrases to the appropriate ends of association lines for them to be role names, e.g. 2) In the UML class model, replace verb-oriented role names with noun-oriented names, if the reading of the model would be improved. For example, replace "goal amplifies vision" with "goal [has the role] amplifier of vision" 3) Where there are necessities in the Concepts Catalog that constrain cardinality, show them explicitly on the UML class model. For example, "mission makes at most one vision operative", "goal amplifies at most one vision". 4) Create a mapping of the fact types in the Concepts Catalog to the associations in the UML class model. Resolution: To be discussed Revised Text: Not yet decided Disposition: Open -------------------------------------------------------------------------------- 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 **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Date: Fri, 01 Sep 2006 17:40:28 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No John Hall wrote: Hello all, Attached are two documents: - A simplified proposal for resolution of issue 10090 so that it deals only with presentation. Any changes to role names should be handled as a separate issue, aster we have dealt with some other issues, including 10093 and 10114 - A new version of chapter 8, with the UML fragment diagrams updated Would all BMM FTF members please vote by end of September 1 on the following: 1) Chapter 8 of the adopted specification should be replaced by the new version with the updated UML fragment diagrams, and the overview of the UML class model in Chapter 7 updated to be consistent with the chapter 8 diagrams. 2) If the BMM FTF votes for an interim specification to be published (see Issue 10094), this change should be included in it. I vote No on replacement of Clause 8 with the document distributed. I agree in principle with item (1), but I have two problems with it: A. It is not clear that the replacement Chapter 8 changes only the UML diagrams. Is that all it changes? And if so, the resolution should be to change the UML diagrams and only that. We may regard the distributed document as a kind of "convenience document" reflecting the directed changes to the FAS. B. There are several errors in the assignments of association end names in the distributed clause 8 replacement: - In figure 8.6, the association-ends (roles) on the Mission-Vision association are reversed. The text of 8.2.2 says: "A Mission makes a Vision operative", i.e., Mission->makes-operative(Vision). But the UML reads Vision->makes-operative(Mission) - In figure 8.6, the association-ends on the Mission-Strategy association also seem to be reversed. - In figure 8.13, ALL of the association-ends are reversed. For example, the UML says: Assessment->judged-in(End) and Potential_Impact->identifies(Assessment) - In figure 8.14, ALL of the association-ends are reversed. - In figure 8.16, the association-ends are reversed (same as 8.13). - In figure 8.17, ALL of the association-ends are reversed. For example, the UML reads: Organization_unit->defined_by(Strategy). This consistent mistake makes the diagrams inconsistent with the text and terribly confusing, and the problem has nothing to do with whether the rolenames (association-ends) are verbs or nouns. Let us please fix the UML to match the text and then vote on replacing the diagrams. -Ed P.S. John, you are correct when you say that the role-name is placed closest to the Class that PLAYS the role, not the Class that OWNS the role. In the 8.17 example, that would place "defined-by" next to organization-unit (which plays the "defined-by" role), and that is NOT what is in the diagram. In UML the "owner" of the association-end is the Subject of the sentence with that reading, but the "role"/verb designating that association-end is placed next to the Object of the sentence with that reading. This is exactly the reverse of the ORM convention. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Fri, 01 Sep 2006 18:09:02 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: LONJON Antoine CC: bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Antoine wrote: But, the current practice is just that role names are noun-oriented rather than gerund-oriented. Of course, but the "current UML practice" is mostly O-O program models, not conceptual models. And that practice causes most UML models to name the association ends without ever naming the associations (even though MOF requires associations to be named). You have only to look at the diagrams in the UML2 spec and any of several others. OMG still thinks in Java. I think that Pete preferes having verb association names to having gerund-oriented role names. Not to put too fine a point on it, MOF needs both, because you have to name the Table as well as the Columns. MOF models are just specific to a different platform-class. The reason is that gerung-orientation looks to close to verb-orientation and is very unsual to the MOF/UML community. This community, indeed, uses role names as object properties. I also annoy UML people by using verb/gerund-oriented association end names. I prefer to use UML association names, but I also find that UML tools have trouble putting a name like assessment-considers-potential-impact on a diagram. The solution I have found is to couple the verb with the accusative Class. So the association-end names on the above are "considersImpact" and "consideredByAssessment". And when you turn it into Java, you get: Assessment->considersImpact, whose data type is "potential_impact" This also has the virtue of avoiding 58 properties whose name (verb) is "has" (as in SBVR). The property is instead called "hasSnark". But frankly, I don't have any problem with John's "gerund" association ends. The confusion in the distributed clause 8 is that more than half of the end names are reversed from what was intended. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Sat, 02 Sep 2006 01:14:54 +0200 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: edbark@nist.gov, BMM FTF Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE Ed, I'll make the same case to you as I did to Antoine and Pete. In diagram 8.6, read the role names as "mission plays the role of making vision operative" and "vision plays the role of being made operative by mission". The role names may look odd to UML/MOF people because they use the directional fact type phrases on the BMM as published by the BRG (as illustrated in appendix A). If we were to choose gerund forms for role names (the simplest mapping from the BMM as published by the BRG) then mission's role would be "making_operative" (vision) and vision's role name would be "being_made_operative_by" (mission). But I know that gerunds for role names are unfamiliar and awkward-looking to many UML modelers, so we ought to find nouns for them. I'd prefer to avoid grotesqueries like "operationalizer" (for mission) and "operationalized" (for vision - maybe not so bad, although it's not immediately obvious that it's meant as a noun). Reading the role names would not be much different from reading those on the diagrams proposed for 1094: "mission plays the role 'operationalizer' in this association with vision", "vision plays the role 'operationalized' in this association with mission" It will take us a little time to get civilized nouns for all the roles but, as we do, I would like the terms that are replaced to be at the correct ends of the association lines. "Operationalizer" (if we used it) would replace "makes_operative" at the "mission" end of the line. I think this rationale would apply to all the diagrams you mention. For example, in 8.16, "assessment plays the role 'identifier_of'' in this association with potential_impact", "potential_impact plays the role 'of'_significance_to' in this association with assessment ", Note that when we drew the UML model we could have done it differently. For example, we could have named the association between "mission" and "vision" as "makes_operative", with a solid black arrowhead pointing towards "vision", and omitted "made-operative_by". The problem with this was that UML supports only one name for an association, but some associations in the BMM as published by the BRG have different phrases in each direction, and we didn't want to lose them. Regards, John Ed Barkmeyer wrote: John Hall wrote: Hello all, Attached are two documents: - A simplified proposal for resolution of issue 10090 so that it deals only with presentation. Any changes to role names should be handled as a separate issue, aster we have dealt with some other issues, including 10093 and 10114 - A new version of chapter 8, with the UML fragment diagrams updated Would all BMM FTF members please vote by end of September 1 on the following: 1) Chapter 8 of the adopted specification should be replaced by the new version with the updated UML fragment diagrams, and the overview of the UML class model in Chapter 7 updated to be consistent with the chapter 8 diagrams. 2) If the BMM FTF votes for an interim specification to be published (see Issue 10094), this change should be included in it. I vote No on replacement of Clause 8 with the document distributed. I agree in principle with item (1), but I have two problems with it: A. It is not clear that the replacement Chapter 8 changes only the UML diagrams. Is that all it changes? And if so, the resolution should be to change the UML diagrams and only that. We may regard the distributed document as a kind of "convenience document" reflecting the directed changes to the FAS. B. There are several errors in the assignments of association end names in the distributed clause 8 replacement: - In figure 8.6, the association-ends (roles) on the Mission-Vision association are reversed. The text of 8.2.2 says: "A Mission makes a Vision operative", i.e., Mission->makes-operative(Vision). But the UML reads Vision->makes-operative(Mission) - In figure 8.6, the association-ends on the Mission-Strategy association also seem to be reversed. - In figure 8.13, ALL of the association-ends are reversed. For example, the UML says: Assessment->judged-in(End) and Potential_Impact->identifies(Assessment) - In figure 8.14, ALL of the association-ends are reversed. - In figure 8.16, the association-ends are reversed (same as 8.13). - In figure 8.17, ALL of the association-ends are reversed. For example, the UML reads: Organization_unit->defined_by(Strategy). This consistent mistake makes the diagrams inconsistent with the text and terribly confusing, and the problem has nothing to do with whether the rolenames (association-ends) are verbs or nouns. Let us please fix the UML to match the text and then vote on replacing the diagrams. -Ed P.S. John, you are correct when you say that the role-name is placed closest to the Class that PLAYS the role, not the Class that OWNS the role. In the 8.17 example, that would place "defined-by" next to organization-unit (which plays the "defined-by" role), and that is NOT what is in the diagram. In UML the "owner" of the association-end is the Subject of the sentence with that reading, but the "role"/verb designating that association-end is placed next to the Object of the sentence with that reading. This is exactly the reverse of the ORM convention. Date: Sat, 02 Sep 2006 01:28:16 +0200 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: edbark@nist.gov Cc: bmm-ftf@omg.org Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE [oops - errorin diagram] Ed, You're right about organization_unit and strategy in 8.17. That's my error in the diagram. The others are (from my perspective) the 'right way around', For example "organization_unit defines {plays the role 'definer_of') end" Sorry, John Ed Barkmeyer wrote: John Hall wrote: Hello all, Attached are two documents: - A simplified proposal for resolution of issue 10090 so that it deals only with presentation. Any changes to role names should be handled as a separate issue, aster we have dealt with some other issues, including 10093 and 10114 - A new version of chapter 8, with the UML fragment diagrams updated Would all BMM FTF members please vote by end of September 1 on the following: 1) Chapter 8 of the adopted specification should be replaced by the new version with the updated UML fragment diagrams, and the overview of the UML class model in Chapter 7 updated to be consistent with the chapter 8 diagrams. 2) If the BMM FTF votes for an interim specification to be published (see Issue 10094), this change should be included in it. I vote No on replacement of Clause 8 with the document distributed. I agree in principle with item (1), but I have two problems with it: A. It is not clear that the replacement Chapter 8 changes only the UML diagrams. Is that all it changes? And if so, the resolution should be to change the UML diagrams and only that. We may regard the distributed document as a kind of "convenience document" reflecting the directed changes to the FAS. B. There are several errors in the assignments of association end names in the distributed clause 8 replacement: - In figure 8.6, the association-ends (roles) on the Mission-Vision association are reversed. The text of 8.2.2 says: "A Mission makes a Vision operative", i.e., Mission->makes-operative(Vision). But the UML reads Vision->makes-operative(Mission) - In figure 8.6, the association-ends on the Mission-Strategy association also seem to be reversed. - In figure 8.13, ALL of the association-ends are reversed. For example, the UML says: Assessment->judged-in(End) and Potential_Impact->identifies(Assessment) - In figure 8.14, ALL of the association-ends are reversed. - In figure 8.16, the association-ends are reversed (same as 8.13). - In figure 8.17, ALL of the association-ends are reversed. For example, the UML reads: Organization_unit->defined_by(Strategy). This consistent mistake makes the diagrams inconsistent with the text and terribly confusing, and the problem has nothing to do with whether the rolenames (association-ends) are verbs or nouns. Let us please fix the UML to match the text and then vote on replacing the diagrams. -Ed P.S. John, you are correct when you say that the role-name is placed closest to the Class that PLAYS the role, not the Class that OWNS the role. In the 8.17 example, that would place "defined-by" next to organization-unit (which plays the "defined-by" role), and that is NOT what is in the diagram. In UML the "owner" of the association-end is the Subject of the sentence with that reading, but the "role"/verb designating that association-end is placed next to the Object of the sentence with that reading. This is exactly the reverse of the ORM convention. Date: Tue, 05 Sep 2006 11:59:05 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: john.hall@modelsys.com CC: BMM FTF Subject: Re: issue 10090 -- BMM FTF issue - CALL FOR VOTE X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No John Hall wrote: I'll make the same case to you as I did to Antoine and Pete. In diagram 8.6, read the role names as "mission plays the role of making vision operative" and "vision plays the role of being made operative by mission". The role names may look odd to UML/MOF people because they use the directional fact type phrases on the BMM as published by the BRG (as illustrated in appendix A). The problem lies rather in how one is taught to read the UML language. Someone who has learned UML and never saw Appendix A will be confused. In the UML language, diagram 8.6 reads: Mission has a relationship to Vision that is called 'Mission has made_operative_by', and the inverse relationship is called 'Vision has makes_operative'. And I am comfortable deleting the 'has' (which is the gerund argument), but that doesn't solve the problem. The reason for role/association-end mismatch is that the form of UML model you are using is a "functional" model, not a "relational" one. If you name the association for the fact-type (table): "mission-makes-vision-operative", then you have two roles (columns), called "mission" and "vision" (in typical SBVR form), and the makes-operative, made-operative-by nomenclature disappears entirely (it is absorbed into the association name). But if I render your UML into a functional DB model, rather than a logical relation, I get: mission-makes-operative: mission -> vision. That is, there is a '(mission)makes-operative' "function" applied to a Mission (key) that yields a Vision (key). And in UML I represent that model with the "makes-operative" on the Vision end (because Jim Rumbaugh did it that way). And notice that the cardinalities go on the Vision end, because of the functional view: for each Mission, that many associated Visions (images under the "function"). (UML cardinality is not the cardinality of participation.) [Yes, UML is backwards. Before I encountered UML, I grew up with three modeling languages that put the role next to the class that plays it, and all of them can model roles in ternary relations and UML can't. Ternary relations don't have a functional model -- they require the artifice of reification. (And reification allows UML to put the roles next to the classes -- the images of the functions on the reified relationship (key).) Yes, functional modeling is not the best practice. But we often standardize dubious practice by market dominance. And the practitioners learn to work around the standards as much as with them.] What you did makes sense to you, and I understand the reasoning, but it won't make sense to anyone educated in UML modeling per the OMG certification exam. And it doesn't match the conventional MOF interpretation. If you want to impose your own "fact-type interpretation" on the association ends, you need to define and use a UML profile. Otherwise, if you can live with UML as she is spoke, just reverse the end labels and make everyone else happy. AFAIK, there is no reason, however, not to just name the association for the fact-type and let the classes be the role names, a la SBVR, and delete the end-names entirely. (Pete may take issue with this.) -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Tue, 09 Jan 2007 14:02:04 +0000 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: BMM FTF Subject: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Happy New Year to all, Attached is a proposal for resolution of Issue 10090. The issue was discussed during the first FTF, and I think that the proposal matches majority opinion, if not complete consensus. For those new to the FTF, the essence of the issue is: the BMM as published gave each association a pair of names, one in each direction. In some pairs the names are simple inverses: for example "tactic implements strategy" and "strategy is implemented by tactic". But in some pairs the verbs are different. For example "business policy is the basis of business rule" and "business rule is derived from business policy". MOF needs association names and UML does not support two names for an association. This proposal is to choose one name for each association: If an association.s names are simple inverses, the active form is used for the association name on the MOF model, e.g. "tactic implements strategy" rather than "strategy is implemented by tactic". If an association.s names are based on different verbs, one has been chosen for the association name on the MOF model, and the other declared as synonymous in the Concepts Catalog. This preserves the BMM vocabulary as published. Could you all, please, vote by end of Monday January 15. Regards, John BMM Issue 10090 UML Associations V4.doc BMM_ Issue_10090_Ch7_UML_overview_.pdf BMM_ Issue_10090_Ch 8_UML_diagrams.pdf Disposition: Resolved OMG Issue No: 10090 Title: BMM: UML Associations Source: John Hall, Business Rules Group John Hall Summary: The BMM as published by the BRG has association names that represent the verb phrases in fact types (except that in a few cases .is. or .has. has been omitted). In the UML class model developed for the RFC submission, the verb phrases were added to associations as .ends. (role names). In FTF discussion a preference was expressed for association names rather than role names on the UML diagrams. This is closer to the BMM as published by the BRG. However, UML supports only one name for each association. In some cases, the as-published BMM association names are active/passive forms of the same verb, but some use different verbs in each direction. This needs to be resolved so that the UML diagrams are correct and the BMM business vocabulary is preserved. Resolution: UML Diagrams (Chapter 8 plus overview model in chapter 7) Role names have been removed from UML diagrams. For each association in the BMM as published, an association name with a directional arrow has been added to the UML diagrams, using the following conventions: · Choose the BMM name that is based on an active verb, e.g. .implements. in the direction from Tactic to Strategy, rather than .is implemented by. in the direction from Strategy to Tactic · If the BMM names are not active/passive forms of the same verb phrase: o choose one for the UML model o define the other as a synonymous form in the concepts catalog, e.g. .Business Rule is derived from Business Policy. is a synonym for .Business Policy is the basis of Business Rule.. This will preserve the business vocabulary of the BMM as published, while complying with the UML constraint that an association may have only one name. Concepts Catalog in SBVR Structured English (chapter 9) As in SBVR Structured English, simple passive forms of verbs are taken to be implicit, i.e. tactic implements strategy does not need strategy is implemented by tactic to be declared explicitly as a synonymous form. If the BMM as published shows a .reverse direction. association name that is not the passive form of the selected association name, this is included as a synonymous form under the definition of the verb concept, e.g. the catalog entry for business policy is the basis of business rule includes a Synonymous Form clause business rule is derived from business policy. Revised Text: 1) Update the BMM overview UML model in chapter 7 of the FAS to be consistent with the updated diagrams in chapter 8, as in attached document: BMM_ Issue_10090_Ch7_UML_overview_.pdf 2) Replace diagrams in chapter 8 of the FAS with the diagrams in the attached document BMM_ Issue_10090_Ch 8_UML_diagrams.pdf 3) Add the following .Synonymous Form. entries to the concepts catalog (chapter 9): assessment provides impetus for directive Synonymous Form: directive is motivated by assessment assessment identifies potential impact Synonymous Form: potential impact is significant to assessment business policy is the basis for business rule Synonymous Form: business rule is derived from business policy business policy1 is composed of business policy2 Synonymous Form: business policy2 is part of business policy1 course of action1 is composed of course of action2 Synonymous Form: course of action2 is part of course of action1 course of action channels efforts towards desired result Synonymous Form: desired result is supported by course of action directive is source of course of action Synonymous Form: course of action is formulated based on directive directive supports achievement of desired result Synonymous Form: desired result has achievement supported by directive potential impact provides impetus for directive Synonymous Form: directive is motivated by potential impact strategy is a component of the plan for mission Synonymous Form: mission is planned by means of strategy strategy determines organization unit Synonymous Form: organization unit is defined by strategy tactic effects enforcement level of business rule Synonymous Form: business rule has enforcement level effected by tactic Disposition: Resolved From: "Markus Schacher" To: "'BMM FTF'" Subject: RE: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Date: Tue, 9 Jan 2007 15:19:57 +0100 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Accz9f23uYsXqMcgTkyG0INNHeKVrQAAx0Ew KnowGravity votes YES to the resolution of this issue. Best regards, Markus Schacher, KnowBody -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Dienstag, 9. Januar 2007 15:02 To: BMM FTF Subject: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Happy New Year to all, Attached is a proposal for resolution of Issue 10090. The issue was discussed during the first FTF, and I think that the proposal matches majority opinion, if not complete consensus. For those new to the FTF, the essence of the issue is: the BMM as published gave each association a pair of names, one in each direction. In some pairs the names are simple inverses: for example "tactic implements strategy" and "strategy is implemented by tactic". But in some pairs the verbs are different. For example "business policy is the basis of business rule" and "business rule is derived from business policy". MOF needs association names and UML does not support two names for an association. This proposal is to choose one name for each association: If an association.s names are simple inverses, the active form is used for the association name on the MOF model, e.g. "tactic implements strategy" rather than "strategy is implemented by tactic". If an association.s names are based on different verbs, one has been chosen for the association name on the MOF model, and the other declared as synonymous in the Concepts Catalog. This preserves the BMM vocabulary as published. Could you all, please, vote by end of Monday January 15. Regards, John Subject: RE: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Date: Tue, 9 Jan 2007 06:58:59 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BMM FTF2] Ballot 1: Issue 10090 UML Associations thread-index: Accz9uK+gWfdySUzQl2qGquFqflkOwABvAww From: "Pete Rivett" To: , "BMM FTF" UML supports one name for the Association and also a name for the Property at each end. MOF requires all of these to be present in a metamodel. In some metamodels (e.g. the UML2 metamodel) these names are auto-generated by a defined algorithm where the name is not explicitly given in the UML diagrams: as a result all names are explicit once the MOF metamodel is created. However it is preferable for usability to avoid such generated names. Pete -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Tuesday, January 09, 2007 2:02 PM To: BMM FTF Subject: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Happy New Year to all, Attached is a proposal for resolution of Issue 10090. The issue was discussed during the first FTF, and I think that the proposal matches majority opinion, if not complete consensus. For those new to the FTF, the essence of the issue is: the BMM as published gave each association a pair of names, one in each direction. In some pairs the names are simple inverses: for example "tactic implements strategy" and "strategy is implemented by tactic". But in some pairs the verbs are different. For example "business policy is the basis of business rule" and "business rule is derived from business policy". MOF needs association names and UML does not support two names for an association. This proposal is to choose one name for each association: If an association.s names are simple inverses, the active form is used for the association name on the MOF model, e.g. "tactic implements strategy" rather than "strategy is implemented by tactic". If an association.s names are based on different verbs, one has been chosen for the association name on the MOF model, and the other declared as synonymous in the Concepts Catalog. This preserves the BMM vocabulary as published. Could you all, please, vote by end of Monday January 15. Regards, John Subject: RE: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Date: Tue, 9 Jan 2007 14:05:10 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BMM FTF2] Ballot 1: Issue 10090 UML Associations thread-index: Accz9vmRh57sEWs0Rd6vApl6CZSqyQAKZ4Qw From: "Cory Casanave" To: , "BMM FTF" DAT votes no. Reason: Lack of role names makes the model harder to understand and when used in MOF, MOF makes up strange names. We would therefore recommend having both role names and association names. Use of directional associations is somewhat unusual and has no meaning in MOF. This is, of course, somewhat stylistic but is more in keeping with the style used in most MOF models. -Cory Casanave -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Tuesday, January 09, 2007 9:02 AM To: BMM FTF Subject: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Happy New Year to all, Attached is a proposal for resolution of Issue 10090. The issue was discussed during the first FTF, and I think that the proposal matches majority opinion, if not complete consensus. For those new to the FTF, the essence of the issue is: the BMM as published gave each association a pair of names, one in each direction. In some pairs the names are simple inverses: for example "tactic implements strategy" and "strategy is implemented by tactic". But in some pairs the verbs are different. For example "business policy is the basis of business rule" and "business rule is derived from business policy". MOF needs association names and UML does not support two names for an association. This proposal is to choose one name for each association: If an association.s names are simple inverses, the active form is used for the association name on the MOF model, e.g. "tactic implements strategy" rather than "strategy is implemented by tactic". If an association.s names are based on different verbs, one has been chosen for the association name on the MOF model, and the other declared as synonymous in the Concepts Catalog. This preserves the BMM vocabulary as published. Could you all, please, vote by end of Monday January 15. Regards, John X-AuditID: c0a8013c-adfc0bb000000a12-85-45a41c7be2e8 X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 09 Jan 2007 16:51:21 -0600 To: john.hall@modelsys.com, BMM FTF From: "Ronald G. Ross" Subject: Re: [BMM FTF2] Ballot 1: Issue 10090 UML Associations X-Brightmail-Tracker: AAAAAA== At 08:02 AM 1/9/2007, John Hall wrote: Business Rule Solutions, LLC abstains on this issue. Ron Happy New Year to all, Attached is a proposal for resolution of Issue 10090. The issue was discussed during the first FTF, and I think that the proposal matches majority opinion, if not complete consensus. For those new to the FTF, the essence of the issue is: the BMM as published gave each association a pair of names, one in each direction. In some pairs the names are simple inverses: for example "tactic implements strategy" and "strategy is implemented by tactic". But in some pairs the verbs are different. For example "business policy is the basis of business rule" and "business rule is derived from business policy". MOF needs association names and UML does not support two names for an association. This proposal is to choose one name for each association: If an association.s names are simple inverses, the active form is used for the association name on the MOF model, e.g. "tactic implements strategy" rather than "strategy is implemented by tactic". If an association.s names are based on different verbs, one has been chosen for the association name on the MOF model, and the other declared as synonymous in the Concepts Catalog. This preserves the BMM vocabulary as published. Could you all, please, vote by end of Monday January 15. Regards, John Subject: RE: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Date: Tue, 9 Jan 2007 16:31:12 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BMM FTF2] Ballot 1: Issue 10090 UML Associations thread-index: Accz9vmRh57sEWs0Rd6vApl6CZSqyQAKZ4QwAAs0VTA= From: "Pete Rivett" To: "Cory Casanave" Cc: , "BMM FTF" Cory, Minor correction (which I do not think will affect your vote): MOF does not make up names. MOF requires the names to be present for both associations and ends. The 'odd names' you might have seen are probably in the UML2 metamodel and were generated, according to rules documented in the UML spec itself, to make what was authored in the original UML tool into a valid MOF metamodel. The use of 'directional' arrows/triangles for Associations has no more meaning in UML: for both UML and MOF it is used to indicate the ordering of the 2 ends within the Association::memberEnd property. I agree it's unusual but I don't object to it: it makes the diagram a more explicit representation of the metamodel (the ends must be in some order and without the arrow the only place to discover it is to look at the XMI or a tool-property sheet). And I can see that for SBVR purposes it could have some definite value. Cheers Pete -------------------------------------------------------------------------------- From: Cory Casanave [mailto:cory-c@enterprisecomponent.com] Sent: Tuesday, January 09, 2007 7:05 PM To: john.hall@modelsys.com; BMM FTF Subject: RE: [BMM FTF2] Ballot 1: Issue 10090 UML Associations DAT votes no. Reason: Lack of role names makes the model harder to understand and when used in MOF, MOF makes up strange names. We would therefore recommend having both role names and association names. Use of directional associations is somewhat unusual and has no meaning in MOF. This is, of course, somewhat stylistic but is more in keeping with the style used in most MOF models. -Cory Casanave -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Tuesday, January 09, 2007 9:02 AM To: BMM FTF Subject: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Happy New Year to all, Attached is a proposal for resolution of Issue 10090. The issue was discussed during the first FTF, and I think that the proposal matches majority opinion, if not complete consensus. For those new to the FTF, the essence of the issue is: the BMM as published gave each association a pair of names, one in each direction. In some pairs the names are simple inverses: for example "tactic implements strategy" and "strategy is implemented by tactic". But in some pairs the verbs are different. For example "business policy is the basis of business rule" and "business rule is derived from business policy". MOF needs association names and UML does not support two names for an association. This proposal is to choose one name for each association: If an association.s names are simple inverses, the active form is used for the association name on the MOF model, e.g. "tactic implements strategy" rather than "strategy is implemented by tactic". If an association.s names are based on different verbs, one has been chosen for the association name on the MOF model, and the other declared as synonymous in the Concepts Catalog. This preserves the BMM vocabulary as published. Could you all, please, vote by end of Monday January 15. Regards, John Date: Wed, 10 Jan 2007 19:46:22 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: john.hall@modelsys.com CC: BMM FTF Subject: Re: [BMM FTF2] Ballot 1: Issue 10090 UML Associations X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No John Hall wrote: Attached is a proposal for resolution of Issue 10090. The issue was discussed during the first FTF, and I think that the proposal matches majority opinion, if not complete consensus. NIST votes No. I don't disagree with the intent, but I think this is not technically what is wanted. I don't understand the relationship between the Structured English and the UML association names. For example, for the fact-type organizational_unit establishes means The UML diagram shows the association name as just the verb 'establishes'. Surely the name of the association should be the name of the fact-type: organizational_unit establishes means with some appropriate punctuation between the words if spaces annoy people. This is what I thought the "apparent consensus" of the FTF was. I guess I was wrong. If I understand correctly, in MOFv2, the association is a first-class object, whose name should be unique within the namespace. With the convention given, 'establishes' is the name of "organizational_unit establishes means" and it is not possible for the BMM to contain any other fact-type of the form: X establishes Y because that would create an identifier conflict. I am very uncomfortable with this. In the previous incarnation, the owned association-end at least had the name: organizational_unit::establishes which avoided this problem. I would suggest that we first distinguish between the model and the diagram. On the diagram, you can choose to show either the association names or the association end names, and I don't suggest you do both. But in the model, one should have both, because the association-name alone is not sufficient for writing constraints in OCL, and is lost in mappings to languages like Java. Further, I would suggest that the association names ought to be some rendition of the fact-types, not just the verbs. The association-end names can be just the verbs. And the end names would reflect the inverse readings. But I don't think we are all on the same page on this yet. -Ed P.S. It is my understanding, probably erroneous, that the original author of what is now the UML "static structure diagram" (who puts in occasional appearances at OMG) had in mind that the association name was the name of the (relationship) table in his relational database, and the association end-names were the column names, which might be left out of the diagram if they were the same as the names of the classes whose primary keys those columns would contain. That is, the association name is the fact-type name, and the association-end names are the role names. The O-O practice of joining the relationship table to the class/entity table usually requires us to put the a reading of the fact-type name and possibly the role name all into the association-end name, because the mapping to C++ and Java discards the association name. MOF tries to be usable in both technologies, which makes for no consistently good naming conventions. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, Date: Wed, 10 Jan 2007 19:46:22 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: john.hall@modelsys.com CC: BMM FTF Subject: Re: [BMM FTF2] Ballot 1: Issue 10090 UML Associations X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No John Hall wrote: Attached is a proposal for resolution of Issue 10090. The issue was discussed during the first FTF, and I think that the proposal matches majority opinion, if not complete consensus. NIST votes No. I don't disagree with the intent, but I think this is not technically what is wanted. I don't understand the relationship between the Structured English and the UML association names. For example, for the fact-type organizational_unit establishes means The UML diagram shows the association name as just the verb 'establishes'. Surely the name of the association should be the name of the fact-type: organizational_unit establishes means with some appropriate punctuation between the words if spaces annoy people. This is what I thought the "apparent consensus" of the FTF was. I guess I was wrong. If I understand correctly, in MOFv2, the association is a first-class object, whose name should be unique within the namespace. With the convention given, 'establishes' is the name of "organizational_unit establishes means" and it is not possible for the BMM to contain any other fact-type of the form: X establishes Y because that would create an identifier conflict. I am very uncomfortable with this. In the previous incarnation, the owned association-end at least had the name: organizational_unit::establishes which avoided this problem. I would suggest that we first distinguish between the model and the diagram. On the diagram, you can choose to show either the association names or the association end names, and I don't suggest you do both. But in the model, one should have both, because the association-name alone is not sufficient for writing constraints in OCL, and is lost in mappings to languages like Java. Further, I would suggest that the association names ought to be some rendition of the fact-types, not just the verbs. The association-end names can be just the verbs. And the end names would reflect the inverse readings. But I don't think we are all on the same page on this yet. -Ed P.S. It is my understanding, probably erroneous, that the original author of what is now the UML "static structure diagram" (who puts in occasional appearances at OMG) had in mind that the association name was the name of the (relationship) table in his relational database, and the association end-names were the column names, which might be left out of the diagram if they were the same as the names of the classes whose primary keys those columns would contain. That is, the association name is the fact-type name, and the association-end names are the role names. The O-O practice of joining the relationship table to the class/entity table usually requires us to put the a reading of the fact-type name and possibly the role name all into the association-end name, because the mapping to C++ and Java discards the association name. MOF tries to be usable in both technologies, which makes for no consistently good naming conventions. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Subject: RE: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Date: Fri, 12 Jan 2007 11:40:57 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Thread-Index: Accz9vmRh57sEWs0Rd6vApl6CZSqyQAKZ4QwAITrmeA= From: "LONJON Antoine" To: "BMM FTF" MEGA votes no. I agree with Cory about the role name issue. In the last SBVR FTF we have clarified the fact-type role concept which has a direct correspondence with "AssociationEnd" in MOF (and a better name by the way). Verbalized association names should use these role names and not the name of concepts playing these roles. From this basis, we could then use John's proposal to have "verbalized names" for associations and use the arrow sign in the diagram to indicate the direction of the verbalization. This unfortunately require some careful usage of the current proposed names in the Motivation Model. Antoine PS: The proposed solution is close to the one adopted by the initial ORM tool from Terry Halpin: The difference is that ORM was able to have two "verbalized names". -------------------------------------------------------------------------------- From: Cory Casanave [mailto:cory-c@enterprisecomponent.com] Sent: Tuesday, January 09, 2007 8:05 PM To: john.hall@modelsys.com; BMM FTF Subject: RE: [BMM FTF2] Ballot 1: Issue 10090 UML Associations DAT votes no. Reason: Lack of role names makes the model harder to understand and when used in MOF, MOF makes up strange names. We would therefore recommend having both role names and association names. Use of directional associations is somewhat unusual and has no meaning in MOF. This is, of course, somewhat stylistic but is more in keeping with the style used in most MOF models. -Cory Casanave -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Tuesday, January 09, 2007 9:02 AM To: BMM FTF Subject: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Happy New Year to all, Attached is a proposal for resolution of Issue 10090. The issue was discussed during the first FTF, and I think that the proposal matches majority opinion, if not complete consensus. For those new to the FTF, the essence of the issue is: the BMM as published gave each association a pair of names, one in each direction. In some pairs the names are simple inverses: for example "tactic implements strategy" and "strategy is implemented by tactic". But in some pairs the verbs are different. For example "business policy is the basis of business rule" and "business rule is derived from business policy". MOF needs association names and UML does not support two names for an association. This proposal is to choose one name for each association: If an association.s names are simple inverses, the active form is used for the association name on the MOF model, e.g. "tactic implements strategy" rather than "strategy is implemented by tactic". If an association.s names are based on different verbs, one has been chosen for the association name on the MOF model, and the other declared as synonymous in the Concepts Catalog. This preserves the BMM vocabulary as published. Could you all, please, vote by end of Monday January 15. Regards, John **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Subject: RE: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Date: Mon, 15 Jan 2007 01:23:11 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BMM FTF2] Ballot 1: Issue 10090 UML Associations thread-index: Accz9uK+gWfdySUzQl2qGquFqflkOwEj62lg From: "Pete Rivett" To: , "BMM FTF" Adaptive votes NO to this issue as currently worded, for reasons previously elaborated. The principle being enacted is OK but the removal of role/association names without any replacement/documented generation rule is not acceptable. Pete -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Tuesday, January 09, 2007 2:02 PM To: BMM FTF Subject: [BMM FTF2] Ballot 1: Issue 10090 UML Associations Happy New Year to all, Attached is a proposal for resolution of Issue 10090. The issue was discussed during the first FTF, and I think that the proposal matches majority opinion, if not complete consensus. For those new to the FTF, the essence of the issue is: the BMM as published gave each association a pair of names, one in each direction. In some pairs the names are simple inverses: for example "tactic implements strategy" and "strategy is implemented by tactic". But in some pairs the verbs are different. For example "business policy is the basis of business rule" and "business rule is derived from business policy". MOF needs association names and UML does not support two names for an association. This proposal is to choose one name for each association: If an association.s names are simple inverses, the active form is used for the association name on the MOF model, e.g. "tactic implements strategy" rather than "strategy is implemented by tactic". If an association.s names are based on different verbs, one has been chosen for the association name on the MOF model, and the other declared as synonymous in the Concepts Catalog. This preserves the BMM vocabulary as published. Could you all, please, vote by end of Monday January 15. Regards, John DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:In-Reply-To:Thread-Index:X-MimeOLE; b=B79A3oXk795iqGhHWkRMXxmHM8GC0V2DGX1EjPCBniNCHzgNj0Ei9VVOo+noOv2vvjSUORYlv8/amzMfRHT79iiTUE7oWxoqH0jvGjNgXZCbtQ/I1L44b0IwqdSv1c1pZTMv0BuUaQ9cHIFm7qQVka3o+6eAWrmc8mrHY/cHDho= ; X-YMail-OSG: 22CaaAcVM1nXhxhH.fAeRhY0rRqfZxMl8yXLwpzt_gEjVW_TzXUuk1gKuEdyv3nmy07mClyYBQ7SbLzmilgS1VmlQsnaNmBJx00k0.qS1.dJWJAqczzRmFyaGc4h7bRYgmA7TtB2w2GoCMQuNCbJt0Y0u0R20w71z9qki7at6RcPdxvWLIIxhFOTlg-- Reply-To: From: "Donald Chapin" To: "'BMM FTF'" Subject: RE: [BMM FTF2] Ballot 1: Issue 10090 UML Associations - extension Date: Wed, 17 Jan 2007 19:20:12 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc6aS3vmHNybMElREqgPCS+PFertgAAtb7g John, In your example I would like to see "Implementing Tactic" and "Implemented Strategy" as role names. Donald > -----Original Message----- > From: John Hall [mailto:john.hall@modelsys.com] > Sent: 17 January 2007 18:56 > Cc: BMM FTF > Subject: Re: [BMM FTF2] Ballot 1: Issue 10090 UML Associations - extension > > Hello all, > > Thanks to all who responded - although it might have been helpful to > have these comments when the proposal was made in the first FTF at the > beginning of November : ). > > Given the responses I'd like to extend the deadline for voting, so that > I can amend the proposal to reflect the feedback. I hope to be able to > do that by tomorrow, although I am travelling at the moment with limited > internet access (this is coming from Geneva rail station). > > Any thoughts on Ed's proposal that association names should be the full > verb concept, e.g. "tactic implements strategy" (with role names > "implementer" and "implemented") rather than just "implements"? > > Regards, > > John > > Date: Mon, 22 Jan 2007 15:21:04 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: keri CC: BMM FTF Subject: Re: [BMM FTF2] Ballot 1: Issue 10090 UML Associations - extension X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No John wrote: Any thoughts on Ed's proposal that association names should be the full verb concept, e.g. "tactic implements strategy" (with role names "implementer" and "implemented") rather than just "implements"? Keri replied: That would be similar to the approach that SBVR applies. To be even more similar, the association name would omit the subject role name and would place the object role name inside square brackets. (That is for binary fact types for verbs other than "has".) Actually, in the SBVR approach, fact-types do not correspond to UML associations at all. In SBVR, a fact-type is represented by a UML class that is named for the fact-type, e.g., "concept generalizes concept", which has two attributes (associations) named for the fact-type roles. (See SBVR clause 13) My proposal was similar in that it recommends naming the UML association to match the fact-type, and the association ends to correspond to the roles. I do not see how Keri's proposal is "more similar" to the SBVR approach. Perhaps she is talking about the non-normative UML drawings in the text, which are purely tutorial to the SBVR metamodel. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Fri, 13 Jul 2007 09:40:24 -0400 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) To: BMM FTF Subject: [BMM] Issue 10090 Hello all, Just before the Brussels meeting Antoine proposed an approach for AssociationEnd names (see below). It has the additional benefits that: Antoine could generate the XMI and XSD without the need for manual editing The architecture would be consistent with that of BPDM, partly resolving issue 10586 Any comments or suggestions before I put it up for ballot (probably bundled with a few minor issues concerned with associations)? Regards, John -------- Original Message -------- Subject: FW: BMM extension and completion Date: Wed, 20 Jun 2007 15:32:34 +0200 From: LONJON Antoine To: These email is a response to issues: 10586 and 10090 10090: The attached documents provide a sample html version of the specification where propositions are made to manage AssociationEnd Names 1. All elements have two names: an english name and and xmi name (technical) name. The English name is the standard name of the specification. The xmi name is used for xmi/xsd generation 2. association names only handles the verb part of the equivalent SBVR fact type 3. Aggreation is used to specify the order in which associations are verbalized: aggregating class + association name + aggreged class The html file provides an example on Assessment 4. There is a proposition to replace motivation_element by OMG Infrastructure elements such as "NamedElement" or "PackagedElement" This provides a better alignment at XMI serialization with other OMG specification, including BPDM. 5. The html files proposed a set of name for roles in BMM. These names are just here for illustration and, of course, require to be validated by the group. The xmi generated files also use these names as an illustration. All rules used here are based on the way BPDM is proposing a serialization of MOF models. It includes an organization the infrastructure is a set of small an reusable xsd files. cmof files are also available from the same source. Rules regarding the management of */* associations may be updated and will benefit for both BPDM and BMM. xsd files provided have been validated by Oxygen 7 10586 Business Process uses now the construct provided by BPDM The XMI files provided includes a references to BPDM xmi constructs. Antoine bmm html.zip xmi1.zip Date: Fri, 13 Jul 2007 09:48:14 -0400 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) To: BMM FTF Subject: [BMM] Issue 10090 Hello all, Just before the Brussels meeting Antoine proposed an approach for AssociationEnd names (see below). It has the additional benefits that: Antoine could generate the XMI and XSD without the need for manual editing The CMOF/XMI would be consistent with that of BPDM, partly resolving issue 10586 Any comments or suggestions before I put it up for ballot (probably bundled with a few minor issues concerned with associations)? Regards, John -------- Original Message -------- Subject: RE: BMM extension and completion Date: Thu, 21 Jun 2007 09:45:09 +0200 From: LONJON Antoine To: References: <72BC838C019C3B488F438A3BF41F05D705178E91@via.fr.mega.com> Following is a better version of the proposed names for associations and roles and a better corresponding html document. The cmof and xsd files have been updated accordingly. Antoine -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Wednesday, June 20, 2007 3:33 PM To: bmm-ftf@omg.org Subject: FW: BMM extension and completion These email is a reponse to issues: 10586 and 10090 10090: The attached documents provide a sample html version of the specification where propositions are made to manage AssociationEnd Names 1. All elements have two names: an english name and and xmi name (technical) name. The English name is the standard name of the specification. The xmi name is used for xmi/xsd generation 2. association names only handles the verb part of the equivalent SBVR fact type 3. Aggreation is used to specify the order in which associations are verbalized: aggregating class + association name + aggreged class The html file provides an example on Assessment 4. There is a proposition to replace motivation_element by OMG Infrastructure elements such as "NamedElement" or "PackagedElement" This provides a better alignment at XMI serialization with other OMG specification, including BPDM. 5. The html files proposed a set of name for roles in BMM. These names are just here for illustration and, of course, require to be validated by the group. The xmi generated files also use these names as an illustration. All rules used here are based on the way BPDM is proposing a serialization of MOF models. It includes an organization the infrastructure is a set of small an reusable xsd files. cmof files are also available from the same source. Rules regarding the management of */* associations may be updated and will benefit for both BPDM and BMM. xsd files provided have been validated by Oxygen 7 10586 Business Process uses now the construct provided by BPDM The XMI files provided includes a references to BPDM xmi constructs. Antoine bmm html1.zip xmi2.zip Date: Fri, 13 Jul 2007 10:21:53 -0400 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) To: john.hall@modelsys.com Cc: BMM FTF Subject: Re: [BMM] Issue 10090 - which version to respond to Hello all, I sent two versions of Antoine's proposal. I thought I had canceled the earlier one before transmission but it got away. The one to respond to is the one where Antoine says "Following is a better version ..." (as below) Sorry, John John Hall wrote: Hello all, Just before the Brussels meeting Antoine proposed an approach for AssociationEnd names (see below). It has the additional benefits that: Antoine could generate the XMI and XSD without the need for manual editing The CMOF/XMI would be consistent with that of BPDM, partly resolving issue 10586 Any comments or suggestions before I put it up for ballot (probably bundled with a few minor issues concerned with associations)? Regards, John -------- Original Message -------- Subject: RE: BMM extension and completion Date: Thu, 21 Jun 2007 09:45:09 +0200 From: LONJON Antoine To: References: <72BC838C019C3B488F438A3BF41F05D705178E91@via.fr.mega.com> Following is a better version of the proposed names for associations and roles and a better corresponding html document. The cmof and xsd files have been updated accordingly. Antoine -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Wednesday, June 20, 2007 3:33 PM To: bmm-ftf@omg.org Subject: FW: BMM extension and completion These email is a reponse to issues: 10586 and 10090 10090: The attached documents provide a sample html version of the specification where propositions are made to manage AssociationEnd Names 1. All elements have two names: an english name and and xmi name (technical) name. The English name is the standard name of the specification. The xmi name is used for xmi/xsd generation 2. association names only handles the verb part of the equivalent SBVR fact type 3. Aggreation is used to specify the order in which associations are verbalized: aggregating class + association name + aggreged class The html file provides an example on Assessment 4. There is a proposition to replace motivation_element by OMG Infrastructure elements such as "NamedElement" or "PackagedElement" This provides a better alignment at XMI serialization with other OMG specification, including BPDM. 5. The html files proposed a set of name for roles in BMM. These names are just here for illustration and, of course, require to be validated by the group. The xmi generated files also use these names as an illustration. All rules used here are based on the way BPDM is proposing a serialization of MOF models. It includes an organization the infrastructure is a set of small an reusable xsd files. cmof files are also available from the same source. Rules regarding the management of */* associations may be updated and will benefit for both BPDM and BMM. xsd files provided have been validated by Oxygen 7 10586 Business Process uses now the construct provided by BPDM The XMI files provided includes a references to BPDM xmi constructs. Antoine Subject: RE: [BMM] Issue 10090 Date: Mon, 16 Jul 2007 01:56:36 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BMM] Issue 10090 Thread-Index: AcfFVf7czd8TrHRYQiSOIA/z9R/GmwBxTyCg From: "Pete Rivett" To: , "BMM FTF" This is a partial review - based on the HTML version. Overall I think it is a step forward, but would not like to take BPDM as a precedent since that has only just started Finalization itself, and the metamodeling conventions are still under similar discussion. In general MOF and UML have conventions as follows: - Classes and Associations start with upper case, properties lower case - all words are camelcase with no spaces - Associations are uniquely named in the package - which typically means the names are of the style "GoalAmplifiesVision' I know that SBVR may apply an opposite influence. Let's at least document a set of conventions that is a good compromise between both. Rather than trying to introduce policy by stealth let's try to document some conventions for "metamodels that are also to be SBVR vocabularies" and get broader agreement (e.g. AB endorsement). The proposal seems to go beyond the scope of the issue (have other resolutions introduced these changes?): a) aggregations are introduced which have no meaning in MOF (only compositions do) Actually many aggregations seem the wrong way round anyway - e.g. Policy, Goal and Strategy should aggregate Business Rule, Objective and Tactic respectively. b) superclasses PackagedElement and NamedElement are used c) The class MotivationElement is not present There are a few cases where the (good) convention of making association ends into noun phrases has not been followed: supports achievement of has achievement supported by has_enforcement level effected by (also retains a '_') effects enforcement level of planned by means of component of the plan for component of (which actually means the same as its opposite end - part of) (there is no association name for this one on DesiredEnd) part of part of composed_of (also retains a '_') governed by Composition on BusinessDirective seems replaced by 'uses' which is semantically different. There are some issues of English: a) The phrase 'impulsed directive' does not make sense. Why not 'directive motivated' b) 'amplified goal' is the wrong way round: it is the Goal that amplifies the Vision so it should be 'amplifying goal' (and 'amplified vision') c) I think 'employed means' is wrong for an Assessment since it's an assessment that affects whether the means is employed at all. In general I think the language should make clearer that it is not just an assessment of an end/means, but the assessment of how an influencer affects the means to the end. Arguably there should be a separate ability to judge how well we're meeting an objective etc (a separate issue) Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 http://www.adaptive.com -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Friday, July 13, 2007 2:48 PM To: BMM FTF Subject: [BMM] Issue 10090 Hello all, Just before the Brussels meeting Antoine proposed an approach for AssociationEnd names (see below). It has the additional benefits that: Antoine could generate the XMI and XSD without the need for manual editing The CMOF/XMI would be consistent with that of BPDM, partly resolving issue 10586 Any comments or suggestions before I put it up for ballot (probably bundled with a few minor issues concerned with associations)? Regards, John -------- Original Message -------- Subject: RE: BMM extension and completion Date: Thu, 21 Jun 2007 09:45:09 +0200 From: LONJON Antoine To: References: <72BC838C019C3B488F438A3BF41F05D705178E91@via.fr.mega.com> Following is a better version of the proposed names for associations and roles and a better corresponding html document. The cmof and xsd files have been updated accordingly. Antoine -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Wednesday, June 20, 2007 3:33 PM To: bmm-ftf@omg.org Subject: FW: BMM extension and completion These email is a reponse to issues: 10586 and 10090 10090: The attached documents provide a sample html version of the specification where propositions are made to manage AssociationEnd Names 1. All elements have two names: an english name and and xmi name (technical) name. The English name is the standard name of the specification. The xmi name is used for xmi/xsd generation 2. association names only handles the verb part of the equivalent SBVR fact type 3. Aggreation is used to specify the order in which associations are verbalized: aggregating class + association name + aggreged class The html file provides an example on Assessment 4. There is a proposition to replace motivation_element by OMG Infrastructure elements such as "NamedElement" or "PackagedElement" This provides a better alignment at XMI serialization with other OMG specification, including BPDM. 5. The html files proposed a set of name for roles in BMM. These names are just here for illustration and, of course, require to be validated by the group. The xmi generated files also use these names as an illustration. All rules used here are based on the way BPDM is proposing a serialization of MOF models. It includes an organization the infrastructure is a set of small an reusable xsd files. cmof files are also available from the same source. Rules regarding the management of */* associations may be updated and will benefit for both BPDM and BMM. xsd files provided have been validated by Oxygen 7 10586 Business Process uses now the construct provided by BPDM The XMI files provided includes a references to BPDM xmi constructs. Antoine Subject: RE: [BMM] Issue 10090 Date: Mon, 16 Jul 2007 14:11:03 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [BMM] Issue 10090 Thread-Index: AcfFVf7czd8TrHRYQiSOIA/z9R/GmwBxTyCgAB+eIoA= From: "LONJON Antoine" To: "Pete Rivett" , , "BMM FTF" Pete, Thank you for this feedback. My responses are below. I have also included a new version of the html file that includes proposed updates you made. Antoine From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Monday, July 16, 2007 10:57 AM To: john.hall@modelsys.com; BMM FTF Subject: RE: [BMM] Issue 10090 This is a partial review - based on the HTML version. Overall I think it is a step forward, but would not like to take BPDM as a precedent since that has only just started Finalization itself, and the metamodeling conventions are still under similar discussion. [ALN] The document I sent was initially a proposal to move forward on issue 10090. Of course, I used some of the elements that are currently being validated by BPDM. There are two main purposes for this. 1. Ensure true logical interoperability between BMI specifications by using a minimum set of core infrastructure elements 2. Ensure true physical interoperability at the XMI serialization level; based on the logical interoperability and one shared serialization rules From an OMG historical viewpoint, this has never really been achieved because of the habit to embed everything in UML with profiling techniques. [ALN] In general MOF and UML have conventions as follows: - Classes and Associations start with upper case, properties lower case - all words are camelcase with no spaces - Associations are uniquely named in the package - which typically means the names are of the style "GoalAmplifiesVision' I know that SBVR may apply an opposite influence. Let's at least document a set of conventions that is a good compromise between both. Rather than trying to introduce policy by stealth let's try to document some conventions for "metamodels that are also to be SBVR vocabularies" and get broader agreement (e.g. AB endorsement). [ALN] Again the document sent is only a proposal. A more formal document has been provided through the BPDM team to formalized this rules but it is still not adopted You have already made a lot a valuable comments about it and The proposal seems to go beyond the scope of the issue (have other resolutions introduced these changes?): a) aggregations are introduced which have no meaning in MOF (only compositions do) Actually many aggregations seem the wrong way round anyway - e.g. Policy, Goal and Strategy should aggregate Business Rule, Objective and Tactic respectively. [ALN] 1. There are many places where the .whole/part. relationship should be clarified. In the proposal, I used the usual pattern: which object is modified when the association is deleted: Are Business Rules part of the definition of Tactics or Tactics part of the definition of Business Rules? 2. I don.t have any other alternative than Aggregation to indicate (from the model) the direction of the association. Any other proposal is welcome. 3. From a MOF viewpoint, MOF merges from Constructs which has aggregation (unless I have missed something). b) superclasses PackagedElement and NamedElement are used [ALN] This is coming with the proposed alignment with Infrastructure c) The class MotivationElement is not present [ALN] This is coming from the proposed alignment with Infrastructure There are a few cases where the (good) convention of making association ends into noun phrases has not been followed: supports achievement of[ALN] => achieved desired result has achievement supported by[ALN] => supporting directive has_enforcement level effected by (also retains a '_')[ALN] => tactic affected enforcement level (could really be improved: also show an issue with enforcement level which is not formalized) effects enforcement level of[ALN] => enforcing business rules planned by means of[ALN] => mission component component of the plan for[ALN] => planned mission component of (which actually means the same as its opposite end - part of) (there is no association name for this one on DesiredEnd)[ALN] => I have understood this role as the strategy being a component of the mission part of[ALN] => There are ambiguities regarding a whole/part relationship here as the multiplicities are N/N part of composed_of (also retains a '_')[ALN] fixed governed by[ALN] = governing policy Composition on BusinessDirective seems replaced by 'uses' which is semantically different. [ALN] That.s the issue about */* multiplicities on composition There are some issues of English: a) The phrase 'impulsed directive' does not make sense. Why not 'directive motivated'[ALN] OK b) 'amplified goal' is the wrong way round: it is the Goal that amplifies the Vision so it should be 'amplifying goal' (and 'amplified vision')[ALN] Yes. Fixed c) I think 'employed means' is wrong for an Assessment since it's an assessment that affects whether the means is employed at all. In general I think the language should make clearer that it is not just an assessment of an end/means, but the assessment of how an influencer affects the means to the end. Arguably there should be a separate ability to judge how well we're meeting an objective etc (a separate issue) [ALN] Let.s raise the issue Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 http://www.adaptive.com -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Friday, July 13, 2007 2:48 PM To: BMM FTF Subject: [BMM] Issue 10090 Hello all, Just before the Brussels meeting Antoine proposed an approach for AssociationEnd names (see below). It has the additional benefits that: Antoine could generate the XMI and XSD without the need for manual editing The CMOF/XMI would be consistent with that of BPDM, partly resolving issue 10586 Any comments or suggestions before I put it up for ballot (probably bundled with a few minor issues concerned with associations)? Regards, John -------- Original Message -------- Subject: RE: BMM extension and completion Date: Thu, 21 Jun 2007 09:45:09 +0200 From: LONJON Antoine To: References: <72BC838C019C3B488F438A3BF41F05D705178E91@via.fr.mega.com> Following is a better version of the proposed names for associations and roles and a better corresponding html document. The cmof and xsd files have been updated accordingly. Antoine -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Wednesday, June 20, 2007 3:33 PM To: bmm-ftf@omg.org Subject: FW: BMM extension and completion These email is a reponse to issues: 10586 and 10090 10090: The attached documents provide a sample html version of the specification where propositions are made to manage AssociationEnd Names 1. All elements have two names: an english name and and xmi name (technical) name. The English name is the standard name of the specification. The xmi name is used for xmi/xsd generation 2. association names only handles the verb part of the equivalent SBVR fact type 3. Aggreation is used to specify the order in which associations are verbalized: aggregating class + association name + aggreged class The html file provides an example on Assessment 4. There is a proposition to replace motivation_element by OMG Infrastructure elements such as "NamedElement" or "PackagedElement" This provides a better alignment at XMI serialization with other OMG specification, including BPDM. 5. The html files proposed a set of name for roles in BMM. These names are just here for illustration and, of course, require to be validated by the group. The xmi generated files also use these names as an illustration. All rules used here are based on the way BPDM is proposing a serialization of MOF models. It includes an organization the infrastructure is a set of small an reusable xsd files. cmof files are also available from the same source. Rules regarding the management of */* associations may be updated and will benefit for both BPDM and BMM. xsd files provided have been validated by Oxygen 7 10586 Business Process uses now the construct provided by BPDM The XMI files provided includes a references to BPDM xmi constructs. Antoine **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received