BestPractice: How to structure a Type Hierarchy

Defining sound domain-specific meta-models

BestPractice: How to structure a Type Hierarchy

Postby sip » Thu Sep 15, 2011 5:51 am

Working with actifsource one is often challenged to define a meta model for the type hierarchy within the model. Especially if the model is used for subsequent Code Generation there is a lot of stuff which should be taken care of.

Out of this need we have developed a type hierarchy which has served us well and which I would like to share with the community!
So let’s start with collecting some requirements for our type hierarchy:
Any non-trivial project has a need to compose (Complex-) Types from (Simple-) Types and other (Complex-) Types. There will be different kind of Simple- and Complex-Types. Also there will be types needed in any kind of operation signatures. So what we see is a great deal of types needed in a lot of different situations. Experience also showed, that there will be a need to enhance these types with some additional meta data. Therefore we need a possibility to annotate a type based on its usage and characteristic.

Based on these requirements we have come up the following type hierarchy. Let’s start with an overview of two Class Diagrams, following with a detailed explanation of the rationales behind the design decisions.

type-hierarchy.png
Type Hierarchy Overview
type-hierarchy.png (40.17 KiB) Viewed 7009 times


First the type hierarchy overview shows how a SimpleType is derived from the based Type class. Currently there are three different kinds of SimpleTypes: LiteralTypes bridging and abstracting the underlying programming language, Framework Types integrating any framework specific types which need to be references in the model and finally EnumTypes.
Second the overview shows the ComplexType (also derived from Type) which can be composed by adding Properties which are either Attributes (=SimpleTypes) or References (= other ComplexTypes). Currently there are three different kinds of Complex Types: TransferTypes for non-persistent, serializable objects, EntityTypes for persistent, identifiable objects and finally so called ValueObjectTypes.
The meta model also indicates, that Types are always referred via Property, Return or Argument classes. These classes all derive from TypeRef which puts them into a common hierarchy which is needed for sub-classing relations as well as for the annotation mechanism as describes below.

Note on using actifsource SubRelations:
actifsource supports the notation of SubRelations which is very useful within class hierarchies. This feature can be explained looking at the type hierarchy in the above diagram: Notice the ‘type’ relation between TypeRef and Type (called ‘TypeRef.type’). This relation indicates that a TypeRef has a relation to exactly one Type. Now look at the Attribute and Reference classes that are derived from the super class TypeRef and therefore have also a relation to Type. But the relation should be constraint to only SimpleType in case of Attribute ( Attribute.simpleType) resp. to only ComplexType in case of Reference ( Reference.complexType). This can be achieved by adding a so called SubRelation in the sub-classes of TypeRef ( Attrbute and Reference). A SubRelation in fact then sub-classes the relation ‘TypeRef.type’ within the selected sub-class from TypeRef. This approach brings several advantages to the meta-model:
  • SubRelations can constraint the parent relation (e.g. narrow the possible types)
  • SubRelation can be associated with a range restrictions
  • Viewed from the parent class (e.g. TypeRef) nothing changes
Looking at the type hierarchy example two usages of SubRelations can be identified:
  • TypeRef.type
    • Attribute.simpleType (narrow Attributes to only refer SimpleTypes)
    • Reference.complexType (narrow References to only refer ComplexTypes)
  • ComplexType.property
    • ValueObjectType.attribue (narrow ValueObjecTypes to only refer Attributes)


annotation-hierachy.png
Type Annotation Hierarchy Detail
annotation-hierachy.png (24.61 KiB) Viewed 7009 times


In any real world scenario a simple type reference is normally not sufficient. A type used in an operation signature or a ComplexType will need some additional information:
  • a type could be wrapped in a collection or map
  • a type reference could be defined final
  • a type could be parameterized by using generics
  • a name of a type reference maybe needs to be mapped to a different name
  • a type needs some validation
  • etc.

In order to handle this additional information every type reference class has a relation to a specific annotation class. This annotation class contains all additional information which is needed for the kind of type reference. This way of modeling allows an easy separation of the business related modeling vs. some aspect of the more technical related modeling.
Also realize that the annotations are following the type reference inheritance hierarchy. By following the inheritance hierarchy the common annotation information can be kept together resp. the specific annotations information can be directly associated to its specific type reference. This is also realized using SubRelations:
  • TypeRef.annotation (referring to AbstractAnnotation)
    • OperationTypeRef.annotation (referring to OperationAnnotation)
    • PropertyTypeRef.annotation (referring to PropertyAnnotation)
      • Attribute.annotation (referring to AttributeAnnotation)
      • Reference.annotation (referring to RefereneAnnotation)

The AbstractAnnotation contains information valid for all type references (e.g. collection, map, final, etc.) whereas ReferenceAnnotation only contains information about a Reference (e.g. traversal direction).

The usage of a type hierarchy as described in this post, provides a nice balance of several modeling aspects:
  • easy creation of the instance model
  • clear structure for writing meta model & template functions
  • good support for writing code templates
  • robust & extensible foundation for any further evolution of the type hierachy
sip
 
Posts: 6
Joined: Wed Feb 16, 2011 7:42 am

Return to Meta Model

Who is online

Users browsing this forum: No registered users and 1 guest

cron