-
Key: SCE-40
-
Status: closed Implementation work Blocked
-
Source: BPM Advantage Consulting ( Dr. Stephen White)
-
Summary:
As part of our approach to create a MVP SCE, we should refactor the packaging mechanisms so that BPMN, CMMN, and particularly DMN can use the SCE infrastructure
-
Reported: SCE 1.0b1 — Tue, 7 Mar 2023 21:48 GMT
-
Disposition: Resolved — SCE 1.0b2
-
Disposition Summary:
Restructure SCE Packaging to be backwards compatible with current BPM+ specifications
This will be a major change but will help with the adoption of the new BPM+ specs and can allow BPMN, CMMN, and DMN to also utilize SCE (at some point). Right now the old BPM+ specs will not be able to use SCE.
The basic idea is to simplify the packaging structures to be compatible with the old specs and still allow new capabilities (such as instance packages).
This will affect the spec doc, the metamodel, and the schemas.
---------
The proposal is to simplify the packaging mechanisms so that the existing BPM+ languages can use SCE. The current SCE packaging structure is too complex.
Further, the approach of the FTF is to create the MVP version of SCE and get that to work (i.e., get working implementations). If we find later that we need more capabilities, then SCE can be updated, from this backwards compatible base, to include those capabilities.
Basically, the SCE packaging would be reduced to a single class called SCEModel, which is the top level container for defining and exchanging model elements. This maps to the “Definitions” class from BPMN, CMMN, and DMN. The SCEDI class is contained within SCEModel and would hold the diagrams associated with the models.
Thus, the new SCE metamodel would be simplified to this (there are more details for SCEModel, but this represents the basic packaging):see attachment
The current SCEModelPackage, SCEModel, and SCEDefinitions have been collapsed into the single SCEModel class.
The SCEProfile class is removed. There are no specific use cases for this class yet. Thus, the MVP approach is to remove it until needed.
Most of the BPM+ languages do not need instance elements in the models. Thus, the MVP approach is to remove it in SCE and add it where needed. For those languages that need to include instances (of types) such as PMN and PPMN, they can create an instance package based on SCEModel within their metamodels. We can work with the PPMN FTF to build that structure.
Without the addition packages of Profile and Instances, the base SCEPackage is not needed either. This can be added back without affecting the downstream languages if necessary. -
Updated: Mon, 16 Sep 2024 14:12 GMT
-
Attachments:
- Figure 10 - SCEInstances MM V2.svg 311 kB (image/svg+xml)
- Figure 15 - The Internal Relationships Metamodel.svg 461 kB (image/svg+xml)
- Figure 16 - ModelArtifact MM.svg 300 kB (image/svg+xml)
- Figure 2 - SCE High-Level Elements v3.svg 585 kB (image/svg+xml)
- Figure 5 - SCE Packaging Elements Metamodel V4.svg 418 kB (image/svg+xml)
- Figure 6 - The SCEPackage Metamodel.svg 251 kB (image/svg+xml)
- Figure 7 - SCEModel MM V2.svg 524 kB (image/svg+xml)
SCE — SCE is not backwards compatible with the original BPM+ specs
- Key: SCE-40
- OMG Task Force: Specification Common Elements (SCE) 1.0 FTF