Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » Papyrus Photon - struggling with sequence diagrams(Sequence diagram)
Papyrus Photon - struggling with sequence diagrams [message #1791836] Fri, 06 July 2018 00:41 Go to next message
Ri Fr is currently offline Ri FrFriend
Messages: 134
Registered: July 2015
Senior Member
Hello
I need some help solving following issues I experience in Papyrus 4.0 sequence diagrams. I did not have these issues in Oxygen (I think it was 3.4??? Maybe)

1. Cannot resize the interaction frame created by Papyrus on diagram creation. Especially when it's too big and I need to shrink it

2. Can create but cannot show in the diagram guard conditions for any operand or message operation. I define the guard using the value of LiteralString in the properties view

Before I create a bug report I'd like to check if I'm doing something wrong... if anyone had success with these please advise! Thanks!
Re: Papyrus Photon - struggling with sequence diagrams [message #1791858 is a reply to message #1791836] Fri, 06 July 2018 09:12 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 477
Registered: May 2015
Location: Germany
Senior Member
Hi Richard,
I can confirm the resizing behavior. The diagram automatically resizes horizontally but not vertically.
/Carsten
Re: Papyrus Photon - struggling with sequence diagrams [message #1791859 is a reply to message #1791836] Fri, 06 July 2018 09:18 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 477
Registered: May 2015
Location: Germany
Senior Member
Hi Richard,

just to cite the UML 2.5.x spec

8.6.17 StringExpression [Class]

8.6.17.1 Description
A StringExpression is an Expression that specifies a String value that is derived by concatenating a sequence of operands with String values or a sequence of subExpressions, some of which might be template parameters.

8.6.17.2 Diagrams
Expressions, Namespaces

8.6.17.3 Generalizations
TemplateableElement, Expression

8.6.17.4 Association Ends
owningExpression : StringExpression [0..1]{subsets Element::owner} (opposite
StringExpression::subExpression)
The StringExpression of which this StringExpression is a subExpression.
♦ subExpression : StringExpression [0..*]{ordered, subsets Element::ownedElement} (opposite
StringExpression::owningExpression)
The StringExpressions that constitute this StringExpression.

8.6.17.5 Operations
stringValue() : String {redefines ValueSpecification::stringValue()}
The query stringValue() returns the String resulting from concatenating, in order, all the component String
values of all the operands or subExpressions that are part of the StringExpression.
body: if subExpression->notEmpty()
then subExpression->iterate(se; stringValue: String = '' |
stringValue.concat(se.stringValue()))
else operand->iterate(op; stringValue: String = '' | stringValue.concat(op.stringValue()))
endif

8.6.17.6 Constraints
operands
All the operands of a StringExpression must be LiteralStrings
inv: operand->forAll (oclIsKindOf (LiteralString))

subexpressions
If a StringExpression has sub-expressions, it cannot have operands and vice versa (this avoids the problem of
having to define a collating sequence between operands and subexpressions).
inv: if subExpression->notEmpty() then operand->isEmpty() else operand->notEmpty() endif


Am I am the only one missing the point about guards?

/Carsten

[Updated on: Fri, 06 July 2018 09:24]

Report message to a moderator

Re: Papyrus Photon - struggling with sequence diagrams [message #1791867 is a reply to message #1791859] Fri, 06 July 2018 10:41 Go to previous messageGo to next message
Ri Fr is currently offline Ri FrFriend
Messages: 134
Registered: July 2015
Senior Member
I Carsten
LiteralString is an allowed guard condition and worked well in Oxygen.
Point being that I cannot see guard conditions on my sequence diagram operands or messages no matter what I do. Either I'm doing something wrong or there is a bug... I'd like to confirm which. Can you get sequence diagrams to show guard conditions... if yes can you share some details on how you do it thanks!
Re: Papyrus Photon - struggling with sequence diagrams [message #1791874 is a reply to message #1791867] Fri, 06 July 2018 11:48 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 477
Registered: May 2015
Location: Germany
Senior Member
Hi Richard,

a guard condition must evaluate to either true or false. A LiteralString as an unconstrained sequence of characters is not guaranteed to evaluate to either true or false.

Given that alone, I would prefer to state the issue is at the Oxygen implementation.

Furthermore I scanned the whole spec for "guard condition" and also "guard expression". That gave me 7 hits altogether, but gave me no hint that "LiteralString is an allowed guard condition".

I also scanned for "GuardCondition" and "GuardExpression". That gives no hits at all. given that there is neither a GuardCondition nor a GuardExpression defined in UML.

The LiteralString being defined as Class in the UML therefore can not be a GuardCondition. Because there is no GuardCondition.

All these details make me quite sure, the issue is at the Oxygen implementation.

/Carsten
Re: Papyrus Photon - struggling with sequence diagrams [message #1791879 is a reply to message #1791874] Fri, 06 July 2018 12:40 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Richard, Carsten,

The statement in the description of the InteractionOperand class is fairly clear that the operand's guard constraint is expected to be boolean-valued:

Quote:

17.12.12 InteractionConstraint [Class]
17.12.12.1 Description
An InteractionConstraint is a Boolean expression that guards an operand in a CombinedFragment.


The semantics of InteractionOperand also states that the interaction trace includes only operands whose guard evaluates true.

For the convenience of informal specification, it would be nice that a tool presents the constraint in the diagram even if its specification is a StringLiteral as Papyrus appears to have done in the Oxygen release, but even so you could try using an OpaqueExpression with a body of any "language" you choose. A tool such as Papyrus should assume that an expression in a language that it doesn't know about would be boolean-valued, if it restricts its presentation only to boolean expressions.

HTH,

Christian
Re: Papyrus Photon - struggling with sequence diagrams [message #1791907 is a reply to message #1791879] Fri, 06 July 2018 16:52 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Surely a LiteralString is guaranteed to not evaluate to true or false; a literal does not evaluate. Only a LiteralBoolean can be true or false. If you want an evaluation, you need an OpaqueExpression, possibly specifying an OCL language and a corresponding expression.

I recall some trouble with LiteralString moderately recently but don't see anything in the OCL or UML2 N&N. Perhaps it was a Papyrus fix.

Searching my workspace, I find the old Infrastructure.uml contains

<ownedAttribute xmi:id="Core-Basic-Class-isAbstract" name="isAbstract" type="Core-PrimitiveTypes-Boolean">
<ownedComment xmi:id="Core-Basic-Class-isAbstract-_ownedComment.0" annotatedElement="Core-Basic-Class-isAbstract">
<body>True when a class is abstract.</body>
</ownedComment>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_XobAM37VEeOu79LxSz8Ylw" value="false"/>
</ownedAttribute>

so there is clearly a legacy bad practice of a Boolean-valued LiteralString.

Regards

Ed Willink
Re: Papyrus Photon - struggling with sequence diagrams [message #1791923 is a reply to message #1791907] Sat, 07 July 2018 12:41 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 477
Registered: May 2015
Location: Germany
Senior Member
Hi Ed,

many, many thanks to confirm my statement by formulating an even more restrictive one.

I also thought of your formulation before I wrote mine. But that very formulation you have chosen requires to define what "to evaluate" means.

I make a first approuch to define "to evaluate":
to evaluate means tp perform operations based on a mathmatical calculus on an expression based on a context-free grammar.

Given that very definition your statement is absolutely correct. But this definition has the issue a natural language UML::OpaqueExpression even typed as UML::Boolean -- I also had in mind -- does not evaluate either.

That is the rationale why I used the definition
to evaluate means can be interpreted as.

That definition while being rather vague has the charm, that a natural language UML::OpaqueExpression typed as UML::Boolean is a candidate to be evaluated. But a UML::LiteralString not being constrained i.e. to be UML::Boolean is not.

Given i.e. the string "at working hours" the interpretation as natural language UML::OpaqueExpression typed as UML::Boolean is quite clear to me, while the interpretation as UML::LiteralString is not.

/Carsten
Re: Papyrus Photon - struggling with sequence diagrams [message #1791924 is a reply to message #1791836] Sat, 07 July 2018 14:12 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 477
Registered: May 2015
Location: Germany
Senior Member
Hi,

I tried it with Papyrus 3.4 (Oxygen) and 4.0 (Photon) and figured out no problems. Even an UML::LiteralString works as guard with Photon.

/Carsten
  • Attachment: Oxygen.zip
    (Size: 5.45KB, Downloaded 93 times)
Re: Papyrus Photon - struggling with sequence diagrams [message #1791941 is a reply to message #1791924] Sun, 08 July 2018 15:19 Go to previous messageGo to next message
Ri Fr is currently offline Ri FrFriend
Messages: 134
Registered: July 2015
Senior Member
Many thanks Carsten for uploading your test model! Great help!
1. Using your model I can confirm that we set up the operand guard conditions in the same way. Encouraged by this, I then discovered that on my model ( which was created with Oxygen and now I'm editing it in Photon), I can ONLY see the guard conditions in the sequence diagram if I delete the old operands and replace them with new ones! I tried may other ways but this seems to be the only one that works.
1.1 So I suspect some backward compatibility issues between the Photon and Oxygen handling of guard conditions
2. Still, I cannot show message guard conditions in your model or mine using Photon, no matter what kludge I try. I can create them (I see them in Model Explorer) but they don't display on the diagrams.

If anyone can get message guard conditions to display on Photon sequence diagrams please share how you do it! Thanks!

p.s. As you noted LiteralString works and actually seems to me that it is the default guard type assigned by Photon if you type it in at operand creation. I don't think it's semantically very distant from OpaqueExpression with natural language... I think some of the confusion of the previous posts is that LiteralString is NOT the guard condition that must evaluate as Boolean; LiteralString is the SPECIFICATION of the guard condition. Cheerio.
Re: Papyrus Photon - struggling with sequence diagrams [message #1791942 is a reply to message #1791941] Sun, 08 July 2018 16:41 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 477
Registered: May 2015
Location: Germany
Senior Member
Hi,

everything works fine for me. The model test model I shared was created using Oxygen, imported to Photon and extended in Photon.

The condition shows up in the diagram as you can see in the attached screenshot.

index.php/fa/33348/0/

/Carsten
Re: Papyrus Photon - struggling with sequence diagrams [message #1791946 is a reply to message #1791942] Sun, 08 July 2018 19:10 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

"LiteralString is the SPECIFICATION of the guard condition."

You seem to have failed to understand the discussion. The true UML LiteralString is equivalent to the "true" String in most programming languages which is never equal to the true Boolean without the help of an explicit conversion operation.

A LiteralString is literally the character sequence of the String. If you want a non-literal string, i.e. the specification of something, you need a UML representation of to specify an evaluation such as an OpaqueExpression. Any tool that converts the "true" LiteralString to a Boolean is wrong. If a tool feels a need to exhibit a legacy bad behaviour for buggy UML 2.4 example text there should at least be a warning.

Regards

Ed Willink
Re: Papyrus Photon - struggling with sequence diagrams [message #1791947 is a reply to message #1791946] Sun, 08 July 2018 19:53 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 477
Registered: May 2015
Location: Germany
Senior Member
Hi Ed,
as you explicitly replied to my post, I think we both are d'accord.
/Carsten
Re: Papyrus Photon - struggling with sequence diagrams [message #1791968 is a reply to message #1791941] Mon, 09 July 2018 08:14 Go to previous message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 477
Registered: May 2015
Location: Germany
Senior Member
Hi Richard,

Quote:
... I don't think it's semantically very distant from OpaqueExpression with natural language. ...


Just to provide you a view from another view point.

Does this mean, you would also use a natural language OpaqueExpression as default value of a String Property?

/Carsten

Previous Topic:Papyrus does not recognize the types from an UML Profile
Next Topic:Papyrus 4.0 is available
Goto Forum:
  


Current Time: Thu Mar 28 20:31:55 GMT 2024

Powered by FUDForum. Page generated in 0.03026 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top