GB
7.2b te
The UML metamodel includes a class "DataType" which
should be used to represent data types, rather than
recreating the same effect with a custom stereotype
called "datatype".
Use UML metamodel "DataType" in place of a
custom stereotype.
GB
6.2e te
The restriction of global uniqueness for attribute, class,
enumeration and package names is unnecessarily
restrictive. It encourages unnecessarily verbose names.
Common good practice is to use scope to distinguish
between these elements.
Remove the restriction
Level B extended system all share the same namespace for their data. The schema mapping ensures that level B extensions will be processed properly by non-extended systems. Fine.
GenericSituationRecord is abstract in the model. It should have been concrete. This makes is impossible to use the class as a hook class for levelB extensions. It is correct on GenericPublication.
The problem is fixed by unchecking the static checkbox on the GenericSituationRecord class.
This meens that we have, according to me, a severe bug in 2.0 and also in the standard part 3.
In practise, this meens for us in Sweden, that we have to continue to create some level C sevices instead of level B.
There seems to be a problem with the constraints in the generetaed XML schema. The unique check does not work, at least not all times.
When we generate DD for Elaborated Data and MeasureData there is a need to be able t configure not to geneate specific classes e.g. VMSFault. Enhance the profile configuration so that it is possible to exclude one or more classes.
If you have a model containing extensions and you choose de deselect a extension via the selection feature, the resulting schema will not validate. Error would be XXXExtensionType is missing.
When loading a selection from file, the tool only updates the current model with the selected elements from the selection. If you load several selection after each other it will become a mess. Before loadig the selection everything should be deselected.
Following the subschema generation principle ("all valid instances of the subschem must be valid instances of the full schema") it should be poosible to restrict the multiplicty range of associations and attributes in the process of creating a subschema. Users would thus be able to make attributes or components mandatory in their use case, e.g. by restricting 0..1 to 1..1. This would significantly increase the expressiveness of subschemas for particular services.
The methodology allows for multiple instances of "entry" classes. The tools accepts these multiplte instances and creates an XML element declaration for each of them, as expected. Th eproblem is that the tool includes the same set of unuqueness contraints in all these element declarations. Now these contraints have themselves have to have unque names, but in case of multiple such element declarations, the conatrsaints are also multiplied, using the same names multiply, which is not allowed as far as I know.