Issue 15909: Stereotypes should be decorated with angle brackets «» (uml-testing-profile-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Clarification Severity: Minor Summary: Within the descriptional sections, the specification often refers to stereotype names, without showing the typical stereotype brackets («»). For example: "A data partition stereotyped classifier..." may be changed to "A «DataPartition» stereotyped classifier.." or "The notation for data partition is a classifier with stereotype data partition." may be changed to "The notation for data partition is a classifier with stereotype «DataPartition»." This should be consequently done along the descriptional sections to increase redeability and consistency, also regarding other UML profile specifications. Resolution: The sections need to be harmonized with each other. The contents of the stereotype sections vary from section to section. Sometimes stereotypes are written in upper-case letters (e.g. GetTimezoneAction), sometines in lower-case letters (e.g. default, default application, test component). The same counts for the notation sections of each stereotype. The resolution of this issue aims at aligning the stereotype's section with each other by using the following scheme: All UML metaclasses are written in camel-case style starting with upper-case letters (e.g. StructuredClassifier) All UTP concepts are written in lower-case letters (e.g. default application, get timezone action) in the description and semantics section. Whenever a dedidacted UTP concept is referenced, the stereotype style is used (e.g. see «ValidationAction» for further details). In case the concept does not represent a stereotype, the letter-case variant is used (e.g. No additional notation for arbiter defined). - UTP concepts in the examples sections are written in stereotype style («ValidationAction») since the examples section addresses the application of the technical concept, i.e. the stereotype. UTP concepts in the notation sections are written in stereotype style («ValidationAction») since the notation section addresses the visualization of the technical concept, i.e. the stereotype. When no additional notation is defined for the stereotype, the standardized paragraph “No additional notation for «StereotypeName» defined.” is used. In the constraint section, the stereotype style («TestContext») is used when the constraints required a particular stereotype to be applied on a UML metaclass (e.g. “a classifier with «TestContext» applied” instead of “a classifier with test context stereotype applied”). Revised Text: Add a new unnumbered subsection with title “Comments on Notations” to section 6.3 (notice, section already re-numbered to 7 by resolution of issue 15770) and with the following text: As a native UML profile, the UML Testing Profile inherits the predefined visualization capabilities of UML (see [UML] section 18 Profiles, in particular section 18.3.8 Stereotypes). For some concepts additional notations are defined, which are explicitly denoted and described in the Notation section of each UTP stereotype. In case where no additional notation is defined, the phrase “No additional notation for «StereotypeName» defined” is used. Update Text Replace the beginning of Description section of stereotype section SUT The SUT stereotype is applied to with «SUT» is applied to Update Text Replace Notation section of stereotype section SUT No additional notation for «SUT» defined. Update Text Replace the beginning of Examples section of stereotype section SUT Examples of SUTs can be found in with Examples of «SUT» can be found in Update Text Replace paragraph of Semantics section of stereotype section TestComponent The zone attribute is available at run-time, and GetTimezoneAction and SetTimezoneAction are used to get and set the timezone in run-time. with The zone attribute is available at run-time, and get timezone action and set timezone action are used to get and set the timezone in run-time. Update Text Replace Notation section of stereotype section TestComponent No additional notation for «TestComponent» defined. Update Text Replace the beginning of Examples section of stereotype section TestComponent Examples of test components can be found in with Examples of «TestComponent» can be found in Update Text Replace Notation section of stereotype section TestContext with: No additional notation for «TestContext» defined. Update Text Replace the beginning of Examples section of stereotype section TestContext Examples of test contexts can be found in with Examples of «TestContext» can be found in Update Text Replace Notation section of stereotype section Default with: No additional notation for «Default» defined. Update Text Replace the beginning of Examples section of stereotype section Default Examples of defaults can be found in with Examples of «Default» can be found in Update Text Change first paragraph of Notation section of stereotype section DefaultApplication from: The notation for a default is identical to a Comment (i.e., a rectangle with a bent corner). The text in the comment symbol has the following syntax: To The notation for a «DefaultApplication» is identical to a Comment (i.e., a rectangle with a bent corner). The text in the comment symbol has the following syntax: Update Text Replace the beginning of Examples section of stereotype section DefaultApplication Examples of DefaultApplication can be found in with Examples of «DefaultApplication» can be found in Update Text Replace the beginning of Examples section of stereotype section DetermAlt An example determAlt operator with An example of «DetermAlt» can be found in Update Text Change the Notation section of stereotype section FinishAction from: In Interaction diagrams, the FinishAction is shown as a black rectangle on the lifeline. In StateMachine diagrams, the FinishAction is shown as a flow branch ending in a black quadrat. In Activity diagrams, the FinishAction is shown as a black quadrat. To An example of «DetermAlt» can be found in In Interaction diagrams, the «FinishAction» is shown as a black rectangle on the lifeline. In StateMachine diagrams, the «FinishAction» is shown as a flow branch ending in a black quadrat. In Activity diagrams, the «FinishAction» is shown as a black quadrat. Update Text Replace the beginning of Examples section of stereotype section FinishAction An example of finish action… with An example of «FinishAction» … Update Text Change the Constraint section of stereotype section TestCase from: [2] A test case stereotype cannot be applied both to a behavior and its specification. [3] If a test case stereotype is applied to an operation, the featuring classifier must have test context stereotype applied. [4] If a test case stereotype is applied to a behavior, the context of the behavior must have the test context stereotype applied. To [2] «TestCase» cannot be applied both to a behavior and its specification. [3] If «TestCase» is applied to an operation, the featuring classifier must have «TestContext» applied. [4] If «TestCase» is applied to a behavior, the context of the behavior must have «TestContext» applied. Update Text Replace Notation section of stereotype section TestCase with: No additional notation for «TestCase» defined. Update Text Replace the beginning of Examples section of stereotype section TestCase Examples of test cases… with Example of «TestCase» … Update Text Change the Notation section of stereotype section TestLogApplication from: The notation for a test log is identical to a comment (i.e., a rectangle with a bent corner) with the keyword testlog. To The notation for a «TestLogApplication» is identical to a comment (i.e., a rectangle with a bent corner) with the keyword testlog. Update Text Change the Constraints section of stereotype section TestObjective from: [1] The client of a test objective must be a named element with a test case or test context stereotype applied To [1] The client of a test objective must be a named element with «TestCase» or «TestContext» applied Update Text Replace the beginning of Examples section of stereotype section TestObjective A test objective is shown… with A «TestObjective» … Update Text Change the Semantics section of stereotype section ValidationAction from: A ValidationAction calls the setVerdict operation on the arbiter of the test context. To A validation action calls the setVerdict operation on the arbiter of the test context. Update Text Change the Constraints section of stereotype section ValidationAction from: [4] Validation actions can only be used in test cases (i.e., a behavior where the test case stereotype is applied to the behavior or its specification). To [4] Validation actions can only be used in test cases (i.e., a behavior where «TestCase» is applied to the behavior or its specification). Update Text Replace the first paragraph of Notation section of stereotype section ValidationAction The notation for a validation action is an ordinary action with the validation action stereotype applied. with No additional notation for «ValidationAction» defined. Update Text Replace the beginning of Examples section of stereotype section ValidationAction from (notice, figure numbering was already changed to Figure 7.9 by the resolution of issue 15770) In Figure 6.9 two validation actions are shown. with In Figure 6.9 two examples of «ValidationAction» are shown. Update Text Change the second paragraph of introductory section Wildcards of section 6.3.3 (notice, section already re-numbered to 7.3 by resolution of issue 15770) from UML 2.0 provides LiteralNull, which is used by the UML Testing Profile for the representation of omitted values. Wildcards for any value (LiteralAny) and any value or omit (LiteralAnyOrNull) are extensions to UML 2.0. To UML 2.3 provides LiteralNull, which is used by the UML Testing Profile for the representation of omitted values. Wildcards for any value («LiteralAny») and any value or omit («LiteralAnyOrNull») are extensions to UML 2.3. Update Text Replace the beginning of Notation section of stereotype section CodingRule The notation for a coding rule is identical… with The notation for a «CodingRule» is identical... Update Text Replace the beginning of Examples section of stereotype section CodingRule A coding rule example… with A «CodingRule» example... Update Text Replace the beginning of Description section of stereotype section DataPool The data pool stereotype extends a classifier or property to specify a container for explicit values or data partitions that are used by test contexts or test cases. with A data pool specifies a container for explicit values or data partitions that are used by test contexts or test cases. Update Text Change Constraints section of stereotype section DataPool from: [1]A data pool stereotyped classifier can only be referenced by a test context or test component. [2]A data pool stereotyped property can only be applied to a property associated connected with a test component within the context of a «TestContext» stereotyped classifier. [3]A data pool stereotyped classifier cannot be associated with both a test context and a test component. To [1]A classifier with «DataPool» applied can only be referenced by a test context or test component. [2]A property with «DataPool» applied can only be applied to a property associated connected with a test component within the context of a classifier with «TestContext» applied. [3]A classifier with «DataPool» applied cannot be associated with both a test context and a test component. Update Text Replace Notation section of stereotype section DataPool with: No additional notation for «DataPool» defined. Update Text Replace the beginning of Examples section of stereotype section DataPool A data pool example is given in… with A «DataPool» example is given in… Update Text Replace the beginning of Description section of stereotype section DataPartition The data partition stereotype extends a classifier to specify a container for a set of values. with A data partition specifies a container for a set of values. Update Text Change Constraints section of stereotype section DataPartition from: A data partition stereotyped classifier can only be associated with a data pool or another data partition. To [1] A classifier with «DataPartition» applied can only be associated with a data pool or another data partition. Update Text Replace Notation section of stereotype section DataPartition with: No additional notation for «DataPartition» defined. Update Text Replace the beginning of Examples section of stereotype section DataPool A data pool example is given in… with A «DataPool» example is given in… Update Text Replace the beginning of Description section of stereotype section DataSelector The data selector stereotype extends an operation to allow the implementation of different data selection strategies with A data selector allows the implementation of different data selection strategies Update Text Change Constraints section of stereotype section DataSelector from: [1] If «DataSelector» is applied to an operation, the featuring classifier must have either «DataPool» or «DataPartition» applied. To [1] A classifier with «DataPartition» applied can only be associated with a data pool or another data partition. Update Text Replace Notation section of stereotype section DataSelector with: No additional notation for «DataSelector» defined. Update Text Replace the beginning of Examples section of stereotype section DataSelector A data selector example is given in… with A «DataSelector» example is given in… Update Text Change Description section of stereotype section LiteralAny from: LiteralAny is a wildcard specification representing any value out of a set of possible values To Literal any is a wildcard specification representing any value out of a set of possible values Update Text Change Semantics section of stereotype section LiteralAny from: If a LiteralAny is used as a literal specification, it denotes any possible value out of a set of possible values. If it is used (e.g., for the reception of a message in an interaction), it specifies that the specified message with any value at the place of the LiteralAny is to be received. If it is used (e.g., for the sending of a message in an interaction), it specifies that this message with a selected value at the place of the LiteralAny is to be sent. The selection of this value can be done along different selection schemes such as default values or random values. To If a literal any is used as a literal specification, it denotes any possible value out of a set of possible values. If it is used (e.g., for the reception of a message in an interaction), it specifies that the specified message with any value at the place of the literal any is to be received. If it is used (e.g., for the sending of a message in an interaction), it specifies that this message with a selected value at the place of the literal any is to be sent. The selection of this value can be done along different selection schemes such as default values or random values. Update Text Change Notation section of stereotype section LiteralAny from The notation for LiteralAny is the question mark character, ‘?’ To The notation for «LiteralAny» is the question mark character, ‘?’ Update Text Change Description section of stereotype section LiteralAnyOrNull from: LiteralAnyOrNull is a wildcard specification representing any value out of a set of possible values, or the lack of a value. To Literal any or null is a wildcard specification representing any value out of a set of possible values Update Text Change Semantics section of stereotype section LiteralAnyOrNull from: If a LiteralAnyOrNull is used as a literal specification, it denotes any possible value out of a set of possible values or the lack of the value. If it is used (e.g., for the reception of a message in an interaction), it specifies that the specified message with any value at the place of the LiteralAnyOrNull or without that value is to be received. If it is used (e.g., for the sending of a message in an interaction), it specifies that this message with a selected value or without a value at the place of the LiteralAnyOrNull is to be sent. The selection of this value or the selection of the absence can be done along different selection schemes such as default values or random values. To If a Literal any or null is used as a literal specification, it denotes any possible value out of a set of possible values or the lack of the value. If it is used (e.g., for the reception of a message in an interaction), it specifies that the specified message with any value at the place of the Literal any or null or without that value is to be received. If it is used (e.g., for the sending of a message in an interaction), it specifies that this message with a selected value or without a value at the place of the Literal any or null is to be sent. The selection of this value or the selection of the absence can be done along different selection schemes such as default values or random values. Update Text Change Notation section of stereotype section LiteralAnyOrNull from The notation for LiteralAnyOrNull is the star character, ‘*’ To The notation for «LiteralAnyOrNull» is the star character, ‘*’ Update Text Change Semantics section of stereotype section GetTimezoneAction from The GetTimezoneAction can be invoked at run-time by a test component to retrieve its current time zone. The result is a Timezone value. To The get timezone action» can be invoked at run-time by a test component to retrieve its current time zone. The result is a Timezone value. Update Text Replace Notation section of stereotype section GetTimezoneAction with: No additional notation for «GetTimezoneAction» defined. Update Text Change Semantics section of stereotype section SetTimezoneAction from The SetTimezoneAction can be invoked at run-time by a test component to set its current time zone. The value of a SetTimezoneAction refers to a Timezone value. To The set timezone action can be invoked at run-time by a test component to set its current time zone. The value of a set timezone action refers to a Timezone value. Update Text Replace Notation section of stereotype section SetTimezoneAction with: No additional notation for «SetTimezoneAction» defined. Update Text Change Semantics section of stereotype section ReadTimerAction from The ReadTimerAction reads the expiration time of a timer. The ReadTimerAction returns null for timers that are not running. To The read timer action reads the expiration time of a timer. The read timer action returns null for timers that are not running Update Text Replace Notation section of stereotype section ReadTimerAction with: No additional notation for «ReadTimerAction» defined. Update Text Change Semantics section of stereotype section StartTimerAction from The StartTimerAction starts a timer. The StartTimerAction on a running timer restarts the timer. To The start timer action starts a timer. The start timer action on a running timer restarts the timer. Update Text Change the first sentence of Notation section of stereotype section StartTimerAction from: The notation for a StartTimerAction is an empty hourglass To The notation for a «StartTimerAction» is an empty hourglass Update Text Replace the beginning of Examples section of stereotype section StartTimerAction: A start timer action example… with A «StartTimerAction» example… Update Text Change Semantics section of stereotype section StopTimerAction from The StopTimerAction stops a running timer. The StopTimerAction on a timer that is not running has no effect. To The stop timer action stops a running timer. The stop timer action on a timer that is not running has no effect. Update Text Change the first sentence of Notation section of stereotype section StopTimerAction from: The notation for a StopTimerAction is a cross To The notation for a «StopTimerAction» is a cross. Update Text Replace the beginning of Examples section of stereotype section StopTimerAction: A stop timer action example… with A «StopTimerAction» example… Update Text Change Semantics section of stereotype section TimeOut from A TimeOut is generated by a timer when it expires and may trigger an associated behavior. The TimeOut is placed in the input pool of the object owning the timer. To A timeout is generated by a timer when it expires and may trigger an associated behavior. The timeout event is placed in the input pool of the object owning the timer. Update Text Change Semantics section of stereotype section TimeOutMessage from A TimeOutMessage is generated by a timer when it expires. The timeout message is sent to the active class that owns the timer. To A timeout message is generated by a timer when it expires. The timeout message is sent to the active class that owns the timer. Update Text Change the first sentence of Notation section of stereotype section TimeOutMessage from: The notation for the TimeOutMessage is an empty hourglass. To The notation for the «TimeOutMessage» is an empty hourglass. Update Text Change the beginning of the Examples section of stereotype section TimeOutMessage from: A TimeOutMessage example can be found To A «TimeOutMessage» example can be found Update Text Change Semantics section of stereotype section TimeOutAction from A timeout is enabled when the timer expires. It may trigger an associated activity. The TimeOutAction occurs, when all input conditions for that activity are satisfied (including the TimeOutAction). To A timeout is enabled when the timer expires. It may trigger an associated activity. The timeout action occurs, when all input conditions for that activity are satisfied (including the timeout action). Update Text Change the beginning of the Notation section of stereotype section TimeOutAction from: The notation for the TimeOutAction is an empty hourglass… To The notation for the «TimeOutAction» is an empty hourglass… Update Text Change the last sentence of the Notation section of interface section Timer from: For details, look in the sections for StartTimerAction, StopTimerAction, and ReadTimerAction. To For details, look in the sections for «StartTimerAction», «StopTimerAction», and «ReadTimerAction». Update Text Change Semantics section of stereotype section TimerRunningAction from The TimerRunningAction checks the running status of a timer. Returns a boolean value, true if the timer is running, false otherwise. To The timer running action checks the running status of a timer. Returns a boolean value, true if the timer is running, false otherwise. Update Text Change the first sentence of Notation section of stereotype section TimerRunningAction from: The notation for a timer running action is an ordinary action with the timer running action stereotype applied. To No additional notation for «TimerRunningAction» defined. Actions taken: January 4, 2011: received issue October 21, 2011: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 04 Jan 2011 04:28:59 -0500 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: several FormalNumber: formal/05-07-07 Version: 1.0 Doc_Year: 2005 Doc_Month: July Doc_Day: 07 Page: several Title: Stereotypes should be decorated with angle brackets «» Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Description: Within the descriptional sections, the specification often refers to stereotype names, without showing the typical stereotype brackets («»). For example: "A data partition stereotyped classifier..." may be changed to "A «DataPartition» stereotyped classifier.." or "The notation for data partition is a classifier with stereotype data partition." may be changed to "The notation for data partition is a classifier with stereotype «DataPartition»." This should be consequently done along the descriptional sections to increase redeability and consistency, also regarding other UML profile specifications.