Issue 17292: Rename predefined type Time to Timepoint (uml-testing-profile-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Clarification Severity: Minor Summary: 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. Resolution: The RTF agreed that the UML Testing Profile should allow to set both a duration and a timepoint for a timer to expire. This is consistent with the UML simple time concepts, where a user can express TimeEvents in terms of Duration or TimeExpression. However, it is not the intention of UTP to predefine or determine the concrete format of a Timepoint or Duration. There is ongoing work within the OMG to standardize those things. Additionally, the RTF agreed on setting a constraint how values/instances of these two primitive types have to be expressed. In order to align the imperative timer concept of UTP with the declarative one of UML simple time, instances/values for utp::Timepoint shall be expressed as utp::TimeExpression with type set to utp::Timepoint. Consequently, instances/values of utp::Duration have to be expressed as uml::Duration with type set to utp::Duration. Again, the concrete format of such a ValueExpression is not predefined and is left open to the user. Finally, the predefined Timer interface of UTP should offer operations to start a Timer with either a Duration or Timepoint for expiration. Revised Text: Replace Figure 7.28 (was initially 7.11 in UTP 1.1) Timer Concepts with Update Text Alter section title of section 7.5.2.7 from Time (a predefined type) To Timepoint Update Text Change text of subsection Description of section 7.5.2.7 from Time is a predefined primitive type used to specify concrete time values. Time values are used to express time constraints and to set timers. A predefined keyword ‘now’ may be used to represent the current time in a system. How this value is obtained is not specified. The difference between two Time values is a Duration. To Timepoint is a predefined primitive type used to specify concrete points in time. Add Section Add a new subsection ‘Semantics’ to section 7.5.2.7 after subsection ‘Description’ Semantics A Timepoint represents a concrete point in time. Instances for that primitive type have to be expressed as TimeExpression with its type set to Timepoint. The concrete format of such a point in time is not predefined and is left open to the user. The keyword ‘now’ is a short cut for expressing the current point in time. Add Section Add a new subsection ‘Constraint’ to section 7.5.2.7 after newly created subsection ‘Semantics’ Constraints [1] Values of the primitive type Timepoint have to be expressed as TimeExpression with its type set to Timepoint. Update Text Alter section title of section 7.5.2.3 from Duration (a predefined type) To Duration Update Text Change text of subsection Description of section 7.5.2.3 from Duration is a predefined primitive type used to specify a duration. Durations are used in time constraints and together with time values. Adding or subtracting a duration to a time value results in a time value. Adding or subtracting two durations results in a duration. To Duration is a predefined primitive type used to specify a finite time range. Add Section Add a new subsection ‘Semantics’ to section 7.5.2.3 after subsection ‘Description’ Semantics A Duration denotes an arbitrary time range. The concrete time unit or the format of a how a Duration is expressed is not predefined and is left open to the user. Instances of Duration have to be expressed as uml::Duration with its type set to utp::Duration. The keyword ‘now’ is a shortcut for expressing the current point in time. Add Section Add a new subsection ‘Constraint’ to section 7.5.2.3 after newly created subsection ‘Semantics’ Constraints [1] Values of the primitive type Duration have to be expressed as uml::Duration with its type set to utp::Duration. Update Text Alter section title of section 7.5.2.11 from Timer (a predefined interface) To Timer Update Text Add the following paragraph to the end of subsection ‘Description’ of section 7.5.2.11 Timers provide means to observe and control test behavior. Also, a timer can be used to prevent from deadlocks, starvation and instable system behavior during test execution. Update Text Alter subsection ‘Operations’ of section 7.5.2.11 from • start(expires : Time) Starts the timer and sets the time of expiration. • stop() Stops the timer • read() : Time Reads the expiration time of the timer. To • start(expires : Timepoint) Starts the timer and sets the timepoint of expiration. • start(expires : Duration) Starts the timer and sets the duration time of expiration. • stop() Stops the timer. • read() : Duration Reads the expiration time of the timer. Update Text Alter first constraints of subsection ‘Constraints’ of section 7.5.2.11 from [1] Only active classes may own properties realizing the timer interface. [2] Timer may only be started with positive expiration time. To [1] Only test components and test contexts may own properties realizing the timer interface. [2] In case the timer is started with a Timepoint, the expiration time point must be a time point in the future. Actions taken: April 10, 2012: received issue January 7, 2013: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 10 Apr 2012 10:21:25 -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 Profile Section: Timing FormalNumber: ptc/2011-07-19 Version: 1.1 Doc_Year: 2011 Doc_Month: July Doc_Day: 19 Page: 31ff. Title: Rename predefined type Time to Timepoint Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Description: 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. Date: Tue, 24 Apr 2012 10:05:39 +0200 From: Cyril Ballagny Organization: ModelioSoft User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: "Wendland, Marc-Florian" CC: uml-testing-profile-rtf@omg.org Subject: Time issue 17292 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=softeam.fr; s=MAILOUT; t=1335254739; bh=FEJ0j9+YjU6TNuf9mzmIgRarMVcGQs3W2jP4xx1TT+k=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=B+7KbCCMXlrIEj+FUpIr6R4FQ5ZvXoS2XIjxiaXmWoP8HCUVsYtzNoLk6ZlQ/1Q3M ZMDfKjvy/tX8ZeKBTrTQ2u66afatf+bPamudTogLqJeH8kXLrBK88D7v9YyeTzC6+p KPwnXgzg5zf6O7Ov5cqQkQP+69voalfNhkAmN3BM= X-DKIM: OpenDKIM Filter v2.2.2 idefix3.softeam.com 8899E63A550E X-Softeam-fr-MailScanner-ID: 8899E63A550E.AB203 X-Softeam-fr-MailScanner: Found to be clean X-Softeam-fr-MailScanner-SpamCheck: n'est pas un polluriel (inscrit sur la liste blanche), SpamAssassin (not cached, score=-4.399, requis 3.5, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Softeam-fr-MailScanner-From: cyril.ballagny@softeam.fr X-Spam-Status: No Hi All, I was looking at this Time issue and actually adding a Timepoint type seems to be redundant with how uml::TimeExpression is defined. Furthermore, using TimeExpression gives access to uml::Duration and uml::TimeInterval which prevents from adding an other operation to the Timer interface. IMHO, the utp::Time is not a duration but a moment, since it is explained that the difference between two Time values is a Duration and that the 'now' keyword represents the current time. Hence, the Time definition does not seem to be ambiguous but rather redundant with the UML time package. I would prefer merging the UTP and UML time concepts instead of adding new types. Best regards, Cyril. On 10/04/2012 16:40, Wendland, Marc-Florian wrote: Participants: Jon Markus Lulu Marc-Florian Minutes: We actually just discussed on an optimized outline for the UTP specification. There we decided: - to extract all non-stereotypes into a separate types packages, which is common standard in OMG's UML profile specifications - to incorporate a new test management chapter in the normative section - Please find the outcome of this discussion attached (also in the SVN in folder /issues/17224) - Feedback expected from all members SIDEMARK - we identified a new issue, i.e. the predefined type time is not precisely enough defined. How it is used by the timer's start operation (Timer::start(expire:Time)) it seems to be used as kind of a Duration (a particular time unit that will be counted down until it expires). But UTP already defined Duration, so what is the difference between Duration and Time? - Markus suggested (and I already filed an issue at OMG) to rename Time to Timepoint. It semantics is that is stands for a particular point in time where the timer expires. The concrete format of such a timepoint is not defined and depends on the underlying OS of the test execution system. Additionally, the Timer interface must incorporate a second start operation with the signature start(duration:Duration), so that the user would be able to defines both a concrete point in time or a duration value to configure a timer. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ -- ************************************** Dr. Cyril Ballagny R&D Department Softeam, Modeliosoft, France http://www.softeam.com/ http://www.modeliosoft.com/ http://www.modelio.org/ Tel. +33 130121675 (office) ************************************** cyril_ballagny.vcf Subject: AW: Time issue 17292 Date: Tue, 24 Apr 2012 10:23:14 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time issue 17292 Thread-Index: Ac0h8Uby2bQZait8TW2Stf6+W4v3iAAAHMbw From: "Wendland, Marc-Florian" To: "Cyril Ballagny" Cc: X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml-testing-profile-rtf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate02-haj2 with 5D36D6EC00C X-cloud-security: scantime:.5629 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q3O8Ogge003090 Cyrill, I partially agree. Just be aware that the UML way of UTP way of time/timer handling is somewhat different. UTP has a kind of imperative concept, i.e. the operation of the timer interface has to be invoked in order to start a timer, whereas in UML you do not have timer, but time constraints and time expression. This is slightly different in my opinion, although uml::TimeExpression and uml::Duration seems to be adequate to represent concrete instances of utp::Time(point) and utp::Duration. We cannot change the Timer interface to start(a : uml::TimeExpression)/start(d : uml::Duration) because TimeExpression and Duration are not types but ValueSpecifications. What we could do in order to align utp::Time(point) and utp::Duration with UML simple time concepts is to say that concrete values of those primitive types have to be expressed with uml::TimeExpression and uml::Duration ValueSpecifications. This would at least represent a clear cut between UML simple time (declarative layer) and UTP timer (imperative layer), whereas UTP is kind of an abstraction of the UML simple time concept. Anyway, no one is forced to use utp::Timer concepts, if one rather prefers to work with the declarative timing concepts of UML. But I would not want the imperative UTP timer mechanisms being removed from the spec. Does this make sense? Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ > -----Ursprühe Nachricht----- > Von: Cyril Ballagny [mailto:cyril.ballagny@softeam.fr] > Gesendet: Dienstag, 24. April 2012 10:06 > An: Wendland, Marc-Florian > Cc: uml-testing-profile-rtf@omg.org > Betreff: Time issue 17292 > > Hi All, > > I was looking at this Time issue and actually adding a Timepoint type seems to > be redundant with how uml::TimeExpression is defined. > Furthermore, using TimeExpression gives access to uml::Duration and > uml::TimeInterval which prevents from adding an other operation to the > Timer interface. > IMHO, the utp::Time is not a duration but a moment, since it is explained that > the difference between two Time values is a Duration and that the 'now' > keyword represents the current time. Hence, the Time definition does not > seem to be ambiguous but rather redundant with the UML time package. I > would prefer merging the UTP and UML time concepts instead of adding new > types. > > Best regards, > Cyril. > > On 10/04/2012 16:40, Wendland, Marc-Florian wrote: > > Participants: > > Jon > > Markus > > Lulu > > Marc-Florian > > > > Minutes: > > We actually just discussed on an optimized outline for the UTP > > specification. There we decided: > > - to extract all non-stereotypes into a separate types packages, which > > is common standard in OMG's UML profile specifications > > - to incorporate a new test management chapter in the normative > > section > > - Please find the outcome of this discussion attached (also in the SVN > > in folder /issues/17224) > > - Feedback expected from all members > > > > SIDEMARK > > - we identified a new issue, i.e. the predefined type time is not > > precisely enough defined. How it is used by the timer's start > > operation > > (Timer::start(expire:Time)) it seems to be used as kind of a Duration > > (a particular time unit that will be counted down until it expires). > > But UTP already defined Duration, so what is the difference between > > Duration and Time? > > - Markus suggested (and I already filed an issue at OMG) to rename > > Time to Timepoint. It semantics is that is stands for a particular > > point in time where the timer expires. The concrete format of such a > > timepoint is not defined and depends on the underlying OS of the test > > execution system. Additionally, the Timer interface must incorporate a > > second start operation with the signature start(duration:Duration), so > > that the user would be able to defines both a concrete point in time > > or a duration value to configure a timer. > > > > Marc-Florian > > ################################################ > > Marc-Florian Wendland > > Master of Science (M.Sc.) > > ------------------------------------------------ > > Fraunhofer Institut FOKUS > > Modeling und Testing Department > > Kaiserin-Augusta-Alle 31 > > D-10589 Berlin > > ------------------------------------------------ > > Tel: +49 (30) - 3463 7395 > > Email: marc-florian.wendland@fokus.fraunhofer.de > > ################################################ > > > > > > > > > > > -- > ************************************** > Dr. Cyril Ballagny > R&D Department > Softeam, Modeliosoft, France > http://www.softeam.com/ > http://www.modeliosoft.com/ > http://www.modelio.org/ > Tel. +33 130121675 (office) > ************************************** > > Subject: Re: Time issue 17292 From: "Prof. Zhen Ru Dai" Date: Tue, 24 Apr 2012 10:46:34 +0200 Cc: "Cyril Ballagny" , To: "Wendland, Marc-Florian" X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q3O8lILD004368 Hi Florian, I think Cyrill is talking about the new timepoint concept and not the timer concept. The timer concept is mandatory for testing in order to catch exepetions and unwanted behavior. But the timepoint concept can be found in uml::timeexpression, I agree. Most people are confused by having both uml:timeexpression AND utp::timer already. But most of them understand after explaining that timer is an active thing, since it can trigger a timeout behavior. But having uml::timeexpression, utp::timer and upt::timepoint would be too much. What do you think? cheers Lulu Am 24.04.2012 um 10:23 schrieb Wendland, Marc-Florian: > Cyrill, > > I partially agree. > > Just be aware that the UML way of UTP way of time/timer handling is somewhat different. UTP has a kind of imperative concept, i.e. the operation of the timer interface has to be invoked in order to start a timer, whereas in UML you do not have timer, but time constraints and time expression. This is slightly different in my opinion, although uml::TimeExpression and uml::Duration seems to be adequate to represent concrete instances of utp::Time(point) and utp::Duration. > > We cannot change the Timer interface to > > start(a : uml::TimeExpression)/start(d : uml::Duration) > > because TimeExpression and Duration are not types but ValueSpecifications. What we could do in order to align utp::Time(point) and utp::Duration with UML simple time concepts is to say that concrete values of those primitive types have to be expressed with uml::TimeExpression and uml::Duration ValueSpecifications. This would at least represent a clear cut between UML simple time (declarative layer) and UTP timer (imperative layer), whereas UTP is kind of an abstraction of the UML simple time concept. > > Anyway, no one is forced to use utp::Timer concepts, if one rather prefers to work with the declarative timing concepts of UML. But I would not want the imperative UTP timer mechanisms being removed from the spec. > > Does this make sense? > > Marc-Florian > > ################################################ > Marc-Florian Wendland > Master of Science (M.Sc.) > ------------------------------------------------ > Fraunhofer Institut FOKUS > Modeling und Testing Department > Kaiserin-Augusta-Alle 31 > D-10589 Berlin > ------------------------------------------------ > Tel: +49 (30) - 3463 7395 > Email: marc-florian.wendland@fokus.fraunhofer.de > ################################################ > > >> -----Ursprühe Nachricht----- >> Von: Cyril Ballagny [mailto:cyril.ballagny@softeam.fr] >> Gesendet: Dienstag, 24. April 2012 10:06 >> An: Wendland, Marc-Florian >> Cc: uml-testing-profile-rtf@omg.org >> Betreff: Time issue 17292 >> >> Hi All, >> >> I was looking at this Time issue and actually adding a Timepoint type seems to >> be redundant with how uml::TimeExpression is defined. >> Furthermore, using TimeExpression gives access to uml::Duration and >> uml::TimeInterval which prevents from adding an other operation to the >> Timer interface. >> IMHO, the utp::Time is not a duration but a moment, since it is explained that >> the difference between two Time values is a Duration and that the 'now' >> keyword represents the current time. Hence, the Time definition does not >> seem to be ambiguous but rather redundant with the UML time package. I >> would prefer merging the UTP and UML time concepts instead of adding new >> types. >> >> Best regards, >> Cyril. >> >> On 10/04/2012 16:40, Wendland, Marc-Florian wrote: >>> Participants: >>> Jon >>> Markus >>> Lulu >>> Marc-Florian >>> >>> Minutes: >>> We actually just discussed on an optimized outline for the UTP >>> specification. There we decided: >>> - to extract all non-stereotypes into a separate types packages, which >>> is common standard in OMG's UML profile specifications >>> - to incorporate a new test management chapter in the normative >>> section >>> - Please find the outcome of this discussion attached (also in the SVN >>> in folder /issues/17224) >>> - Feedback expected from all members >>> >>> SIDEMARK >>> - we identified a new issue, i.e. the predefined type time is not >>> precisely enough defined. How it is used by the timer's start >>> operation >>> (Timer::start(expire:Time)) it seems to be used as kind of a Duration >>> (a particular time unit that will be counted down until it expires). >>> But UTP already defined Duration, so what is the difference between >>> Duration and Time? >>> - Markus suggested (and I already filed an issue at OMG) to rename >>> Time to Timepoint. It semantics is that is stands for a particular >>> point in time where the timer expires. The concrete format of such a >>> timepoint is not defined and depends on the underlying OS of the test >>> execution system. Additionally, the Timer interface must incorporate a >>> second start operation with the signature start(duration:Duration), so >>> that the user would be able to defines both a concrete point in time >>> or a duration value to configure a timer. >>> >>> Marc-Florian >>> ################################################ >>> Marc-Florian Wendland >>> Master of Science (M.Sc.) >>> ------------------------------------------------ >>> Fraunhofer Institut FOKUS >>> Modeling und Testing Department >>> Kaiserin-Augusta-Alle 31 >>> D-10589 Berlin >>> ------------------------------------------------ >>> Tel: +49 (30) - 3463 7395 >>> Email: marc-florian.wendland@fokus.fraunhofer.de >>> ################################################ >>> >>> >>> >>> >> >> >> -- >> ************************************** >> Dr. Cyril Ballagny >> R&D Department >> Softeam, Modeliosoft, France >> http://www.softeam.com/ >> http://www.modeliosoft.com/ >> http://www.modelio.org/ >> Tel. +33 130121675 (office) >> ************************************** >> >> > -- Prof. Zhen Ru Dai University of Applied Science Hamburg Berliner Tor 7 Room 7.86 20099 Hamburg Tel. +49-40-42875-8153 Subject: AW: Time issue 17292 Date: Tue, 24 Apr 2012 10:57:45 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time issue 17292 Thread-Index: Ac0h9xHf743pejp+QQSpR/kKFKsANgAABmAQ From: "Wendland, Marc-Florian" To: "Prof. Zhen Ru Dai" Cc: "Cyril Ballagny" , X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml-testing-profile-rtf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate03-haj2 with 026B712B4005 X-cloud-security: scantime:.7460 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q3O8vrLt004845 >But having uml::timeexpression, utp::timer and upt::timepoint would be too much Well, currently we have utp::Time and utp::Duration which are both types. Instead of, we would have utp::Timepoint and utp::Duration. The first one would represent a particular point in time where the timer is supposed to expire, the latter one a duration the timer would count down before it expire. Utp::Duration is not use by anyone to my knowledge and as it is currently, the Duration type completely senseless. Utp::Time represents concrete time values (taken from UTP 1.1 spec) and is used in utp::Timer:start() to denote the expiration time of a timer. Was Markus mentioned, and I agree so far, that timer are actually started with a Duration. Since UTP has this declarative timer concepts, we cannot make directly use of uml::TimeExpression and uml::Duration within the Timer interface! They are not types and a parameter of an operation has to be typed by type. That was the reason, I reckon, why utp::Time and utp::Duration have been introduced in addition. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ > -----Ursprühe Nachricht----- > Von: Prof. Zhen Ru Dai [mailto:dai@informatik.haw-hamburg.de] > Gesendet: Dienstag, 24. April 2012 10:47 > An: Wendland, Marc-Florian > Cc: Cyril Ballagny; uml-testing-profile-rtf@omg.org > Betreff: Re: Time issue 17292 > > Hi Florian, > > I think Cyrill is talking about the new timepoint concept and not the timer > concept. > > The timer concept is mandatory for testing in order to catch exepetions and > unwanted behavior. But the timepoint concept can be found in > uml::timeexpression, I agree. Most people are confused by having both > uml:timeexpression AND utp::timer already. But most of them understand > after explaining that timer is an active thing, since it can trigger a timeout > behavior. But having uml::timeexpression, utp::timer and upt::timepoint > would be too much. What do you think? > > cheers > > Lulu > > > > Am 24.04.2012 um 10:23 schrieb Wendland, Marc-Florian: > > > Cyrill, > > > > I partially agree. > > > > Just be aware that the UML way of UTP way of time/timer handling is > somewhat different. UTP has a kind of imperative concept, i.e. the operation > of the timer interface has to be invoked in order to start a timer, whereas in > UML you do not have timer, but time constraints and time expression. This is > slightly different in my opinion, although uml::TimeExpression and > uml::Duration seems to be adequate to represent concrete instances of > utp::Time(point) and utp::Duration. > > > > We cannot change the Timer interface to > > > > start(a : uml::TimeExpression)/start(d : uml::Duration) > > > > because TimeExpression and Duration are not types but > ValueSpecifications. What we could do in order to align utp::Time(point) and > utp::Duration with UML simple time concepts is to say that concrete values of > those primitive types have to be expressed with uml::TimeExpression and > uml::Duration ValueSpecifications. This would at least represent a clear cut > between UML simple time (declarative layer) and UTP timer (imperative > layer), whereas UTP is kind of an abstraction of the UML simple time > concept. > > > > Anyway, no one is forced to use utp::Timer concepts, if one rather prefers > to work with the declarative timing concepts of UML. But I would not want > the imperative UTP timer mechanisms being removed from the spec. > > > > Does this make sense? > > > > Marc-Florian > > > > ################################################ > > Marc-Florian Wendland > > Master of Science (M.Sc.) > > ------------------------------------------------ > > Fraunhofer Institut FOKUS > > Modeling und Testing Department > > Kaiserin-Augusta-Alle 31 > > D-10589 Berlin > > ------------------------------------------------ > > Tel: +49 (30) - 3463 7395 > > Email: marc-florian.wendland@fokus.fraunhofer.de > > ################################################ > > > > > >> -----Ursprühe Nachricht----- > >> Von: Cyril Ballagny [mailto:cyril.ballagny@softeam.fr] > >> Gesendet: Dienstag, 24. April 2012 10:06 > >> An: Wendland, Marc-Florian > >> Cc: uml-testing-profile-rtf@omg.org > >> Betreff: Time issue 17292 > >> > >> Hi All, > >> > >> I was looking at this Time issue and actually adding a Timepoint type > >> seems to be redundant with how uml::TimeExpression is defined. > >> Furthermore, using TimeExpression gives access to uml::Duration and > >> uml::TimeInterval which prevents from adding an other operation to > >> the Timer interface. > >> IMHO, the utp::Time is not a duration but a moment, since it is > >> explained that the difference between two Time values is a Duration and > that the 'now' > >> keyword represents the current time. Hence, the Time definition does > >> not seem to be ambiguous but rather redundant with the UML time > >> package. I would prefer merging the UTP and UML time concepts instead > >> of adding new types. > >> > >> Best regards, > >> Cyril. > >> > >> On 10/04/2012 16:40, Wendland, Marc-Florian wrote: > >>> Participants: > >>> Jon > >>> Markus > >>> Lulu > >>> Marc-Florian > >>> > >>> Minutes: > >>> We actually just discussed on an optimized outline for the UTP > >>> specification. There we decided: > >>> - to extract all non-stereotypes into a separate types packages, > >>> which is common standard in OMG's UML profile specifications > >>> - to incorporate a new test management chapter in the normative > >>> section > >>> - Please find the outcome of this discussion attached (also in the > >>> SVN in folder /issues/17224) > >>> - Feedback expected from all members > >>> > >>> SIDEMARK > >>> - we identified a new issue, i.e. the predefined type time is not > >>> precisely enough defined. How it is used by the timer's start > >>> operation > >>> (Timer::start(expire:Time)) it seems to be used as kind of a > >>> Duration (a particular time unit that will be counted down until it > expires). > >>> But UTP already defined Duration, so what is the difference between > >>> Duration and Time? > >>> - Markus suggested (and I already filed an issue at OMG) to rename > >>> Time to Timepoint. It semantics is that is stands for a particular > >>> point in time where the timer expires. The concrete format of such a > >>> timepoint is not defined and depends on the underlying OS of the > >>> test execution system. Additionally, the Timer interface must > >>> incorporate a second start operation with the signature > >>> start(duration:Duration), so that the user would be able to defines > >>> both a concrete point in time or a duration value to configure a timer. > >>> > >>> Marc-Florian > >>> ################################################ > >>> Marc-Florian Wendland > >>> Master of Science (M.Sc.) > >>> ------------------------------------------------ > >>> Fraunhofer Institut FOKUS > >>> Modeling und Testing Department > >>> Kaiserin-Augusta-Alle 31 > >>> D-10589 Berlin > >>> ------------------------------------------------ > >>> Tel: +49 (30) - 3463 7395 > >>> Email: marc-florian.wendland@fokus.fraunhofer.de > >>> ################################################ > >>> > >>> > >>> > >>> > >> > >> > >> -- > >> ************************************** > >> Dr. Cyril Ballagny > >> R&D Department > >> Softeam, Modeliosoft, France > >> http://www.softeam.com/ > >> http://www.modeliosoft.com/ > >> http://www.modelio.org/ > >> Tel. +33 130121675 (office) > >> ************************************** > >> > >> > > > > -- > Prof. Zhen Ru Dai > University of Applied Science Hamburg > Berliner Tor 7 > Room 7.86 > 20099 Hamburg > Tel. +49-40-42875-8153 Subject: Re: Time issue 17292 From: "Prof. Zhen Ru Dai" Date: Tue, 24 Apr 2012 11:10:37 +0200 Cc: "Cyril Ballagny" , To: "Wendland, Marc-Florian" X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q3O9AoJH005616 Hi Florian Am 24.04.2012 um 10:57 schrieb Wendland, Marc-Florian: >> But having uml::timeexpression, utp::timer and upt::timepoint would be too much > Well, currently we have utp::Time and utp::Duration which are both types. Instead of, we would have utp::Timepoint and utp::Duration. The first one would represent a particular point in time where the timer is supposed to expire, the latter one a duration the timer would count down before it expire. so upt::timepoint is an absolut time at which timer is supposed to expire. But I don't think that this is really much used in testing. Usually we define relative time starting from the setup of the test. What is the experience of the others? cheers lulu > > Utp::Duration is not use by anyone to my knowledge and as it is currently, the Duration type completely senseless. > > Utp::Time represents concrete time values (taken from UTP 1.1 spec) and is used in utp::Timer:start() to denote the expiration time of a timer. Was Markus mentioned, and I agree so far, that timer are actually started with a Duration. > > Since UTP has this declarative timer concepts, we cannot make directly use of uml::TimeExpression and uml::Duration within the Timer interface! They are not types and a parameter of an operation has to be typed by type. That was the reason, I reckon, why utp::Time and utp::Duration have been introduced in addition. > > Marc-Florian > > ################################################ > Marc-Florian Wendland > Master of Science (M.Sc.) > ------------------------------------------------ > Fraunhofer Institut FOKUS > Modeling und Testing Department > Kaiserin-Augusta-Alle 31 > D-10589 Berlin > ------------------------------------------------ > Tel: +49 (30) - 3463 7395 > Email: marc-florian.wendland@fokus.fraunhofer.de > ################################################ > > >> -----Ursprühe Nachricht----- >> Von: Prof. Zhen Ru Dai [mailto:dai@informatik.haw-hamburg.de] >> Gesendet: Dienstag, 24. April 2012 10:47 >> An: Wendland, Marc-Florian >> Cc: Cyril Ballagny; uml-testing-profile-rtf@omg.org >> Betreff: Re: Time issue 17292 >> >> Hi Florian, >> >> I think Cyrill is talking about the new timepoint concept and not the timer >> concept. >> >> The timer concept is mandatory for testing in order to catch exepetions and >> unwanted behavior. But the timepoint concept can be found in >> uml::timeexpression, I agree. Most people are confused by having both >> uml:timeexpression AND utp::timer already. But most of them understand >> after explaining that timer is an active thing, since it can trigger a timeout >> behavior. But having uml::timeexpression, utp::timer and upt::timepoint >> would be too much. What do you think? >> >> cheers >> >> Lulu >> >> >> >> Am 24.04.2012 um 10:23 schrieb Wendland, Marc-Florian: >> >>> Cyrill, >>> >>> I partially agree. >>> >>> Just be aware that the UML way of UTP way of time/timer handling is >> somewhat different. UTP has a kind of imperative concept, i.e. the operation >> of the timer interface has to be invoked in order to start a timer, whereas in >> UML you do not have timer, but time constraints and time expression. This is >> slightly different in my opinion, although uml::TimeExpression and >> uml::Duration seems to be adequate to represent concrete instances of >> utp::Time(point) and utp::Duration. >>> >>> We cannot change the Timer interface to >>> >>> start(a : uml::TimeExpression)/start(d : uml::Duration) >>> >>> because TimeExpression and Duration are not types but >> ValueSpecifications. What we could do in order to align utp::Time(point) and >> utp::Duration with UML simple time concepts is to say that concrete values of >> those primitive types have to be expressed with uml::TimeExpression and >> uml::Duration ValueSpecifications. This would at least represent a clear cut >> between UML simple time (declarative layer) and UTP timer (imperative >> layer), whereas UTP is kind of an abstraction of the UML simple time >> concept. >>> >>> Anyway, no one is forced to use utp::Timer concepts, if one rather prefers >> to work with the declarative timing concepts of UML. But I would not want >> the imperative UTP timer mechanisms being removed from the spec. >>> >>> Does this make sense? >>> >>> Marc-Florian >>> >>> ################################################ >>> Marc-Florian Wendland >>> Master of Science (M.Sc.) >>> ------------------------------------------------ >>> Fraunhofer Institut FOKUS >>> Modeling und Testing Department >>> Kaiserin-Augusta-Alle 31 >>> D-10589 Berlin >>> ------------------------------------------------ >>> Tel: +49 (30) - 3463 7395 >>> Email: marc-florian.wendland@fokus.fraunhofer.de >>> ################################################ >>> >>> >>>> -----Ursprühe Nachricht----- >>>> Von: Cyril Ballagny [mailto:cyril.ballagny@softeam.fr] >>>> Gesendet: Dienstag, 24. April 2012 10:06 >>>> An: Wendland, Marc-Florian >>>> Cc: uml-testing-profile-rtf@omg.org >>>> Betreff: Time issue 17292 >>>> >>>> Hi All, >>>> >>>> I was looking at this Time issue and actually adding a Timepoint type >>>> seems to be redundant with how uml::TimeExpression is defined. >>>> Furthermore, using TimeExpression gives access to uml::Duration and >>>> uml::TimeInterval which prevents from adding an other operation to >>>> the Timer interface. >>>> IMHO, the utp::Time is not a duration but a moment, since it is >>>> explained that the difference between two Time values is a Duration and >> that the 'now' >>>> keyword represents the current time. Hence, the Time definition does >>>> not seem to be ambiguous but rather redundant with the UML time >>>> package. I would prefer merging the UTP and UML time concepts instead >>>> of adding new types. >>>> >>>> Best regards, >>>> Cyril. >>>> >>>> On 10/04/2012 16:40, Wendland, Marc-Florian wrote: >>>>> Participants: >>>>> Jon >>>>> Markus >>>>> Lulu >>>>> Marc-Florian >>>>> >>>>> Minutes: >>>>> We actually just discussed on an optimized outline for the UTP >>>>> specification. There we decided: >>>>> - to extract all non-stereotypes into a separate types packages, >>>>> which is common standard in OMG's UML profile specifications >>>>> - to incorporate a new test management chapter in the normative >>>>> section >>>>> - Please find the outcome of this discussion attached (also in the >>>>> SVN in folder /issues/17224) >>>>> - Feedback expected from all members >>>>> >>>>> SIDEMARK >>>>> - we identified a new issue, i.e. the predefined type time is not >>>>> precisely enough defined. How it is used by the timer's start >>>>> operation >>>>> (Timer::start(expire:Time)) it seems to be used as kind of a >>>>> Duration (a particular time unit that will be counted down until it >> expires). >>>>> But UTP already defined Duration, so what is the difference between >>>>> Duration and Time? >>>>> - Markus suggested (and I already filed an issue at OMG) to rename >>>>> Time to Timepoint. It semantics is that is stands for a particular >>>>> point in time where the timer expires. The concrete format of such a >>>>> timepoint is not defined and depends on the underlying OS of the >>>>> test execution system. Additionally, the Timer interface must >>>>> incorporate a second start operation with the signature >>>>> start(duration:Duration), so that the user would be able to defines >>>>> both a concrete point in time or a duration value to configure a timer. >>>>> >>>>> Marc-Florian >>>>> ################################################ >>>>> Marc-Florian Wendland >>>>> Master of Science (M.Sc.) >>>>> ------------------------------------------------ >>>>> Fraunhofer Institut FOKUS >>>>> Modeling und Testing Department >>>>> Kaiserin-Augusta-Alle 31 >>>>> D-10589 Berlin >>>>> ------------------------------------------------ >>>>> Tel: +49 (30) - 3463 7395 >>>>> Email: marc-florian.wendland@fokus.fraunhofer.de >>>>> ################################################ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> ************************************** >>>> Dr. Cyril Ballagny >>>> R&D Department >>>> Softeam, Modeliosoft, France >>>> http://www.softeam.com/ >>>> http://www.modeliosoft.com/ >>>> http://www.modelio.org/ >>>> Tel. +33 130121675 (office) >>>> ************************************** >>>> >>>> >>> >> >> -- >> Prof. Zhen Ru Dai >> University of Applied Science Hamburg >> Berliner Tor 7 >> Room 7.86 >> 20099 Hamburg >> Tel. +49-40-42875-8153 > -- Prof. Zhen Ru Dai University of Applied Science Hamburg Berliner Tor 7 Room 7.86 20099 Hamburg Tel. +49-40-42875-8153 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=A9a2oEAfkRpAxVnbSGWL9v1lXJxxNtYF/sckZxrCDUg=; b=wOf9YrvyI01AXAsGnXNmy6k5x+57dUCSr2UOpAkQPgKVAY9fMSirxCTYhgWUVo4rLV xBE/M510MZQeGWePd9E1LqqIbgO3I6/qm6QWkziyzjfFA1Wr/dIbccB8L69jDS5QS7Mw up+kE143R4taahWY9tOvino5SF2+k8+3tscNy6uJRvaRwJF7B/yeXngmYqtmy+OsI+IE TLsaLGbyuBK+/8N7tVwQCG1IG1TN/xUSR79P3PmmiNg96SiePXMqTBjE00yrqyZICVpb IP9O1vh04v/4R+XXILoJRrxNv39FSwaVxNrN9gBGP+WZjsHqrfjOz151mvLGJlPWfsZq JjvQ== Reply-To: gcarrozza@sesm.it Sender: gcarrozza@gmail.com From: Gabriella Carrozza Date: Tue, 24 Apr 2012 11:17:12 +0200 X-Google-Sender-Auth: 5fk4hiU0QjSVyQt-66DfvsF0zmA Subject: Re: Time issue 17292 To: "Prof. Zhen Ru Dai" Cc: "Wendland, Marc-Florian" , Cyril Ballagny , uml-testing-profile-rtf@omg.org To me, Using relative time is much more common and probably makes more sense gabriella -- ____________________________________________________Gabriella Carrozza, Ph.Dmobile: +39 3343404139 skype: bluegabry e-mail: gcarrozza@sesm.it http://www.gabriellacarrozza.it_________R&D Project Manager at SESM scarlStabilimento SELEX Sistemi Integrati di Giuglianovia Circumvallazione esterna di Napoli 80014 Giugliano in Campania (NA)tel:+390818180650 fax:+390818180404http://www.sesm.it---------Consorzio Interuniversitario Nazionale per l'Informatica Complesso Univ.Monte Sant'Angelo Via Cinthia, Ed.1. 80125 Napoli, ITALY http://www.consorzio-cini.it______________________________________________________ This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address. Avoid printing this message if it is not absolutely necessary. On Tue, Apr 24, 2012 at 11:10 AM, Prof. Zhen Ru Dai wrote: Hi Florian Am 24.04.2012 um 10:57 schrieb Wendland, Marc-Florian: >> But having uml::timeexpression, utp::timer and upt::timepoint would be too much > Well, currently we have utp::Time and utp::Duration which are both types. Instead of, we would have utp::Timepoint and utp::Duration. The first one would represent a particular point in time where the timer is supposed to expire, the latter one a duration the timer would count down before it expire. so upt::timepoint is an absolut time at which timer is supposed to expire. But I don't think that this is really much used in testing. Usually we define relative time starting from the setup of the test. What is the experience of the others? cheers lulu > > Utp::Duration is not use by anyone to my knowledge and as it is currently, the Duration type completely senseless. > > Utp::Time represents concrete time values (taken from UTP 1.1 spec) and is used in utp::Timer:start() to denote the expiration time of a timer. Was Markus mentioned, and I agree so far, that timer are actually started with a Duration. > > Since UTP has this declarative timer concepts, we cannot make directly use of uml::TimeExpression and uml::Duration within the Timer interface! They are not types and a parameter of an operation has to be typed by type. That was the reason, I reckon, why utp::Time and utp::Duration have been introduced in addition. > > Marc-Florian > > ################################################ > Marc-Florian Wendland > Master of Science (M.Sc.) > ------------------------------------------------ > Fraunhofer Institut FOKUS > Modeling und Testing Department > Kaiserin-Augusta-Alle 31 > D-10589 Berlin > ------------------------------------------------ > Tel: +49 (30) - 3463 7395 > Email: marc-florian.wendland@fokus.fraunhofer.de > ################################################ > > >> -----Ursprühe Nachricht----- >> Von: Prof. Zhen Ru Dai [mailto:dai@informatik.haw-hamburg.de] >> Gesendet: Dienstag, 24. April 2012 10:47 >> An: Wendland, Marc-Florian >> Cc: Cyril Ballagny; uml-testing-profile-rtf@omg.org >> Betreff: Re: Time issue 17292 >> >> Hi Florian, >> >> I think Cyrill is talking about the new timepoint concept and not the timer >> concept. >> >> The timer concept is mandatory for testing in order to catch exepetions and >> unwanted behavior. But the timepoint concept can be found in >> uml::timeexpression, I agree. Most people are confused by having both >> uml:timeexpression AND utp::timer already. But most of them understand >> after explaining that timer is an active thing, since it can trigger a timeout >> behavior. But having uml::timeexpression, utp::timer and upt::timepoint >> would be too much. What do you think? >> >> cheers >> >> Lulu >> >> >> >> Am 24.04.2012 um 10:23 schrieb Wendland, Marc-Florian: >> >>> Cyrill, >>> >>> I partially agree. >>> >>> Just be aware that the UML way of UTP way of time/timer handling is >> somewhat different. UTP has a kind of imperative concept, i.e. the operation >> of the timer interface has to be invoked in order to start a timer, whereas in >> UML you do not have timer, but time constraints and time expression. This is >> slightly different in my opinion, although uml::TimeExpression and >> uml::Duration seems to be adequate to represent concrete instances of >> utp::Time(point) and utp::Duration. >>> >>> We cannot change the Timer interface to >>> >>> start(a : uml::TimeExpression)/start(d : uml::Duration) >>> >>> because TimeExpression and Duration are not types but >> ValueSpecifications. What we could do in order to align utp::Time(point) and >> utp::Duration with UML simple time concepts is to say that concrete values of >> those primitive types have to be expressed with uml::TimeExpression and >> uml::Duration ValueSpecifications. This would at least represent a clear cut >> between UML simple time (declarative layer) and UTP timer (imperative >> layer), whereas UTP is kind of an abstraction of the UML simple time >> concept. >>> >>> Anyway, no one is forced to use utp::Timer concepts, if one rather prefers >> to work with the declarative timing concepts of UML. But I would not want >> the imperative UTP timer mechanisms being removed from the spec. >>> >>> Does this make sense? >>> >>> Marc-Florian >>> >>> ################################################ >>> Marc-Florian Wendland >>> Master of Science (M.Sc.) >>> ------------------------------------------------ >>> Fraunhofer Institut FOKUS >>> Modeling und Testing Department >>> Kaiserin-Augusta-Alle 31 >>> D-10589 Berlin >>> ------------------------------------------------ >>> Tel: +49 (30) - 3463 7395 >>> Email: marc-florian.wendland@fokus.fraunhofer.de >>> ################################################ >>> >>> >>>> -----Ursprühe Nachricht----- >>>> Von: Cyril Ballagny [mailto:cyril.ballagny@softeam.fr] >>>> Gesendet: Dienstag, 24. April 2012 10:06 >>>> An: Wendland, Marc-Florian >>>> Cc: uml-testing-profile-rtf@omg.org >>>> Betreff: Time issue 17292 >>>> >>>> Hi All, >>>> >>>> I was looking at this Time issue and actually adding a Timepoint type >>>> seems to be redundant with how uml::TimeExpression is defined. >>>> Furthermore, using TimeExpression gives access to uml::Duration and >>>> uml::TimeInterval which prevents from adding an other operation to >>>> the Timer interface. >>>> IMHO, the utp::Time is not a duration but a moment, since it is >>>> explained that the difference between two Time values is a Duration and >> that the 'now' >>>> keyword represents the current time. Hence, the Time definition does >>>> not seem to be ambiguous but rather redundant with the UML time >>>> package. I would prefer merging the UTP and UML time concepts instead >>>> of adding new types. >>>> >>>> Best regards, >>>> Cyril. >>>> >>>> On 10/04/2012 16:40, Wendland, Marc-Florian wrote: >>>>> Participants: >>>>> Jon >>>>> Markus >>>>> Lulu >>>>> Marc-Florian >>>>> >>>>> Minutes: >>>>> We actually just discussed on an optimized outline for the UTP >>>>> specification. There we decided: >>>>> - to extract all non-stereotypes into a separate types packages, >>>>> which is common standard in OMG's UML profile specifications >>>>> - to incorporate a new test management chapter in the normative >>>>> section >>>>> - Please find the outcome of this discussion attached (also in the >>>>> SVN in folder /issues/17224) >>>>> - Feedback expected from all members >>>>> >>>>> SIDEMARK >>>>> - we identified a new issue, i.e. the predefined type time is not >>>>> precisely enough defined. How it is used by the timer's start >>>>> operation >>>>> (Timer::start(expire:Time)) it seems to be used as kind of a >>>>> Duration (a particular time unit that will be counted down until it >> expires). >>>>> But UTP already defined Duration, so what is the difference between >>>>> Duration and Time? >>>>> - Markus suggested (and I already filed an issue at OMG) to rename >>>>> Time to Timepoint. It semantics is that is stands for a particular >>>>> point in time where the timer expires. The concrete format of such a >>>>> timepoint is not defined and depends on the underlying OS of the >>>>> test execution system. Additionally, the Timer interface must >>>>> incorporate a second start operation with the signature >>>>> start(duration:Duration), so that the user would be able to defines >>>>> both a concrete point in time or a duration value to configure a timer. >>>>> >>>>> Marc-Florian >>>>> ################################################ >>>>> Marc-Florian Wendland >>>>> Master of Science (M.Sc.) >>>>> ------------------------------------------------ >>>>> Fraunhofer Institut FOKUS >>>>> Modeling und Testing Department >>>>> Kaiserin-Augusta-Alle 31 >>>>> D-10589 Berlin >>>>> ------------------------------------------------ >>>>> Tel: +49 (30) - 3463 7395 >>>>> Email: marc-florian.wendland@fokus.fraunhofer.de >>>>> ################################################ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> ************************************** >>>> Dr. Cyril Ballagny >>>> R&D Department >>>> Softeam, Modeliosoft, France >>>> http://www.softeam.com/ >>>> http://www.modeliosoft.com/ >>>> http://www.modelio.org/ >>>> Tel. +33 130121675 (office) >>>> ************************************** >>>> >>>> >>> >> >> -- >> Prof. Zhen Ru Dai >> University of Applied Science Hamburg >> Berliner Tor 7 >> Room 7.86 >> 20099 Hamburg >> Tel. +49-40-42875-8153 > -- Prof. Zhen Ru Dai University of Applied Science Hamburg Berliner Tor 7 Room 7.86 20099 Hamburg Tel. +49-40-42875-8153 Subject: AW: Time issue 17292 Date: Tue, 24 Apr 2012 11:22:39 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time issue 17292 Thread-Index: Ac0h+yWP9/VgJ8EVRxev/16pERO0UwAADRbw From: "Wendland, Marc-Florian" To: , "Prof. Zhen Ru Dai" Cc: "Cyril Ballagny" , X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml-testing-profile-rtf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate04-haj2 with BCDEF794008 X-cloud-security: scantime:1.336 Yes, me too, but we should allow both; UML allows relative and absolute time expression for declarative time constraints We shall postpone this discussion to the today.s call.. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ Von: gcarrozza@gmail.com [mailto:gcarrozza@gmail.com] Im Auftrag von Gabriella Carrozza Gesendet: Dienstag, 24. April 2012 11:17 An: Prof. Zhen Ru Dai Cc: Wendland, Marc-Florian; Cyril Ballagny; uml-testing-profile-rtf@omg.org Betreff: Re: Time issue 17292 To me, Using relative time is much more common and probably makes more sense gabriella -- ____________________________________________________Gabriella Carrozza, Ph.Dmobile: +39 3343404139 skype: bluegabry e-mail: gcarrozza@sesm.it http://www.gabriellacarrozza.it_________R&D Project Manager at SESM scarlStabilimento SELEX Sistemi Integrati di Giuglianovia Circumvallazione esterna di Napoli 80014 Giugliano in Campania (NA)tel:+390818180650 fax:+390818180404http://www.sesm.it---------Consorzio Interuniversitario Nazionale per l'Informatica Complesso Univ.Monte Sant'Angelo Via Cinthia, Ed.1. 80125 Napoli, ITALY http://www.consorzio-cini.it______________________________________________________ This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address. Avoid printing this message if it is not absolutely necessary. On Tue, Apr 24, 2012 at 11:10 AM, Prof. Zhen Ru Dai wrote: Hi Florian Am 24.04.2012 um 10:57 schrieb Wendland, Marc-Florian: >> But having uml::timeexpression, utp::timer and upt::timepoint would be too much > Well, currently we have utp::Time and utp::Duration which are both types. Instead of, we would have utp::Timepoint and utp::Duration. The first one would represent a particular point in time where the timer is supposed to expire, the latter one a duration the timer would count down before it expire. so upt::timepoint is an absolut time at which timer is supposed to expire. But I don't think that this is really much used in testing. Usually we define relative time starting from the setup of the test. What is the experience of the others? cheers lulu > > Utp::Duration is not use by anyone to my knowledge and as it is currently, the Duration type completely senseless. > > Utp::Time represents concrete time values (taken from UTP 1.1 spec) and is used in utp::Timer:start() to denote the expiration time of a timer. Was Markus mentioned, and I agree so far, that timer are actually started with a Duration. > > Since UTP has this declarative timer concepts, we cannot make directly use of uml::TimeExpression and uml::Duration within the Timer interface! They are not types and a parameter of an operation has to be typed by type. That was the reason, I reckon, why utp::Time and utp::Duration have been introduced in addition. > > Marc-Florian > > ################################################ > Marc-Florian Wendland > Master of Science (M.Sc.) > ------------------------------------------------ > Fraunhofer Institut FOKUS > Modeling und Testing Department > Kaiserin-Augusta-Alle 31 > D-10589 Berlin > ------------------------------------------------ > Tel: +49 (30) - 3463 7395 > Email: marc-florian.wendland@fokus.fraunhofer.de > ################################################ > > >> -----Ursprühe Nachricht----- >> Von: Prof. Zhen Ru Dai [mailto:dai@informatik.haw-hamburg.de] >> Gesendet: Dienstag, 24. April 2012 10:47 >> An: Wendland, Marc-Florian >> Cc: Cyril Ballagny; uml-testing-profile-rtf@omg.org >> Betreff: Re: Time issue 17292 >> >> Hi Florian, >> >> I think Cyrill is talking about the new timepoint concept and not the timer >> concept. >> >> The timer concept is mandatory for testing in order to catch exepetions and >> unwanted behavior. But the timepoint concept can be found in >> uml::timeexpression, I agree. Most people are confused by having both >> uml:timeexpression AND utp::timer already. But most of them understand >> after explaining that timer is an active thing, since it can trigger a timeout >> behavior. But having uml::timeexpression, utp::timer and upt::timepoint >> would be too much. What do you think? >> >> cheers >> >> Lulu >> >> >> >> Am 24.04.2012 um 10:23 schrieb Wendland, Marc-Florian: >> >>> Cyrill, >>> >>> I partially agree. >>> >>> Just be aware that the UML way of UTP way of time/timer handling is >> somewhat different. UTP has a kind of imperative concept, i.e. the operation >> of the timer interface has to be invoked in order to start a timer, whereas in >> UML you do not have timer, but time constraints and time expression. This is >> slightly different in my opinion, although uml::TimeExpression and >> uml::Duration seems to be adequate to represent concrete instances of >> utp::Time(point) and utp::Duration. >>> >>> We cannot change the Timer interface to >>> >>> start(a : uml::TimeExpression)/start(d : uml::Duration) >>> >>> because TimeExpression and Duration are not types but >> ValueSpecifications. What we could do in order to align utp::Time(point) and >> utp::Duration with UML simple time concepts is to say that concrete values of >> those primitive types have to be expressed with uml::TimeExpression and >> uml::Duration ValueSpecifications. This would at least represent a clear cut >> between UML simple time (declarative layer) and UTP timer (imperative >> layer), whereas UTP is kind of an abstraction of the UML simple time >> concept. >>> >>> Anyway, no one is forced to use utp::Timer concepts, if one rather prefers >> to work with the declarative timing concepts of UML. But I would not want >> the imperative UTP timer mechanisms being removed from the spec. >>> >>> Does this make sense? >>> >>> Marc-Florian >>> >>> ################################################ >>> Marc-Florian Wendland >>> Master of Science (M.Sc.) >>> ------------------------------------------------ >>> Fraunhofer Institut FOKUS >>> Modeling und Testing Department >>> Kaiserin-Augusta-Alle 31 >>> D-10589 Berlin >>> ------------------------------------------------ >>> Tel: +49 (30) - 3463 7395 >>> Email: marc-florian.wendland@fokus.fraunhofer.de >>> ################################################ >>> >>> >>>> -----Ursprühe Nachricht----- >>>> Von: Cyril Ballagny [mailto:cyril.ballagny@softeam.fr] >>>> Gesendet: Dienstag, 24. April 2012 10:06 >>>> An: Wendland, Marc-Florian >>>> Cc: uml-testing-profile-rtf@omg.org >>>> Betreff: Time issue 17292 >>>> >>>> Hi All, >>>> >>>> I was looking at this Time issue and actually adding a Timepoint type >>>> seems to be redundant with how uml::TimeExpression is defined. >>>> Furthermore, using TimeExpression gives access to uml::Duration and >>>> uml::TimeInterval which prevents from adding an other operation to >>>> the Timer interface. >>>> IMHO, the utp::Time is not a duration but a moment, since it is >>>> explained that the difference between two Time values is a Duration and >> that the 'now' >>>> keyword represents the current time. Hence, the Time definition does >>>> not seem to be ambiguous but rather redundant with the UML time >>>> package. I would prefer merging the UTP and UML time concepts instead >>>> of adding new types. >>>> >>>> Best regards, >>>> Cyril. >>>> >>>> On 10/04/2012 16:40, Wendland, Marc-Florian wrote: >>>>> Participants: >>>>> Jon >>>>> Markus >>>>> Lulu >>>>> Marc-Florian >>>>> >>>>> Minutes: >>>>> We actually just discussed on an optimized outline for the UTP >>>>> specification. There we decided: >>>>> - to extract all non-stereotypes into a separate types packages, >>>>> which is common standard in OMG's UML profile specifications >>>>> - to incorporate a new test management chapter in the normative >>>>> section >>>>> - Please find the outcome of this discussion attached (also in the >>>>> SVN in folder /issues/17224) >>>>> - Feedback expected from all members >>>>> >>>>> SIDEMARK >>>>> - we identified a new issue, i.e. the predefined type time is not >>>>> precisely enough defined. How it is used by the timer's start >>>>> operation >>>>> (Timer::start(expire:Time)) it seems to be used as kind of a >>>>> Duration (a particular time unit that will be counted down until it >> expires). >>>>> But UTP already defined Duration, so what is the difference between >>>>> Duration and Time? >>>>> - Markus suggested (and I already filed an issue at OMG) to rename >>>>> Time to Timepoint. It semantics is that is stands for a particular >>>>> point in time where the timer expires. The concrete format of such a >>>>> timepoint is not defined and depends on the underlying OS of the >>>>> test execution system. Additionally, the Timer interface must >>>>> incorporate a second start operation with the signature >>>>> start(duration:Duration), so that the user would be able to defines >>>>> both a concrete point in time or a duration value to configure a timer. >>>>> >>>>> Marc-Florian >>>>> ################################################ >>>>> Marc-Florian Wendland >>>>> Master of Science (M.Sc.) >>>>> ------------------------------------------------ >>>>> Fraunhofer Institut FOKUS >>>>> Modeling und Testing Department >>>>> Kaiserin-Augusta-Alle 31 >>>>> D-10589 Berlin >>>>> ------------------------------------------------ >>>>> Tel: +49 (30) - 3463 7395 >>>>> Email: marc-florian.wendland@fokus.fraunhofer.de >>>>> ################################################ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> ************************************** >>>> Dr. Cyril Ballagny >>>> R&D Department >>>> Softeam, Modeliosoft, France >>>> http://www.softeam.com/ >>>> http://www.modeliosoft.com/ >>>> http://www.modelio.org/ >>>> Tel. +33 130121675 (office) >>>> ************************************** >>>> >>>> >>> >> >> -- >> Prof. Zhen Ru Dai >> University of Applied Science Hamburg >> Berliner Tor 7 >> Room 7.86 >> 20099 Hamburg >> Tel. +49-40-42875-8153 > -- Prof. Zhen Ru Dai University of Applied Science Hamburg Berliner Tor 7 Room 7.86 20099 Hamburg Tel. +49-40-42875-8153 Date: Tue, 24 Apr 2012 11:27:45 +0200 From: Cyril Ballagny Organization: ModelioSoft User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: "Wendland, Marc-Florian" CC: "Prof. Zhen Ru Dai" , uml-testing-profile-rtf@omg.org Subject: Re: AW: Time issue 17292 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=softeam.fr; s=MAILOUT; t=1335259666; bh=l8tnayvoajDAvJlZ3LVx6uPUkm6yfHF8xLI1XJDGyTM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=Q7j3xEfHr/umTpFfTDbDyzR2gza/0JhgVR50dqlHK2W9B2e5RAH04QSPiJexgv524 aMmA6DCcr0EIo6Lt46NITNYC2vI4kLpXGvjTpsY6MZ+QyUyp9E7IczBMpEkMqgWgqb gmlhh/hMp/M3gw9xF7ERe/otO7lf4c/b4Co9k9zs= X-DKIM: OpenDKIM Filter v2.2.2 idefix3.softeam.com 118EC63A402A X-Softeam-fr-MailScanner-ID: 118EC63A402A.A1863 X-Softeam-fr-MailScanner: Found to be clean X-Softeam-fr-MailScanner-SpamCheck: n'est pas un polluriel (inscrit sur la liste blanche), SpamAssassin (not cached, score=-1.799, requis 3.5, ALL_TRUSTED -1.80, BAYES_50 0.00) X-Softeam-fr-MailScanner-From: cyril.ballagny@softeam.fr X-Spam-Status: No I think I understand your point Marc-Florian, about the two layers you are talking about. In that case, when invoking Timer.start we can indeed give as an argument a value specification which is either a uml::time expression or a uml::duration. Hence, uml::duration is typed by utp::Duration and uml::TimeExpression is typed by utp::Time. In the semantics section of utp::timer, the example that is given is 'start timer1(now+2.0)'/ 'now + 2.0' is some kind of uml::timeExpression typed by utp::Timer in that case, right? Thus, how is specified 'now+2.0' in UML? is it a literalstring which is associated through the 'expr' link of uml::timeexpression? should the parts of the expression have to be split such as '2.0' is an instance of a utp::duration, which is specified by uml::duration whose 'expr' is a LiteralInteger? Cyril. On 24/04/2012 10:57, Wendland, Marc-Florian wrote: But having uml::timeexpression, utp::timer and upt::timepoint would be too much Well, currently we have utp::Time and utp::Duration which are both types. Instead of, we would have utp::Timepoint and utp::Duration. The first one would represent a particular point in time where the timer is supposed to expire, the latter one a duration the timer would count down before it expire. Utp::Duration is not use by anyone to my knowledge and as it is currently, the Duration type completely senseless. Utp::Time represents concrete time values (taken from UTP 1.1 spec) and is used in utp::Timer:start() to denote the expiration time of a timer. Was Markus mentioned, and I agree so far, that timer are actually started with a Duration. Since UTP has this declarative timer concepts, we cannot make directly use of uml::TimeExpression and uml::Duration within the Timer interface! They are not types and a parameter of an operation has to be typed by type. That was the reason, I reckon, why utp::Time and utp::Duration have been introduced in addition. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ -----Ursprühe Nachricht----- Von: Prof. Zhen Ru Dai [mailto:dai@informatik.haw-hamburg.de] Gesendet: Dienstag, 24. April 2012 10:47 An: Wendland, Marc-Florian Cc: Cyril Ballagny; uml-testing-profile-rtf@omg.org Betreff: Re: Time issue 17292 Hi Florian, I think Cyrill is talking about the new timepoint concept and not the timer concept. The timer concept is mandatory for testing in order to catch exepetions and unwanted behavior. But the timepoint concept can be found in uml::timeexpression, I agree. Most people are confused by having both uml:timeexpression AND utp::timer already. But most of them understand after explaining that timer is an active thing, since it can trigger a timeout behavior. But having uml::timeexpression, utp::timer and upt::timepoint would be too much. What do you think? cheers Lulu Am 24.04.2012 um 10:23 schrieb Wendland, Marc-Florian: Cyrill, I partially agree. Just be aware that the UML way of UTP way of time/timer handling is somewhat different. UTP has a kind of imperative concept, i.e. the operation of the timer interface has to be invoked in order to start a timer, whereas in UML you do not have timer, but time constraints and time expression. This is slightly different in my opinion, although uml::TimeExpression and uml::Duration seems to be adequate to represent concrete instances of utp::Time(point) and utp::Duration. We cannot change the Timer interface to start(a : uml::TimeExpression)/start(d : uml::Duration) because TimeExpression and Duration are not types but ValueSpecifications. What we could do in order to align utp::Time(point) and utp::Duration with UML simple time concepts is to say that concrete values of those primitive types have to be expressed with uml::TimeExpression and uml::Duration ValueSpecifications. This would at least represent a clear cut between UML simple time (declarative layer) and UTP timer (imperative layer), whereas UTP is kind of an abstraction of the UML simple time concept. Anyway, no one is forced to use utp::Timer concepts, if one rather prefers to work with the declarative timing concepts of UML. But I would not want the imperative UTP timer mechanisms being removed from the spec. Does this make sense? Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ -----Ursprühe Nachricht----- Von: Cyril Ballagny [mailto:cyril.ballagny@softeam.fr] Gesendet: Dienstag, 24. April 2012 10:06 An: Wendland, Marc-Florian Cc: uml-testing-profile-rtf@omg.org Betreff: Time issue 17292 Hi All, I was looking at this Time issue and actually adding a Timepoint type seems to be redundant with how uml::TimeExpression is defined. Furthermore, using TimeExpression gives access to uml::Duration and uml::TimeInterval which prevents from adding an other operation to the Timer interface. IMHO, the utp::Time is not a duration but a moment, since it is explained that the difference between two Time values is a Duration and that the 'now' keyword represents the current time. Hence, the Time definition does not seem to be ambiguous but rather redundant with the UML time package. I would prefer merging the UTP and UML time concepts instead of adding new types. Best regards, Cyril. On 10/04/2012 16:40, Wendland, Marc-Florian wrote: Participants: Jon Markus Lulu Marc-Florian Minutes: We actually just discussed on an optimized outline for the UTP specification. There we decided: - to extract all non-stereotypes into a separate types packages, which is common standard in OMG's UML profile specifications - to incorporate a new test management chapter in the normative section - Please find the outcome of this discussion attached (also in the SVN in folder /issues/17224) - Feedback expected from all members SIDEMARK - we identified a new issue, i.e. the predefined type time is not precisely enough defined. How it is used by the timer's start operation (Timer::start(expire:Time)) it seems to be used as kind of a Duration (a particular time unit that will be counted down until it expires). But UTP already defined Duration, so what is the difference between Duration and Time? - Markus suggested (and I already filed an issue at OMG) to rename Time to Timepoint. It semantics is that is stands for a particular point in time where the timer expires. The concrete format of such a timepoint is not defined and depends on the underlying OS of the test execution system. Additionally, the Timer interface must incorporate a second start operation with the signature start(duration:Duration), so that the user would be able to defines both a concrete point in time or a duration value to configure a timer. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ -- ************************************** Dr. Cyril Ballagny R&D Department Softeam, Modeliosoft, France http://www.softeam.com/ http://www.modeliosoft.com/ http://www.modelio.org/ Tel. +33 130121675 (office) ************************************** -- Prof. Zhen Ru Dai University of Applied Science Hamburg Berliner Tor 7 Room 7.86 20099 Hamburg Tel. +49-40-42875-8153 -- ************************************** Dr. Cyril Ballagny R&D Department Softeam, Modeliosoft, France http://www.softeam.com/ http://www.modeliosoft.com/ http://www.modelio.org/ Tel. +33 130121675 (office) ************************************** cyril_ballagny1.vcf Subject: AW: AW: Time issue 17292 Date: Tue, 24 Apr 2012 11:46:07 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: Time issue 17292 Thread-Index: Ac0h/KHdmCrNwN7ISVu6OBgUy6S7UwAAhLnw From: "Wendland, Marc-Florian" To: "Cyril Ballagny" Cc: "Prof. Zhen Ru Dai" , X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml-testing-profile-rtf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate02-haj2 with 3687A6EC008 X-cloud-security: scantime:.7809 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q3O9kCli007955 Cyrill, > I think I understand your point Marc-Florian, about the two layers you are > talking about. In that case, when invoking Timer.start we can indeed give as > an argument a value specification which is either a uml::time expression or a > uml::duration. Hence, uml::duration is typed by utp::Duration and > uml::TimeExpression is typed by utp::Time. Yes, exactly. This is what I wanted to say. Sounds actually quite reasonably to me, if we enforce that actual parameters for those operation have to be expressed as uml::TimeExpression and uml::Duration typed with the utp types. By doing so, we have a good alignment between UML simple time and utp timer concepts. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ > -----Ursprühe Nachricht----- > Von: Cyril Ballagny [mailto:cyril.ballagny@softeam.fr] > Gesendet: Dienstag, 24. April 2012 11:28 > An: Wendland, Marc-Florian > Cc: Prof. Zhen Ru Dai; uml-testing-profile-rtf@omg.org > Betreff: Re: AW: Time issue 17292 > > I think I understand your point Marc-Florian, about the two layers you are > talking about. In that case, when invoking Timer.start we can indeed give as > an argument a value specification which is either a uml::time expression or a > uml::duration. Hence, uml::duration is typed by utp::Duration and > uml::TimeExpression is typed by utp::Time. > > In the semantics section of utp::timer, the example that is given is 'start > timer1(now+2.0)'/ 'now + 2.0' is some kind of uml::timeExpression typed by > utp::Timer in that case, right? > Thus, how is specified 'now+2.0' in UML? is it a literalstring which is associated > through the 'expr' link of uml::timeexpression? > should the parts of the expression have to be split such as '2.0' is an instance > of a utp::duration, which is specified by uml::duration whose 'expr' is a > LiteralInteger? > > Cyril. > > On 24/04/2012 10:57, Wendland, Marc-Florian wrote: > >> But having uml::timeexpression, utp::timer and upt::timepoint would > >> be too much > > Well, currently we have utp::Time and utp::Duration which are both types. > Instead of, we would have utp::Timepoint and utp::Duration. The first one > would represent a particular point in time where the timer is supposed to > expire, the latter one a duration the timer would count down before it > expire. > > > > Utp::Duration is not use by anyone to my knowledge and as it is currently, > the Duration type completely senseless. > > > > Utp::Time represents concrete time values (taken from UTP 1.1 spec) and > is used in utp::Timer:start() to denote the expiration time of a timer. Was > Markus mentioned, and I agree so far, that timer are actually started with a > Duration. > > > > Since UTP has this declarative timer concepts, we cannot make directly use > of uml::TimeExpression and uml::Duration within the Timer interface! They > are not types and a parameter of an operation has to be typed by type. That > was the reason, I reckon, why utp::Time and utp::Duration have been > introduced in addition. > > > > Marc-Florian > > > > ################################################ > > Marc-Florian Wendland > > Master of Science (M.Sc.) > > ------------------------------------------------ > > Fraunhofer Institut FOKUS > > Modeling und Testing Department > > Kaiserin-Augusta-Alle 31 > > D-10589 Berlin > > ------------------------------------------------ > > Tel: +49 (30) - 3463 7395 > > Email: marc-florian.wendland@fokus.fraunhofer.de > > ################################################ > > > > > >> -----Ursprühe Nachricht----- > >> Von: Prof. Zhen Ru Dai [mailto:dai@informatik.haw-hamburg.de] > >> Gesendet: Dienstag, 24. April 2012 10:47 > >> An: Wendland, Marc-Florian > >> Cc: Cyril Ballagny; uml-testing-profile-rtf@omg.org > >> Betreff: Re: Time issue 17292 > >> > >> Hi Florian, > >> > >> I think Cyrill is talking about the new timepoint concept and not the > >> timer concept. > >> > >> The timer concept is mandatory for testing in order to catch > >> exepetions and unwanted behavior. But the timepoint concept can be > >> found in uml::timeexpression, I agree. Most people are confused by > >> having both uml:timeexpression AND utp::timer already. But most of > >> them understand after explaining that timer is an active thing, since > >> it can trigger a timeout behavior. But having uml::timeexpression, > >> utp::timer and upt::timepoint would be too much. What do you think? > >> > >> cheers > >> > >> Lulu > >> > >> > >> > >> Am 24.04.2012 um 10:23 schrieb Wendland, Marc-Florian: > >> > >>> Cyrill, > >>> > >>> I partially agree. > >>> > >>> Just be aware that the UML way of UTP way of time/timer handling is > >> somewhat different. UTP has a kind of imperative concept, i.e. the > >> operation of the timer interface has to be invoked in order to start > >> a timer, whereas in UML you do not have timer, but time constraints > >> and time expression. This is slightly different in my opinion, > >> although uml::TimeExpression and uml::Duration seems to be adequate > >> to represent concrete instances of > >> utp::Time(point) and utp::Duration. > >>> We cannot change the Timer interface to > >>> > >>> start(a : uml::TimeExpression)/start(d : uml::Duration) > >>> > >>> because TimeExpression and Duration are not types but > >> ValueSpecifications. What we could do in order to align > >> utp::Time(point) and utp::Duration with UML simple time concepts is > >> to say that concrete values of those primitive types have to be > >> expressed with uml::TimeExpression and uml::Duration > >> ValueSpecifications. This would at least represent a clear cut > >> between UML simple time (declarative layer) and UTP timer (imperative > >> layer), whereas UTP is kind of an abstraction of the UML simple time > concept. > >>> Anyway, no one is forced to use utp::Timer concepts, if one rather > >>> prefers > >> to work with the declarative timing concepts of UML. But I would not > >> want the imperative UTP timer mechanisms being removed from the > spec. > >>> Does this make sense? > >>> > >>> Marc-Florian > >>> > >>> ################################################ > >>> Marc-Florian Wendland > >>> Master of Science (M.Sc.) > >>> ------------------------------------------------ > >>> Fraunhofer Institut FOKUS > >>> Modeling und Testing Department > >>> Kaiserin-Augusta-Alle 31 > >>> D-10589 Berlin > >>> ------------------------------------------------ > >>> Tel: +49 (30) - 3463 7395 > >>> Email: marc-florian.wendland@fokus.fraunhofer.de > >>> ################################################ > >>> > >>> > >>>> -----Ursprühe Nachricht----- > >>>> Von: Cyril Ballagny [mailto:cyril.ballagny@softeam.fr] > >>>> Gesendet: Dienstag, 24. April 2012 10:06 > >>>> An: Wendland, Marc-Florian > >>>> Cc: uml-testing-profile-rtf@omg.org > >>>> Betreff: Time issue 17292 > >>>> > >>>> Hi All, > >>>> > >>>> I was looking at this Time issue and actually adding a Timepoint > >>>> type seems to be redundant with how uml::TimeExpression is defined. > >>>> Furthermore, using TimeExpression gives access to uml::Duration and > >>>> uml::TimeInterval which prevents from adding an other operation to > >>>> the Timer interface. > >>>> IMHO, the utp::Time is not a duration but a moment, since it is > >>>> explained that the difference between two Time values is a Duration > >>>> and > >> that the 'now' > >>>> keyword represents the current time. Hence, the Time definition > >>>> does not seem to be ambiguous but rather redundant with the UML > >>>> time package. I would prefer merging the UTP and UML time concepts > >>>> instead of adding new types. > >>>> > >>>> Best regards, > >>>> Cyril. > >>>> > >>>> On 10/04/2012 16:40, Wendland, Marc-Florian wrote: > >>>>> Participants: > >>>>> Jon > >>>>> Markus > >>>>> Lulu > >>>>> Marc-Florian > >>>>> > >>>>> Minutes: > >>>>> We actually just discussed on an optimized outline for the UTP > >>>>> specification. There we decided: > >>>>> - to extract all non-stereotypes into a separate types packages, > >>>>> which is common standard in OMG's UML profile specifications > >>>>> - to incorporate a new test management chapter in the normative > >>>>> section > >>>>> - Please find the outcome of this discussion attached (also in the > >>>>> SVN in folder /issues/17224) > >>>>> - Feedback expected from all members > >>>>> > >>>>> SIDEMARK > >>>>> - we identified a new issue, i.e. the predefined type time is not > >>>>> precisely enough defined. How it is used by the timer's start > >>>>> operation > >>>>> (Timer::start(expire:Time)) it seems to be used as kind of a > >>>>> Duration (a particular time unit that will be counted down until > >>>>> it > >> expires). > >>>>> But UTP already defined Duration, so what is the difference > >>>>> between Duration and Time? > >>>>> - Markus suggested (and I already filed an issue at OMG) to rename > >>>>> Time to Timepoint. It semantics is that is stands for a particular > >>>>> point in time where the timer expires. The concrete format of such > >>>>> a timepoint is not defined and depends on the underlying OS of the > >>>>> test execution system. Additionally, the Timer interface must > >>>>> incorporate a second start operation with the signature > >>>>> start(duration:Duration), so that the user would be able to > >>>>> defines both a concrete point in time or a duration value to configure > a timer. > >>>>> > >>>>> Marc-Florian > >>>>> ################################################ > >>>>> Marc-Florian Wendland > >>>>> Master of Science (M.Sc.) > >>>>> ------------------------------------------------ > >>>>> Fraunhofer Institut FOKUS > >>>>> Modeling und Testing Department > >>>>> Kaiserin-Augusta-Alle 31 > >>>>> D-10589 Berlin > >>>>> ------------------------------------------------ > >>>>> Tel: +49 (30) - 3463 7395 > >>>>> Email: marc-florian.wendland@fokus.fraunhofer.de > >>>>> ################################################ > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> -- > >>>> ************************************** > >>>> Dr. Cyril Ballagny > >>>> R&D Department > >>>> Softeam, Modeliosoft, France > >>>> http://www.softeam.com/ > >>>> http://www.modeliosoft.com/ > >>>> http://www.modelio.org/ > >>>> Tel. +33 130121675 (office) > >>>> ************************************** > >>>> > >>>> > >> -- > >> Prof. Zhen Ru Dai > >> University of Applied Science Hamburg Berliner Tor 7 Room 7.86 > >> 20099 Hamburg > >> Tel. +49-40-42875-8153 > > > > > > > > > -- > ************************************** > Dr. Cyril Ballagny > R&D Department > Softeam, Modeliosoft, France > http://www.softeam.com/ > http://www.modeliosoft.com/ > http://www.modelio.org/ > Tel. +33 130121675 (office) > ************************************** >