Object states and the need for occurrence-level attributes

Ivo Velitchkov on March 20, 2012

When there is a need to express dynamic aspects, one of the most important things we need to know about Data Objects are their states. Please correct me if I'm wrong. BPMN recognised Data Object as a first class object in version 2 (why it took them so long?) but that's as much as it goes for data-in-process modelling. Still, it has two essential attributes: itemSubjectRef for item definition and dataState. Regrettably, they are both not supported in ARIS 7.2 [Modelling BPMN 2.x in ARIS 7.2, p.50]. While the first one is pertinent to execution, the second one is essential for analysis and also for process automation not using process engines. That seems widely recognised and other, less sophisticated and expensive tools, support it. In any case, if we want to maintain states in ARIS, and especially in BPMN models, what are the options: 1. Link it to an event in a FAD. (-) cumbersome (-) not visible in the process diagram (-) analysis is not straightforward
There is a clear need (not only for object states) to have 'occurence-level' attribute. Currently, the only such attribute available for customisation is the symbol name. That would give us: 2. Define all needed states by new symbols of the Data Object with [<state>] below the standard Data Object symbol. (-) definition of a new state would mean: create new symbol, change configuration, change filter, change template (that's a big 'con') (+) states can be easily filtered using Find with object-symbol filters (-) changing the state could not be done as easily as changing the task type in BPMN2 diagrams Both are clearly not elegant solutions. Now my questions: 1. Do you share this frustration? 2. What are the solutions you use or know of? 3. Are there some macros that you've used for a more elegant handling of Data object states? 4. Do you think that occurrence-level attributes are needed in ARIS? Thank you! Ivo

Bookmark

Notify Moderator

5 Replies

Martin Felder on March 22, 2012 - 10:32

Hi Ivo,

In my previous company we had the same problem, not with BPMN but in working with data object states in eEPCs. We solved it by maintaining multiple state attributes for each object definition. In our case 10-15 text attributes have been sufficient. In the occurence the appropriate attribute was displayed. This was not very convenient for the modeller and difficult for analysis - but at least it worked somehow. Could be something you want to consider as well?

Best regards, Martin

or register to reply.

Notify Moderator

Damian Gawlowski on March 22, 2012 - 12:00

Hi Ivo and Martin,

I have the same issue and I am stumped on this one as I have no idea how to associate different states to the same object.

Try this...

Create your first data object Policy and give it a state eg New
Create your second data object Policy and give it a state eg Reviewed
Create your third data object Policy and give it a state eg Approved

Now select the properties of your first data object, select Variants, select New, select Use existing objects, select Next, select Add, navigate to the location where you have created your data object Policy and select all the data objects of that name.

You have now created a Master object (the first data object) and the other are all Variants of this object.

I'm not sure if this will give us the results we want but have a go and let me know what you think.

Damian

or register to reply.

Notify Moderator

Ivo Velitchkov Author on March 22, 2012 - 13:44

@Martin,

Good idea, it's just that I'd prefer to have an easy way to allocate different states (for example using standard group-level Find). Alternatively there would be e need for a special report and a bit of risk for the quality of data. That latter is also associated with having the attribute as text. I'd prefer user-defined values but I understand that it's at the expense of flexibility.

A sort of a mixed approach would be to use a State attribute within annotation in cases where annotation is used to indicate state. Then getting the states is a query away.

@ Damian,

Using variants is nice but at the expense of having variant attributes diverge and not getting the right results in Output object information and other definition-level reports. (I forgot to mention that the Data Object is used in non-BPMN models as well. In any case.) Do you have any idea how to meet this requirement as well?

Regards,

Ivo

or register to reply.

Notify Moderator

Martin Felder on March 23, 2012 - 10:15

Ivo,

I fully agree. Searching for models with a specific object state would not work following our approach. In a report it is possible but more work as you need to check the attribute placement of each object occurence.

But I am not sure if the standard group-level Find method would work if different symbols are used as you have described. As far as I know the search result is only reflecting the default symbol. E.g. in case an object is used 5 times with the "New" state symbol and 2 times with "Released" the default symbol would be either "New" or the "Released". And I guess the default symbol needs to be defined manually or is based on the symbol which has been used first for the object.

The annotation could indeed work better here. We have evaluated the option as well to use a different "state" object connected to data objects but in our case it was prefered to work with one object type only. Another option would be using different connection types (similar effort as different symbols) or writing the state in an attribute of the connection. But this would both not fulil your requirement for being searchable.

In a nutshell: yes, we need occurence level attributes!

Martin

or register to reply.

Notify Moderator

Radek Laža on December 7, 2021 - 14:40

Hello Ivo,

almost 10 years later I have found your post and have to say, yes we (still) need it!

Regards,

Radek.

or register to reply.

Notify Moderator

ARIS User Group DACH Meeting zum Thema „Simulation mit ARIS“