Reuse the result of a decision

Hello Stefan,

So suppose the events after the decision are "Decision A" and "Decision B". When you need the result of that decision later you obviously should not reuse those events, because the connections of the events would become ambiguous at definition level.

Say, the last function before the new split is "Do something C". If there were no split you would call the subsequent event "Something C done". Now there is a split. I suggest you call the events "Decision A and something C done" and "Decision B and something C done". That perfectly reflects, what the event means to the process.

If you want to have modelling elements supporting the connection, you might use ERM attributes connected to the events which give the notion of "storing" the decision and referring to it. Some people will disagree, because the idea of ERM attributes assigned to events is capturing process data for KPI definitions, such as counters or time stamps. But in a sense this does apply because you might be interested how many times decisions A and B were taken respectively.

Regards, M. Zschuckelt

@ Mr. M. Zschuckelt

I have a question to your post above.

Is it possible - to speak OO -- to deep clone the event object and to reuse that clone later?

Hello Carsten,

I am not sure, what you mean by "deep clone". Forgive me, if I now explain most basic things.

ARIS knows the terms "Occurrence copy", which means mutiple references to the same object. In Java you would write this as:

MyClass a = new MyClass();

MyClass b = a;

In contrast to that there is the "Definition copy", where two completely different and independent objects exist, which have the same set of attributes and references (connections) at the time of creation. Speaking Java:

MyClass a = new MyClass();

MyClass b = a.clone();

In the latter case both objects do not know of each other and will live their lives independent from each other.

A third option is the "variant copy". It is essentially a definition copy, where ARIS additionally maintains a link between the objects. Speaking Java:

MyClass a = new MyClass();

MyClass b = a.clone();

a.setVariants(new HashSet());

a.getVariants().add(b);

b.setMaster(a);

What I wanted to suggest above is to use different events. Link them through a common "ERM attribute", if you feel you need that to model the "storage" of a decision. Otherwise just convey the idea of the link between the objects using a naming convention as I suggested.

Regards, M. Zschuckelt

One correction to my previous comment:

The definition copy is a bit poorer than the Java clone() method. It only copies the set of attributes to the clone. It does not create definition copies of the connections and assignments of the object.

Is that what you mean by "deep clone", Carsten? To copy all connections and assignments as well?

Regards, M. Zschuckelt

a clone only creates a duplicate of the object itself. A deep clone creates a duplicate of the complete object tree. As a consequence a deep clone also substitutes references to a referenced object by a reference to the duplicate of that referenced object.

In the current case of a map a clone would create a new map object but the objects representing keys and values will not be duplicated. As a consequence if a mapped value is altered in the original map, that change also affects the clone.

A deep clone would also create duplicates of all objects representing keys and values and link these to the newly created map object. Performing a deep clone a change of a mapped value in the original map does NOT affects the clone.

Hope that helps and sorry for the late answer.

correction to my above text: a deep clone duplicates a complete object graph, this graph could be a tree, but is not restricted to trees.

Hello Carsten,

I am still not sure, where you draw the border of an "object tree". As a general rule of thumb in a complete database model all objects are connected with each other on some (longer or shorter) path, so if you only wanted an object "tree" you would have to specify along which connection type you want to deep clone the objects. Sometimes an object type might allow multiple semantic connection types to itself and thus participate in multiple hierarchies.

Your question was about deep cloning an event before reusing it. Generally events are not connected directly to events and do not occur in hierarchical tree structures, so you probably intend something different with your idea of deep cloning. If you are referring to the attributes of an object as "keys and values", those are definitely cloned with a definition copy. It would be very surprising if an attribute were linked to multiple objects. Nobody would understand, why another object changes its name or any other attribute, while you are changing one object. Speaking Java: You can consider all attributes as primitive types. On definition copy they are copied by value, not by reference.

I'm afraid I am still missing your point, so please give an example to clarify your idea.

Regards, M. Zschuckelt

Yes, you are right, a deep clone could result in all existing data to be duplicated.

The original point was re-use event data. So my idea simply was:

A simple & secure way to re-use that possibly volatile data is the create a deep clone first. That deep clone will not be altered by the underlying BPM engine. So I can re-use that deep cone anytime later and be sure I work on the original state.

This approach is a common, platform independent approach. As a common, platform independent approach it is very likely not the most efficient. But it works on all platforms somehow supporting a deep clone.

So that small piece of code can do the trick until it becomes a bottleneck and a more optimized solution is required.

Hello Carsten,

normally there is no underlying BPM engine to an EPC. It is only model, not implementation.

In what sense is "event data" is volatile? Because it only represents the decision in a certain moment?

That is why I suggest to draw connections from the events "Decision A" and "Decision B" to an ERM attribute of the name "Decision A or B taken". Then later when you have the split again based on the same decision, connect the events to occurrence copies of the same ERM attribute. That is no implementation, but a help to identify the impact of the decision on the process flow, because you can navigate to all occurrence copies of the ERM attribute on the "Occurrences" tab of the "Properties" window.

This way the ERM attribute definition is the "bracket" around the otherwise formally independent event definitions. The developer implementing the process thus gets the information, that the decision is somehow important to be stored for later use.

Regards, M. Zschuckelt

OK, I was interested in the common case: Say, how to handle volatile data likely to be re-used at runtime.

I am aware of the fact: an EPC might be directly run in a process simulation, but is not likely to be directly run in production. 

To my person:

I am mostly interested in the common case. I rarely have to squeeze out the last cycle on a specific case. Maybe I have to in my next project starting in July, maybe ...

That is why I like the UML 2.4.x implementation of your Software AG ARIS Business Architect. It adheres strictly to the UML specification and as a result also works in the common case. I am only aware of a second UML tool -- mostly done by Airbus, AtoS, Thales and OBEO -- that works in the common case.

I also commonly do not model to get a drawing (please refer to my posts http://www.ariscommunity.com/users/pica/2013-12-21-drawing-vs-modeling-my-aris-express-evaluation and http://www.ariscommunity.com/users/pica/2014-04-26-validation-features). I mostly model to generate code -- or any other artifact -- out of the model. And I often model because DO178, CENELEC or ISO 26262 require it.

I evaluated ARIS Express as a tool to teach modeling to schoolars. Process modeling -- in my opinion -- is the most obvious, the most easy to understand and the most useful modeling in every day use.  That is why I want to use BPM. Would be a nice inter-project-job for me.