KDM14 — current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit

The current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit and to a certain extent ParameterUnit and StorableUnit.

The issue is that some of the kind enumeration are tied to a class but in reality can apply in other places and that those enumeration are single valued where in real life usage we would need to often specify more than one value.

Some concrete example:

1- ClassUnit (and InterfaceUnit) supports no modifiers (or kind enumeration in KDM speak). This issue was raised in 2006 and never addressed. How can we, without resorting to stereotypes, which are not very interoperable, describe a Java class that is “final public” or “static”

2- MethodUnit has a MethodKind but it has no ExportKind which would be a start to try to capture a Java method like “final protected” (also needs multi-value)

3- ParameterUnit has a ParameterKind but it again has no ExportKind. So another example, your Java method parameter that is declared as “final” (or is that an “ImportKind”)

4- MemberUnit represent for example Java field class member (JLS names). There we have ExportKind but like other places for Java modifiers it would be missing “static”, “transient”, “volatile” and a way to express “default”, unless we agree that it is in force if none of public, private or protected is specified. But we should be able to easily support a field declaration such as: “private static final String CONST1 = “xx”; “

I am not sure what the best approach is here in all regards. First I think we must change the cardinality to support multiple “modifiers” for the same “unit”. We also need to look if we want to simply expand the ExportKind and move it to the ComputationObject class instead of being at the MemberUnit level. That obviously expands the classes that can make use of it, but it addresses most of the issues, except for the ClassUnit and InterfaceUnit which are children of DataType

current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit

Added attributes since using an enum does not seem appropriate. These should match some UML concepts.