The MDA
The Model Driven Architecture (MDA) is a systematic design approach for the development of software systems. It provides a set of guidelines for the structuring of system specifications, which are presented as models (conceptual diagrams). The MDA is based on the principle of modelling separately technology-independent and technology-specific aspects of a system. These aspects are taken into consideration at different stages during the development process.
The most important aspect of the MDA approach is the explicit identification of Platform-Independent Models (PIMs) which can be implemented on different platforms via Platform-Specific Models (PSMs). An essential feature of the MDA framework is to make transformations between models (design levels) automatic (see 1). This means that a transformation tool takes a PIM and transforms it into a PSM. In a follow-up step, the transformation tool transforms the PSM to code. 1 shows how a UoD is represented in a unique PIM, which in turn can be transformed into a PSM, based on a platform of choice. A second transformation derives code for the implementation of the PSM. Detailed information about the MDA can be found through the following link:
https://www.omg.org/mda/This design approach is made possible by the availability of extensibility mechanisms included in the UML. The following section therefore introduces the concept of UML stereotypes.
UML Stereotypes
Stereotypes are one of three extensibility mechanisms available in UML. Stereotypes allow designers to extend the vocabulary of UML in order to create new model elements. These new elements are derived from existing ones but have specific properties and semantic that are suitable for a particular problem domain or for specialized use. In our case, this means that we can add modelling elements to represent spatial data types, topological rules, etc. By using stereotyped elements, we can incorporate these, application specific concepts, into the language. This in turn allows us to use the extended elements as primitives or building blocks during the design process.
Graphically, a stereotype is rendered as a name enclosed by guillemets (≪ ≫) and placed above the name of a modelling element. Alternatively, a stereotyped element may be indicated by a specific icon (see 2). The icon image may even replace the entire UML symbol.
Modelling Considerations
To properly follow the MDA approach in the design of a spatial database, we need to decide on the data types to be used at every design level. 3 shows the relationship between each MDA design level and the specific data types that will be used at each level.
At the Platform Independent (PIM) level, we will use standard data types as specified by ISO in the 19107 - Geographic information - Spatial schema – ISO/TC 211 - 2002 (more...). At the Platform Specific (PSM) level, we will use data types as specified in the OpenGIS Simple Features Specification for SQL (more...). And, at the code level we will use Spatial and Geographic objects for PostgreSQL – PostGIS (more...).
PIM Data Types
Several elements are required to cover the modelling aspects of spatial applications at the platform independent level. ISO's 19107 Geometry Package provides a set of datatype definitions that can be used to represent geometric characteristics of objects in the real world and are considered platform independent. ISO covers a broad set of issues regarding geometries. Too many to cover them all, so here we only present a small subset. ISO’s modelling elements are organized into packages. The elements we need in this exercise are defined in the Geometry Package. The geometry package has several internal packages that separate primitive geometric objects, aggregates, and complexes, which have a more elaborate internal structure than simple aggregates (see 4). At the root of the geometry package sits the GM Object which represents a combination of a geometry and a reference system.
The GM_Primitive is the abstract root class of the geometric primitives (see 4). A geometric primitive (GM_Primitive) is a geometric object that is not decomposed further into other geometric primitives in the system. All other primitives imply some form of composition of geometric primitives to form more elaborated geometries. In this exercise we will use some of these primitives as data types for our spatial attributes. The extension of Enterprise Architect available for you includes the following types: GM Point, GM LineString, GM_Polygon, GM_MultiPoint, GM_MultiCurve, GM_MultiSurface, and GM_Complex.
The FeatureType Stereotype
Another concept provided by ISO is that of FeatureType, which is used as an abstraction for a real-world phenomenon that has geometrical characteristics. ≪ FeatureType ≫ is a stereotype that is instantiated as a class that represent objects for which geometry properties are included in the model, e.g., parcels, lakes.
Enumerations & CodeLists
An enumeration is a UML standard concept used in class diagrams to list user-defined sets of named identifiers. These identifiers represent the values of the enumeration. These values are called enumeration literals. You can add enumerations to depict discrete sets of values. Models can include user-defined enumerations such as one that defines the days of the week. For example, an enumeration called Day would have enumeration literals Monday, Tuesday, Wednesday, and so on.
ISO defines a special type of enumeration, the so-called ≪ CodeList ≫. A code list is similar to an enumeration, in that one of a number of values is possible, but differs in intent, in that a codelist may be expanded over time. Most codelists are stored as numeric values, but some implementations use character strings. Please note that this is only an ISO subtlety that you may decide to disregard in your design process, but since in this exercise we want to be compliant, we follow ISO to the letter.
