Issue 16945: Question about the Activity decomposition in Bloc Definition Diagrams (sysml-rtf) Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de) Nature: Uncategorized Issue Severity: Summary: I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a different behavior. Resolution: Revised Text: Actions taken: January 8, 2012: received issue Discussion: End of Annotations:===== ubject: Question about the Activity decomposition in Bloc Definition Diagrams Date: Sun, 8 Jan 2012 14:15:36 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about the Activity decomposition in Bloc Definition Diagrams thread-index: AczOB5vK/0jV9j+pS2+lJ1zFHZwRYw== From: "Tim Weilkiens" To: I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a different behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de te: Sun, 08 Jan 2012 08:27:19 -0500 From: "Chonoles, Michael J" Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams To: Tim Weilkiens , "sysml-rtf@omg.org" Thread-Topic: Question about the Activity decomposition in Bloc Definition Diagrams Thread-Index: AczOB5vK/0jV9j+pS2+lJ1zFHZwRYwAAY9qQ Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-08_05:2012-01-06,2012-01-08,1970-01-01 signatures=0 Tim, I also use this capability in my methodological approach . but the tools don.t automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Tim Weilkiens CC: "sysml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: Sun, 8 Jan 2012 13:17:20 -0800 Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams Thread-Topic: Question about the Activity decomposition in Bloc Definition Diagrams Thread-Index: AczOSug/ewn+8ezVTH6EZWC4DuA79A== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized I agree that there should be an association but the correspondence between CallBehaviorActions & composite part associations like those shown in Fig 11.1 needn't be 1-1. For example, an Activity A could invoke an Activity B for two distinct purposes -- p1 & p2. We can represent that with distinct composite part associations like those of Fig 11.1: A::p1 : B A::p2 : B Does this mean that there is necessarily only one CallBehaviorAction in A corresponding to A::p1 and only one CallBehaviorAction in A corresponding to A::p2? I believe this would be too restrictive. Perhaps we could use the multiplicity range of A::p1 to indicate how many distinct invocations of B are considered to be occurrences of the same functional purpose that A::p1 : B represents. This approach might fit nicely as a kind of SysML Activity extension for ontological behavior modeling per Bock & Odell: http://www.jot.fm/issues/issue_2011_01/article3.pdf - Nicolas. On Jan 8, 2012, at 5:27 AM, Chonoles, Michael J wrote: Tim, I also use this capability in my methodological approach . but the tools don.t automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de From: Matthew Hause To: "Chonoles, Michael J" , Tim Weilkiens , "sysml-rtf@omg.org" Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams Thread-Topic: Question about the Activity decomposition in Bloc Definition Diagrams Thread-Index: AczOB5vK/0jV9j+pS2+lJ1zFHZwRYwAAY9qQABQVbvA= Date: Sun, 8 Jan 2012 23:02:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [208.54.95.21] x-esetresult: clean, is OK x-esetid: F85AB8204FD84931AC1EE0 Artisan Studio automates all of this. We also do so in the UPDM profile. Sounds like you need to upgrade. From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, January 08, 2012 8:27 AM To: Tim Weilkiens; sysml-rtf@omg.org Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams Tim, I also use this capability in my methodological approach . but the tools don.t automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams From: Daniel Brookshier Date: Mon, 9 Jan 2012 02:03:12 -0500 Cc: "Chonoles, Michael J" , Tim Weilkiens , "sysml-rtf@omg.org" To: Matthew Hause X-Mailer: Apple Mail (2.1251.1) MagicDraw automates this as well. On Jan 8, 2012, at 6:02 PM, Matthew Hause wrote: Artisan Studio automates all of this. We also do so in the UPDM profile. Sounds like you need to upgrade. From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, January 08, 2012 8:27 AM To: Tim Weilkiens; sysml-rtf@omg.org Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams Tim, I also use this capability in my methodological approach . but the tools don.t automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de --------------------------------------------------------------- Daniel Brookshier Distinguished Fellow danielb@nomagic.com Office 214-291-9100 Cell 214-207-6614 Veteran-Owned Small Business Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams X-KeepSent: D3711D1D:3F9E2575-C2257980:00277B91; type=4; name=$KeepSent To: "Rouquette, Nicolas F (313K)" Cc: "Jenkins, J Steven (3101)" , "Chonoles, Michael J" , "sysml-rtf@omg.org" , Tim Weilkiens X-Mailer: Lotus Notes Release 8.5.1 FP3 May 24, 2010 From: Eldad Palachi Date: Mon, 9 Jan 2012 09:48:12 +0200 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 09/01/2012 09:49:28 x-cbid: 12010907-4966-0000-0000-000001161540 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id q097nujI002008 Few comments: It is not clear to me what the values of the compositions properties are. I understand that an instance of an activity is its execution (clearly written in the standard) but I don't think the intent of this composition means that all the activities are being executed concurrently all the time - I think it means that one activity calls the other. So what is the value of this property before and after the called activity is executed? In my opinion, if the purpose is just to visualize the call tree, we should derive the BDD from the set of the relevant ACDs and this should be pure notation without having these redundant properties representing something else (the call behaviors). This has the disadvantage of not being able to specify the BDD before the ACDs, but I don't really see a need to specify the call tree before specifying the behavior itself since to me this BDD is only a visualization or abstraction of the detailed behavioral specification. I think Nicolas point emphasis the semantic issue more - what is the meaning of the property multiplicity? what is the meaning of the rolename? To me it only strengthen the argument for not having two model elements that represent the same thing (only notations). Any thoughts? Eldad From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: 08/01/2012 11:18 PM Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams I agree that there should be an association but the correspondence between CallBehaviorActions & composite part associations like those shown in Fig 11.1 needn't be 1-1. For example, an Activity A could invoke an Activity B for two distinct purposes -- p1 & p2. We can represent that with distinct composite part associations like those of Fig 11.1: A::p1 : B A::p2 : B Does this mean that there is necessarily only one CallBehaviorAction in A corresponding to A::p1 and only one CallBehaviorAction in A corresponding to A::p2? I believe this would be too restrictive. Perhaps we could use the multiplicity range of A::p1 to indicate how many distinct invocations of B are considered to be occurrences of the same functional purpose that A::p1 : B represents. This approach might fit nicely as a kind of SysML Activity extension for ontological behavior modeling per Bock & Odell: http://www.jot.fm/issues/issue_2011_01/article3.pdf - Nicolas. On Jan 8, 2012, at 5:27 AM, Chonoles, Michael J wrote: Tim, I also use this capability in my methodological approach ­ but the tools donât automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, Björn Schneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams Date: Mon, 9 Jan 2012 09:49:24 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about the Activity decomposition in Bloc Definition Diagrams thread-index: AczOnMNKkVAkoUMGRc2T75Zo17/OWwADh0YA From: "Tim Weilkiens" To: "Daniel Brookshier" , "Matthew Hause" Cc: "Chonoles, Michael J" , Daniel, MagicDraw does not create the association between activities when you model a callbehavioraction to another activity. It creates the association relationships when using the diagram wizard for activity decomposition. It think it is strange that a diagram wizard modifies the model. Another issue is that MagicDraw does not remove the association when you remove a callbehavioraction. Anyway that.s a tool discussion. I.m interested if the sysml specification requires the association relationship. Tim From: Daniel Brookshier [mailto:danielb@nomagic.com] Sent: Monday, January 09, 2012 8:03 AM To: Matthew Hause Cc: Chonoles, Michael J; Tim Weilkiens; sysml-rtf@omg.org Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams MagicDraw automates this as well. On Jan 8, 2012, at 6:02 PM, Matthew Hause wrote: Artisan Studio automates all of this. We also do so in the UPDM profile. Sounds like you need to upgrade. From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, January 08, 2012 8:27 AM To: Tim Weilkiens; sysml-rtf@omg.org Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams Tim, I also use this capability in my methodological approach . but the tools don.t automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de --------------------------------------------------------------- Daniel Brookshier Distinguished Fellow danielb@nomagic.com Office 214-291-9100 Cell 214-207-6614 Veteran-Owned Small Business Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams Date: Mon, 9 Jan 2012 09:52:46 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about the Activity decomposition in Bloc Definition Diagrams thread-index: AczOoz2W0CuAaDTaSlW1/pwx/E+CcgACH2bw From: "Tim Weilkiens" To: "Eldad Palachi" , "Rouquette, Nicolas F (313K)" Cc: "Jenkins, J Steven (3101)" , "Chonoles, Michael J" , X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id q098qt5d004876 Eldad, good point. The important thing is the visualization of the call tree and not the properties in the model. I remember a similar discussion in this group that it is important to minimize the number of elements in the model due to quality and regulatory requirements. I think that Conrad could give us good input to our questions. He has a deep knowledge of the semantics of behavior and activity modeling. @Conrad: Are you listening? Tim -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Monday, January 09, 2012 8:48 AM To: Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org; Tim Weilkiens Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams Few comments: It is not clear to me what the values of the compositions properties are. I understand that an instance of an activity is its execution (clearly written in the standard) but I don't think the intent of this composition means that all the activities are being executed concurrently all the time - I think it means that one activity calls the other. So what is the value of this property before and after the called activity is executed? In my opinion, if the purpose is just to visualize the call tree, we should derive the BDD from the set of the relevant ACDs and this should be pure notation without having these redundant properties representing something else (the call behaviors). This has the disadvantage of not being able to specify the BDD before the ACDs, but I don't really see a need to specify the call tree before specifying the behavior itself since to me this BDD is only a visualization or abstraction of the detailed behavioral specification. I think Nicolas point emphasis the semantic issue more - what is the meaning of the property multiplicity? what is the meaning of the rolename? To me it only strengthen the argument for not having two model elements that represent the same thing (only notations). Any thoughts? Eldad From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: 08/01/2012 11:18 PM Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams I agree that there should be an association but the correspondence between CallBehaviorActions & composite part associations like those shown in Fig 11.1 needn't be 1-1. For example, an Activity A could invoke an Activity B for two distinct purposes -- p1 & p2. We can represent that with distinct composite part associations like those of Fig 11.1: A::p1 : B A::p2 : B Does this mean that there is necessarily only one CallBehaviorAction in A corresponding to A::p1 and only one CallBehaviorAction in A corresponding to A::p2? I believe this would be too restrictive. Perhaps we could use the multiplicity range of A::p1 to indicate how many distinct invocations of B are considered to be occurrences of the same functional purpose that A::p1 : B represents. This approach might fit nicely as a kind of SysML Activity extension for ontological behavior modeling per Bock & Odell: http://www.jot.fm/issues/issue_2011_01/article3.pdf - Nicolas. On Jan 8, 2012, at 5:27 AM, Chonoles, Michael J wrote: Tim, I also use this capability in my methodological approach ­ but the tools donât automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, Björn Schneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Date: Mon, 09 Jan 2012 10:20:29 -0500 From: "Chonoles, Michael J" Subject: RE: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams To: Eldad Palachi , "Rouquette, Nicolas F (313K)" Cc: "Jenkins, J Steven (3101)" , "sysml-rtf@omg.org" , Tim Weilkiens Thread-Topic: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams Thread-Index: AczOpAzkxmtS39Q6R4K5TswvXCEqqwAPR8GQ Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-09_03:2012-01-09,2012-01-09,1970-01-01 signatures=0 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id q09FLBPn020066 The importance of the activity decomposition on the BDD is not just to visualize work previously done on the activity diagram. If that is all it is, then it could be done with some of reporting script. Many system engineers actually think in a functional decomposition manner. It's considerably easier to many to determine the functionality required separately from when the functionality is applied. We consider the BDD(activity) -- Activity Diagram pair similarly to the BDD(block)-IBD pair. The IBD supplies the 'wiring' to the BDD, as does the Activity Diagram supply wiring/ordering to the BDD(Activity). In addition, the BDD(activity) allows us to show the properties, operations, ... compartments on the activity. Defining them allows us later to reference/update them later in the activity diagram to support sophisticated algorithms. Michael LMCO -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Monday, January 09, 2012 2:48 AM To: Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org; Tim Weilkiens Subject: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams Few comments: It is not clear to me what the values of the compositions properties are. I understand that an instance of an activity is its execution (clearly written in the standard) but I don't think the intent of this composition means that all the activities are being executed concurrently all the time - I think it means that one activity calls the other. So what is the value of this property before and after the called activity is executed? In my opinion, if the purpose is just to visualize the call tree, we should derive the BDD from the set of the relevant ACDs and this should be pure notation without having these redundant properties representing something else (the call behaviors). This has the disadvantage of not being able to specify the BDD before the ACDs, but I don't really see a need to specify the call tree before specifying the behavior itself since to me this BDD is only a visualization or abstraction of the detailed behavioral specification. I think Nicolas point emphasis the semantic issue more - what is the meaning of the property multiplicity? what is the meaning of the rolename? To me it only strengthen the argument for not having two model elements that represent the same thing (only notations). Any thoughts? Eldad From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: 08/01/2012 11:18 PM Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams I agree that there should be an association but the correspondence between CallBehaviorActions & composite part associations like those shown in Fig 11.1 needn't be 1-1. For example, an Activity A could invoke an Activity B for two distinct purposes -- p1 & p2. We can represent that with distinct composite part associations like those of Fig 11.1: A::p1 : B A::p2 : B Does this mean that there is necessarily only one CallBehaviorAction in A corresponding to A::p1 and only one CallBehaviorAction in A corresponding to A::p2? I believe this would be too restrictive. Perhaps we could use the multiplicity range of A::p1 to indicate how many distinct invocations of B are considered to be occurrences of the same functional purpose that A::p1 : B represents. This approach might fit nicely as a kind of SysML Activity extension for ontological behavior modeling per Bock & Odell: http://www.jot.fm/issues/issue_2011_01/article3.pdf - Nicolas. On Jan 8, 2012, at 5:27 AM, Chonoles, Michael J wrote: Tim, I also use this capability in my methodological approach ­ but the tools donât automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, Björn Schneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams Date: Mon, 9 Jan 2012 17:34:45 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about the Activity decomposition in Bloc Definition Diagrams thread-index: AczO3K+9GOWMtXhNQXiJ8ghBMl7cmgAD8+oQ From: "Tim Weilkiens" To: "Juergen Boldt" Hi Juergen! Dir auch ein gutes neues Jahr! Ja, bitte erstelle ein Issue. Danke, Tim From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, January 09, 2012 3:41 PM To: Tim Weilkiens Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams Hi Tim, soll ich hierfuer eine issue-number vergeben? ach ja, Ein Gutes Neues Jahr sollte ich auch noch wuenschen -Juergen At 08:15 AM 1/8/2012, you wrote: I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a different behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Subject: RE: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams X-KeepSent: 02935DEF:3053DB0E-C2257980:00663873; type=4; name=$KeepSent To: "Chonoles, Michael J" Cc: "Jenkins, J Steven (3101)" , "Rouquette, Nicolas F (313K)" , "sysml-rtf@omg.org" , Tim Weilkiens X-Mailer: Lotus Notes Release 8.5.1 FP3 May 24, 2010 From: Eldad Palachi Date: Mon, 9 Jan 2012 20:47:40 +0200 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 09/01/2012 20:49:01 x-cbid: 12010919-1948-0000-0000-000000972C88 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id q09J6Oup009218 Hi Michael, In the BDD-IBD pair we show the same model elements with different notations (for example composition as black diamond vs. an inner box). In the current SysML spec we have two model elements types for the same thing in the case of activities and that makes it error prone as well as open to interpretations. I think we can consider drawing lines between activities on a BDD with the meaning of call behavior actions and then show these actions on an ACD (say by drag a drop or by other tool means). Another approach is to have a stereotyped dependency between the activities and have a tag that signifies the call behavior action - this is less ideal but more consistent than using composition. Eldad From: "Chonoles, Michael J" To: Eldad Palachi/Haifa/IBM@IBMIL, "Rouquette, Nicolas F (313K)" Cc: "Jenkins, J Steven (3101)" , "sysml-rtf@omg.org" , Tim Weilkiens Date: 09/01/2012 05:21 PM Subject: RE: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams The importance of the activity decomposition on the BDD is not just to visualize work previously done on the activity diagram. If that is all it is, then it could be done with some of reporting script. Many system engineers actually think in a functional decomposition manner. It's considerably easier to many to determine the functionality required separately from when the functionality is applied. We consider the BDD (activity) -- Activity Diagram pair similarly to the BDD(block)-IBD pair. The IBD supplies the 'wiring' to the BDD, as does the Activity Diagram supply wiring/ordering to the BDD(Activity). In addition, the BDD(activity) allows us to show the properties, operations, ... compartments on the activity. Defining them allows us later to reference/update them later in the activity diagram to support sophisticated algorithms. Michael LMCO -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Monday, January 09, 2012 2:48 AM To: Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org; Tim Weilkiens Subject: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams Few comments: It is not clear to me what the values of the compositions properties are. I understand that an instance of an activity is its execution (clearly written in the standard) but I don't think the intent of this composition means that all the activities are being executed concurrently all the time - I think it means that one activity calls the other. So what is the value of this property before and after the called activity is executed? In my opinion, if the purpose is just to visualize the call tree, we should derive the BDD from the set of the relevant ACDs and this should be pure notation without having these redundant properties representing something else (the call behaviors). This has the disadvantage of not being able to specify the BDD before the ACDs, but I don't really see a need to specify the call tree before specifying the behavior itself since to me this BDD is only a visualization or abstraction of the detailed behavioral specification. I think Nicolas point emphasis the semantic issue more - what is the meaning of the property multiplicity? what is the meaning of the rolename? To me it only strengthen the argument for not having two model elements that represent the same thing (only notations). Any thoughts? Eldad From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: 08/01/2012 11:18 PM Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams I agree that there should be an association but the correspondence between CallBehaviorActions & composite part associations like those shown in Fig 11.1 needn't be 1-1. For example, an Activity A could invoke an Activity B for two distinct purposes -- p1 & p2. We can represent that with distinct composite part associations like those of Fig 11.1: A::p1 : B A::p2 : B Does this mean that there is necessarily only one CallBehaviorAction in A corresponding to A::p1 and only one CallBehaviorAction in A corresponding to A::p2? I believe this would be too restrictive. Perhaps we could use the multiplicity range of A::p1 to indicate how many distinct invocations of B are considered to be occurrences of the same functional purpose that A::p1 : B represents. This approach might fit nicely as a kind of SysML Activity extension for ontological behavior modeling per Bock & Odell: http://www.jot.fm/issues/issue_2011_01/article3.pdf - Nicolas. On Jan 8, 2012, at 5:27 AM, Chonoles, Michael J wrote: Tim, I also use this capability in my methodological approach ­ but the tools donât automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, Björn Schneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Date: Mon, 09 Jan 2012 14:02:45 -0500 From: "Chonoles, Michael J" Subject: RE: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams To: Eldad Palachi Cc: "Jenkins, J Steven (3101)" , "Rouquette, Nicolas F (313K)" , "sysml-rtf@omg.org" , Tim Weilkiens Thread-Topic: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams Thread-Index: AczPAEvY3sTD3gTxQAeHS45VYLW3WAAABu5A Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-09_06:2012-01-09,2012-01-09,1970-01-01 signatures=0 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id q09J3HPu008777 The regularity of BDD-->IBD, BDD->ACT, and BDD-PAR is quite well ingrained in SysML already. All use composition, and I believe the use of composition BDD for activities arises from UML considerations. Of course, making them the same model element with different notations makes the most sense (as with BDD->IBD) Eliminating the BDD for activities would have methodological impacts on several organizations. For one thing, it would prevent documentation of properties and behaviors for activities, that are required for sophisticated algorithms that monitor their own process. (Yes, we need to relax the minimum multiplicity to allow 0). Michael Chonoles -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Monday, January 09, 2012 1:48 PM To: Chonoles, Michael J Cc: Jenkins, J Steven (3101); Rouquette, Nicolas F (313K); sysml-rtf@omg.org; Tim Weilkiens Subject: RE: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams Hi Michael, In the BDD-IBD pair we show the same model elements with different notations (for example composition as black diamond vs. an inner box). In the current SysML spec we have two model elements types for the same thing in the case of activities and that makes it error prone as well as open to interpretations. I think we can consider drawing lines between activities on a BDD with the meaning of call behavior actions and then show these actions on an ACD (say by drag a drop or by other tool means). Another approach is to have a stereotyped dependency between the activities and have a tag that signifies the call behavior action - this is less ideal but more consistent than using composition. Eldad From: "Chonoles, Michael J" To: Eldad Palachi/Haifa/IBM@IBMIL, "Rouquette, Nicolas F (313K)" Cc: "Jenkins, J Steven (3101)" , "sysml-rtf@omg.org" , Tim Weilkiens Date: 09/01/2012 05:21 PM Subject: RE: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams The importance of the activity decomposition on the BDD is not just to visualize work previously done on the activity diagram. If that is all it is, then it could be done with some of reporting script. Many system engineers actually think in a functional decomposition manner. It's considerably easier to many to determine the functionality required separately from when the functionality is applied. We consider the BDD (activity) -- Activity Diagram pair similarly to the BDD(block)-IBD pair. The IBD supplies the 'wiring' to the BDD, as does the Activity Diagram supply wiring/ordering to the BDD(Activity). In addition, the BDD(activity) allows us to show the properties, operations, ... compartments on the activity. Defining them allows us later to reference/update them later in the activity diagram to support sophisticated algorithms. Michael LMCO -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Monday, January 09, 2012 2:48 AM To: Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org; Tim Weilkiens Subject: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams Few comments: It is not clear to me what the values of the compositions properties are. I understand that an instance of an activity is its execution (clearly written in the standard) but I don't think the intent of this composition means that all the activities are being executed concurrently all the time - I think it means that one activity calls the other. So what is the value of this property before and after the called activity is executed? In my opinion, if the purpose is just to visualize the call tree, we should derive the BDD from the set of the relevant ACDs and this should be pure notation without having these redundant properties representing something else (the call behaviors). This has the disadvantage of not being able to specify the BDD before the ACDs, but I don't really see a need to specify the call tree before specifying the behavior itself since to me this BDD is only a visualization or abstraction of the detailed behavioral specification. I think Nicolas point emphasis the semantic issue more - what is the meaning of the property multiplicity? what is the meaning of the rolename? To me it only strengthen the argument for not having two model elements that represent the same thing (only notations). Any thoughts? Eldad From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: 08/01/2012 11:18 PM Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams I agree that there should be an association but the correspondence between CallBehaviorActions & composite part associations like those shown in Fig 11.1 needn't be 1-1. For example, an Activity A could invoke an Activity B for two distinct purposes -- p1 & p2. We can represent that with distinct composite part associations like those of Fig 11.1: A::p1 : B A::p2 : B Does this mean that there is necessarily only one CallBehaviorAction in A corresponding to A::p1 and only one CallBehaviorAction in A corresponding to A::p2? I believe this would be too restrictive. Perhaps we could use the multiplicity range of A::p1 to indicate how many distinct invocations of B are considered to be occurrences of the same functional purpose that A::p1 : B represents. This approach might fit nicely as a kind of SysML Activity extension for ontological behavior modeling per Bock & Odell: http://www.jot.fm/issues/issue_2011_01/article3.pdf - Nicolas. On Jan 8, 2012, at 5:27 AM, Chonoles, Michael J wrote: Tim, I also use this capability in my methodological approach ­ but the tools donât automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, Björn Schneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Date: Mon, 09 Jan 2012 16:31:11 -0500 From: "Chonoles, Michael J" Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams To: Tim Weilkiens , Eldad Palachi , "Rouquette, Nicolas F (313K)" Cc: "Jenkins, J Steven (3101)" , "sysml-rtf@omg.org" Thread-Topic: Question about the Activity decomposition in Bloc Definition Diagrams Thread-Index: AczOoz2W0CuAaDTaSlW1/pwx/E+CcgACH2bwABqKBRA= Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-09_06:2012-01-09,2012-01-09,1970-01-01 signatures=0 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id q09LVf09022236 Many people would want to make the BDD form of activity diagram first. This is a strong methodological issue for some. Michael -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Monday, January 09, 2012 3:53 AM To: Eldad Palachi; Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org Subject: EXTERNAL: RE: Question about the Activity decomposition in Bloc Definition Diagrams Eldad, good point. The important thing is the visualization of the call tree and not the properties in the model. I remember a similar discussion in this group that it is important to minimize the number of elements in the model due to quality and regulatory requirements. I think that Conrad could give us good input to our questions. He has a deep knowledge of the semantics of behavior and activity modeling. @Conrad: Are you listening? Tim -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Monday, January 09, 2012 8:48 AM To: Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org; Tim Weilkiens Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams Few comments: It is not clear to me what the values of the compositions properties are. I understand that an instance of an activity is its execution (clearly written in the standard) but I don't think the intent of this composition means that all the activities are being executed concurrently all the time - I think it means that one activity calls the other. So what is the value of this property before and after the called activity is executed? In my opinion, if the purpose is just to visualize the call tree, we should derive the BDD from the set of the relevant ACDs and this should be pure notation without having these redundant properties representing something else (the call behaviors). This has the disadvantage of not being able to specify the BDD before the ACDs, but I don't really see a need to specify the call tree before specifying the behavior itself since to me this BDD is only a visualization or abstraction of the detailed behavioral specification. I think Nicolas point emphasis the semantic issue more - what is the meaning of the property multiplicity? what is the meaning of the rolename? To me it only strengthen the argument for not having two model elements that represent the same thing (only notations). Any thoughts? Eldad From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: 08/01/2012 11:18 PM Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams I agree that there should be an association but the correspondence between CallBehaviorActions & composite part associations like those shown in Fig 11.1 needn't be 1-1. For example, an Activity A could invoke an Activity B for two distinct purposes -- p1 & p2. We can represent that with distinct composite part associations like those of Fig 11.1: A::p1 : B A::p2 : B Does this mean that there is necessarily only one CallBehaviorAction in A corresponding to A::p1 and only one CallBehaviorAction in A corresponding to A::p2? I believe this would be too restrictive. Perhaps we could use the multiplicity range of A::p1 to indicate how many distinct invocations of B are considered to be occurrences of the same functional purpose that A::p1 : B represents. This approach might fit nicely as a kind of SysML Activity extension for ontological behavior modeling per Bock & Odell: http://www.jot.fm/issues/issue_2011_01/article3.pdf - Nicolas. On Jan 8, 2012, at 5:27 AM, Chonoles, Michael J wrote: Tim, I also use this capability in my methodological approach ­ but the tools donât automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, Björn Schneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams Date: Tue, 10 Jan 2012 08:32:06 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about the Activity decomposition in Bloc Definition Diagrams thread-index: AczOoz2W0CuAaDTaSlW1/pwx/E+CcgACH2bwABqKBRAAFNvuIA== From: "Tim Weilkiens" To: "Chonoles, Michael J" , "Eldad Palachi" , "Rouquette, Nicolas F (313K)" Cc: "Jenkins, J Steven (3101)" , X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id q0A7WcbR017916 Michael, Just to be sure that I understand you correctly: If I model a bdd with activities and composite relationships first the tool automatically must create the appropriate callbehavioractions in the model. That exactly the other direction I've requested that modeling callbehavioractions automatically creates the composite relationship. Another option could be that the composite relationship is only a notation for the callbehavioraction structure in the bdd, but is not part of the model. /Tim -----Original Message----- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Monday, January 09, 2012 10:31 PM To: Tim Weilkiens; Eldad Palachi; Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); sysml-rtf@omg.org Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams Many people would want to make the BDD form of activity diagram first. This is a strong methodological issue for some. Michael -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Monday, January 09, 2012 3:53 AM To: Eldad Palachi; Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org Subject: EXTERNAL: RE: Question about the Activity decomposition in Bloc Definition Diagrams Eldad, good point. The important thing is the visualization of the call tree and not the properties in the model. I remember a similar discussion in this group that it is important to minimize the number of elements in the model due to quality and regulatory requirements. I think that Conrad could give us good input to our questions. He has a deep knowledge of the semantics of behavior and activity modeling. @Conrad: Are you listening? Tim -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Monday, January 09, 2012 8:48 AM To: Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org; Tim Weilkiens Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams Few comments: It is not clear to me what the values of the compositions properties are. I understand that an instance of an activity is its execution (clearly written in the standard) but I don't think the intent of this composition means that all the activities are being executed concurrently all the time - I think it means that one activity calls the other. So what is the value of this property before and after the called activity is executed? In my opinion, if the purpose is just to visualize the call tree, we should derive the BDD from the set of the relevant ACDs and this should be pure notation without having these redundant properties representing something else (the call behaviors). This has the disadvantage of not being able to specify the BDD before the ACDs, but I don't really see a need to specify the call tree before specifying the behavior itself since to me this BDD is only a visualization or abstraction of the detailed behavioral specification. I think Nicolas point emphasis the semantic issue more - what is the meaning of the property multiplicity? what is the meaning of the rolename? To me it only strengthen the argument for not having two model elements that represent the same thing (only notations). Any thoughts? Eldad From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: 08/01/2012 11:18 PM Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams I agree that there should be an association but the correspondence between CallBehaviorActions & composite part associations like those shown in Fig 11.1 needn't be 1-1. For example, an Activity A could invoke an Activity B for two distinct purposes -- p1 & p2. We can represent that with distinct composite part associations like those of Fig 11.1: A::p1 : B A::p2 : B Does this mean that there is necessarily only one CallBehaviorAction in A corresponding to A::p1 and only one CallBehaviorAction in A corresponding to A::p2? I believe this would be too restrictive. Perhaps we could use the multiplicity range of A::p1 to indicate how many distinct invocations of B are considered to be occurrences of the same functional purpose that A::p1 : B represents. This approach might fit nicely as a kind of SysML Activity extension for ontological behavior modeling per Bock & Odell: http://www.jot.fm/issues/issue_2011_01/article3.pdf - Nicolas. On Jan 8, 2012, at 5:27 AM, Chonoles, Michael J wrote: Tim, I also use this capability in my methodological approach ­ but the tools donât automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, Björn Schneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Subject: RE: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams X-KeepSent: CD30D3E9:68F3669F-C2257981:0039A556; type=4; name=$KeepSent To: Phil Astle Cc: "Jenkins, J Steven (3101)" , "Chonoles, Michael J" , "Rouquette, Nicolas F (313K)" , "sysml-rtf@omg.org" , Tim Weilkiens X-Mailer: Lotus Notes Release 8.5.1 FP3 May 24, 2010 From: Eldad Palachi Date: Tue, 10 Jan 2012 12:32:42 +0200 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 10/01/2012 12:34:00 x-cbid: 12011010-8372-0000-0000-00000150D576 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id q0AAYVs5027019 Good question ! For all I know we can define any notation we like, although some may claim that using the same notation as composition might be confusing. I prefer if we use the same notation as composition or some other line to represent CBA than having a composition representing CBA. Eldad From: Phil Astle To: Eldad Palachi/Haifa/IBM@IBMIL, "Chonoles, Michael J" Cc: "Jenkins, J Steven (3101)" , "Rouquette, Nicolas F (313K)" , "sysml-rtf@omg.org" , Tim Weilkiens Date: 10/01/2012 12:19 PM Subject: RE: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams Hi all, I've been following this thread for a while now and thought I'd chip in a question. Is there any reason why SysML couldn't define that the composite notation could be used on BDD to represent a CBA between two Activities without having an association? I.e. a Composition symbol attached to a CBA dictionary item. I've always struggled to see the value of having an actual Association between two Activities - the CBA seems like the more important and relevant element... Phil -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: 09 January 2012 18:48 To: Chonoles, Michael J Cc: Jenkins, J Steven (3101); Rouquette, Nicolas F (313K); sysml-rtf@omg.org; Tim Weilkiens Subject: RE: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams Hi Michael, In the BDD-IBD pair we show the same model elements with different notations (for example composition as black diamond vs. an inner box). In the current SysML spec we have two model elements types for the same thing in the case of activities and that makes it error prone as well as open to interpretations. I think we can consider drawing lines between activities on a BDD with the meaning of call behavior actions and then show these actions on an ACD (say by drag a drop or by other tool means). Another approach is to have a stereotyped dependency between the activities and have a tag that signifies the call behavior action - this is less ideal but more consistent than using composition. Eldad From: "Chonoles, Michael J" To: Eldad Palachi/Haifa/IBM@IBMIL, "Rouquette, Nicolas F (313K)" Cc: "Jenkins, J Steven (3101)" , "sysml-rtf@omg.org" , Tim Weilkiens Date: 09/01/2012 05:21 PM Subject: RE: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams The importance of the activity decomposition on the BDD is not just to visualize work previously done on the activity diagram. If that is all it is, then it could be done with some of reporting script. Many system engineers actually think in a functional decomposition manner. It's considerably easier to many to determine the functionality required separately from when the functionality is applied. We consider the BDD (activity) -- Activity Diagram pair similarly to the BDD(block)-IBD pair. The IBD supplies the 'wiring' to the BDD, as does the Activity Diagram supply wiring/ordering to the BDD(Activity). In addition, the BDD(activity) allows us to show the properties, operations, ... compartments on the activity. Defining them allows us later to reference/update them later in the activity diagram to support sophisticated algorithms. Michael LMCO -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Monday, January 09, 2012 2:48 AM To: Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org; Tim Weilkiens Subject: EXTERNAL: Re: Question about the Activity decomposition in Bloc Definition Diagrams Few comments: It is not clear to me what the values of the compositions properties are. I understand that an instance of an activity is its execution (clearly written in the standard) but I don't think the intent of this composition means that all the activities are being executed concurrently all the time - I think it means that one activity calls the other. So what is the value of this property before and after the called activity is executed? In my opinion, if the purpose is just to visualize the call tree, we should derive the BDD from the set of the relevant ACDs and this should be pure notation without having these redundant properties representing something else (the call behaviors). This has the disadvantage of not being able to specify the BDD before the ACDs, but I don't really see a need to specify the call tree before specifying the behavior itself since to me this BDD is only a visualization or abstraction of the detailed behavioral specification. I think Nicolas point emphasis the semantic issue more - what is the meaning of the property multiplicity? what is the meaning of the rolename? To me it only strengthen the argument for not having two model elements that represent the same thing (only notations). Any thoughts? Eldad From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: 08/01/2012 11:18 PM Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams I agree that there should be an association but the correspondence between CallBehaviorActions & composite part associations like those shown in Fig 11.1 needn't be 1-1. For example, an Activity A could invoke an Activity B for two distinct purposes -- p1 & p2. We can represent that with distinct composite part associations like those of Fig 11.1: A::p1 : B A::p2 : B Does this mean that there is necessarily only one CallBehaviorAction in A corresponding to A::p1 and only one CallBehaviorAction in A corresponding to A::p2? I believe this would be too restrictive. Perhaps we could use the multiplicity range of A::p1 to indicate how many distinct invocations of B are considered to be occurrences of the same functional purpose that A::p1 : B represents. This approach might fit nicely as a kind of SysML Activity extension for ontological behavior modeling per Bock & Odell: http://www.jot.fm/issues/issue_2011_01/article3.pdf - Nicolas. On Jan 8, 2012, at 5:27 AM, Chonoles, Michael J wrote: Tim, I also use this capability in my methodological approach ­ but the tools donât automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, Björn Schneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de __________ Information from ESET NOD32 Antivirus, version of virus signature database 6779 (20120109) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6780 (20120109) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com Date: Tue, 10 Jan 2012 23:06:01 -0500 From: "Chonoles, Michael J" Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams To: Tim Weilkiens , Eldad Palachi , "Rouquette, Nicolas F (313K)" Cc: "Jenkins, J Steven (3101)" , "sysml-rtf@omg.org" Thread-Topic: Question about the Activity decomposition in Bloc Definition Diagrams Thread-Index: AczOoz2W0CuAaDTaSlW1/pwx/E+CcgACH2bwABqKBRAAFNvuIAArBdBg Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-10_05:2012-01-10,2012-01-10,1970-01-01 signatures=0 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id q0B46aqP008175 Hmm, I'd like the tool to work both ways, because under some circumstances either diagram would be first. And they should be consistent. Now, I'm probably ok if the composition is only just another notation for the CBA. That would certainly reduce model-element pollution, though I'm trying to visualize how/where the browsers would represent the relationship. If we use two notations for one underlying relationship (CBA) how would a typical browser represent this. MJC -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, January 10, 2012 2:32 AM To: Chonoles, Michael J; Eldad Palachi; Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); sysml-rtf@omg.org Subject: EXTERNAL: RE: Question about the Activity decomposition in Bloc Definition Diagrams Michael, Just to be sure that I understand you correctly: If I model a bdd with activities and composite relationships first the tool automatically must create the appropriate callbehavioractions in the model. That exactly the other direction I've requested that modeling callbehavioractions automatically creates the composite relationship. Another option could be that the composite relationship is only a notation for the callbehavioraction structure in the bdd, but is not part of the model. /Tim -----Original Message----- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Monday, January 09, 2012 10:31 PM To: Tim Weilkiens; Eldad Palachi; Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); sysml-rtf@omg.org Subject: RE: Question about the Activity decomposition in Bloc Definition Diagrams Many people would want to make the BDD form of activity diagram first. This is a strong methodological issue for some. Michael -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Monday, January 09, 2012 3:53 AM To: Eldad Palachi; Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org Subject: EXTERNAL: RE: Question about the Activity decomposition in Bloc Definition Diagrams Eldad, good point. The important thing is the visualization of the call tree and not the properties in the model. I remember a similar discussion in this group that it is important to minimize the number of elements in the model due to quality and regulatory requirements. I think that Conrad could give us good input to our questions. He has a deep knowledge of the semantics of behavior and activity modeling. @Conrad: Are you listening? Tim -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Monday, January 09, 2012 8:48 AM To: Rouquette, Nicolas F (313K) Cc: Jenkins, J Steven (3101); Chonoles, Michael J; sysml-rtf@omg.org; Tim Weilkiens Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams Few comments: It is not clear to me what the values of the compositions properties are. I understand that an instance of an activity is its execution (clearly written in the standard) but I don't think the intent of this composition means that all the activities are being executed concurrently all the time - I think it means that one activity calls the other. So what is the value of this property before and after the called activity is executed? In my opinion, if the purpose is just to visualize the call tree, we should derive the BDD from the set of the relevant ACDs and this should be pure notation without having these redundant properties representing something else (the call behaviors). This has the disadvantage of not being able to specify the BDD before the ACDs, but I don't really see a need to specify the call tree before specifying the behavior itself since to me this BDD is only a visualization or abstraction of the detailed behavioral specification. I think Nicolas point emphasis the semantic issue more - what is the meaning of the property multiplicity? what is the meaning of the rolename? To me it only strengthen the argument for not having two model elements that represent the same thing (only notations). Any thoughts? Eldad From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Tim Weilkiens Cc: "sysml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: 08/01/2012 11:18 PM Subject: Re: Question about the Activity decomposition in Bloc Definition Diagrams I agree that there should be an association but the correspondence between CallBehaviorActions & composite part associations like those shown in Fig 11.1 needn't be 1-1. For example, an Activity A could invoke an Activity B for two distinct purposes -- p1 & p2. We can represent that with distinct composite part associations like those of Fig 11.1: A::p1 : B A::p2 : B Does this mean that there is necessarily only one CallBehaviorAction in A corresponding to A::p1 and only one CallBehaviorAction in A corresponding to A::p2? I believe this would be too restrictive. Perhaps we could use the multiplicity range of A::p1 to indicate how many distinct invocations of B are considered to be occurrences of the same functional purpose that A::p1 : B represents. This approach might fit nicely as a kind of SysML Activity extension for ontological behavior modeling per Bock & Odell: http://www.jot.fm/issues/issue_2011_01/article3.pdf - Nicolas. On Jan 8, 2012, at 5:27 AM, Chonoles, Michael J wrote: Tim, I also use this capability in my methodological approach ­ but the tools donât automate it yet. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, January 08, 2012 8:16 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Question about the Activity decomposition in Bloc Definition Diagrams I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a diff erent behavior. /Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, Björn Schneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 4 1 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de