UAF14 — ActualPerson is not a Distinct Type. Inconsistent Representation of Individual vs Type/Class wrt Other Metamodel Elements (ActualXXX Elements Contradict Class Mechanism))

9.1.6 Domain Metamodel::Personnel - Person, Figure 9:234

Person is defined as 'A type of a human being used to define the characteristics that need to be described for ActualPersons (e.g., properties such as address, telephone number, nationality, etc).'

1) This doesn't define what the 'Person' concept is - it only defines how it is used for an implementation that seeks to be able to represent a real world person. Every Class/Type defines properties applied to an individual - this is not an identifying feature.

2) In most modelling languages such the UML etc we have a means to represent a type (Class) e.g. UML Class and an individual (instance of a UML Class). The individual / instance automatically takes on the propertties of the type / Class.

If, for example, I instantiate a UML Class named 'Car' that has a property, 'manufacturer' the resulting element is an individual which we understand to represent a real world thing, Car. I can then allocated the manufacter's name to the 'manufacturer' property. None of this requires an ActualCar - all of the Class/Type properties are defined as part of the Class/Type - there is no new type or stereotype needed to define Class properties.

For example if I have a model element of Type/Class = Standard and then give it a DCMIIdentifier = 'ISO/IEC/IEEE 42010' and DCMITitle = 'Interational Standard - Systems and Software - Architecture Description' everyone understands that this is a representation of the real world artefact - ISO/IEC/IEEE 42010. There is only the one Class/Type which defines the properties that make the Class unique from all other types. Class definitions have to be unique - if they depend on another Class then they're not. There is no ActualStandard required.

ActualPerson is not a type of Person - as defined it only exists to hold a set of properties that can be applied to an individual or instance of the Person Class/Type.

This separation is completely inconsistent with every other UAF metamodel element - we don't have ActualArchitecturalDescription, ActualArchitectureViewpoint, ActualStandard et al. This looks to be an old error inherited from early MODAF days where someone was thinking of abstractly representing instantiation but made the mistake of embedding this in what was a UML implementation (the M3).

The 'Actualxxx' construct isn't needed in the UAF. Nor is it needed by any implementation of the UAF in any other ADL. On p288 we have ActualPerson = 'An individual human being.' - it isn't - it's supposed to be a type of Person. This makes no sense since the metamodel presents types.

It adds more elements, relationships, complicates implementation, adds inconsistencies and increases the cost of maintenance for no good reason.

From a practical means to define properties of individuals there is no technical need for ActualPerson, Actual-anything.

The DMM looks to be a bottom-up merging of donor AF metamodels warts and all rather than a top-down what-do-I need-to-address-each-viewpoint-concern. This has not only not preserved errors but does not produce the smallest metamodel needed (very much like constructing programme task logic from the start/left rather than starting with the end deliverable and working to the left).