Issue 15651: Who is the receiver of a LogAction? (uml-testing-profile-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Clarification Severity: Minor Summary: Rational: Section 6.3.2 Test Behavior, Subsection LogAction says the following: --- The LogAction defines the tester‘s desire to log certain aspects during the execution of a test case. --- Issue: Since «LogAction» stereotype enhances UML::SendObjectAction, the receiver of the object to be logged must be explicitly mentioned. It is not clear who receives the sent object. Commonly, a log is sent to the execution environment which accepts and persists the entry. This seems to be a tool concepts, too, comparable to Scheduler semantics. It might make sense to introduce another additional technical interface for logging at test execution system level. «LogAction» might extend uml::OpaqueAction, so that there is no explicit receiver to be specified on model level. Vendors must ensure that logs are transported properly to the log interface. Resolution: Actually, the issue does not target a technical error in the specification, since the multiplicity of the target pin of SendObjectAction is not defined and left open. Therefore, it is possible to neglect the receiver or to add one if needed. However, subsection semantics and constraints are stated more precisely Revised Text: Replace subsection Semantics of section LogAction The target of a log action refers to a logging mechanism in the run-time system. The request refers to the information that is logged. The representation of the logging mechanism is not specified. The LogAction records some snapshot of the test component With The target of a log action either refers implicitly to a logging facility in the run-time system, or explicitly to an element within the model acting as the receiver of the information to be logged. In the first case, the logging can be seen as a declaration of what should be logged rather than saying how or where the information is finally stored. The request input pin of the underlying SendObjectAction determines what information shall be logged. The type of the request input pin is not determined and may represent simple strings, instance values, or any other information values of interest. A log action must submit either one single information value or a set of information (at least one), which are supposed to be logged all at once. This is a shortcut for invoking the log action multiple times in a row. The receiver of the log action is optional. Per default, omitting the receiver object means the execution environment is responsible to log the values transferred by the log action. Update Text Add new constraints to subsection Constraints of section LogAction (notice, Constraint section was introduced by resolution of issue 15770): [1] The multiplicity of the target input pin of a «LogAction» is set to 0..1. [2] The multiplicity of the request input pin of a «LogAction»is set to 1..*. [3] There must be no further argument input pins attached to a «LogAction». Disposition: Resolved Actions taken: September 27, 2010: received issue October 21, 2011: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 27 Sep 2010 18:04:03 -0400 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 Porifle Section: 6.3.2 FormalNumber: formal/05-07-07 Version: 1.0 Doc_Year: 2005 Doc_Month: July Doc_Day: 07 Page: 21 Title: Who is the receiver of a LogAction? Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Description: Rational: Section 6.3.2 Test Behavior, Subsection LogAction says the following: --- The LogAction defines the tester.s desire to log certain aspects during the execution of a test case. --- Issue: Since «LogAction» stereotype enhances UML::SendObjectAction, the receiver of the object to be logged must be explicitly mentioned. It is not clear who receives the sent object. Commonly, a log is sent to the execution environment which accepts and persists the entry. This seems to be a tool concepts, too, comparable to Scheduler semantics. It might make sense to introduce another additional technical interface for logging at test execution system level. «LogAction» might extend uml::OpaqueAction, so that there is no explicit receiver to be specified on model level. Vendors must ensure that logs are transported properly to the log interface.