Issue 18687: UML 2.5: Time Observation and Duration Observation problem (uml25-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: In the current model of Time (UML 2.5), TimeObservation and DurationObservation are both a kind of Observation which is, in turn, a kind of PackageableElement. Significantly, however, neither is a kind of ValueSpecificaiton or even a kind of TypedElement. Hence, it is not particularly meaningful to use it in expressions such as constraints or shown in numerous diagrams such as Figure 8.5 or in numerous diagrams in the Interactions clause (clause 17). Note that these examples might be OK if they actually referenced not the observations themselves, but to the associated TimeExpressions. Unfortunately, there are two issues that prevent this as a solution to the above problem: (1) It is not possible to navigate from an observation to its associated TimeExpression, which means that, given a TimeObservation or a DurationObservation element in a model, it is not possible to easily find the time value that is associated with it (what is the use of a time observation if we do not know the time value associated with it?) (2) A TimeExpression can be associated with multiple TimeObservations (or DurationObservations), which means that referencing a given TimeExpression does not necessarily identify which observation is being referenced. Hence, if the time expression is referenced in a constraint, that would presumably automatically apply to all observations pointed to by that expression, even if that is not the intent. One possible simple solution is to make Observation a kind of ValueSpecification instead of a kind of PackageableElement. (A more systematic solution would be to revisit and rationalize the entire SimpleTime and Intervals metamodel, which seem unnecessarily complicated.) Resolution: Revised Text: Actions taken: April 24, 2013: received issue Discussion: End of Annotations:===== M-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=oU9XZm1nktwHhZNWEUAVNN5CPu5cyxAXEWdzlsgVgZk=; b=axP4ExlSNBkPrO4PfX4AHvWBpM45pZCA5/YNYVVG6vok5PloA411UmfDgOj6zP0Ikj AR7nx27F8N546dS7jVvFzLsYv/vz0bKEeSAQ938pNswv+70cG35uXDv46R5Y+4mZIVV5 FopAUI/IlW/AcrWjaPSOil6GnBDehGtZ/AVmM7F6s3eVc4h9e/CKajOz2rZ5IK7jBDv8 SaqyxIzUBBY6gRyBZpOevswdCXRE6bZCyo7qwCcWyMdL+R8C8Gd+YjDSN3ZRAUqsPD0k mPdGw4eUiuMuHv4m8wiNe8FYRbmgXGgycGdH1y3aQgPnsElko+j06VVL2yECzYwoiamj Y5+w== X-Received: by 10.52.26.209 with SMTP id n17mr22067205vdg.26.1366817832856; Wed, 24 Apr 2013 08:37:12 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 24 Apr 2013 11:36:32 -0400 X-Google-Sender-Auth: AU4_uRmC8SfxEjYO7l_y-canD2I Subject: UML 2.5: Time Observation and Duration Observation problem To: "issues@omg.org" X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0deRqa X-Brightmail-Tracker: AAAAAA== In the current model of Time (UML 2.5), TimeObservation and DurationObservation are both a kind of Observation which is, in turn, a kind of PackageableElement. Significantly, however, neither is a kind of ValueSpecificaiton or even a kind of TypedElement. Hence, it is not particularly meaningful to use it in expressions such as constraints or shown in numerous diagrams such as Figure 8.5 or in numerous diagrams in the Interactions clause (clause 17). Note that these examples might be OK if they actually referenced not the observations themselves, but to the associated TimeExpressions. Unfortunately, there are two issues that prevent this as a solution to the above problem: (1) It is not possible to navigate from an observation to its associated TimeExpression, which means that, given a TimeObservation or a DurationObservation element in a model, it is not possible to easily find the time value that is associated with it (what is the use of a time observation if we do not know the time value associated with it?) (2) A TimeExpression can be associated with multiple TimeObservations (or DurationObservations), which means that referencing a given TimeExpression does not necessarily identify which observation is being referenced. Hence, if the time expression is referenced in a constraint, that would presumably automatically apply to all observations pointed to by that expression, even if that is not the intent. One possible simple solution is to make Observation a kind of ValueSpecification instead of a kind of PackageableElement. (A more systematic solution would be to revisit and rationalize the entire SimpleTime and Intervals metamodel, which seem unnecessarily complicated.)