|Action in Activities [message #503500]
||Mon, 14 December 2009 04:25
Registered: December 2009
There is a point in the UML implementation (org.eclipse.uml2.uml plugin) which I don't fully understand, given the UML specification (http://www.omg.org/spec/UML/2.2/Superstructure/PDF/).
In activity diagrams, there is the Action class :
p311 : 12.3.2 Action (from CompleteActivities, FundamentalActivities, StructuredActivities)
According to the specification, this class has, as generalization, the "Action (from BasicActions)" class.
As I understand the specification :
- there should be an Action (from Activities) class, extending the Action (from BasicActions) class.
- CallBehaviorAction and over classes extending Action (from BasicActions) do not extend Action (from Activities).
In org.eclipse.uml2.uml plugin, there is only one Action class, which seems to be the combination of Action classes from BasicActions and from Activities.
On the other hand, in Activities, actions classes are specialized. Let's take for example p348: 12.3.14 CallBehaviorAction (as specialized).
This class is told containing edges, which suppose it inherits ActivityNode, which is not possible if it extends the Action (from BasicActions) class and if the two Action classes are distinct (since classes extending Action (from BasicActions) do not extend Action (from Activities)).
- Is the 12.3.2 Action (from CompleteActivities, FundamentalActivities, StructuredActivities) paragraph describing the same class as Action (from BasicActions), giving more information specific to its use in Activities ?
- Should there be two Action classes. Which means that org.eclipse.uml2.uml plugin does not conforms to the specification and that the specification is not coherent with itself?
Thanks in advance for helping me clarifying this point.
|Re: Action in Activities [message #504284 is a reply to message #503500]
||Thu, 17 December 2009 23:32
| Kenn Hussey
Registered: July 2009
This is probably a bug in the specification, left over from an older version (e.g., before the finalized 2.0, when the package merge mechanism was changed significantly). In practice, generalizations like this disappear when packages are merged; the intent is for there only to ever be on representation of a given metaclass (in this case Action).|
Powered by FUDForum
. Page generated in 0.08663 seconds