Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » Activities in block definition diagrams(To be or not to be?)
Activities in block definition diagrams [message #1154389] Fri, 25 October 2013 02:57 Go to next message
Tomas Sandkvist is currently offline Tomas Sandkvist
Messages: 101
Registered: October 2013
Senior Member
When reading the OMG standard as well as the book A practical guide to SysML, placing activity elements in a BDD seems valid. However this is not possible in Papyrus.

Is this because it is an interpretation issue, the OMG standard might be read as if an «activity» block is just a specialization of «block» and that is why it is not possible in Papyrus? (That is, I have to create that specialization by myself)

Or is this a planned feature for the future?

Regards,
Tomas Sandkvist
Re: Activities in block definition diagrams [message #1156812 is a reply to message #1154389] Sat, 26 October 2013 17:15 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Hi Tomas,

Tomas Sandkvist wrote on Fri, 25 October 2013 02:57
When reading the OMG standard as well as the book A practical guide to SysML, placing activity elements in a BDD seems valid. However this is not possible in Papyrus.


Could you point to the section in the SysML standard where this is stated?

Quote:

Is this because it is an interpretation issue, the OMG standard might be read as if an «activity» block is just a specialization of «block» and that is why it is not possible in Papyrus? (That is, I have to create that specialization by myself)

Or is this a planned feature for the future?


Unless I missed something, there's no such thing as an "activity block", in the sense that SysML activities are UML activities. I thought representing activities on BDDs went via the SysML callout mechanism. A quick search gave me some feature requests on the papyrus bugzilla, but they rather targeted to the requirements elements.

So if I'm right (generally I'm not Smile, you might want to create a feature request for this.
Re: Activities in block definition diagrams [message #1157914 is a reply to message #1156812] Sun, 27 October 2013 11:15 Go to previous messageGo to next message
Tomas Sandkvist is currently offline Tomas Sandkvist
Messages: 101
Registered: October 2013
Senior Member
Hi Klaas!

Well, me being the lesser experienced person in this conversation (only been doing SysML for half year or so), I will probably be wrong more often than you. And also, I've just came to realize that it is the 1.1 version that is supported, and not the 1.3 that I have learned from.

In the book there is chapter on activities in a block diagram on page 240, and that's why I asked. I thought that what was described was something that requires some connection between the blocks and the activities since these being different element types in the model.

In the standard it is stated on page 171 that:

Block definition diagram usage for a block hierarchy - Block Hierarchy where block can be replaced by system, item,
activity, etc.

I think I overinterpreted what I have read. There is actually nothing that says anything particular about this, it's just for me to create a stereotype «activity» and that's it.

Regards,
Tomas

Re: Activities in block definition diagrams [message #1175491 is a reply to message #1154389] Thu, 07 November 2013 14:59 Go to previous messageGo to next message
Rodrigo Batista is currently offline Rodrigo Batista
Messages: 2
Registered: December 2012
Junior Member
Hi,

what Thomas is talking about is very well explained in a blog entry by Tim Weilkiens, who is a recognized expert for SysML:

model-based-systems-engineering.com/2012/09/10/hidden-feature-of-sysml-activity-trees/

I guess in his examples he is using MagicDraw, and he draws the activity trees in package diagrams.

In the SysML specification (version 1.3, figure 11.13) we can see an example for an activity decomposition in a bdd (which kind of makes more sense).

In the SysML specification chapter 11.1.4 "Activities as Blocks" it is explained that "In UML, all behaviors including activities are classes (...). Behaviors can appear in block definition diagrams, and participate in generalization and associations."

Since activity decomposition is part of almost every development process using SysML, and for the reasons explained in more detail by Tim in his blog, I think it is important for Papyrus to support this feature.

Best regards
Rodrigo
Re: Activities in block definition diagrams [message #1176418 is a reply to message #1175491] Fri, 08 November 2013 05:16 Go to previous message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Hi Rodrigo,

Rodrigo Batista wrote on Thu, 07 November 2013 14:59
Hi,

what Thomas is talking about is very well explained in a blog entry by Tim Weilkiens, who is a recognized expert for SysML:

model-based-systems-engineering.com/2012/09/10/hidden-feature-of-sysml-activity-trees/

I guess in his examples he is using MagicDraw, and he draws the activity trees in package diagrams.

In the SysML specification (version 1.3, figure 11.13) we can see an example for an activity decomposition in a bdd (which kind of makes more sense).

In the SysML specification chapter 11.1.4 "Activities as Blocks" it is explained that "In UML, all behaviors including activities are classes (...). Behaviors can appear in block definition diagrams, and participate in generalization and associations."

Since activity decomposition is part of almost every development process using SysML, and for the reasons explained in more detail by Tim in his blog, I think it is important for Papyrus to support this feature.

Best regards
Rodrigo


Thanks for this update! However, the devil is indeed in the details (and it look like Tim Weilkiens realises this as he stated the following in a comment below the original post)
Quote:

There is one small formal problem with activity trees. The composite association relationship in the trees should be just the notation for the call hierarchy, i.e. there should be NO such association in the repository. If you create the association relationship in the repository it is nearly impossible in practice to keep them in sync with changes in the activity structure.


I've had a look into the SysML specification document, and it seems like (starting from) SysML 1.2 indeed introduced the necessary constraints wrt. this synchronisation issue and invalidates the comment of Tim (ie. the assocation _should_ be in the repository)

Quote:

The following constraints apply when composition associations in block definition diagrams are defined between activities:
[1] The part endname must be the same as the name of asynchronous Call Behavior Action in the composing activity. If the action has no name, and the invoked activity is only used once in the calling activity, then the end name is the same as name of the invoked activity.

self.ownedAttribute->forAll(a | (a.type.oclIsKindOf(Activity) and aggregation= #composite)
implies self.node->exists(n | n.oclIsKindOf(CallBehaviorAction)
and n.isSynchronous= #true and a.type = n.behavior and
(( n.name->notEmpty() and n.name=a.name) or ( n.name->empty() and n.behavior.name = a.name)))


In turn, this also means that implementing this feature is not as simple as 'allowing activities' to be used on a BDD but it will require the necessary constraints and tool support to keep call behaviour actions and assocations in sync...

So please go ahead and submit the feature request Smile

ps. FWIW: I'm not a papyrus developer
Previous Topic:Checking OCL contraints in Papyrus
Next Topic:Conjugation of ports not displayed on BDD
Goto Forum:
  


Current Time: Fri Jul 25 09:49:16 EDT 2014

Powered by FUDForum. Page generated in 0.11867 seconds