Issue 6955: Data guards on observations
Issue 6956: Grey box testing
Issue 15726: OCL expressions should be used for precise description of constraints
Issue 15914: Test scheduling should be supported explecitely
Issue 15927: Test Cases as an Operation
Issue 15928: Verify Relationship not in UTP
Issue 15931: Test Objective issue
Issue 15933: term data value issue
Issue 15934: Test Context
Issue 15935: Test Case Types & Instances
Issue 15936: Anatomy of a Test Case
Issue 15937: Visual & Standalone Test Cases
Issue 15938: Associations among Test Cases
Issue 15939: UTP & SysML
Issue 15940: Test Maps
Issue 15941: Complex Data
Issue 15943: Default
Issue 15944: getDistributionInterval
Issue 15998: Alter predefined interfaces to stereotypes with constraints
Issue 15999: Align test-related actions for Interactions with UML 2.4
Issue 16000: TestRequirements shall be defined
Issue 16346: UTP profile
Issue 16568: Invalid Figure B.14
Issue 16878: Integration of TTCN-3 template modification
Issue 16898: Tag definitions of test management concepts should be of type ValueSpecification
Issue 16899: Attribute CodingRule::coding should be typed by ValueSpecification
Issue 16900: Correction for issue #15652
Issue 16901: TestComponent stereotype should extend Property
Issue 16902: TestLog should have detailed information as TestLogEntry
Issue 16905: Constraints on superclasses needs to be overwritable for test data specifications
Issue 16906: Base class of TestComponents must be instances of BehavioredClassifier, too
Issue 17222: LogAction should be FinishAction
Issue 17223: Modernization of introductory chapters
Issue 17224: UTP should constitute a new conceptual package structure
Issue 17228: Verdict should be renamed to VerdictKind
Issue 17229: Typos, style glitches and figures
Issue 17230: Figure B.28 - Transaction detail - is erroneous
Issue 17231: ValidationAction should extends CallOperationAction
Issue 17292: Rename predefined type Time to Timepoint
Issue 6955: Data guards on observations (uml-testing-profile-rtf)
Click here for this issue's archive.
Source: Motorola (Mr. Paul Baker, Paul.Baker(at)motorola.com)
Nature: Uncategorized Issue
Severity:
Summary:
For each operand the guard has to be on each leading event within an alternative
Deferred due to time restrictions.
Monitoring of interfaces between components within the SUT.
Since UTP 1.1 rather addresses technical and conceptual issues, the elaboration of such a new concept is deferred to one of the next revisions.
Rational ##################### OCL is the OMG’s formal, MOF-based language to express fine-grained constraints in MOF-based models. OCL expressions are unambiguous, precise and computable. Issue ##################### All constraints in UTP specification are defined with natural language. In order to help readers (tool vendors, tester, modeler) to implement, understand and apply the stereotypes of UTP properly, it would be helpful to use formal OCL expressions for these constraints. The natural language description may remain in the specification, meaning the OCL supplements the already existing description. The benefits would be two-folded: Both readers with and without OCL knowledge would be able to understand the specification. UML 2.3 Superstructure, section 18.3.2 Extension, subsection Semantics explains how OCL constraints can be exploited to define restriction on the extended metaclass.
Deferred due to time restrictions
Some test cases might required additional hardware that is only available in specific timeframes. This means the test cases must be scheduled in detail and in certain sequences. Also, test cases may depend on each other. Corresponding model element assignments can be established in principle with the current UTP specification, but a corresponding rule-set or a basic standard is missing. Such kind of rule-set standard is necessary for potential tooling support of scheduling aspects coming out of an UTP test model.
Deferred due to time restrictions
Source: Lockheed Martin, Jon Hagar Specification: UML Testing Profile Section: fig 6.2 Nature: Issue Severity: med Summary: Test Cases as an Operation There isn’t a formal diagram notation for an operation in the UTP; therefore you can’t show it on a diagram using a standard notation. Tool vendors have provided solutions but they are not part of the standard. Figure 6.2 shows test case and operation (metaclass) Resolution: Provide notation definition of operation to be used throughout the standard. Revised Text:
Deferred due to time restrictions
Source: Lockheed Martin, Jon Hagar Specification: UML Testing Profile Section: tbd section Nature: Issue Severity: med Summary: Verify Relationship The verify relationship, a «verify» stereotype dependency, is defined in SysML (section 16.3.2.7) and is used from a test case to a requirement. It can also be used between a test context and a requirement. There is nothing specified in the Testing Profile. Resolution: The UTP should state that it uses the «verify» relationship from the SysML specification, and have sections/diagram created to show this.
Show an additional example of how UTP might use stereotypes from SysML to define test specifications and maintain requirements traceability
Test Objective
1. In the OMG Testing Profile (OTP) specification a Test Objective is defined both as a stereotype on a dependency, «TestObjective», and as an artifact elsewhere. The «TestObjective» stereotype does not apply to this artifact, just to the dependency.
2. The Test Objective dependency relationship is intended to show the dependency from a Test Context or a Test Case to a model element that contains the textual string stating the objective of the test, the test objective artifact.
Resolution:
Test Objective as a dependency:
a. Change Suggestion 1 - No longer use the stereotype «TestObjective» for this dependency relationship. A dependency relationship stereotype name is typically a verb, like verify, satisfy, refine, and copy. Using a noun phrase like “TestObjectiveon” to name a dependency does not provide the declaration that is needed, i.e. subject verb object, e.g. “BlockA satisfies requirement 1”, or “Use Case A refines requirement 1”.
b. Change Suggestion 2 – Use the verb “Validate” as the name of the stereotype that is associated with a dependency. This stereotyped dependency can be used from a Test Case or Test Context to a Test Objective but, can also be used between a test case and model elements that state objectives/goals/capabilities of the item being validated.
c. Why use validate? – Others were considered such as satisfy, realize and implement.
i. The validation definition used by test is “Validation is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals and objectives (i.e. meet stakeholder requirements) in the intended operational environment” , or “Did we build the right thing?” These system uses, goals and objectives are represented in the model in the form of use cases, MOEs, TPMs, etc.
ii. There is a clear distinction between verification and validation. Based on this, there will be unique Test Contexts for verification and validation.
iii. Just as we need to show what test cases will be verifying what requirements we will also need to show what test cases will be validating objectives and goals of the system (or the thing being validated). Therefore, this relationship will ultimately be needed just as verify is used today to verify requirements.
iv. This relationship can also be used to show what test cases are validating the objectives stated for a Test Context. It is the same relationship pattern.
Test Objective part 2
1. A Test Objective artifact is a textual statement stating a goal or objective of a test context. The OTP specification doesn’t define the type of model element to use for this artifact.
Resolution:
1. Test Objective artifact suggestion –
a. We have selected a comment stereotyped «TestObjective» to capture the Test Objective artifact for a Test Context. However, other model elements could be used, such as an attribute of the Test Context. The advantage of a comment is that it can be reused across test contexts
Deferred due to time restrictions
Source: Lockheed Martin, Jon Hagar Specification: UML Testing Profile Section: term data value Nature: Issue Severity: med Summary: The term data value is used many places and seems to be a root for data definitions, e.g. pools, but is not semantically defined. Resolution: Create a semantic definition for data values
Deferred due to time restrictions
Today, «TestContext» is a stereotype of a "StructuredClassifier". However, test contexts must be able to contain anything that is useful to model test specifications, including other test contexts, test cases, test components, and even different kinds of diagrams.
Acutally, the text context was introduced to represent something that provides the structural foundation for the test cases, such as test components, utility componentes, the sut and so forth. Additionally, a test context is by definition something that is instantiable in order to dynamically invoke test cases as operation, to parametrize them with data values (in terms of instance specification). The way as a test context is described in the issue rather refers to something like a dedicated «TestPackage», a packaging mechanism that combines any test relevant information. It must be analyzed whether there are some basic information that would justify the existence of a dedicated test package. Technically, it would definitely make sense for tool developers to have dedicated concept being present in the profile. From the current point of discussion, this issue will be deferred to a further revision. Disposition: Deferred
A single test case is a type that needs to be instantiable (i.e. executed) many times. Instances of a single test case may either be executed in a sequence or in parallel (in which case multiple instances of the same test case exist at the same time). When a single instance of a test case has been executed it should mainly be frozen but may be retained for historical reasons.
This issue will be merged with issue 15927 for resolution
A single test case must be stateful as it controls the sequence of the individual test steps and may need to store temporary data while being executed. These requirements make it difficult to have test cases based on operations. On the other hand, test cases need to be parameterized to achieve some level of genericity, which is less common to behaviors.
This issue will be merged with issue 15927 for resolution
A common early step in specifying test cases is identifying a set of test cases. Today, «TestCase» is a stereotype of an "Operation" or a "Behavior" which is a specialization of a "Class". To support test case identification a test case should be a first-class model element that may exist standalone and that may visually be recognized as a test case.
This issue will be merged with issue 15927 for resolution
Test cases must support various associations among them so that they may be organized into families of related test cases.
This issue will be merged with issue 15927 for resolution
SysML also defines a stereotype «TestCase» on "Operation" and "Behavior" as well as a stereotype «Verify» between requirements and test cases. This should be reflected in the UTP specification as well.
This issue will be merged with issue 15928 for resolution
When identifying test cases one of the most important goals is to minimize the number of test cases while maximizing the test coverage. The core approach to achieve this is to employ various mechanism that facilitate reusability. Therefore, it is very helpful to visualize families of related test cases and their associations on dedicated diagrams.
A diagram for associating test cases in an early phase of a test process makes definitely sense and should be considered for one of the next minor revisions. Since test cases can be expressed as UML::Behavior, and UML::Behavior is a subclass of UML::Class, the most appropriate diagram would be a class diagram with additional symbols. In order to achieve this, it must be clearly and precisely states what concepts ans relationships are needed among test cases. Further more, definitions of monitors for test cases should be included; a test map may define behavioral description stating what should happen, if a monitored situation for a currently execute test case happens (write a log somewhere or interrupt the test case execution). The definition of such “behavioral” monitors must be aligned with issue 6956. Disposition: Deferred
UTP 1.0 provides little support specification of large datasets that are of complex structure. Such data set are typical in test cases for information systems that process complex business objects (e.g. contracts). Furthermore the concepts "DataPool", "DataPartition", and "DataSelector" are based on a programmer's procedural paradigm and are currently not specified proper stereotypes.
The current data package must doubtlessly be thoroughly revised. However, data partitions are quite useful to express equivalence classes for a given base type (currently done with generalizations, but this does not scale). The issue rather points to the inflexible extension or specification capabilities of instance specifications in the UML. Currently, instance specifications cannot participate in a generalization dependency, preventing reusage of partially defines instance specification in order to avoid redundancy. This seems to be an issue for UML, however, since instance specification are more vital for testing pruposes than for architecture design purposes, UTP should address a refinement mechanism for instance specification in the next minor revisions. Necessary concepts: Extension of already defined instance specification Refinement of slots Overriding of slots Disposition: Deferred
The wildcard * to indicate any kind of default is particularly on state machines uncommon and inflexible.
This issue is rather related to the non-defined concepts of any message (Fig. 6.30), any state (Fig. 6.31) and any event (Fig. 6.32). Those concepts are intuitively used in the UTP example sections, but neither part of the UML nor of the UTP. The wildcards, introduced by UTP, are dedicated to values of test data instance specifications (for slot values). In the example sections, the UTP uses the wildcard notation for defaults to capture various situations: undefined messages are received (Fig. 6.31) a set of “exception handling” transitions (Fig. 6.32) are intended to augment each state in the behavior referencing the default, in a way that all transitions of the generic state (state with * as its name) are copied to each state in the test case state machine an undefinied event is recognized in the state machines event queue (Fig. 6.33). No doubt, those are very powerful and helpful concepts, however, they are not defined in the semantics sections of the UTP. Further minor revision must address this issue in order to produce a more precise UTP specification. Disposition: Deferred
The role of operation "getDistributionInterval" on class "DataPool" (in figures 6.39 and 6.41) is not clear.
Deferred due to time restrictions.
The UTP predefines three interfaces, that are Scheduler, Arbiter and Timer. Mixing interfaces and stereotypes, which are supposed to work with those interfaces, is confusing and complicates the implementation of the profile. The idea of those interfaces is straight forward, however, the technical realization is hard to achieve due to mixed meta layers. UML::Interfaces instances are located at meta layer M1 (model layer), whereas Stereotype instances are located at meta layer M2 (meta-model layer). Since the profile mechanism allows the definition of constraints for the base class of a stereotype, it is possible to express the semantics of the predefined interfaces with stereotypes and constraints, being applied on them. Even if a UML profile tool does not include OCL evaluation, the profile would be still easily implementable. The key point is here: Including OCL constraints into the semantics of a stereotype does not restrict the technical feasibility of the profile. Rather, the modeler would be responsible to respect the constraints of the stereotype. If a tool makes use of OCL expressions, the validity of the model would be checked automatically.
Deferred due to time restrictions
In the current UTP specification, the different test actions (StartTimerAction, ValidationAction, etc.) are indirectly bound to a lifeline by being referenced from an ActionExecutionSpecification that covers a lifeline, representing a structured classifier with <<TestComponent>> stereotype applied. This was necessary because there was no adequate meta model element in Interactions for placing a single action onto a lifeline. With UML 2.4, the meta model of Interactions have been reworked significantly in the way that the meta model element OccurrenceSpecification became a concrete class, specializing InteractionFragment. An OccurrenceSpecification has a reference to exactly one lifeline it covers. This the precise redefinition of test actions for Interactions, using the new UML 2.4 semantics. Therefore, each test action (StartTimerAction, StopTimerAction, ValidationAction, etc.) shall extend UML::OccurrenceSpecification directly. Since OccurrenceSpecifications do not have a notation a priori, each test action has to define a dedicated notation (for some actions, there is already a notation defined, e.g. TimeOutMessage). This makes the actions easily and freely positionable on the lifelines. By doing so, the applicability of UTP would be significantly simplified. Besides, the memory footprint in the background would be extremly decreased, due to the fact that the event would be bound directly to the OccurrenceSpecification instead of creating a lot of elements (ActionExecutionSpecification, Action, Event, Input/OutputPins...)
Deferred due to time restrictions
The UTP contains a stereotype <<TestObjective>>, connects either a test context of test case to any model element, expressing the purpose/objective of the test case or the test context. However, most standards related to testing define standalone specifications of such a test case's target in forms of test purposes (ETSI) or test requirements (IEEE/ISQTB). It would be good to have a dedicated stereotype <<TestRequirement>> to express the test case descriptions, similar to system requirements (for example stereotype <<Requirement>> in SysML). It should have atleast an ID, a name, a description and a priority
Deferred due to time restrictions
IN both changebarred / no-changebar documents for UTP (i.e., 11-06-10 and 11-06-09) do the following: Keep: • [OCL] Object Constraint Language (OCL), version 2.2, formal/2010-02-01, 2010 Replace: [UMLi] Unified Modeling Language (UML) Specification: Infrastructure, version 2.3, formal/2010-05-03, 2010 • [UMLs] Unified Modeling Language (UML) Specification: Superstructure, version 2.3, formal/2010-05-05, 2010 • [MOF] Meta Object Facility (MOF) Core Specification, version 2.0, formal/2006-01-01, 2010 with corresponding names for: http://www.omg.org/spec/UML/2.4.1 http://www.omg.org/spec/MOF/2.4.1 http://www.omg.org/spec/XMI/2.4.1 I have to produce the SysML1.3 normative / SMSC-kosher files in XMI anyway, I'll do the same for your profile. I'll send you XMI2.4.1 profiles for UTP normative & informative files that extend UML2.4.1. Change the inventory such that the following files are: informative machine-readable artifacts: http://www.omg.org/cgi-bin/doc?ptc/11-05-15 http://www.omg.org/cgi-bin/doc?ptc/11-05-14 In the inventory, add: http://www.omg.org/cgi-bin/doc?ptc/xx-yy-zz (the XMI2.4.1 / UML2.4.1 version of 11-05-14 -- normative -- without test case management http://www.omg.org/cgi-bin/doc?ptc/xx-yy-zz+1 (the XMI2.4.1 / UML2.4.1 version of 11-05-15 -- informative -- with test case management Get the numbers from Juergen. I don't know if you want new numbers for the whole series of UTP or if Juergen can get you 11-05-XX/XX+1 numbers for the two additional artifacts & the new versions of the UTP documents that say UTP1.1 extends the 2.4.1 series of UML/XMI/MOF. Finally, add another resolution to explain the changes in your updated report (i.e., 11-06-08)
Given by constraint 6 of UML::Message (Section 14.3.18 in UML 2.4 Superstructure), messages are not allowed to cross boundaries of a CombinedFragment. Gates manage the connection of messages outside of a CombinedFragment to messages inside the CombinedFragment. So, in general, a cfragmentGate should be used in this Figure. However, in picture B.14 a Default is depicted. Defaults express behavior for exceptional situation within a test case specfication, so actually, the behavior of a Default is added to the receiving test component lifeline for a particular message (shown in Figure B.13), or for a set of messages (not mentioned in the spec at all). Thus, the two boundary-crossing messages shown in B.14 do not have a real counterpart in Figure B.13 (they are just additional messages). For resolution, I suggest to use found messages (UML::Message with MessageKind::Found) within the InteractionOperands of the determAlt CombinedFragment, to indicate they are additional message for which no real counterparts exists in the interaction applying a Default.
This issue is probably coupled with (at least related with issue #15941 http://www.omg.org/issues/uml-testing-profile-rtf.open.html#Issue15941) and targets a more convenient handling of UML instance specifications for test modeling to avoid redundancy. TTCN-3 offer quite efficient and proven concepts to exploit already defined/created instance specifications (called template in TTCN-3). The concept is called "modifies" and allows the derivation of new templates by reusing existing templates. See Clause 15.5 of TTCN-3 core specification (ETSI ES 201 873-1 V4.2.1) for further information.
In most situation in the UML superstructure, the abstract metaclass ValueSpecification is used when flexibility should be granted to the user in how to model concrete values for an attribute/tag definition.
Using ValueSpecification allows a clear way for tools to deal with different ways of how user model values.
In the test management extension chapter, the tag definitions are typed as semantic-free string types, which makes it hard to calculate them automatically and to interchange the models.
Going from String to ValueSpecification would allow user to define their UML_compliant way of value modeling and still not restrict the user to a certain modeling method.
Example:
TestCase{
priority : ValueSpecification [0..1]
}
A user could therefore provide an enumeration for priorities he uses in his test process like
MyPriorityKind{
low
medium
high
}
This allows the user to fill the priority tag definition of test case with a user-specific value of priority.
instance:TestCase{
slot{
definingFeature = priority
value=InstanceValue{
type = MyPriorityKInd
instance = low
}
}
}
Possible solution:
Change tag definition types in the test management extension chapter from String to ValueSpecifcationThe specification states that coding rules should be defined outside of the utp model and just being referred from the utp model. In some situations, it can might be required to include a precise coding and decoding of values already in the model. Therefore, the coding attribute should be typed by ValueSpecification, which would allow both merely naming the coding rule that should be used by an external test execution environment (LiteralString) and a formal representation of the coding/decoding mechanism itself (Expression/InstanceValue/OpaqueExpression)
This is a correction for issue #15652: In the resolution for issue #15652 we restricted the number of <<TestComponent>> lifelines that are covered by a <<DetermAlt>> to one. This is too restrictive. There can be of course several test component lifelines being covered by the very same <<DetermAlt>>. Possible resolution: Remove the first paragraph in the semantics section Change the first sentence of the current second paragraph from If a deterministic alternative is reached during the execution of an interaction, the involved test component waits until it receives an input to If a deterministic alternative is reached during the execution of an interaction, the involved test component lifeline waits until it receives an input - Remove constraint [2]
In situations where components already exist which shall be reused for the test architecture, it is contra-productive that test component only extends StructuredClassifier. This requires always the creation of a completely new test component (maybe using generalization) for the test architecture. Treating TestComponent, in addition to its current representation, similar to <<SUT>> (which extends Property) would result in more flexibility since existing classifier can be reused for being both the SUT and a TestComponent in different tets context. This is in particular helpful for reusing existing classifier. This way would ot restrict the situation where completely new tets component classifiers must be created (maybe though generalization from already existing classifier in the system model). Current approaches would not become invalid, in contrast, this would result in a more precise and clear test configuration.
TestLog describe the actual execution of a test case against the SUT it was stimulating. A TestLog is described as concrete subclass of Behavior.
For particular behavioral descriptions (Activity, Interaction) the tets log allows the integration of more details for the exeuction of a single test step, e.g. a timestamp when this test step (sending of a message, performing a validation action, ...) has been carried out by the test execution environment.
Therefore, there should be at least for test log's represented as Interaction and Activity a concept like the following:
TestLogEntry extends OccurrenceSpecification/Action{
timestamp : UML::TimeExpression [0..1]
...
}UML supports the substitution principle of the object-oriented paradigm among other by not allowing the violation of constraints on superclasses in specialized subclasses. This is fine for the definition of system specifications. Testing, however, has to deal with invalid situations and data types. The most common test design/test data design technique relies on that fundamental principle of identifying "invalid" partitions of data types - the equivalence classes. Invalid means that the data partition does not comply with the constraints that is either applied to an interface operation or the data type itself.
In UTP, data partitions are defined as stereotypes on classifier, hence it is possible to reuse existing type definition (from an existing system model) and to create data partitions for that type (let's called it base type) that divides the base type into several different data partitions.
As an example, consider the following:
class A{
+ i : Integer {i >= 0 and i <= 100}
}
Applying the equivalence class method, this base data type would result in three equivalence classes/data partitions:
1. DP_1 = i >= 0 and <= 100 //valid
2. DP_2 = i < 0 //invalid
3. DP_3 = i > 100 //invalid
If we want to reuse the base data type for the design of test specifications, we would have to generalize the already existing class A by three different data partitions like:
DP_1 extends A{ //valid
+ a : Integer {i >= 0 and i <=100}
} //constraint inherited by class A
DP_2 extends A{ //invalid
+ a : Integer {i < 0}
}
DP_3 extends A{ //invalid
+ a : Integer {i > 0}
}
Creating DP_2 and DP_3 would result in a contradiction, since UML disallows constraints to be deactivated or overwritten. DP_2 would look like this:
DP_2 extends A{ //invalid
+ a : Integer {i < 0 and i >= 0 and i <=100}
}
This requires a mechanism to explicitly target constraints in superclasses which are overwritten (not redefined) in subclasses with <<DataParition>> applied.
To summarize: Test specifications address a larger set of data types than sytem specification, since they have to stimulate the system with data which are invalid by the system specification.
A possible and minimal inversive solution could the following be:
Introduce a new stereotype <<OverwritingConstraint>> or <<TestConstraint>> that has at least one tag definition, namely:
+ overwrittenConstraints : Constraint [1..*]
whereas each Constraint being referenced by the tag definition must be a constraint initially introduced by the base type of the data partition or one of its subclasses.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.
The term 'LogAction' actually refers to the element FinishAction. So it should be renamed to 'FinishAction' and a new term for 'LogAction' should be included
UTP is a specification for the creation of model-based test specififcation, thus, it has an important and meaningful role in the realm of model-based testing. Unfortunately, the introductory chapters do not mentione, nor define, model-based testing, test model or any relevant concept related to MBT techniques. As the first and the most sophisticated standardization approach of MBT concepts, the UTP specification should be much clearer on its purpose and relationship to MBT. In fact, being incepted and mostly written almost 10 years ago, UTP needs a modernization polishing.
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
The enumeration Verdict should be renamed to VerdictKind, to be consistent with UML and all other UML profiles.
During UTP 1.1 revision, the entire document structure has been modernized, cleaned-up and restructured. However, there are several typos and style glitches in the current specification, which mostly originated from copy and paste errors. In addition, some of the figures need polishing as well (e.g. Figure 7.8, Figure B.14, Figure B.23, Figure B.26, Figure B.28)
Figure B.28 depicts an interaction between a tect component lifeline and several SUT lifeline. The first two and the last two messages invoke an operation called checkBalance with a actual parameter p.euAccount/p.usAccount, where p is of type TrxnData. The type TrxnData is specified in Figure B.23, and in this Figure (which is the only Figure for the definition of TrxnData) there are no attributes for TrxnData called euAccount or usAccount, but account.
There was an error introduced into the textual definition of ValidationAction during the sophisticated restructuring of UTP 1.0 to UTP 1.1. So actually, ValidationAction should extend CallOperationAction instead of Dependency (as it is correctly depicted in the abstract syntax)
In UTP 1.1 there are two predefined time-related types: Time and Duration. Time is used for starting a timer (Timer::start(expre:Time)), so it represent rather a Duration. In addition, time is ambiguous, because it is not clear what time actually represents, a particular point in time or a duration of time units. Since UTO already defines a Duration type to express a duration of time unit, Time should be renamed to Timepoint to cope with particular points in time. Concrete timepoint formats are not given by UTP. Furthermore, Timer should offer a second start() method with the signature Timer::start(duration:Duration). The user would be able to decide whether a time should timeout at a certain point in time or after a given duration.