Up Previous Next Title Page Index Contents

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.

Up Previous Next Title Page Index Contents