|
|
| Re: Papyrus Photon - struggling with sequence diagrams [message #1791859 is a reply to message #1791836] |
Fri, 06 July 2018 09:18   |
|
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 #1791874 is a reply to message #1791867] |
Fri, 06 July 2018 11:48 |
|
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 |
|
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 #1791923 is a reply to message #1791907] |
Sat, 07 July 2018 12:41 |
|
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
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.09375 seconds
Search
Help
Register
Login
Home
