Issue 11410: simpleTime package problems (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: We are experiencing problems with elements of simpleTime Package. TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package. If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds). Resolution: Revised Text: Actions taken: September 14, 2007: received issue Discussion: End of Annotations:===== m: "Nerijus Jankevicius" To: Subject: simpleTime package problems Date: Fri, 14 Sep 2007 17:51:40 +0300 X-Mailer: Microsoft Windows Mail 6.0.6000.16480 Hello, We are experiencing problems with elements of simpleTime Package. TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package. If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds). We insist to define new compositions between Behavior and these elements. Have someone arguments against such metamodel changes? Regards, -- Nerijus Jankevicius Senior System Analyst OMG-Certified UML Professional No Magic Lithuanian Development Center Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! X-Scan-Server: spamd03.cc.umr.edu X-Scan-Recipient: outbound@msx.umr.edu X-Spam-Virus: No X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on spamd03.cc.umr.edu X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE autolearn=disabled version=3.2.3 Subject: RE: simpleTime package problems Date: Fri, 14 Sep 2007 10:55:40 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: simpleTime package problems Thread-Index: Acf2355pUeKMoku0S4K0fhhb3xLYswAByLmA From: "Weigert, Thomas" To: "Nerijus Jankevicius" , X-OriginalArrivalTime: 14 Sep 2007 15:55:41.0681 (UTC) FILETIME=[B3BE2610:01C7F6E7] First, it is not quite correct to say that these do not have owners. TimeEvent and Observation are PackagableElements. TimeExpression and Duration are a ValueSpecifications. As such, they all have defined owners (namely the package that contains them). I believe your concern is that you would prefer a different owner. Let me just comment on TimeEvent right now. TimeEvent is just like the other events that we had a long discussion on who should own these. Note that events are typically referenced from Triggers (which in turn are owned by a behavior). So first we thought it might be best for that behavior to own the Event also (which is what you suggest below). However, it turns out that events are often used beyond a single behavior, e.g., so in the end we decided to put the event in some package (they are packagable elements). This equally applies to TimeEvent. Cheers, Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, September 14, 2007 9:52 AM To: uml2-rtf@omg.org Subject: simpleTime package problems Hello, We are experiencing problems with elements of simpleTime Package. TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package. If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds). We insist to define new compositions between Behavior and these elements. Have someone arguments against such metamodel changes? From: "Nerijus Jankevicius" To: "Weigert, Thomas" , Subject: Re: simpleTime package problems Date: Mon, 17 Sep 2007 11:05:49 +0300 X-Mailer: Microsoft Windows Mail 6.0.6000.16480 Thomas, You are right, ownership of events was discussed before (however solution is not satisfying, I'm not sure MessageEvents are reusable), but how about all other elements? Do you think they could be reused in several behaviors also? Thanks, Nerijus ----- Original Message ----- From: Weigert, Thomas To: Nerijus Jankevicius ; uml2-rtf@omg.org Sent: Friday, September 14, 2007 6:55 PM Subject: RE: simpleTime package problems First, it is not quite correct to say that these do not have owners. TimeEvent and Observation are PackagableElements. TimeExpression and Duration are a ValueSpecifications. As such, they all have defined owners (namely the package that contains them). I believe your concern is that you would prefer a different owner. Let me just comment on TimeEvent right now. TimeEvent is just like the other events that we had a long discussion on who should own these. Note that events are typically referenced from Triggers (which in turn are owned by a behavior). So first we thought it might be best for that behavior to own the Event also (which is what you suggest below). However, it turns out that events are often used beyond a single behavior, e.g., so in the end we decided to put the event in some package (they are packagable elements). This equally applies to TimeEvent. Cheers, Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, September 14, 2007 9:52 AM To: uml2-rtf@omg.org Subject: simpleTime package problems Hello, We are experiencing problems with elements of simpleTime Package. TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package. If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds). We insist to define new compositions between Behavior and these elements. Have someone arguments against such metamodel changes? X-Scan-Server: spamd01.cc.umr.edu X-Scan-Recipient: outbound@msx.umr.edu X-Spam-Virus: No X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on spamd01.cc.umr.edu X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE autolearn=disabled version=3.2.3 Subject: RE: simpleTime package problems Date: Mon, 17 Sep 2007 08:58:14 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: simpleTime package problems Thread-Index: Acf5Ado1NibYjNoeRVmywgSSQ3nsvQAMFlUQ From: "Weigert, Thomas" To: "Nerijus Jankevicius" , X-OriginalArrivalTime: 17 Sep 2007 13:58:16.0441 (UTC) FILETIME=[CBB11690:01C7F932] Nerijus, First, please involve Oystein Haugen in this discussion, as he is the primary person responsible for the SimpleTime package. Secondly, it appears to me that there are many such situations throughout the model where the ultimate owner of a model element ends up to be a package. Why is this an issue only with the 4 elements listed below? In general, I think that it would be somewhat unnatural for Behavior to have ownership over value expressions that are used somewhere inside of it. Then you give the behavior package functionality. We have tried to have properties of model elements only in a way that makes sense for that model element. A property .ElementsFromSimpleTimeNotOwnedByAnybodyElse. would not be a very sensible one, I fear. Cheers, Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Monday, September 17, 2007 3:06 AM To: Weigert, Thomas; uml2-rtf@omg.org Subject: Re: simpleTime package problems Thomas, You are right, ownership of events was discussed before (however solution is not satisfying, I'm not sure MessageEvents are reusable), but how about all other elements? Do you think they could be reused in several behaviors also? Thanks, Nerijus ----- Original Message ----- From: Weigert, Thomas To: Nerijus Jankevicius ; uml2-rtf@omg.org Sent: Friday, September 14, 2007 6:55 PM Subject: RE: simpleTime package problems First, it is not quite correct to say that these do not have owners. TimeEvent and Observation are PackagableElements. TimeExpression and Duration are a ValueSpecifications. As such, they all have defined owners (namely the package that contains them). I believe your concern is that you would prefer a different owner. Let me just comment on TimeEvent right now. TimeEvent is just like the other events that we had a long discussion on who should own these. Note that events are typically referenced from Triggers (which in turn are owned by a behavior). So first we thought it might be best for that behavior to own the Event also (which is what you suggest below). However, it turns out that events are often used beyond a single behavior, e.g., so in the end we decided to put the event in some package (they are packagable elements). This equally applies to TimeEvent. Cheers, Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, September 14, 2007 9:52 AM To: uml2-rtf@omg.org Subject: simpleTime package problems Hello, We are experiencing problems with elements of simpleTime Package. TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package. If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds). We insist to define new compositions between Behavior and these elements. Have someone arguments against such metamodel changes? From: "Nerijus Jankevicius" To: "Weigert, Thomas" , Cc: Subject: Re: simpleTime package problems Date: Mon, 17 Sep 2007 18:03:44 +0300 X-Mailer: Microsoft Windows Mail 6.0.6000.16480 Thomas, we are tool makers and we write about the issues that cause most problems to implementation. So this is why those 4 elements are discussed now. Don't worry, there will be more later. Elements like observations and constraints are used in context of concrete Interaction, so they must be part of this Interaction, so you could move or delete all such elements together with Interaction. I know that you have tried a lot to make UML 2 a very good spec, but we, again as tool vendors, see a lot of problems. Honestly, it's hard to find most buggy standard. From your answers I'm not sure you understand the problems. I would like to suggest to try model something real and maybe you will see real-world problems soon. Try to use templates for example :) If you are responding to emails, I expect more constructive answer, not only "it is how it is and will not be changed, because we've already spent lots of time to make this unusable". We need practical solutions, not only academical contemplations and fears. UML standard must be rational and implementable, this is what we (tool vendors) and our customers (real world architects and engineers) need. If OMG does not care about it, I want to hear that loud and clear. Regards, -- Nerijus Jankevicius Senior System Analyst OMG-Certified UML Professional No Magic Lithuanian Development Center Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Weigert, Thomas To: Nerijus Jankevicius ; uml2-rtf@omg.org Sent: Monday, September 17, 2007 4:58 PM Subject: RE: simpleTime package problems Nerijus, First, please involve Oystein Haugen in this discussion, as he is the primary person responsible for the SimpleTime package. Secondly, it appears to me that there are many such situations throughout the model where the ultimate owner of a model element ends up to be a package. Why is this an issue only with the 4 elements listed below? In general, I think that it would be somewhat unnatural for Behavior to have ownership over value expressions that are used somewhere inside of it. Then you give the behavior package functionality. We have tried to have properties of model elements only in a way that makes sense for that model element. A property .ElementsFromSimpleTimeNotOwnedByAnybodyElse. would not be a very sensible one, I fear. Cheers, Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Monday, September 17, 2007 3:06 AM To: Weigert, Thomas; uml2-rtf@omg.org Subject: Re: simpleTime package problems Thomas, You are right, ownership of events was discussed before (however solution is not satisfying, I'm not sure MessageEvents are reusable), but how about all other elements? Do you think they could be reused in several behaviors also? Thanks, Nerijus ----- Original Message ----- From: Weigert, Thomas To: Nerijus Jankevicius ; uml2-rtf@omg.org Sent: Friday, September 14, 2007 6:55 PM Subject: RE: simpleTime package problems First, it is not quite correct to say that these do not have owners. TimeEvent and Observation are PackagableElements. TimeExpression and Duration are a ValueSpecifications. As such, they all have defined owners (namely the package that contains them). I believe your concern is that you would prefer a different owner. Let me just comment on TimeEvent right now. TimeEvent is just like the other events that we had a long discussion on who should own these. Note that events are typically referenced from Triggers (which in turn are owned by a behavior). So first we thought it might be best for that behavior to own the Event also (which is what you suggest below). However, it turns out that events are often used beyond a single behavior, e.g., so in the end we decided to put the event in some package (they are packagable elements). This equally applies to TimeEvent. Cheers, Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, September 14, 2007 9:52 AM To: uml2-rtf@omg.org Subject: simpleTime package problems Hello, We are experiencing problems with elements of simpleTime Package. TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package. If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds). We insist to define new compositions between Behavior and these elements. Have someone arguments against such metamodel changes? X-Scan-Server: spamd01.cc.umr.edu X-Scan-Recipient: outbound@msx.umr.edu X-Spam-Virus: No X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on spamd01.cc.umr.edu X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE autolearn=disabled version=3.2.3 Subject: RE: simpleTime package problems Date: Mon, 17 Sep 2007 11:15:38 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: simpleTime package problems Thread-Index: Acf5P/uNKB3AnP59RimyPhsSrP9tjQAAzMTA From: "Weigert, Thomas" To: "Nerijus Jankevicius" , Cc: X-OriginalArrivalTime: 17 Sep 2007 16:15:40.0145 (UTC) FILETIME=[FD527E10:01C7F945] Nerijus, The rule that we adhere to is roughly as follows: Model elements need to be owned by another model element which has a semantic relation to that model element. If there is no such element, than model elements should be owned by the closest enclosing package. One consequence of this rule is that sometimes packages have a lot of elements in them (they become a grab bag of unrelated elements) in addition to the classifiers defined in the package. There are tool solutions to this such as using mechanisms of the class browser to categorize model elements so that the many small model elements are kept out of sight. However, one should analyze, as you suggest, whether there are sensible owners of such model elements. However, these have to be semantically meaningful ownership relations, otherwise we merely distribute the problem throughout the model. Personally, I am not convinced by the reuse argument that I listed below, but nevertheless, that was the decision of the process of building the specification which was a multi-year effort and involved many compromises. I am offering this as an explanation of the current situation. If you have sensible ownership relations to propose for below examples (TimeExpression, Duration, TimeEvent and Observation) I am sure that can be discussed. The emphasis is on that the relation must make sense. Behavior is an unlikely candidate, however. I could see of having for example Observation owned by TimeExpression and Duration. Duration could be owned by DurationInterval, and probably TimeExpression should then also be. By the way, TimeExpression is owned by TimeEvent, so you should take that off your list. In that case, you are left with TimeEvent. To tackle that one you would have to tackle the general question of whether events should be owned by their triggers or whether they should stand alone. That will be a long discussion, I fear. Anyway, I hope I have given you some food for thought. Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Monday, September 17, 2007 10:04 AM To: Weigert, Thomas; uml2-rtf@omg.org Cc: oysteinh@ifi.uio.no Subject: Re: simpleTime package problems we are tool makers and we write about the issues that cause most problems to implementation. So this is why those 4 elements are discussed now. Don't worry, there will be more later. Elements like observations and constraints are used in context of concrete Interaction, so they must be part of this Interaction, so you could move or delete all such elements together with Interaction. ----- Original Message ----- From: Weigert, Thomas To: Nerijus Jankevicius ; uml2-rtf@omg.org Sent: Monday, September 17, 2007 4:58 PM Subject: RE: simpleTime package problems In general, I think that it would be somewhat unnatural for Behavior to have ownership over value expressions that are used somewhere inside of it. Then you give the behavior package functionality. We have tried to have properties of model elements only in a way that makes sense for that model element. A property .ElementsFromSimpleTimeNotOwnedByAnybodyElse. would not be a very sensible one, I fear. Cheers, Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Monday, September 17, 2007 3:06 AM To: Weigert, Thomas; uml2-rtf@omg.org Subject: Re: simpleTime package problems Thomas, You are right, ownership of events was discussed before (however solution is not satisfying, I'm not sure MessageEvents are reusable), but how about all other elements? Do you think they could be reused in several behaviors also? Thanks, Nerijus ----- Original Message ----- From: Weigert, Thomas To: Nerijus Jankevicius ; uml2-rtf@omg.org Sent: Friday, September 14, 2007 6:55 PM Subject: RE: simpleTime package problems I believe your concern is that you would prefer a different owner. Let me just comment on TimeEvent right now. TimeEvent is just like the other events that we had a long discussion on who should own these. Note that events are typically referenced from Triggers (which in turn are owned by a behavior). So first we thought it might be best for that behavior to own the Event also (which is what you suggest below). However, it turns out that events are often used beyond a single behavior, e.g., so in the end we decided to put the event in some package (they are packagable elements). This equally applies to TimeEvent. Cheers, Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, September 14, 2007 9:52 AM To: uml2-rtf@omg.org Subject: simpleTime package problems Hello, We are experiencing problems with elements of simpleTime Package. TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package. If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds). We insist to define new compositions between Behavior and these elements. Have someone arguments against such metamodel changes? Subject: RE: simpleTime package problems Date: Mon, 17 Sep 2007 12:34:23 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: simpleTime package problems thread-index: Acf5PYxpr1HZFiJPQ6W1bGVtsdcsMwACcQgQ From: "Frank, Karl (Mission Systems)" To: "Nerijus Jankevicius" , "Weigert, Thomas" , Cc: X-OriginalArrivalTime: 17 Sep 2007 16:34:23.0588 (UTC) FILETIME=[9AF24A40:01C7F948] As a former architect with a tool vendor and now on user side with embedded systems (hence triggers/events issues), some observations. I appreciate the importance of the containment hiearchy in tool architeture, (this was one of the important points that Nerijus raised wrt Diagrams, that they needed to find a place in the containment hierarchy). Making the owner of Events a package has the unpleasant effect of their being syntactically permissable ANYWHERE, and I suspect that this is at least part of what is troubling the MagicDraw folk, it would trouble anyone trying to design a tool to support the abstract syntax. But the reusability of Events relative to different behaviors is a worthy goal also, and that is the motivation for making them simply packageable elements. I was at the meeting when we discussed and agreed the inclusion of Triggers and Events as distinct modeling elements, with Events as packageable. The (imo reasonable) pragmatic was that Events modeled the external happenings which, through Triggers, drove transitions, and that introducing Triggers as a layer of indirection between behavior and Events was to enable the same Event to represent an aspect of the problem domain, which could be reused in relation to different behaviors, using a Trigger as the connecting element. The question then is, is this approach not in fact as useful as it seemed when it was agreed? Nerjius seems to have some problem case in mind which it could be helpful if he explained in more detail. Cordially yours, Karl Frank General Scientist, Mission Systems Northrop-Grumman Corporation GMT-5 (EDT, EST) cell: +1 978 853 3592 -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Monday, September 17, 2007 11:04 AM To: Weigert, Thomas; uml2-rtf@omg.org Cc: oysteinh@ifi.uio.no Subject: Re: simpleTime package problems Thomas, we are tool makers and we write about the issues that cause most problems to implementation. So this is why those 4 elements are discussed now. Don't worry, there will be more later. Elements like observations and constraints are used in context of concrete Interaction, so they must be part of this Interaction, so you could move or delete all such elements together with Interaction. I know that you have tried a lot to make UML 2 a very good spec, but we, again as tool vendors, see a lot of problems. Honestly, it's hard to find most buggy standard. From your answers I'm not sure you understand the problems. I would like to suggest to try model something real and maybe you will see real-world problems soon. Try to use templates for example :) If you are responding to emails, I expect more constructive answer, not only "it is how it is and will not be changed, because we've already spent lots of time to make this unusable". We need practical solutions, not only academical contemplations and fears. UML standard must be rational and implementable, this is what we (tool vendors) and our customers (real world architects and engineers) need. If OMG does not care about it, I want to hear that loud and clear. Regards, -- Nerijus Jankevicius Senior System Analyst OMG-Certified UML Professional No Magic Lithuanian Development Center Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Weigert, Thomas To: Nerijus Jankevicius ; uml2-rtf@omg.org Sent: Monday, September 17, 2007 4:58 PM Subject: RE: simpleTime package problems Nerijus, First, please involve Oystein Haugen in this discussion, as he is the primary person responsible for the SimpleTime package. Secondly, it appears to me that there are many such situations throughout the model where the ultimate owner of a model element ends up to be a package. Why is this an issue only with the 4 elements listed below? In general, I think that it would be somewhat unnatural for Behavior to have ownership over value expressions that are used somewhere inside of it. Then you give the behavior package functionality. We have tried to have properties of model elements only in a way that makes sense for that model element. A property .ElementsFromSimpleTimeNotOwnedByAnybodyElse. would not be a very sensible one, I fear. Cheers, Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Monday, September 17, 2007 3:06 AM To: Weigert, Thomas; uml2-rtf@omg.org Subject: Re: simpleTime package problems Thomas, You are right, ownership of events was discussed before (however solution is not satisfying, I'm not sure MessageEvents are reusable), but how about all other elements? Do you think they could be reused in several behaviors also? Thanks, Nerijus ----- Original Message ----- From: Weigert, Thomas To: Nerijus Jankevicius ; uml2-rtf@omg.org Sent: Friday, September 14, 2007 6:55 PM Subject: RE: simpleTime package problems First, it is not quite correct to say that these do not have owners. TimeEvent and Observation are PackagableElements. TimeExpression and Duration are a ValueSpecifications. As such, they all have defined owners (namely the package that contains them). I believe your concern is that you would prefer a different owner. Let me just comment on TimeEvent right now. TimeEvent is just like the other events that we had a long discussion on who should own these. Note that events are typically referenced from Triggers (which in turn are owned by a behavior). So first we thought it might be best for that behavior to own the Event also (which is what you suggest below). However, it turns out that events are often used beyond a single behavior, e.g., so in the end we decided to put the event in some package (they are packagable elements). This equally applies to TimeEvent. Cheers, Th. -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, September 14, 2007 9:52 AM To: uml2-rtf@omg.org Subject: simpleTime package problems Hello, We are experiencing problems with elements of simpleTime Package. TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package. If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds). We insist to define new compositions between Behavior and these elements. Have someone arguments against such metamodel changes?