Release 2.3.0

Release 2.3.0 [20-Dec-2019]

Note that there was no jCleanCim-2.2.0, but rather only 2 beta milestones (2.2.0.beta-2 and 2.2.0.beta-3) that were made available for the internal needs of WG13 and ENTSO-E CGMES SG work - needed to validate CIM canonical and profile models and produce various WG13 documents at that time. The 2.2.0.beta-3 ended up being released as 2.3.0. Note that due to limited time a corresponding update of the .pptx tutorial for 2.3.0 was not completed for the release.

New features

In this release, the primary focus was on generic namespace support, stereotypes, document generation options (especially on generating documents from UML profile models), and ongoing work related to supporting English document generation with non-English versions of MS Word. The release also features the contribution used for generation of MIBs for IEC62351-7 (thanks Gigi!) as well as several smaller changes to better support IEC61850 modelling and document generation (more coming in the next release - thanks Laurent!). And as usual, there are a number of new tests and bug fixes.

Stereotype informative

From this release, you can add stereotype informative to any UML model element and it will also be picked for determining whether something is informative, along with the other existing and new logic. The only ignored informative stereotype is for dependency as it does not really make sense to tag a dependency as informative (until proven otherwise :-)).

Along with this change, filtering on printing informative elements (controlled by configuration option docgen.includeInformative ) has been largely improved, to ensure to really exclude informative content of any kind by default, i.e., when option is set to ("false", "", null). You may want to set that option to true to print the informative content for debuging purposes, or during extensions development, but never for official standard documents.

New configuration option docgen.showCustomStereotypes (TODO - add to .ppt:docgen.showCustomStereotypes=true)

If set "true", it allows to show in the generated document custom UML stereotypes on UML model elements, in addition to built-in stereotypes already handled per model nature. Default is ("false", "", null) to preserve old behaviour, in which all custom stereotypes (non-built-in for a model nature) are not explicitly shown in generated documents. UML model managers in standardisation bodies want to keep this empty/false for main standard documents, and set it to true for these use cases:

1. peer reviews during standard model development (through use of custom stereotypes such as changed, new, old, delete, discuss, etc.);
2. review of proposed extensions marked with a given stereotype;
3. standard document generation from standard extensions model (e.g., European extensions);
4. users of the tool with models which are neither CIM nor IEC61850 may want to generate UML documentation (MS Word or XML) with their own stereotypes. Default model nature is CIM (unless explicitly specified as IEC61850 with configuration property model.nature.iec61850), so the built-in CIM stereotypes are "reserved" and cannot be modified at present.

Note: This option does not filter elements for document generation, it merely allows you to "hide" and show the custom stereotypes on UML elements in the generated document. For actual filtered printing based on custom stereotypes, see the next section.

New configuration option docgen.skipForCustomStereotypes (TODO - add to .ppt e.g.: docgen.skipForCustomStereotypes=European,new)

This new option allows for selective document generation from UML models of a given nature that contain both standard model parts and extensions tagged with a custom stereotype for that nature. You can use this option now to explicitly skip during document generation all UML elements that have any of the custom stereotypes in the list specified here. This is useful in at least these use cases:

1. a WG develops extensions which are mixed with the normative parts of the model and tags those extensions with a stereotype (e.g., new), and wants to be able to generate documentation both with and without these extensions, e.g. for peer review
2. an organisation or a project develops extensions tagged with a custom stereotype which are either mixed with the normative parts of the model or are in extension package, but the inheritance and associations result in stereotyped extensions being mixed with the normative parts of the model. The standardisation WG then wants to be able to skip these when generating documents, without manually removing anything from the model (they add the custom stereotype(s) in this option), and the organisation or project owning extensions want to leave this option empty (to see their extensions printed).

This list is matched against the built-in, standard stereotypes according to modelling rules and any built-in stereotype (per model nature) from this list is removed (i.e., there is no overriding of built-in stereotype consideration for document generation). Empty list is valid and reflects default behaviour, i.e., everything found in the model according to other specified filtering options is printed. Not having this option or having it with an empty value preserves the default behaviour: to not exclude anything based on stereotype only, i.e., to include everything not disabled by other options (e.g., informative or private model elements).

Important: The list given here ignores any built-in stereotype per nature in order to not modify the behaviour established and defined for built-in stereotypes. So, any built-in stereotype you specify here will simply be ignored. Examples of built-in stereotypes:

• enumeration for classes; informative, deprecated for any UML element in model of any nature - you cannot modify built-in behaviour for these in any case (at present);
• Primitive, CIMDatatype for CIM classes - you cannot modify built-in behaviour for these in CIM models, but these are custom if ever used in non-CIM models; and inversly,
• cond for IEC61850 presence condition enumeration - you cannot modify built-in behaviour for these in IEC61850 models, but these are custom if ever used in non-IEC61850 models.

New configuration option docgen.showNamespacePackages (TODO - add to .ppt model.showNamespacePackages = Base, Dynamics, Part303, IEC61968, IEC62325, ExtEuBase)

According to CIM modelling guidelines, we can use tagged values nsuri and nsprefix to support namespace definition within the UML model itself, as well as for extensions and for generation of various implementation afterfacts. We typically specify these two tagged values at the top level (e.g., TC57CIM) and then everything below that package will have the same namespace, unless an element of UML model overwrites it. Almost every element of UML that supports tagged values can use this mechanism. So, from this release, you can control document generation inclusion or not of this information, by specifying for which UML packages to output in the MS Word document a line of text with the namespace information. Examples include Base and ExtEuBase (for 61970-301 main part and Annex A, respectively), Dynamics (for 61970-302), etc. If you don't specify any package name, or use an older config.properties file, no namespace information gets printed (default).

Note that this mechanism of namespace (the usual URI and optional prefix) is supported for any UML model nature, so in theory, for IEC61850 models as well.

However, IEC61850 has a special definition for document namespace and dedicated UML modelling for this. The IEC61850Namespace mechanism will be supported in the next jCleanCim release.

New configuration option docgen.word.includeInheritancePath (TODO - add to .ppt:docgen.word.includeInheritancePath = true)

This options allows to include the list of classes along the inheritance path for a class. Default is false, as well as when the option is missing from the configuration, to preserve the default behaviour. In the supplied configuration file we have enabled this option as it is rather useful and you can see with the test run how the result looks like and whether to keep it.

Important: jCleanCim does not support multiple inheritance, but it should not crash if it finds it in the model. The behaviour for multiple inheritance is undefined.

Support for custom styles (TODO - update .ppt)

Disclaimer: The MS Word and its API are for certain features unpredictable, as are all the people who edited in the past 25 years the document you use as template. This is the best I can give at the moment. Please pay attention to the WARN or ERROR log entries (what you see on the screen and what gets saved in the ./log/jCleanCim.log file). And please, be careful about style names in MS Word (see how MS Word can smart you out).

You can now try using the following new configuration options:

• docgen.word.styles.prefix.toc and docgen.word.styles.prefix.head: for TOC and heading styles prefix, and,
• docgen.word.styles.para, docgen.word.styles.fig, docgen.word.styles.tabhead, docgen.word.styles.tabcell, docgen.word.styles.figcapt and docgen.word.styles.tabcapt: for styles names for paragraphs text, figure, table heading, table cell, figure caption and table captions,

to specify a comma-separated list of style names, in order of your preference. To accommodate for non-portable style handling accross some application locales (English vs. non-English installation of MS Word), we expect the user to configure preferred styles in order of preference, and the first one found in the existing document will be used all allong. If none of configured styles exists in the document, the built-in one fr...