Profile attribute multiplicity

[scottrudy]

I know there is a rule that states attributes must have a multiplicity of 0..1 in the model. I noticed that the CImTool also seems to enforce that restriction on profiles. So in order to get a type in a Profile with a <<Primitive>> or <<Compound>> stereotype to show up as an XSD element where the maxOccurs="unbounded" I'm forced to create an association in the model. Is that by design?

[tviegut]

Hi @scottrudy: Thanks for posting your question and its a good one that I'm sure others may be interested in the answer as well. First off, the CIM itself, by design, is intended to serve purely as an information model for our particular domain. As such, in this CIM "information world", we also have de facto rules and conventions that we enforce that all of our supporting tooling is expected to adhere to as well. This is one of those areas. So, to directly address your question the answer is "Yes", CIMTool does enforce at the profiling level this rule of only 0..1 or 1..1 (i.e. enforces a max cardinality of 1) for attributes within a class (see: ). Hopefully this helps. Again, thanks for using the discussion forum to get answers to your questions. It's helps the community in general so we appreciate it.

As for the use of associations to these types of classes, this is not allowed. From the modeling guide:

[scottrudy]

What I mentioned above seems to work, but I'm open to alternatives.

[scottrudy]

Upon further reading, I have found a document that says stereotyped classes may not participate in relationships, which of course includes inheritance. I think this may leave me no choice except to create a class that is not stereotyped, and looks just like the stereotyped class. Again, this is just for backward compatibility purposes. I realize there are better ways to do this moving forward, such as creating a wrapper class around the stereotyped class, which would allow the collection to be held.

[tviegut]

@scottrudy : what document are you referring to?

[scottrudy]

@tviegut Application of IEC CIM Standards in Power System Modeling, Smart Grid and Enterprise integration, page 151 states:

Stereotyped classes are types that never participate in relationships (i.e., no associations, no inheritance), but are used as types for attributes

[tviegut]

@scottrudy : Thanks for the link. I got a chance to check it out today. I'm familiar with the presentation as it was at an IEEE conference probably 12 or 13 years ago. I apologize as there are different contexts for different presentations and sometime it may not match the scenario you're attempting to apply. What is described in that presentation was a formal approach for how to prepare a use case and corresponding UML modelling proposal in the form of extensions with the goal of having such extensions reviewed and formally added (normatively) to base CIM. What is not explicitly called out or explained (but is implied) is that such a proposal would serve as interim UML model representation for extensions that help make a CIM Model Managers life much easier (i.e. I am a CIM Model Managers for Transmission) when it comes time to integrate/synthesize new attributes, classes, associations into the core CIM. If I were to receive a separate package of extensions as described in the presentation and those extensions reviewed and broadly approved by the team I could easily migrated the relevant attributes, classes, associations and generalizations out of the extensions package and into the normative CIM model. That's a key reason for the proposed format for those extensions. They would not remain in the format you see in the presentation but rather the "shadow" classes would be deleted after relevant attributes and associations were either moved or "reassigned" to appropriate classes within the normative CIM. In that context I wouldn't retain any stereotypes on these extensions upon migrating them into the CIM. Anyway, this was my reason for asking for the source of what you were referencing so as to review the context. Note that in CIMTool, an internal "union" of extensions into a base CIM model, in principal, achieves something roughly similar to what I'm describing as a manual merging. In any event, just following up on your response.