Thermo Special Interest Group met on July 12, 2022 from 9:30 am till 11:30 am (Central European Time).
Agenda
- Draft the Manager Common interface specification.
Participants
BASF (represented by Sergej BLAGOV), AmsterCHEM (represented by Jasper van BATEN), Michel PONS (Consultant as Chief Technology Officer).
Klaus MÖLLER (University of Cape Town) apologized for not being able to attend while on a trip to the Republic of Mozambique to teach there.
Highlights
Thermo SIG progressed further the CAPE-OPEN interface specification for Managers, which contains, so far, one interface named ICapeManager. Thermo SIG went through comments raised in the sections on architecture and requirements. Several design decisions were revised or introduced, mostly in that case by moving requirements to being design decisions.
- The design decision that CAPE-OPEN considers both stand-alone and managed Primary PMC Objects of the same type was further explained by giving a meaningful example.
- Within the rationale on the design decision that persistence is not required on a Manager, the concept of a “PME document” was dropped in favour of the more generic concept of “persistence storage provided by the PME“.
- The design decision that adding, removing, renaming, editing a Template through the Manager are private operations of the Manager was better formulated to be seen as clearly out of the scope of the interface specification.
- An additional design decision was introduced: in the scope of the Manager, a Template is identified through its name only. In the current version of the specification, no other generic descriptor of a Template is provided. Templates of different Managers may be qualified by similar meta information (date of creation for example), that could be made accessible without instantiating the corresponding Primary PMC Object, but the current design decision is to focus on names only. It is further stated, as a warning, that the Primary PMC Object should not be instantiated unnecessarily because it can be costly and prone to errors.
- Making mandatory that managed Primary PMC Objects implement persistence needed a proper rationale to be developed. The previously existing interface specification on Property Package Managers is relying on the persistence offered by the Manager to persist a managed PMC. The new specification moves the responsability of persisting to the Primary PMC Object managed by the Manager. Relying exclusively on the persistence of the Primary PMC Object seems the only way to ensure a straightforward workflow. The PME can then relies on the functionality provided by the Manager to de-persist the named Primary PMC Object.
Several requirements were further reviewed as well:
- The rationale for the requirement that “Objects instantiated by a Manager are Primary Process Modelling Components” was clarified.
- The rationale for the requirement that “Each instance created by a Manager is of the software component type(s) consistent with the Manager type(s)” was reworked for clarification purposes.
- To better reflect its meaning, the requirement that “The Manager supports the service to provide the list of its Templates” was reworded in “A Manager provides the service to deliver the list of names of its Templates“. Its rationale was reworked as well. And the rationale was re-targeted at this specific requirement and simplified by stating that one cannot address an element without knowing the list of elements than may be addressed. For example, for interaction with the Process Engineer, the PME must have access to the list of Templates supported by the Manager since the name of the Template is needed to request the creation of a Primary PMC based on the Template.
- Thermo SIG discussed the expectation put into the list of Templates provided by a Manager. Is it a requirement that any Template listed exists? Not really since instantiation of a Primary PMC Object based on a listed Template may still fail for various reasons such as the lack of a proper license corresponding to the Template. In a particular case used as example for possible failure, the list of Templates is obtained by the Manager from reading the contents of a folder where each template is represented by a file. This does not mean that each Template present is properly configured for instantiation. The absence of guaranty is therefore stated within the rationale.
- The requirement initially worded as “A Template is identified by its name in a case insensitive manner” was the only one addressing how the name of a Template should be. An additional requirement was introduced stating that “The name of a Template follows the rules of the name property in ICapeIdentification.” The discussion of this requirement led to the addition, as mentioned above, of a design decision about using names to identify Templates of a given Manager.
- Thermo SIG focused next on the requirement that “A Primary PMC Object created via a Manager supports persistence“. Portability was used as the reason for this requirement. Reference to portability was enhanced as being in time and space. The requirement was essentially moved to the design section.
Thermo SIG will meet next on July 19, 2022.
