Issue 17224: UTP should constitute a new conceptual package structure (uml-testing-profile-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Revision Severity: Minor Summary: Currently, UTP consists of four conceptual (not technical) packages: test architecture, test behavior, test data and timer concepts. The concepts which are described within those packages (which are represented as different subsections in the normative section of the specification) can be further separated. For example, timing (all concepts of timer concepts package) is mainly associated with test behavior. A timer can only be started if a behavior is executed. It might be more consistent to move the concepts from timer concepts into test behavoir as well, since it is clearly dedicated to test behavior. Another example are some concepts which clearly belong to the test management area like TestObjective and/or TestLog. Those test management concepts are part of UTP since its adoption by OMG, so it would just be consequent to establish a new package exclusively for test management concepts. A more consistent conceptual package structure could look like this: 1. Test Architecture 2. Test Behavior 2.1 Test Case and Defaults 2.2 Test Actions 2.3 Test Timer 3 Test Data 3.1 Wildcards 3.2 Test Data Structure 4. Test Management Resolution: The RTF agreed that having a modernized and polished specification document is highly beneficial. Therefore, a new outline and new introductory chapters have been written. Except from changes in the outline and introductory sections, this resolution does not change the semantics of a stereotype. NOTE: For the sake of clarity, this resolution is split into two parts. The first part incorporates only changes from section 1 (Scope) to 6 (Additional Information). These changes are marked with the issue tag (Issue 17224 (part one)) and are incorporated into the intermediate convenience document with change bars. The second part incorporates changes from newly created section 7 until the end of the document. These changes are marked with the issue tag (Issue 17224 (part two)) and are incorporated into the final convenience document with change bars. The second part is responsible for several new sections, section and figure renumbering. The issue marker in the change-bared convenience document provide information whether this section has been newly incorporated or changed. This ensures a direct traceability from the old document structure to the new one. Revised Text: Actions taken: March 12, 2012: received issue January 7, 2013: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org To: Subject: Issue/Bug Report ******************************************************************************* Name: Marc-Florian Wendland Employer: Fraunhofer FOKUS mailFrom: marc-florian.wendland@fokus.fraunhofer.de Terms_Agreement: I agree Specification: UML Testing Profile Section: 7 FormalNumber: ptc/2011-07-19 Version: 1.1 Doc_Year: 2011 Doc_Month: July Doc_Day: 19 Page: 9-39 Title: UTP should constitute a new conceptual package structure Nature: Revision Severity: Minor CODE: 3TMw8 B1: Report Issue Description: Currently, UTP consists of four conceptual (not technical) packages: test architecture, test behavior, test data and timer concepts. The concepts which are described within those packages (which are represented as different subsections in the normative section of the specification) can be further separated. For example, timing (all concepts of timer concepts package) is mainly associated with test behavior. A timer can only be started if a behavior is executed. It might be more consistent to move the concepts from timer concepts into test behavoir as well, since it is clearly dedicated to test behavior. Another example are some concepts which clearly belong to the test management area like TestObjective and/or TestLog. Those test management concepts are part of UTP since its adoption by OMG, so it would just be consequent to establish a new package exclusively for test management concepts. A more consistent conceptual package structure could look like this: 1. Test Architecture 2. Test Behavior 2.1 Test Case and Defaults 2.2 Test Actions 2.3 Test Timer 3 Test Data 3.1 Wildcards 3.2 Test Data Structure 4. Test Management Subject: Request for Comments: 17224 Date: Wed, 28 Mar 2012 19:55:09 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for Comments: 17224 Thread-Index: Ac0MnBohjz0u/+3BRL6W5gSSSKlxGg== Priority: Urgent 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 8458112B400D X-cloud-security: scantime:.1796 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q2SI2alA019596 Issue 17224: In the course of the constitution of a new conceptual test management package, I was wondering whether the entire structure could be further improved - Test Architectur remains unchained - Test Behavior will be further refined - Subsection Foundation/Test Case: TestCase - Subsection TestActions: All test-related actions (like ValidationAction, LogAction, etc. ) - Subsection TimerConcepts: Move timing concepts into test behavior, because timing concepts are only relevant in the context of test behavior. From my perspective, this would definitely make perfectly sense! - Subsection Defaults: Default, DefaultApplication - Test Data will be further refined - Subsection Values: LiteralAny, LiteralAnyOrNull, CodingRule - Subsection Test Item/Data Specification: DataParitition, DataPool, DataSelector (Data Item, Set Expression, ...) - Test Management: Test Objective, TestLog, TestLogApplication, ... Date: Thu, 29 Mar 2012 17:19:56 +0000 From: "Hagar, Jon D" Subject: RE: Request for Comments: 17224 X-Originating-IP: [158.186.156.84] To: "Wendland, Marc-Florian" , "uml-testing-profile-rtf@omg.org" Thread-Topic: Request for Comments: 17224 Thread-Index: Ac0MnBohjz0u/+3BRL6W5gSSSKlxGgBM6CPg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-03-29_06:2012-03-28,2012-03-29,1970-01-01 signatures=0 This makes sense to me. Further suggestions: 1. under test management, I think it might be nice to add "risk", but do it as a pointer to the appendix where we actually demonstrate how t "model" risk in testing. 2. subsection testcase may need discussion. People in the US still trip over this. Jon D. Hagar Cell - 303-903-5536 Lockheed Martin -----Original Message----- From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Wednesday, March 28, 2012 1:55 PM To: uml-testing-profile-rtf@omg.org Subject: EXTERNAL: Request for Comments: 17224 Importance: High Issue 17224: In the course of the constitution of a new conceptual test management package, I was wondering whether the entire structure could be further improved - Test Architectur remains unchained - Test Behavior will be further refined - Subsection Foundation/Test Case: TestCase - Subsection TestActions: All test-related actions (like ValidationAction, LogAction, etc. ) - Subsection TimerConcepts: Move timing concepts into test behavior, because timing concepts are only relevant in the context of test behavior. From my perspective, this would definitely make perfectly sense! - Subsection Defaults: Default, DefaultApplication - Test Data will be further refined - Subsection Values: LiteralAny, LiteralAnyOrNull, CodingRule - Subsection Test Item/Data Specification: DataParitition, DataPool, DataSelector (Data Item, Set Expression, ...) - Test Management: Test Objective, TestLog, TestLogApplication, ... Subject: AW: Request for Comments: 17224 Date: Fri, 30 Mar 2012 09:29:28 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for Comments: 17224 Thread-Index: Ac0MnBohjz0u/+3BRL6W5gSSSKlxGgBM6CPgAB2SfHA= From: "Wendland, Marc-Florian" To: "Hagar, Jon D" , 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-gate04-haj2 with 0967B794017 X-cloud-security: scantime:1.439 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q2U7Ts5W024735 Jon, Thanks for your comments. > 1. under test management, I think it might be nice to add "risk", but do it as a > pointer to the appendix where we actually demonstrate how t "model" risk > in testing. Yeah, may be. But if we include risk with an explanation that dedicated UTP risk concepts are not provided, but rather reused as indicated by the referenced examples, we might consider further test management subtasks?! > 2. subsection testcase may need discussion. I do not mean naming the subsection simply 'Test Behavior Foundation' with just the single concept Test Case in it. Well, the longer I reflect on this the more I get convinced that this name is more appropriate than naming the subsection 'TestCase' > People in the US still trip over this. You mean the test case stereotype as it is right now (i.e. based on an operation a Behavior) 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 ################################################ > -----Ursprühe Nachricht----- > Von: Hagar, Jon D [mailto:jon.d.hagar@lmco.com] > Gesendet: Donnerstag, 29. Mä 2012 19:20 > An: Wendland, Marc-Florian; uml-testing-profile-rtf@omg.org > Betreff: RE: Request for Comments: 17224 > > This makes sense to me. Further suggestions: > > 1. under test management, I think it might be nice to add "risk", but do it as a > pointer to the appendix where we actually demonstrate how t "model" risk > in testing. > 2. subsection testcase may need discussion. People in the US still trip over > this. > > Jon D. Hagar > Cell - 303-903-5536 > Lockheed Martin > > -----Original Message----- > From: Wendland, Marc-Florian [mailto:marc- > florian.wendland@fokus.fraunhofer.de] > Sent: Wednesday, March 28, 2012 1:55 PM > To: uml-testing-profile-rtf@omg.org > Subject: EXTERNAL: Request for Comments: 17224 > Importance: High > > Issue 17224: In the course of the constitution of a new conceptual test > management package, I was wondering whether the entire structure could > be further improved > - Test Architectur remains unchained > - Test Behavior will be further refined > - Subsection Foundation/Test Case: TestCase > - Subsection TestActions: All test-related actions (like > ValidationAction, LogAction, etc. ) > - Subsection TimerConcepts: Move timing concepts into test > behavior, because timing concepts are only relevant in the context of test > behavior. From my perspective, this would definitely make perfectly sense! > - Subsection Defaults: Default, DefaultApplication > - Test Data will be further refined > - Subsection Values: LiteralAny, LiteralAnyOrNull, CodingRule > - Subsection Test Item/Data Specification: > DataParitition, DataPool, DataSelector (Data Item, Set Expression, ...) > - Test Management: Test Objective, TestLog, TestLogApplication, ... Date: Mon, 23 Apr 2012 18:16:21 +0000 From: "Hagar, Jon D" Subject: RE: Request for Comments: 17224 X-Originating-IP: [158.186.156.93] To: "Wendland, Marc-Florian" , "uml-testing-profile-rtf@omg.org" Thread-Topic: Request for Comments: 17224 Thread-Index: Ac0MnBohjz0u/+3BRL6W5gSSSKlxGgBM6CPgAB2SfHAEzbkWEA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580,1.0.260,0.0.0000 definitions=2012-04-23_06:2012-04-23,2012-04-23,1970-01-01 signatures=0 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q3NIGquC004336 > 1. under test management, I think it might be nice to add "risk", but > do it as a pointer to the appendix where we actually demonstrate how t > "model" risk in testing. Yeah, may be. But if we include risk with an explanation that dedicated UTP risk concepts are not provided, but rather reused as indicated by the referenced examples, we might consider further test management subtasks?! JH: possibly, but for the moment, risk is the important one we see. > 2. subsection testcase may need discussion. I do not mean naming the subsection simply 'Test Behavior Foundation' with just the single concept Test Case in it. Well, the longer I reflect on this the more I get convinced that this name is more appropriate than naming the subsection 'TestCase' JH: I think I agree. > People in the US still trip over this. You mean the test case stereotype as it is right now (i.e. based on an operation a Behavior) JH: Yes 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 ################################################ > -----Ursprühe Nachricht----- > Von: Hagar, Jon D [mailto:jon.d.hagar@lmco.com] > Gesendet: Donnerstag, 29. Mä 2012 19:20 > An: Wendland, Marc-Florian; uml-testing-profile-rtf@omg.org > Betreff: RE: Request for Comments: 17224 > > This makes sense to me. Further suggestions: > > 1. under test management, I think it might be nice to add "risk", but > do it as a pointer to the appendix where we actually demonstrate how t > "model" risk in testing. > 2. subsection testcase may need discussion. People in the US still > trip over this. > > Jon D. Hagar > Cell - 303-903-5536 > Lockheed Martin > > -----Original Message----- > From: Wendland, Marc-Florian [mailto:marc- > florian.wendland@fokus.fraunhofer.de] > Sent: Wednesday, March 28, 2012 1:55 PM > To: uml-testing-profile-rtf@omg.org > Subject: EXTERNAL: Request for Comments: 17224 > Importance: High > > Issue 17224: In the course of the constitution of a new conceptual > test management package, I was wondering whether the entire structure > could be further improved > - Test Architectur remains unchained > - Test Behavior will be further refined > - Subsection Foundation/Test Case: TestCase > - Subsection TestActions: All test-related actions > (like ValidationAction, LogAction, etc. ) > - Subsection TimerConcepts: Move timing concepts into > test behavior, because timing concepts are only relevant in the > context of test behavior. From my perspective, this would definitely make perfectly sense! > - Subsection Defaults: Default, DefaultApplication > - Test Data will be further refined > - Subsection Values: LiteralAny, LiteralAnyOrNull, CodingRule > - Subsection Test Item/Data Specification: > DataParitition, DataPool, DataSelector (Data Item, Set Expression, ...) > - Test Management: Test Objective, TestLog, TestLogApplication, ... X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:none;EFVD:NLI X-SpamScore: -14 X-BigFish: VS-14(z21cRzc85fh62a3Izz1202hzz8275bh8275dh5eeeKz2fh2a8h668h839hd25hf0ah107ah) From: Steve Cook To: "Wendland, Marc-Florian" CC: "Andrew Watson (andrew@omg.org)" , "ab@omg.org" Subject: RE: Re-formulate of issue 17224 Thread-Topic: Re-formulate of issue 17224 Thread-Index: Ac2BHk/irtb1LSOFTL+oR3WxDE6sKgAC+J8Q Date: Thu, 23 Aug 2012 12:29:40 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.104] X-OriginatorOrg: microsoft.com Marc-Florian I believe that would work. What is mandatory is traceability between the resolutions and the document. Having two convenience documents is not strictly in conformance with the P&P .The Report must be accompanied by a complete revised specification which includes change-marks indicating where issue resolutions were applied. but in my view it is in in the spirit of the P&P. I.m copying Andrew and rest of the AB for advice. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 23 August 2012 12:07 To: Steve Cook Subject: Re-formulate of issue 17224 Hi Steve, I.m on and about to re-formulate resolution for issue 17224, and I encountered a major problem: I reckon you walk issue by issue through the report and check all changes in the report with the attached changebarred convenience document. Thus, in case for issue 17292 (Rename Timer to Timepoint) you would search for Figure 7.11 and/or section 7.5.2.7 in the changebarred document, and not in the 1.1 document, where the resolution is actually based on. This is due to 17224! However, 17224 is the very last resolution, so I would have to introduce forward references regarding the changed numbers I guess the only way to find a way out of that dilemma is to provide two changebarred convenience documents. One intermediate document for the changes to the content (before 17224) and a second final document for mapping the old outline to the new outline (after 17224). In addition, the report for issue 17224 will contain a precise mapping with respect to old numbers (sections and figures) and new numbers. Otherwise, I do not think I can handle this problem. Do you think providing two changebarred conveniences document would be helpful for you and other other reviewers? 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. ####################################################### Authentication-Results: cm-omr11 smtp.user=tom@coastenterprises.com; auth=pass (LOGIN) X-Authenticated-UID: tom@coastenterprises.com Date: Thu, 23 Aug 2012 10:38:06 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 To: Steve Cook CC: "Wendland, Marc-Florian" , "Andrew Watson (andrew@omg.org)" , "ab@omg.org" Subject: Re: Re-formulate of issue 17224 On 8/23/2012 8:29 AM, Steve Cook wrote: Marc-Florian I believe that would work. What is mandatory is traceability between the resolutions and the document. Having two convenience documents is not strictly in conformance with the P&P .The Report must be accompanied by a complete revised specification which includes change-marks indicating where issue resolutions were applied. but in my view it is in in the spirit of the P&P. I.m copying Andrew and rest of the AB for advice. I see no problem with a two phase changebar presentation in this case. The reason for the changebar document is to insure that the changes in the report resolutions are fully reflected in the final document. Your proposal meets that goal perfectly. Tom Rutt -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 23 August 2012 12:07 To: Steve Cook Subject: Re-formulate of issue 17224 Hi Steve, I.m on and about to re-formulate resolution for issue 17224, and I encountered a major problem: I reckon you walk issue by issue through the report and check all changes in the report with the attached changebarred convenience document. Thus, in case for issue 17292 (Rename Timer to Timepoint) you would search for Figure 7.11 and/or section 7.5.2.7 in the changebarred document, and not in the 1.1 document, where the resolution is actually based on. This is due to 17224! However, 17224 is the very last resolution, so I would have to introduce forward references regarding the changed numbers I guess the only way to find a way out of that dilemma is to provide two changebarred convenience documents. One intermediate document for the changes to the content (before 17224) and a second final document for mapping the old outline to the new outline (after 17224). In addition, the report for issue 17224 will contain a precise mapping with respect to old numbers (sections and figures) and new numbers. Otherwise, I do not think I can handle this problem. Do you think providing two changebarred conveniences document would be helpful for you and other other reviewers? 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. ####################################################### -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133