5.2 Data model
To understand how to build models as well as reuse and link
design information between models you should know something about the higher
level structure of the repository, i.e. the data model. In this chapter we
describe the underlying data model
.
Basically the data model defines:
 | What
aspects of your design information are stored in the Object Repository.
|
 | How
the various tools of MetaEdit+ manage that
information. |
 | How
reporting, document generation and code generation retrieve information from the
repository.
|
 | How
new system development methods can be implemented into MetaEdit+.
|
In the following the structure of the data
model is explained with eight general
rules.
5.2.1 Tool independence
The first rule, tool independence, lets you view and edit the
same design information in any of the MetaEdit+ tools; even at the same time.
You can open any of your graphs in a Diagram Editor, Matrix Editor, or Table
Editor and the underlying graph is basically the same: only its representation
differs (
Figure 5-8). Because of this
tool independence changes made to graphs in one of the tools are also reflected
by other tools representing the same graph.

Figure 5-8. Tool independence.
To test tool independence in
MetaEdit+ you can try to open any of the existing graphs in a Diagram Editor,
Matrix Editor, or Table Editor.
Figure 1-2 shows an example of using
multiple representations for the same graph: in the figure a Data Flow Diagram
called ‘Sales system’ is opened in all of the editors at the same
time.
5.2.2 Representation independence
The second rule extends the tool independence, allowing you to
have multiple representations of the same graph made with the same
tool
. For example we could have
two different diagram representations of a graph ‘Sales system’: the
first representation could be for programmers and the second, omitting some
details, for managers.
To understand representation independence two aspects need
to be separated: the concept and its representation.
Table 5-1 illustrates the difference.
Information in the Object Repository can be viewed as a two-by-two grid. The
vertical axis represents the distinction between types and instances, i.e.
between methods and the models made with them. The horizontal axis represents
the distinction between concepts and representations, e.g. between a given
conceptual object and a particular representation of that object as a symbol at
a certain place in a diagram. A conceptual object is one that just has a type,
properties and maybe a decomposition, appears in reports and browsers, and in
other CASE tools would have been considered as an entry in a Data Dictionary.
|
Concept
|
Representation
|
Type
|
Method components, e.g. a graph type
|
Property dialogs, symbols
|
Instance
|
Model components, e.g. a graph
|
Diagrams, matrices, tables and their contents
|
Table 5-1. Representation independence.
In MetaEdit+ each
concept can have multiple representations, and all representations of a given
concept refer to the same concept. For example at the graph level (graph can be
loosely equated with model) each graph in MetaEdit+ can be viewed and edited
either as a graphical diagram, as a matrix, or as a table. Because the graph is
conceptually the same in all the representations, changes of the graph’s
properties in one representation will also affect other representations of the
same graph.
Moreover, each model can have multiple representations of
the same paradigm: diagram, matrix or table. For example, the object model of a
sales system can have multiple diagram representations, and the conceptual
information is common for all of them.
Creating and modifying representations of graphs
Representation management for graphs is accessible in two
ways: when they are created or used, and when they are removed. An example of
the former can be found every time a graph is opened with a selected editor and
a dialog such as in
Figure 5-9 opens. It
allows the possibility to create new representations or to select one of the
available representations to be opened.

Figure 5-9. Selecting a graph representation.
Deleting graph representations
Another aspect of managing representations is their deletion.
Graph representations can be removed through browsers by selecting the graph and
choosing
Delete Representations... from the graph related pop-up menu.
This operation opens a dialog as in
Figure 5-10 showing a list of
representations together with information about their type (i.e. diagram, matrix
or table) and creation date.

Figure 5-10. Selecting representations for deletion.
Element representations
The conceptual graph also includes information about the
elements of the graph, such as its objects and
relationships
. Representation
independence also covers these elements: any element can have multiple
representations in the same representation, in the same representation paradigm,
or it can be represented in different tools differently.
An example of the first can be found from in which an
external entity Customer can have multiple representations in the same
diagram. An example of the second is the situation in which the external entity
Customer is represented in several different diagram representations. An
example of the last element representation is a situation in which an entity
Customer is represented as a rectangle in a selected place of the
diagram, and in a matrix representation the same entity can form part of the
axis of the matrix. Still in all of these representation alternatives the design
information about the Customer is the same and changes to that
information through any of these representations will also affect other
representations of the Customer.

Figure 5-11. Two representations for the entity Customer.
5.2.3 Concepts of the data model
The data model defines what constructs your design information
consists of. In MetaEdit+ the structure of the data model is based on the GOPRR
data model. GOPRR is an acronym from the words
Graph-Object-Property-Relationship-Role. Each
of these is called a metatype. The GOPRR metatypes may be described as
follows:
Object
An
object is a thing that exists
on its own. Examples of objects are a
Data Store, an
Entity, and a
Process that belong to a Data Flow Diagram or
Class and
Object that belong to an Object Diagram. All instances of objects support
reuse
functionality: an existing object (e.g. a Process
‘Verify orders’) can be reused in other graphs by using the add
existing function.
Relationship
A
relationship is an
explicit
connection between a group of objects. Relationships attach to objects via
roles. An example of a relationship in an
Inheritance, a
Message
connection that can be usually found from object diagrams or a
Data Flow
that belongs to a Data Flow Diagram.
Role
A
role specifies how an object
participates in a relationship. Examples for a
Data Flow relationship are
the roles
Flows from and
Flows to, which specify how the objects
at either end of the
Data Flow participate in the relationship.
Similarly, in
Inheritance relationships there are two kind of roles:
Ancestors and
Descendants.
Graph
A
graph is a collection of
objects, relationships, roles, and
bindings of these to show which
objects a relationship connects via which roles. A graph also maintains
information about which graphs its elements explode too. Examples of graphs are
Data Flow Diagram, Object Diagram, Problem list
etc.
Property
A
property is a
describing or
qualifying characteristic associated with the other types, such as a
name, an
identifier or a
description.
The GOPRR metatypes are applied on both the type and the
instance level, e.g. a graph type could be Data Flow Diagram, and an
instance of that would be a particular Data Flow Diagram, e.g. ‘Sales
system’. Graph types contain object types, whereas graphs contain
objects.
As stated in the second rule, representation independence,
each of these concepts (apart from property) can have multiple representations
(
Figure 5-8) even in different
representational paradigms (i.e. diagram, matrix,
table).
5.2.4 Properties and non-properties
According to the fourth rule the concepts of GOPRR can be
divided into two categories: properties and non-properties.
Figure 5-12 illustrates the division.
Graph, Object, Role and Relationship can all have properties. In MetaEdit+ these
properties are created, edited and viewed through property dialogs. The property
dialogs
work similarly in all tools of MetaEdit+: to test
a property dialog open it by selecting
Properties... from any
non-property pop-up menu.

Figure 5-12. Properties and non-properties.
Data type
The property has two additional characteristics: it has a data
type
and its values can be shared to other similar
properties. Data types of the properties include:
 | String
(e.g. name of a
process) |
 | Number
(e.g. thread of execution of
message) |
 | Boolean
(e.g. primary
key?) |
 | Text
(e.g. documentation
field) |
 | Collection
of items (e.g. attributes of an
object) |
 | Non-property
(e.g. an attribute in an attribute list of an object may itself be an
object). |
Property types of data type String
can further specify which widget is used in property dialogs for inputting their
values. The widget type is one of the following:
 | Input
Field: a normal one-line text entry field (the
default). |
 | Fixed
List: a pull-down list of values: only values in the list are allowed.
|
 | Overridable
List: a pull-down list of values: the user can also type a value which is
not in the
list. |
 | Editable
List: a pull-down list of values: the user can also type a value which is
not in the list. Such new values are added to the list for this property type in
this
project. |
 | External
Element: a one-line text entry field, whose values are intended to refer to
external file names. These external files can be opened with the Execute
command from the widget’s pop-up
menu. |
For the list widgets, the initial
contents of the list are specified in the property type.
For collection data types, the property type must also
specify the type of the contents, which can be either a simple string or a
non-property type. Similarly property types with non-property data type must
specify which non-property they may contain. In this way complex property types
can be built up. An example of a complex property can be found from object type
Class in object-oriented methods because it has a collection of
attributes and methods as properties and each attribute or method itself is an
object, and as such can have one or more properties. In principle these new
properties could be again complex ones and therefore they could have their own
properties and so on. MetaEdit+ does not limit the number of complex properties
or their depth in any way: you can even have cyclic structures.
Property sharing
A particular property can be shared between two or more
non-properties, meaning that changes to the property via one non-property are
also reflected in the other non-properties. Therefore the property is basically
defined only once and several properties refer to the same value. For this to be
possible, the property in each of them which is to be common must have the same
property type, and the data type of that property type must be string, number,
or text.
This can be used in e.g. object diagrams, so that a
‘Superclass’ string property in one class can be shared with the
‘Class name’ string property in the superclass. Thus if the
‘Class name’ of the superclass is changed, this will also be
reflected in the ‘superclass’ property of the subclass. (Another,
better way of achieving the same result would be to have Superclass property
with a Non-property data type of Class: that way the whole superclass can be
linked, not just its name).
The property sharing can be accessed through property
dialogs by clicking the property field and selecting
Share Property...
from the pop-up menu (see Section
2.3.1
to see how property sharing can be accessed). Note that if you change the
property value in one place all other non-properties that have that property
will show the changed value as well.
To remove property sharing, select the shared field and
choose
Remove Sharing from the pop-up menu. Therefore, by making both
commands one after another you can copy property values from other
non-properties, and remove the sharing so changes to one no longer affect the
other.
5.2.5 Parts of the graph
The fifth rule defines the parts of the graph. Each graph
consists of a number of other non-properties: objects, roles and relationships.
E.g. a Data Flow Diagram graph consists of objects (Processes, Stores
and Externals), relationships (Data Flows) and roles (Flows
from, Flows to).

Figure 5-13. Parts of the graph.
5.2.6 Bindings
The information about how the objects, roles and relationships
in a graph are connected is stored as
bindings in that graph. Each
binding stores a relationship, two or more roles, and for each role, one or more
objects. A binding in a Data Flow Diagram could have a relationship
Orders with a role
from connecting to an external
Customer,
and a role
to connecting to a process
Verify
orders.

Figure 5-14. Binding components.
Graph types also contain
bindings, that specify what kinds of bindings are legal in graphs of this type:
for instance, a Data Flow Diagram specifies that a binding can exist for a
Data Flow with an
External in a
from role and a
Process in a
to role. However, it will not contain a similar
binding with an
External in both
from and
to roles, because
such a binding is illegal in Data Flow
Diagrams.
5.2.7 Decomposition structure
Depending on the method in use one or several objects (e.g. a
Process in a Data Flow Diagram) can be decomposed into a new diagram.
This feature is usually known as decomposition or levelling as it forms a
hierarchy of models.

Figure 5-15. Decomposition structures.
In MetaEdit+ you can
create decomposition
structures in two ways
(
Figure 5-15):
top-down, by
selecting an existing object and making a new decomposition graph, where you
describe it in more detail, or
bottom-up, by selecting some existing
objects and moving them and their relationships into a new decomposition graph,
replacing them in the top graph with a new object. The end result is the same:
an object in the top graph has a decomposition graph describing it in more
detail.
A typical decomposition structure can be found from Data
Flow Diagrams, in which a process can decompose into a new Data Flow Diagram.
Note that only one decomposition is allowed for an object, and applies in all
graphs containing that
object.
5.2.8 Explosion structure
Each object, relationship or role in a graph can also be
linked to other graphs via explosion structure
(
Figure 5-16). Basically the explosion
structure allows to select one element from the graph and
explode that to a new graph. An object (or a relationship or a role) can have a
different set of explosions in each graph where it is used. Explosion always
happens by first selecting one object, unlike decomposition where several can be
selected. Explosion is often used between different graph types.

Figure 5-16. Explosion structure.
As with decomposition,
explosion structures are also method dependent. An example of a explosion graph
can be found from most object-oriented methods, in which an Object or Class in
an Object Diagram can be further described in a State Diagram by exploding it
into a new graph.