Issue 16906: Base class of TestComponents must be instances of BehavioredClassifier, too (uml-testing-profile-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Revision Severity: Significant Summary: Since TestComponents can define test-relevant behavior, it must be ensured by definition that each base class of a TestComponent is also a BehavioredClassifier. Behaviors for test cases can be expressed as operations in the test component, for example. To make this formally and by definition possible (and if we do not change the base class of TestComponent to Property - see previously submitted issue by me), we should also extend BehavioredClassifier and make clear that a base class, to which <<TestComponent>> is applied must be both a StructuredClassifier and BehavioredClassifier. Resolution: RTF agreed on narrowing the possible metaclasses the stereotype <<TestComponent>> down to uml::Class. Furthermore, uml::Behavior and uml::AssociationClass is excluded from the list of extendable metaclasses by a constraint, because they just do not make sense to be treated as a test component. This results in three concrete metaclasses where <<TestComponent>> can be applied to, which are: Class, Component and Node. Revised Text: Replace Figure 7.1 Test Architecture with Update Text Alter text of subsection ‘Description’ of section 7.2.2.3 from A test component is commonly an active class with a set of ports and interfaces. Test components are used to specify test cases as interactions between a number of test components. To Test components are part of the test environment and are used to communication with the system under test (SUT) and other test components. The main function of test components is to drive a test case by stimulating the system under test through its provided interfaces and to evaluate whether the actual responses of the system under test comply with the expected ones. Update Text Alter subsection ‘Extension’ of section 7.2.2.3 from • StructuredClassifier (from UML::CompositeStructures::InternalStructures) To • Class (from UML::Kernel) Replace Text Replace current test of subsection ‘Semantics’ of section 7.2.2.3 to A test component is commonly an active class that provides or requires interfaces in order to communicate with the system under test (SUT) or other test components. Test components usually establish connectors between their dedicated (i.e. owned) ports and ports of other participants in a test case, e.g. either the system under test or other test components. Connectors are used as communication channels over which exchange of test data is actually carried out. Test components participate in test cases mainly for stimulating the system under test (SUT) with test data and for evaluating whether the responses of the system under test adhere with the expected ones afterwards. In addition, test components can be used to provide auxiliary, user-defined functionality during the execution of a test case. «TestComponent» can either be applied to a Class, a Component or a Node. A test component as a Class or Component represents a part of the architectural design of the test environment. A test component as a Node is normally used as part of a deployment specification of the test environment. In case the test system is distributed over different timezones (e.g. a test system that is deployed in the cloud) the involved test components may need to be kept in synch with regard to their actual timezones. This can be achieved by using the optional zone attribute, if required. The corresponding timezone actions (see SetTimezoneAction and GetTimezoneAction) are intended to set and retrieve the timezone of a test component. Update Text Alter subsection ‘Constraints’ of section 7.2.2.3 from None. To [1] «TestComponent» can only be applied to a Class or the following subclasses of Class: Component and Node. context TestComponent inv: self.base_Class.oclIsKindOf(Class) or self.base_Class.oclIsKindOf(Component) or self.base_Class.oclIsKindOf(Node) Actions taken: December 14, 2011: received issue January 7, 2013: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 14 Dec 2011 14:41:53 -0500 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.1.2.3 FormalNumber: ptc/2011-07-19 Version: 1.1 - beta 2 Doc_Year: 2011 Doc_Month: July Doc_Day: 19 Page: 11 Title: Base class of TestComponents must be instances of BehavioredClassifier, too Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Since TestComponents can define test-relevant behavior, it must be ensured by definition that each base class of a TestComponent is also a BehavioredClassifier. Behaviors for test cases can be expressed as operations in the test component, for example. To make this formally and by definition possible (and if we do not change the base class of TestComponent to Property - see previously submitted issue by me), we should also extend BehavioredClassifier and make clear that a base class, to which <> is applied must be both a StructuredClassifier and BehavioredClassifier.