Eclipse Community Forums: Papyrus

Help

Home

Home » Modeling » Papyrus » IBD item flow

Show: Today's Messages :: Show Polls :: Message Navigator

IBD item flow [message #1715271]

Fri, 20 November 2015 17:42

Stephen Blackwell

Messages: 138
Registered: March 2014

Senior Member

Section 9.3.0.5 of the SysML1.4 spec describes the notation of an Item Flow as "...a black arrowhead on the connector or association.". Table 9.1 show several examples as solid black lines with a filled arrowheads in the middle of the line.

The Item Flow on the IBD diagram in Papyrus is a dashed line with an unfilled open arrowhead at the destination end of the flow.

Another bug?

Steve

Report message to a moderator

Re: IBD item flow [message #1715391 is a reply to message #1715271]

Mon, 23 November 2015 08:56

Klaas Gadeyne

Messages: 165
Registered: July 2009

Senior Member

Stephen Blackwell wrote on Fri, 20 November 2015 12:42

Section 9.3.0.5 of the SysML1.4 spec describes the notation of an Item Flow as "...a black arrowhead on the connector or association.". Table 9.1 show several examples as solid black lines with a filled arrowheads in the middle of the line.

The Item Flow on the IBD diagram in Papyrus is a dashed line with an unfilled open arrowhead at the destination end of the flow.

Another bug?

Hi Stephen,

I can confirm it doesn't work Smile

AFAICT, this might rather be a complex issue. As you can see in Figure 9.5, SysML itemflow is a stereotype that extends the UML InformationFlow metaClass. Looking at the UML 2.5 specification, it looks as if UML 2.5 specifies 2 possible notations for InformationFlow. On the one hand, there's the dashed line with open arrowhead, on the other hand there's the 'add-on' notation that just 'adds' a closed arrowhead onto an existing connector or association.

I had a quick look, and (I might have missed something) it seems that the SysML specification adds an additional constraint (see 9.3.2.11, constraint [1]) that specifies that
Quote:

A Connector or an Association, or an inherited Association must exist between the source and the target of the InformationFlow.

This is probably the reason why the SysML specification only retains the second (add-on) notation.

So my guess is that this is not (only) a papyrus SysML 1.4 bug. I would assume that the proper way to fix this, is to provide the necessary support in papyrus UML for the add-on option, and then "forbid" the first notation in the SysML 1.4 plugins.

So, instead of 'another bug', I would say, some more enhancement requests Smile

Feel free to verify my thoughts, and create the necessary bugs and link them from within this thread!

HTH,

Klaas

Report message to a moderator

Re: IBD item flow [message #1715395 is a reply to message #1715391]

Mon, 23 November 2015 09:47

Camille Letavernier

Messages: 952
Registered: February 2011

Senior Member

Hi,

This kind of notation is indeed not supported in Papyrus in general, so we need to improve the base framework. Then we can fix the bugs specifically for UML Information Flows and SysML ones Smile

BTW, the final version of the SysML 1.4 specification has been released a few months ago. It seems your references are based on the beta version. This doesn't change the contents, but it's easier to retrieve up-to-date references Smile

(Especially when the beta specification has duplicated, unordered page numbers)

Camille

Camille Letavernier

Report message to a moderator

Re: IBD item flow [message #1716040 is a reply to message #1715395]

Mon, 30 November 2015 19:04

Stephen Blackwell

Messages: 138
Registered: March 2014

Senior Member

Hi Camille,

This is bit confusing.

Section 20.1.4 of the UML 2.5 spec clearly says that "Quote:

An InformationFlow is represented using the same notation as Dependency, with the keyword <<flow>> adorning its dashed line."

and as you pointed out the SysML ItemFlow is an extension of the UML InformationFlow so I can see why Papyrus has the ItemFlow as a dashed line

However, section 20.1.4 of the UML 2.5 spec also states that Quote:

"Representation of InformationItems is determined by the context is which they are displayed:

[3rd bullet] Quote:

"When attached to a realization of an InformationFlow's information channel, a black-filled isosceles triangle on the information channel indicates the direction of information flow. ..."

It doesn't say anything about changing the notation of the InformationFlow with which the InformationItem is associated, from a dashed line to a solid line or dropping the arrowhead and yet the examples show the solid line.

I'd be happy to enter a bug but I'm not sure what component it would be against.

Thanks,
Steve

PS Got the updated spec - thanks.

Report message to a moderator

Re: IBD item flow [message #1716090 is a reply to message #1716040]

Tue, 01 December 2015 09:22

Camille Letavernier

Messages: 952
Registered: February 2011

Senior Member

Hi,

The Papyrus Diagrams do not support all the different notations of the InformationItem. However, the underlying framework is flexible enough to be able to represent most of them.

There is one exception however: we don't support the Fig. 20.5 or 20.6 notation (A Triangle on a Connector - or any other decoration)

So there are several bugs and/or limitations:

- Papyrus UML Diagrams do not properly allow all representations of the InformationItem: Fig. 20.2 is OK, 20.3 is OK, 20.4, 20.5 and 20.6 are not supported
- Papyrus Framework doesn't support custom decorators on Connectors: This prevents support for Fig. 20.5 and 20.6

So 20.4 could be supported with the current framework, whereas 20.5 and 20.6 would need additional customization capabilities in Papyrus

I think this requires at least two bug entries: One against the Class Diagram (And possibly other diagrams where InformationItem/Flow should be supported) for 20.4, and another one for the generic diagram framework to support decorators on connectors

Then, on top of that comes SysML 1.4 with either extra notations (New/different notations) or restricted notations (Only one notation among the many allowed by UML)

HTH,
Camille

Camille Letavernier

Report message to a moderator