Fundamentals of Information Modelling - Internal Draft

Bryan Lawrence

See trac ticket #158

We need a common language for the things we need. For that we can use ISO19101 and ISO19103, which give us:

1. application schema: conceptual schema for data required by one or more applications [ISO 19101]
2. conceptual model: model that defines concepts of a universe of discourse [ISO 19101]
3. conceptual schema: formal description of a conceptual model [ISO 19101]
4. data type: specification of a value domain with operations allowed on values in this domain (nb:Data types include primitive predefined types and user-definable types).
5. domain: well-defined set (nb: Domains are used to define the domain set and range set of attributes, operators and functions).
6. feature: abstraction of real world phenomena [ISO 19101] (nb: A feature may occur as a type or an instance. Feature type or feature instance should be used when only one is meant).
7. feature association: relationship between features [ISO 19109]
8. feature attribute: characteristic of a feature [ISO 19101] (ITSELF A FEATURE)
9. feature operation:  operation that every instance of a feature type may perform [ISO 19101] (aka affordance).  Feature operations provide a basis for feature type definition.
10. value domain: set of accepted values

We also need some UML terminology. The key ones for cooperative working are:

1. constraint: semantic condition or restriction
2. metamodel: model that defines the language for expressing a model
3. package: general purpose mechanism for organizing elements into groups  (nb: packages may be nested within other packages. Both model elements and diagrams may appear in a package.). Note that a <<leaf>> is a package with only definitions and no sub-packages.
4. realization: relationship between a specification and its implementation, shown using <<realize>> stereotype on an association (An indication of the inheritance of behaviour without the inheritance of structure.)
5. refinement: relationship that represents a fuller specification of something that has already been specified at a certain level of detail
6. specification: declarative description of what something is or does (Contrast: implementation.)
7. stereotype: new type of modelling element that extends the semantics of the metamodel (nb:  Stereotypes must be based on certain existing types or classes in the metamodel. Stereotypes may extend the semantics, but not the structure of pre-existing types and classes. Certain stereotypes are predefined in the UML, others may be user defined. Stereotypes are one of three extensibility mechanisms in UML. The others are constraint and tagged value.) Stereotypes are essential in the creation of code generators for UML models. Generally speaking, stereotypes act as flags to language compilers to determine how to create implementation models from the abstract.
8. tagged value: explicit definition of a property as a name-value pair (nb: In a tagged value, the name is referred as the tag. Certain tags are predefined in the UML; others may be user defined. Tagged values are one of three extensibility mechanisms in UML. The others are constraint and stereotype.)
9. type: stereotype of class that is used to specify a domain of instances (objects) together with the operations applicable to the objects (nb: A type may have attributes and associations.)
10. primitive_type: A class definition where the actual representation will be supported by appropriate primitive types in a platform, implementation environment or encoding.

Some rules and notes (from ISO19103):

1. For each class defined the set of attributes defined with this class, together with the sets of attributes of classes that are reachable directly or indirectly via associations, shall be sufficient to fully support the implementation of each operation defined for this particular class.
2. Use of multiple inheritance shall be minimized, because it tends to increase model complexity.
3. .All associations shall have cardinalities defined for both association ends. At least one role name shall be defined. If only one role name is defined, the other will by default be inv_rolename.
4. If an association is navigable in a particular direction, the model shall supply a "role name" that is appropriate for the role of the target object in relation to the source object. Thus in a 2-way association, two role names will be supplied. The default role name is "the<target class name>" in which the target class is referenced from the source class (this is the default name in many UML tools).
5. Relationships involving more than two classes should be avoided in order to reduce complexity.
6. An association with role names can be viewed as similar to defining attributes for the two classes involved, with the additional constraint that updates and deletions are consistently handled for both sides. For one-way associations, it thus becomes equivalent to an attribute definition. A role thus serves as a pseudo-attribute.
7. The recommendation for the 19100 series of standards is to use the association notation for classes and interfaces, and to use attribute notation for data types.
8. Note the existence of Sets, Bags and Sequences as collection types (the first two differ by not having duplicates, and the last differs by the concept of order). Note that arrays and lists are examples of sequences.
9. Note also explicit support for dictionaries, enumerations and codelists. The difference between an enumeration and codelist comes down to expected extensibility <<CodeList>> can be used to describe a more open enumeration. <<CodeList>> is a flexible enumeration that uses string values through a binding of the Dictionary type key and return values as string types; e.g. Dictionary (String, String). Code lists are useful for expressing a long list of potential values. If the elements of the list are completely known, an enumeration shall be used; if the only likely values of the elements are known, a code list shall be used.

A class definition where the actual representation will be supported by appropriate

• primitive types in a platform, implementation environment or encoding.

Issues (with iso19103)

• The Date Type!

Naming Conventions

• For attributes and operation names, association roles, and parameters capitalize only the first letter of each word after the first word that is combined in a name. Capitalize the first letter of the first word for each name of a class, package, type-specification and association names. (Example: computePartialDerivatives (not computepartialderivatives or COMPUTEPARTIALDERIVATIVES. Example (Class): CoordinateTransformation (not coordinateTransformation).

ISO 19109 Methodology