differentiate between fork and join

[martin.grotzke]

hello,

do you plan to make a difference between fork and join nodes?
currently there's only one symbol for both, and in the exported xmi (1.2)
the corresponding pseudostates all have the attribute kind="join".

in the custom properties it's possible to specify the kind of the node, but this information is exported via the tagged value "$ea_xref_property", which is a little bit cryptical .

do you plan to change or support the diffentiation between fork and join?

kind regards,
martin

[Andreas_G]

Hi Martin,

is there realy a difference between fork and join in UML?

Since you can do a join and a fork with one node, in my opinion there is no difference.

regards,
Andreas

[martin.grotzke]

there is one: JoinNode and ForkNode  
moreover, the ForkNode has a joinSpec : "ValueSpecification [1..1] A specification giving the conditions under which the join will emit a token. " (UML Superstructure 03-08-02, p. 339)

seriously: i'm currently using the exported xmi for code generation with open architectureware (http://sourceforge.net/projects/architecturware).
the metamodel of this generator framework is currently extended, so that it's possible to model with activities and actions and have these represented in the instantiated metamodel.
regarding this, it's important to be able to distinguish between fork and join node, what would be most easy if this information would be contained in the xmi or the model.

but you are right, if one would model a fork and join with a single fork/join symbol, you'd have the problem not to be able to specify a single kind, or this would be fork+join.
more clearly: if you use only one symbol for specifying a fork and a join node, this would represent two model elements: one ForkNode and one JoinNode. so you have to distinguish between the notation and the model

regards,
martin

[Andreas_G]

ok, I throw the towel.
You are right.
I think there is nothing more to say after a look to the superstructure.



bye
Andreas

[sargasso]

Interesting problem.  Can only suggest as a workaround that you preprocess the XMI to change the pseudostate kind attribute.
B

[martin.grotzke]

You mean preprocess from the enterprise architect view (export xmi), or from the architectureware view (read xmi)?

Currently i have no much time (writing my thesis that must be finished to the end of august), so i think i'll take the practical approach and use stereotypes on the nodes. These can be bound to specific metaclasses in architectureware, so i know which kind of node i got.

Cheers,
Martin