Issue 16163: Rework of TestArchitecture section (uml-testing-profile-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Revision Severity: Significant Summary: A master issue for the rework of test architecture package. Several issues will be merged into this issue to improve readability and understandability of the resolutions Resolution: Incorporate the issues 15644, 15648 and 15910. The first two issues targets the fact the Scheduler is never part of the test model by definition. Therefore, it represents a pure tooling concept which has nothing in common with a domain-specific profile. The resolution for this is to remove the Scheduler from the profile section and to put it into the annex. The last issue deals with a semantically necessary precision of a TestContext. Currently, a TestContext is only required to be an instance of uml::StructuredClassifier. Since a TestContext must have the ability to contain operations and classifier behavior, the UTP has to ensure that each instance of a TestContext is both a StructuredClassifier and BehavioredClassifier (e.g. Class, Component…). Revised Text: Remove Section Remove subsection Scheduler from the stereotype description section 6.3.1 (notice, section 6.3.1 already renumbered to section 7.1 by resolution of issue 15770) Rename Section Rename Annex C Arbiter and Scheduler Protocols to Scheduling (notice Annex C has been altered to Annex D due to resolution of issue 15770) Add Section Add new numbered subsection Interface Definition to the Annex C (notice Annex C has been altered to Annex D due to resolution of issue 15770) and add new section Scheduler into this subsection Scheduler Description Scheduler is a predefined interface defining operations used for controlling the tests and the test components. None of the operations of the Scheduler are available to the UML specifier. Generalizations None. Attributes None. Operations • Scheduler() The constructor of Scheduler. It will start the SUT and the Arbiter. • startTestCase() The scheduler will start the test case by notifying all involved test • components. • finishTestCase(t:TestComponent Records that the test component t has finished its execution of this test case. When all test components involved in the current test case have finished, the arbiter will be notified. createTestComponent(t:TestComponent) Records that the test component t has been created by some other test component. Semantics The implementation of the predefined interface will determine the detailed semantics. The implementation must make sure that the scheduler has enough information to keep track of the existence and participation of the test components in every test case. The test context itself will ensure the creation of a scheduler. Constraints None. Notation No additional notation for Scheduler is defined. Examples Example protocols for how the scheduler could work is found in Annex C. Add Section Add new numbered subsection Scheduler and Arbiter Protocol to the Annex C (notice that Annex C was already renumbered to Annex D due to resolution of issue 15770) that contains the old content of the Annex C Update Text Change the first paragraph of the newly created Scheduler and Arbiter Protocol section from This annex shows how the Scheduler and the Arbiter should work together with the test components and the SUT such that the execution of the test cases are performed properly and the verdict delivered at the right time. It is not necessary that a valid implementation conforms in detail to these sequence diagrams, but the net effect should be the same. To This section shows how the Scheduler and the Arbiter should work together with the test components and the SUT such that the execution of the test cases are performed properly and the verdict delivered at the right time. It is not necessary that a valid implementation conforms in detail to these sequence diagrams, but the net effect should be the same. Remove Attribute Remove the scheduler:Scheduler property in from stereotype TestContext Update Text Remove the entry and definition of Scheduler from tables 6.1 and 6.2 (notice, table numbering has already been changed to A.1 and A.2 due to resolution of issue 15770) Update Text Update description section of stereotype section TestContext from A StructuredClassifier acting as a grouping mechanism for a set of test cases. The composite structure of a test context is referred to as test configuration. The classifier behavior of a test context is used for test control. To A test context acts as a grouping mechanism for a set of test cases. The composite structure of a test context is referred to as test configuration. The classifier behavior of a test context may be used for test control. Add Extension Add new metaclass in extension section (introduced by resolution of issue 15770) of TestContext BehavioredClassifier (from UML::CommonBehaviors::BasicBehaviors, Communications) Update Text Add content to the empty semantics section (introduced by resolution of issue 15770) of stereotype TestContext A test context is a both a StructuredClassifier and BehavioredClassifier providing the foundation for a test configuration, a collection of test cases (operating on those test cases) and an optional test control, scheduling the execution order of its test cases. The test configuration is a collection of test component objects and of connections between the test component objects and to the SUT. It test configuration defines both (1) test component objects and connections when a test case is started (the initial test configuration) and (2) the maximal number of test component objects and connections during the test execution. It is established by using the composite structure concepts for StructuredClassifiers. Test cases are either realized as operations or as owned behavior (both stereotyped with «TestCase») of a test context. If required, test control can be added to a test context by defining a classifier behavior for the test context, describing the order and under what conditions test cases are supposed to be executed. Remove Constraints Remove both constraints from the constraint section of stereotype TestContext. Constraint 1 is given by the fact that the tagged value arbiter has a multiplicity of 1. Same counts for Constraint 2, additionally, the Scheduler was never part of the model as described by the resolution. Add Constraint Add a new constrain in the constraint section of stereotype TestContext, that a TestContext can only be applied to a classifier being both an instance of StructuredClassifier and BehavioredClassifier [1] The classifier with «TestContext» applied must be both an instance of StructuredClassifier and BehavioredClassifier. Replace Figure Replace Figure 6.1 (renumbered to Figure 7.1 by resolution of issue15770) with Disposition: Resolved Actions taken: May 4, 2011: received issue October 21, 2011: closed issue Discussion: see figure on page 75 of ptc/2011-07-18 End of Annotations:===== m: webmaster@omg.org Date: 02 May 2011 07:15:22 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Marc-Florian Wendland Employer: Fraunhofer FOKUS mailFrom: marc-florian.wendland@fokus.fraunhofer.de Terms_Agreement: Specification: UML Testing Profile Section: 6.3.1 FormalNumber: formal/05-07-07 Version: 1.0 Doc_Year: 2005 Doc_Month: July Doc_Day: 07 Page: several Title: Rework of TestArchitecture section Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Description: A master issue for the rework of test architecture package. Several issues will be merged into this issue to improve readability and understandability of the resolutions.