Each activity execution should have its own locus

[GoogleCodeExporter]

Currently, there is only one common locus for all running activity executions. 
It would be good to have separated loci for each execution.

If this is doable, we could also assign easily the extensional value events to 
the respective execution IDs, since we may navigate from the value to its locus 
and check whether the locus is active in the context of a specified execution 
ID. Thus, extensional value events may have an execution ID also.

Once this is done, we also have to integrate this in the filtering mechanism in 
the InternalActivityProcess, which only populates the events that are of 
interest for a respective client. However, extensional value events have to be 
populated to all clients at the moment.

Original issue reported on code.google.com by p.langer on 19 May 2012 at 4:16

[GoogleCodeExporter]

This is the definition of a Locus from the fUML Standard:

"Every execution takes place at a specific locus. A locus is an abstraction of 
a physical or virtual computer capable of executing fUML models. It is a place 
at which extensional values (objects or links) can exist. ... 
All objects and links created during an execution are created at the locus of 
that execution. And, unless an object or link is explicitly destroyed, it will 
persist at the locus even after the execution has completed. This means that 
objects and
links may already exist at a locus before a specific behavior execution begins, 
providing part of the environment in which the execution takes place."

Because of this I would stick to the current implementation and maybe provide a 
method in ExecutionContext that enables the deletion of all extensional values 
at a locus.

Original comment by tanjaema...@gmail.com on 21 May 2012 at 10:56

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Tanja,

thanks for pointing out that aspect in the standard. I agree with 
deferring this issue.

Original comment by p.langer on 21 May 2012 at 1:28

[GoogleCodeExporter]

Original comment by p.langer on 24 May 2012 at 12:20

• Changed state: Deferred