Issue 14758: Beta 1: Section 10.3.1 Data Objects [Data]: Change Multiplicity of datastate attribute from 0..1 to 0..* (bpmn2-ftf) Source: International Business Machines (Dr. Stephen White, wstephe(at)us.ibm.com) Nature: Enhancement Severity: Significant Summary: A Data Object can have multiple states at the same time. Change Multiplicity of datastate attribute from 0..1 to 0..* Resolution: The FTF decided this change is not required, since it implementing another way extending state multiplicity for data objects (DataObjectRefs). See 15080. Disposition: Closed, No Change Revised Text: Actions taken: November 20, 2009: received issue October 21, 2010: closed issue Discussion: Comments: From: ssamoojh@ca.ibm.com created: Tue, 9 Dec 2008 17:20:35 -0600 (CST) Steve, what exactly do you mean by "multiple states at the same time"? I can see value in modeling possible states (i.e. the Order is in either PENDING or APPROVED state), which would require changing the multiplicity. But is that what you mean? From: wstephe created: Wed, 10 Dec 2008 01:00:50 -0600 (CST) A Data Object could be a JIRA issue, for example. The issue could have states across muliple dimensions. One dimension could be its status, which could be New, Open, Resolved, etc. Another dimension could be whether or not it has been assigned. These could all be defined states (meaning the multiplicity of State would be 0..*). Instead of requiring the modeler to make complex states, such as "Open Unassigned" for a single state. it would be better to have the modeler create two different states for the Data Object, one that could be for the status and one for th Assignment. So the Data Object could go from "Open, Unassigned" to"Open, Assigned" by changing one of those states, leaving the other the same. It would be easier to track those states this way also. From: mariano.benitez created: Wed, 10 Dec 2008 04:54:08 -0600 (CST) Steve, what you are describing are data object attributes for sure. I don't think people would like to model those things as states (which are separated form the data object itself). And people would also want to access this states from expressions and assignments, so states would not be a perfect fit. What I would find useful is to "externalize" as state some attribute and keep the state and attribute in sync, but I don't think it is relevant to the spec. Nevertheless, if the state is an opaque object, people could use any structure and manipulate it as they need, so I don't think multiple states are needed. From: wstephe created: Fri, 12 Dec 2008 20:53:27 -0600 (CST) Mariano, that's a good point. I'm not sure how to differentiate Data Object state(s) with the attributes. The states are generally displayed with the Issue name and help the users track what is going on. I posted a model of the JIRA Issue Workflow (<a href="https://www-1.ibm.com/QuickPlace/bpmnnext/Main.nsf/h_Library/4A8A326614E7CF0E8525751E0008AE67/?OpenDocument">https://www-1.ibm.com/QuickPlace/bpmnnext/Main.nsf/h_Library/4A8A326614E7CF0E8525751E0008AE67/?OpenDocument</a>). Here you can see that the Data Objects (the Issues) are updated throughout the process and their states change in multiple ways. This is what spawned this issue. Take a look and see if this helps you see the issue or what could be done. From: mariano.benitez created: Mon, 15 Dec 2008 07:57:08 -0600 (CST) Steve, The JIRA example you are using is borderline between executable and non-executable processes, which creates some confusion on the intention. I have a couple comments regarding your use case (JIRA Issue Workflow.jpg): 1) we agreed that there is only one state object associated with a data object, without any notion of location in the process. This means that you can only represent a single state in the metamodel. This in itself is an issue we should address if we want to support your use case. Unless the state moves completely to the visual model, and each representation of the data object can have its own state/s. 2) I assume your process is not designed for execution. But in the case we would like to make it executable, we would need to transform/create all those state changes into assignments manually. This creates a gap between non-executable and executable processes. So as a conclusion of my evaluation: - People can do anything they like with states, so I don't see harm in allowing multiple states, all we should do is ensure that states are shown in the right order. - Diagram notation makes no mention to states, but it should since the different states are associated with the DataObjectShape class. From: ssamoojh@ca.ibm.com created: Tue, 16 Dec 2008 11:49:29 -0600 (CST) Mariano, I don't agree with #1 in your comment above. The State represents the state of the data in the Data Object (and not the state of the Data Object). I could easily have multiple Data Objects in the semantic model that hold the same data at different points in its lifecycle .... Data Object 1 holds "Order" when it's in state New and Data Object 2 holds "Order" when it's in state "Pending". From: mariano.benitez created: Tue, 16 Dec 2008 12:42:09 -0600 (CST) Suzette, The fact that there are other use cases (like your example) does not invalidate my interpretation (or my use case, or the JIRA use case, where the issue data object is the same across the process). Do you have other proposal or suggestion? I do propose to change it, but I also would like to move the state to the visual model. This proposal do not invalidate your use case, nor mine. From: ssamoojh@ca.ibm.com created: Tue, 16 Dec 2008 15:52:28 -0600 (CST) My comment was not related to my use-case. I was simply responding to your comment #1, where the lack of a "notion of location" is raised as an issue. I don't see that location is a problem here, and I gave an example of how the current metamodel allows me to represent different states at different locations in the process flow. But maybe I'm misunderstanding what you are describing in #1. In any case, state is not just visual-only information. Hence it needs to be in the semantic model. To address Steve's use-case of multiple States on a single DataObject at a single point in the process flow: I'd recommend we don't do anything. There are several use-cases that we could come up with, and I'm not confident we understand them all well enough to accommodate in BPMN. Hence I'd propose we leave the model as-is. Tool vendors will have to extend the DataObjectState irregardless in order to use it. So they could just as easily extend it to accommodate multiple states. The NET of all of the above is: I don't see a need for any changes. From: mariano.benitez created: Wed, 17 Dec 2008 12:58:33 -0600 (CST) While I agree with your "action" for this issue, I would still be concerned about how to visualize the state in a diagram, we do not propose any way of displaying it. Steve's example is not compliant in this aspect. So to expand Suzette's proposal, I would say: no need for any change in the MM, but we would need to describe how to show a state, of where... End of Annotations:===== s is issue # 14758 [OMG 14758] Beta 1: Section 10.3.1 Data Objects [Data]: Change Multiplicity of datastate attribute from 0..1 to 0..* ##Source: IBM (Stephen A. White, wstephe@us.ibm.com) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-350 ##Original Info: (Severity: Significant - Nature: Enhancement) A Data Object can have multiple states at the same time. Change Multiplicity of datastate attribute from 0..1 to 0..* Comments: From: ssamoojh@ca.ibm.com created: Tue, 9 Dec 2008 17:20:35 -0600 (CST) Steve, what exactly do you mean by "multiple states at the same time"? I can see value in modeling possible states (i.e. the Order is in either PENDING or APPROVED state), which would require changing the multiplicity. But is that what you mean? From: wstephe created: Wed, 10 Dec 2008 01:00:50 -0600 (CST) A Data Object could be a JIRA issue, for example. The issue could have states across muliple dimensions. One dimension could be its status, which could be New, Open, Resolved, etc. Another dimension could be whether or not it has been assigned. These could all be defined states (meaning the multiplicity of State would be 0..*). Instead of requiring the modeler to make complex states, such as "Open Unassigned" for a single state. it would be better to have the modeler create two different states for the Data Object, one that could be for the status and one for th Assignment. So the Data Object could go from "Open, Unassigned" to"Open, Assigned" by changing one of those states, leaving the other the same. It would be easier to track those states this way also. From: mariano.benitez created: Wed, 10 Dec 2008 04:54:08 -0600 (CST) Steve, what you are describing are data object attributes for sure. I don't think people would like to model those things as states (which are separated form the data object itself). And people would also want to access this states from expressions and assignments, so states would not be a perfect fit. What I would find useful is to "externalize" as state some attribute and keep the state and attribute in sync, but I don't think it is relevant to the spec. Nevertheless, if the state is an opaque object, people could use any structure and manipulate it as they need, so I don't think multiple states are needed. From: wstephe created: Fri, 12 Dec 2008 20:53:27 -0600 (CST) Mariano, that's a good point. I'm not sure how to differentiate Data Object state(s) with the attributes. The states are generally displayed with the Issue name and help the users track what is going on. I posted a model of the JIRA Issue Workflow (https://www-1.ibm.com/QuickPlace/bpmnnext/Main.nsf/h_Library/4A8A326614E7CF0E8525751E0008AE67/?OpenDocument). Here you can see that the Data Objects (the Issues) are updated throughout the process and their states change in multiple ways. This is what spawned this issue. Take a look and see if this helps you see the issue or what could be done. From: mariano.benitez created: Mon, 15 Dec 2008 07:57:08 -0600 (CST) Steve, The JIRA example you are using is borderline between executable and non-executable processes, which creates some confusion on the intention. I have a couple comments regarding your use case (JIRA Issue Workflow.jpg): 1) we agreed that there is only one state object associated with a data object, without any notion of location in the process. This means that you can only represent a single state in the metamodel. This in itself is an issue we should address if we want to support your use case. Unless the state moves completely to the visual model, and each representation of the data object can have its own state/s. 2) I assume your process is not designed for execution. But in the case we would like to make it executable, we would need to transform/create all those state changes into assignments manually. This creates a gap between non-executable and executable processes. So as a conclusion of my evaluation: - People can do anything they like with states, so I don't see harm in allowing multiple states, all we should do is ensure that states are shown in the right order. - Diagram notation makes no mention to states, but it should since the different states are associated with the DataObjectShape class. From: ssamoojh@ca.ibm.com created: Tue, 16 Dec 2008 11:49:29 -0600 (CST) Mariano, I don't agree with #1 in your comment above. The State represents the state of the data in the Data Object (and not the state of the Data Object). I could easily have multiple Data Objects in the semantic model that hold the same data at different points in its lifecycle .... Data Object 1 holds "Order" when it's in state New and Data Object 2 holds "Order" when it's in state "Pending". From: mariano.benitez created: Tue, 16 Dec 2008 12:42:09 -0600 (CST) Suzette, The fact that there are other use cases (like your example) does not invalidate my interpretation (or my use case, or the JIRA use case, where the issue data object is the same across the process). Do you have other proposal or suggestion? I do propose to change it, but I also would like to move the state to the visual model. This proposal do not invalidate your use case, nor mine. From: ssamoojh@ca.ibm.com created: Tue, 16 Dec 2008 15:52:28 -0600 (CST) My comment was not related to my use-case. I was simply responding to your comment #1, where the lack of a "notion of location" is raised as an issue. I don't see that location is a problem here, and I gave an example of how the current metamodel allows me to represent different states at different locations in the process flow. But maybe I'm misunderstanding what you are describing in #1. In any case, state is not just visual-only information. Hence it needs to be in the semantic model. To address Steve's use-case of multiple States on a single DataObject at a single point in the process flow: I'd recommend we don't do anything. There are several use-cases that we could come up with, and I'm not confident we understand them all well enough to accommodate in BPMN. Hence I'd propose we leave the model as-is. Tool vendors will have to extend the DataObjectState irregardless in order to use it. So they could just as easily extend it to accommodate multiple states. The NET of all of the above is: I don't see a need for any changes. From: mariano.benitez created: Wed, 17 Dec 2008 12:58:33 -0600 (CST) While I agree with your "action" for this issue, I would still be concerned about how to visualize the state in a diagram, we do not propose any way of displaying it. Steve's example is not compliant in this aspect. So to expand Suzette's proposal, I would say: no need for any change in the MM, but we would need to describe how to show a state, of where...