Issue 15931: Test Objective issue (uml-testing-profile-rtf) Source: Grand Software Testing (Mr. Jon Hagar, embedded(at)ecentral.com) Nature: Uncategorized Issue Severity: Summary: Test Objective 1. In the OMG Testing Profile (OTP) specification a Test Objective is defined both as a stereotype on a dependency, «TestObjective», and as an artifact elsewhere. The «TestObjective» stereotype does not apply to this artifact, just to the dependency. 2. The Test Objective dependency relationship is intended to show the dependency from a Test Context or a Test Case to a model element that contains the textual string stating the objective of the test, the test objective artifact. Resolution: Test Objective as a dependency: a. Change Suggestion 1 - No longer use the stereotype «TestObjective» for this dependency relationship. A dependency relationship stereotype name is typically a verb, like verify, satisfy, refine, and copy. Using a noun phrase like “TestObjectiveon” to name a dependency does not provide the declaration that is needed, i.e. subject verb object, e.g. “BlockA satisfies requirement 1”, or “Use Case A refines requirement 1”. b. Change Suggestion 2 – Use the verb “Validate” as the name of the stereotype that is associated with a dependency. This stereotyped dependency can be used from a Test Case or Test Context to a Test Objective but, can also be used between a test case and model elements that state objectives/goals/capabilities of the item being validated. c. Why use validate? – Others were considered such as satisfy, realize and implement. i. The validation definition used by test is “Validation is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals and objectives (i.e. meet stakeholder requirements) in the intended operational environment” , or “Did we build the right thing?” These system uses, goals and objectives are represented in the model in the form of use cases, MOEs, TPMs, etc. ii. There is a clear distinction between verification and validation. Based on this, there will be unique Test Contexts for verification and validation. iii. Just as we need to show what test cases will be verifying what requirements we will also need to show what test cases will be validating objectives and goals of the system (or the thing being validated). Therefore, this relationship will ultimately be needed just as verify is used today to verify requirements. iv. This relationship can also be used to show what test cases are validating the objectives stated for a Test Context. It is the same relationship pattern. Test Objective part 2 1. A Test Objective artifact is a textual statement stating a goal or objective of a test context. The OTP specification doesn’t define the type of model element to use for this artifact. Resolution: 1. Test Objective artifact suggestion – a. We have selected a comment stereotyped «TestObjective» to capture the Test Objective artifact for a Test Context. However, other model elements could be used, such as an attribute of the Test Context. The advantage of a comment is that it can be reused across test contexts Resolution: Test Objective as a dependency: a. Change Suggestion 1 - No longer use the stereotype «TestObjective» for this dependency relationship. A dependency relationship stereotype name is typically a verb, like verify, satisfy, refine, and copy. Using a noun phrase like “TestObjectiveon” to name a dependency does not provide the declaration that is needed, i.e. subject verb object, e.g. “BlockA satisfies requirement 1”, or “Use Case A refines requirement 1”. b. Change Suggestion 2 – Use the verb “Validate” as the name of the stereotype that is associated with a dependency. This stereotyped dependency can be used from a Test Case or Test Context to a Test Objective but, can also be used between a test case and model elements that state objectives/goals/capabilities of the item being validated. c. Why use validate? – Others were considered such as satisfy, realize and implement. i. The validation definition used by test is “Validation is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals and objectives (i.e. meet stakeholder requirements) in the intended operational environment” , or “Did we build the right thing?” These system uses, goals and objectives are represented in the model in the form of use cases, MOEs, TPMs, etc. ii. There is a clear distinction between verification and validation. Based on this, there will be unique Test Contexts for verification and validation. iii. Just as we need to show what test cases will be verifying what requirements we will also need to show what test cases will be validating objectives and goals of the system (or the thing being validated). Therefore, this relationship will ultimately be needed just as verify is used today to verify requirements. iv. This relationship can also be used to show what test cases are validating the objectives stated for a Test Context. It is the same relationship pattern. Test Objective part 2 1. A Test Objective artifact is a textual statement stating a goal or objective of a test context. The OTP specification doesn’t define the type of model element to use for this artifact. Resolution: 1. Test Objective artifact suggestion – a. We have selected a comment stereotyped «TestObjective» to capture the Test Objective artifact for a Test Context. However, other model elements could be used, such as an attribute of the Test Context. The advantage of a comment is that it can be reused across test contexts Resolution: The RTF discussed a lot on the test objective issue and we agreed entirely that a dependency as test objective is quite unintuitive, confusing and misleading. We had a long way to go until the RTF agreed on a resolution that suits all and is most accepted in the testing area in the industry. Finally, we decided to change the metaclass of the current «TestObjective» from Dependency to Class and to put tag definitions into the stereotype that are pertinent to test management, test planning and test schedule. The new «TestObjective» is conceptually compatible with the concept Objective from the Business Motivation Metamodel (BMM), although BMM does not provide a UML profile yet and is therefore not a normative reference for the UML Testing Profile. Revised Text: Actions taken: January 13, 2011: received issue January 7, 2013: closed issue Discussion: Deferred due to time restrictions End of Annotations:===== te: Thu, 13 Jan 2011 10:38:58 -0500 From: "Hagar, Jon D" Subject: Test Objective issue To: "issues@omg.org" Thread-Topic: Test Objective issue Thread-Index: AcuxAf19cX13/iFwQYiflm2pp5xQiACNKTEQ Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-01-13_07:2011-01-13,2011-01-13,1970-01-01 signatures=0 Source: Lockheed Martin, Jon Hagar Specification: UML Testing Profile Section: figure 6.2 Nature: Issue Severity: med Summary: Test Objective 1. In the OMG Testing Profile (OTP) specification a Test Objective is defined both as a stereotype on a dependency, «TestObjective», and as an artifact elsewhere. The «TestObjective» stereotype does not apply to this artifact, just to the dependency. 2. The Test Objective dependency relationship is intended to show the dependency from a Test Context or a Test Case to a model element that contains the textual string stating the objective of the test, the test objective artifact. Resolution: Test Objective as a dependency: a. Change Suggestion 1 - No longer use the stereotype «TestObjective» for this dependency relationship. A dependency relationship stereotype name is typically a verb, like verify, satisfy, refine, and copy. Using a noun phrase like .TestObjectiveon. to name a dependency does not provide the declaration that is needed, i.e. subject verb object, e.g. .BlockA satisfies requirement 1., or .Use Case A refines requirement 1.. b. Change Suggestion 2 . Use the verb .Validate. as the name of the stereotype that is associated with a dependency. This stereotyped dependency can be used from a Test Case or Test Context to a Test Objective but, can also be used between a test case and model elements that state objectives/goals/capabilities of the item being validated. c. Why use validate? . Others were considered such as satisfy, realize and implement. i. The validation definition used by test is .Validation is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals and objectives (i.e. meet stakeholder requirements) in the intended operational environment. , or .Did we build the right thing?. These system uses, goals and objectives are represented in the model in the form of use cases, MOEs, TPMs, etc. ii. There is a clear distinction between verification and validation. Based on this, there will be unique Test Contexts for verification and validation. iii. Just as we need to show what test cases will be verifying what requirements we will also need to show what test cases will be validating objectives and goals of the system (or the thing being validated). Therefore, this relationship will ultimately be needed just as verify is used today to verify requirements. iv. This relationship can also be used to show what test cases are validating the objectives stated for a Test Context. It is the same relationship pattern. Revised Text: Actions taken: Date: Thu, 13 Jan 2011 10:42:33 -0500 From: "Hagar, Jon D" Subject: FW: Test Objective issue - continued To: "issues@omg.org" Thread-Topic: Test Objective issue - continued Thread-Index: AcuxAf19cX13/iFwQYiflm2pp5xQiACNKTEQAABrieA= Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-01-13_07:2011-01-13,2011-01-13,1970-01-01 signatures=0 Source: Lockheed Martin, Jon Hagar Specification: UML Testing Profile Section: test objective part 2 Nature: Issue Severity: med Summary: Test Objective part 2 1. A Test Objective artifact is a textual statement stating a goal or objective of a test context. The OTP specification doesn.t define the type of model element to use for this artifact. Resolution: 1. Test Objective artifact suggestion . a. We have selected a comment stereotyped «TestObjective» to capture the Test Objective artifact for a Test Context. However, other model elements could be used, such as an attribute of the Test Context. The advantage of a comment is that it can be reused across test contexts. Revised Text: Actions taken: Subject: Concerning issue 15931: Test Objective issue X-KeepSent: 2177BF7D:6C62905B-C2257A3C:0023140A; type=4; name=$KeepSent To: "Wendland, Marc-Florian" Cc: , "Marc Lettrari" X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eldad Palachi Date: Sun, 15 Jul 2012 09:52:11 +0300 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 15/07/2012 09:52:04 x-cbid: 12071506-3548-0000-0000-0000028C448F Hi, Concerning issue 15931: Test Objective issue. I realized that this was discussed a lot until an agreement was reached. However we also need to consider backward compatibility for tools. Our tool is using TestObjective as dependency now, we would at least like to have some guidance from the spec on how to transform an existing model. This is the approach we have taken in SysML 1.3 spec when we made the changes for ports - we provided transformation rules (Annex B) with guidance on how to transform existing ports (which were deprecated) to the new ports. Btw, we stated that the existing ports are deprecated but we did not remove them from the spec - this is cleaner for an RTF. I understand that in this case a change is made to an existing stereotype (this is actually worse from backward compatibility perspective), so even if the change is agreed, we need to consider how to deal with existing models in a standard way. I apologize for raising this so late, I would have liked to participate more in the group but unfortunately I am quite constrained these days. Thanks, Eldad From: "Wendland, Marc-Florian" To: , Date: 06/07/2012 04:40 PM Subject: UTP 1.2 Vote #1 Dear RTF voting members, Could you please vote on the resolutions to UTP 1.2 issues described in the attached report and already incorporated in the likewise attached convenience documents. Please do not pay attention to preface chapters or additional design stuff like headers and footers. Those things are going to be cleaned up and updated when the final version of the specification is about to be rendered. Changes are only applied to normative chapters and annexes starting from chapter 1. Deadline for this vote is set to the 20th of July! Please remain the subject of the mail as it is so that it can be organized automatically in mail clients. ----------------- Voting Form ----------------- (Mark each Issue with YES, NO or ABSTAIN based on resolutions proposed in attached document, or YES TO ALL as a shortcut) Issue #17292: Issue #16906: Issue #16878: Issue #15931: Issue #16900: Issue #17222: Issue #17231: Issue #16000: Issue #15941: As we had several roundtrips and remark requests of and for the resolutions relevant in this vote, I do not expect any further need for substantial discussions. Many thanks in advance, Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ [attachment "utp_1-2.pdf" deleted by Eldad Palachi/Haifa/IBM] [attachment "UTP_1.2_changebar.pdf" deleted by Eldad Palachi/Haifa/IBM] [attachment Subject: AW: Concerning issue 15931: Test Objective issue Date: Sun, 15 Jul 2012 21:24:45 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Concerning issue 15931: Test Objective issue Thread-Index: Ac1iVmTgQUzQXDSuRmO6jemOIXuVBQAZuPTQ priority: Urgent From: "Wendland, Marc-Florian" To: "Eldad Palachi" Cc: , "Marc Lettrari" X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml-testing-profile-rtf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate03-haj2 with 3602712B4001 X-cloud-security: scantime:.4339 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q6FJQfV9013782 Hi Eldad, yes, it's indeed quite late to raise such a fundamental concern. The report has been passed around twice before requesting the vote. I know that you are actively involved in SysML, so it might be a sensible solution for all parties if IBM could send another representative for UTP in the future who is less busy with other stuff and could actively contribute in the work or even respons at least to a certain extent in time. It is difficult to make progress without responses from the formally involved members until the very last chance. However, I agree with your concern regarding backward compatibility. Due to the tight time frame for the entire RTF, I would like to ask you for another solution than to withdraw or extend the first vote again. Since we're providing a new structure of the specification document in the second (and last vote), I would like to incorporate that issue you just described in the very last vote. This would allow us to finish the first vote in time. As resolution, I suggest the following: Have a new annex section for deprecated concepts, as you did for SysML. We would put the old way of defining TestObjectives (as dependency) in there with a description how to transition from UTP 1.1 models to UTP 1.2 models, if required. I do not have time this week to fix further things due to a business trip and vacations. I would really appreciate if you agree with my suggestion for handling your concern. Marc-Florian -----Ursprühe Nachricht----- Von: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Gesendet: Sonntag, 15. Juli 2012 08:52 An: Wendland, Marc-Florian Cc: uml-testing-profile-rtf@omg.org; Marc Lettrari Betreff: Concerning issue 15931: Test Objective issue Hi, Concerning issue 15931: Test Objective issue. I realized that this was discussed a lot until an agreement was reached. However we also need to consider backward compatibility for tools. Our tool is using TestObjective as dependency now, we would at least like to have some guidance from the spec on how to transform an existing model. This is the approach we have taken in SysML 1.3 spec when we made the changes for ports - we provided transformation rules (Annex B) with guidance on how to transform existing ports (which were deprecated) to the new ports. Btw, we stated that the existing ports are deprecated but we did not remove them from the spec - this is cleaner for an RTF. I understand that in this case a change is made to an existing stereotype (this is actually worse from backward compatibility perspective), so even if the change is agreed, we need to consider how to deal with existing models in a standard way. I apologize for raising this so late, I would have liked to participate more in the group but unfortunately I am quite constrained these days. Thanks, Eldad From: "Wendland, Marc-Florian" To: , Date: 06/07/2012 04:40 PM Subject: UTP 1.2 Vote #1 Dear RTF voting members, Could you please vote on the resolutions to UTP 1.2 issues described in the attached report and already incorporated in the likewise attached convenience documents. Please do not pay attention to preface chapters or additional design stuff like headers and footers. Those things are going to be cleaned up and updated when the final version of the specification is about to be rendered. Changes are only applied to normative chapters and annexes starting from chapter 1. Deadline for this vote is set to the 20th of July! Please remain the subject of the mail as it is so that it can be organized automatically in mail clients. ----------------- Voting Form ----------------- (Mark each Issue with YES, NO or ABSTAIN based on resolutions proposed in attached document, or YES TO ALL as a shortcut) Issue #17292: Issue #16906: Issue #16878: Issue #15931: Issue #16900: Issue #17222: Issue #17231: Issue #16000: Issue #15941: As we had several roundtrips and remark requests of and for the resolutions relevant in this vote, I do not expect any further need for substantial discussions. Many thanks in advance, Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ [attachment "utp_1-2.pdf" deleted by Eldad Palachi/Haifa/IBM] [attachment "UTP_1.2_changebar.pdf" deleted by Eldad Palachi/Haifa/IBM] [attachment "UTP_1-2_RTF_report.doc" deleted by Eldad Palachi/Haifa/IBM] Subject: Re: AW: Concerning issue 15931: Test Objective issue X-KeepSent: 885A95FE:C3BB75DC-C2257A3D:0020E5AC; type=4; name=$KeepSent To: "Wendland, Marc-Florian" Cc: "Marc Lettrari" , uml-testing-profile-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eldad Palachi Date: Mon, 16 Jul 2012 10:15:34 +0300 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 16/07/2012 10:15:31 x-cbid: 12071607-3548-0000-0000-0000028EB380 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q6G7FpvH003458 Hi Marc-Florian, I agree with your proposal as long as it is agreed to address the issue before the submission is finalized. >From a technical perspective we cannot have two stereotypes (one in section 7 and one in the annex) with the same name so we will probably have to rename either the new TestObject or the old TestObjective. I can make a proposal to resolve the issue after we resume the technical work - I think it should be quite straightforward. I will probably need your help though in presenting it in the right format. Regarding your first paragraph - all I can say is that in my experience it is not uncommon to get "fundamental concerns" late. I have experienced this myself quite a few times at the OMG, Also, what is the purpose of circulating the ballot if not to get feedback from the "less active" participants? (the ballot was sent 10 days ago and to be honest I have not even "digested" all of it) As a general comment, I think that the RTF is "pushing the boundaries" - not only fixing issues but also introducing new concepts and extending the original profile. I support this approach as long as the RTF remains open to defer issues once concerns are raised, even if they are raised late (although for this particular issue I am fine with not deferring). I am still digesting some of the other issues (e.g. <> for instance specification) and may raise other concerns in the next couple of days as I may also get feedback from my colleagues who are also looking at the ballot. Kind regards, Eldad From: "Wendland, Marc-Florian" To: Eldad Palachi/Haifa/IBM@IBMIL, Cc: , "Marc Lettrari" Date: 15/07/2012 10:26 PM Subject: AW: Concerning issue 15931: Test Objective issue Hi Eldad, yes, it's indeed quite late to raise such a fundamental concern. The report has been passed around twice before requesting the vote. I know that you are actively involved in SysML, so it might be a sensible solution for all parties if IBM could send another representative for UTP in the future who is less busy with other stuff and could actively contribute in the work or even respons at least to a certain extent in time. It is difficult to make progress without responses from the formally involved members until the very last chance. However, I agree with your concern regarding backward compatibility. Due to the tight time frame for the entire RTF, I would like to ask you for another solution than to withdraw or extend the first vote again. Since we're providing a new structure of the specification document in the second (and last vote), I would like to incorporate that issue you just described in the very last vote. This would allow us to finish the first vote in time. As resolution, I suggest the following: Have a new annex section for deprecated concepts, as you did for SysML. We would put the old way of defining TestObjectives (as dependency) in there with a description how to transition from UTP 1.1 models to UTP 1.2 models, if required. I do not have time this week to fix further things due to a business trip and vacations. I would really appreciate if you agree with my suggestion for handling your concern. Marc-Florian -----Ursprühe Nachricht----- Von: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Gesendet: Sonntag, 15. Juli 2012 08:52 An: Wendland, Marc-Florian Cc: uml-testing-profile-rtf@omg.org; Marc Lettrari Betreff: Concerning issue 15931: Test Objective issue Hi, Concerning issue 15931: Test Objective issue. I realized that this was discussed a lot until an agreement was reached. However we also need to consider backward compatibility for tools. Our tool is using TestObjective as dependency now, we would at least like to have some guidance from the spec on how to transform an existing model. This is the approach we have taken in SysML 1.3 spec when we made the changes for ports - we provided transformation rules (Annex B) with guidance on how to transform existing ports (which were deprecated) to the new ports. Btw, we stated that the existing ports are deprecated but we did not remove them from the spec - this is cleaner for an RTF. I understand that in this case a change is made to an existing stereotype (this is actually worse from backward compatibility perspective), so even if the change is agreed, we need to consider how to deal with existing models in a standard way. I apologize for raising this so late, I would have liked to participate more in the group but unfortunately I am quite constrained these days. Thanks, Eldad From: "Wendland, Marc-Florian" To: , Date: 06/07/2012 04:40 PM Subject: UTP 1.2 Vote #1 Dear RTF voting members, Could you please vote on the resolutions to UTP 1.2 issues described in the attached report and already incorporated in the likewise attached convenience documents. Please do not pay attention to preface chapters or additional design stuff like headers and footers. Those things are going to be cleaned up and updated when the final version of the specification is about to be rendered. Changes are only applied to normative chapters and annexes starting from chapter 1. Deadline for this vote is set to the 20th of July! Please remain the subject of the mail as it is so that it can be organized automatically in mail clients. ----------------- Voting Form ----------------- (Mark each Issue with YES, NO or ABSTAIN based on resolutions proposed in attached document, or YES TO ALL as a shortcut) Issue #17292: Issue #16906: Issue #16878: Issue #15931: Issue #16900: Issue #17222: Issue #17231: Issue #16000: Issue #15941: As we had several roundtrips and remark requests of and for the resolutions relevant in this vote, I do not expect any further need for substantial discussions. Many thanks in advance, Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ [attachment "utp_1-2.pdf" deleted by Eldad Palachi/Haifa/IBM] [attachment "UTP_1.2_changebar.pdf" deleted by Eldad Palachi/Haifa/IBM] [attachment "UTP_1-2_RTF_report.doc" deleted by Eldad Palachi/Haifa/IBM] Date: Fri, 20 Jul 2012 14:10:03 +0000 From: "Hagar, Jon D" Subject: RE: UTP 1.2 Vote #1 on #15931 X-Originating-IP: [158.186.156.82] To: "Wendland, Marc-Florian" , "uml-testing-profile-rtf@omg.org" Thread-Topic: UTP 1.2 Vote #1 on #15931 Thread-Index: AQHNZoFbz080n43Y5UWzQwWFdObM5A== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-07-20_03:2012-07-19,2012-07-20,1970-01-01 signatures=0 Okay, the below helps a lot. I think I (we) basically agree and would vote yes on the final once everything is done, but for now I vote abstain on #15931 Jon D. Hagar Cell - 303-903-5536 Lockheed Martin From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Thursday, July 19, 2012 5:43 PM To: Hagar, Jon D; uml-testing-profile-rtf@omg.org Subject: EXTERNAL: AW: UTP 1.2 Vote #1 Jon et al, my answer to your question regarding issue #15931 >Issue #15931: - I believe we have closure on the changes for this, but don't think the files for this vote reflect that with Eldad's considerations (or did I miss something?). Can you resend the exact >changes we are agreeing on? Actually, the files I sent last weekend are the files that are important for the vote. Indeed, Eldad's concerns regarding backward compatibility are not part of this vote. If you follow the conversation between me and Eldad, we agreed on targeting the backward compatibility in the final vote for UTP 1.2 (kind of supplementary resolution on issue #15931, I'd say). This is due to the tight schedule we have for 1.2. Since Eldad accepted the current resolution, the changes to UTP 1.2 are logically accepted (have a standalone concept for test objective instead a dependency), but we have to technically re-work it to guarantee backward compatibility. As Eldad mentioned, SysML 1.3 was in a simmilar solution, when they decided to retreat from the FlowPort concepts. To guarantee backward compatibility, they moved the depracted concepts into a normative annex and declared them as deprecated but preserved for backward compatibility. At the same time, they conveyed the deprecated elements with transformation rules how to get to a non-deprecated 1.3-compliant model. Due to the fact that this has been accepted by the AB, we should go the same way for UTP 1.2. In my opinion, the best solution would be: 1. Instead of having TestObjective extending Class (make it standalone), we should name it TestObjectiveSpecification extending Class (or a similar name - I do not really care) - so, we would treat it as a newly incorporated stereotype 2. Move the 1.1 TestObjective (extending Dependency) into a new normative annex "Deprecated Elements", but preserve it for backward compatibility. Add some transformation rules how to get to non-deprecated UTP 1.2 models. By doing so, we are 100% backward compatibility to UTP 1.1, but keep the improved way of dealing with test objectives. The advantage of this approach is its simplicity. I'd say it does not matter whether the standalone concept is called TestObjective or TestObjectiveSpecification as long as its semantics remains the same as we agreed on in the first vote. So, in case you won't vote for that issue right now, I recommend using ABSTAIN for that issue and wait for the final vote. On the other hand, since even Eldad agreed on that change being necessary and sensible, the is actually nothing against YES. I'm going to compile some slides for the discussion on Tuesday. We have actually some resolutions for vote 2 to dicuss. Marc-Florian -----Ursprühe Nachricht----- Von: Hagar, Jon D [mailto:jon.d.hagar@lmco.com] Gesendet: Do 19.07.2012 19:54 An: Wendland, Marc-Florian; uml-testing-profile-rtf@omg.org Betreff: RE: UTP 1.2 Vote #1 See below ----------------- Voting Form ----------------- (Mark each Issue with YES, NO or ABSTAIN based on resolutions proposed in attached document, or YES TO ALL as a shortcut) Issue #17292: Yes Issue #16906: Yes Issue #16878: Yes Issue #15931: - I believe we have closure on the changes for this, but don't think the files for this vote reflect that with Eldad's considerations (or did I miss something?). Can you resend the exact changes we are agreeing on? Issue #16900: yes Issue #17222: yes Issue #17231: yes Issue #16000: yes Issue #15941: yes As we had several roundtrips and remark requests of and for the resolutions relevant in this vote, I do not expect any further n eed for substantial discussions. Many thanks in advance, Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ Subject: Issue#15931 targeting backward compatibility Date: Mon, 23 Jul 2012 11:03:23 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Issue#15931 targeting backward compatibility Thread-Index: Ac1osWm5d6OEblCtRcimbvFCZozh1w== From: "Wendland, Marc-Florian" To: X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml-testing-profile-rtf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate03-haj2 with 32E3612B4044 X-cloud-security: scantime:9.592 Dear members, please find attached as suggestion how we could tackle the backward compatibility problems introduced by the first resolution of issue #15931. Please double-check for the discussion tomorrow, so that we can agree on that solution rather quickly. Please review the suggested Constraints on <> (slide 11) carefully and provide feedback for the discussion tomorrow. Marc-Florian ######################################################## M.Sc. Marc-Florian Wendland Senior Researcher ------------------------------------------------------- Fraunhofer Institute for Open Communication Systems FOKUS MOTION . Modeling and Testing for System and Service Solutions Kaiserin-Augusta-Allee 31, 10589 Berlin, Germany Tel.: +49 (0)30 3463 7395 E-Mail: marc-florian.wendland@fokus.fraunhofer.de Web:http://www.fokus.fraunhofer.de/en/go/motion ------------------------------------------------------- Read our latest MOTION Newsletter. ####################################################### supplement_resolution_15931.ppt