Method Description of Object Role Modeling

Table of Contents

Introduction

This paper describes and illustrates a method to modeling and querying an information system at the conceptual level. This is termed Object-Role Modeling (ORM) and this method is most likely less well known than Entity Relational, Object-Oriented and Unified Modeling approaches, even though fact oriented modeling has been used successfully in industry and academia for over 30 years.

Furthermore, Object-Role Modeling is used to create a mapping between the conceptual and logical levels for information systems. The formalization of the method was provided in 1989 by Halpin when he completed his PhD? thesis on ORM.

The method allows an information analyst to build a model of the Universe of Discourse in a clear, unambiguous way by describing the user requirements in elementary facts (Halpin, 1998). These are fact sentences in a natural language, which can be validated by subject matter experts.

Background

The roots of ORM can be traced to the Netherlands and Belgium where Nijssen in the 1970s started experimenting with semantic, fact-based modeling and developed the Natural language Information Analysis Method (NIAM). He is considered the founder of the verbalization technique and information analysis based on natural language.

In 1989 he worked together with Halpin amongst others to further develop the method at the University of Queensland, Australia. This collaboration resulted in ORM which Halpin describes as a method for designing and querying database models at the conceptual level, where the application is described in terms easily understood by non-technical users.

After they parted in 1990, Nijssen returned to the Netherlands where he further developed NIAM whilst Halpin continued developing ORM. This explains the similarities and the differences between the two methods.

Since the conception of ORM, many variations or dialects have come into existence, such as the Fully Communication Oriented Information Modeling (FCO-IM) which strictly focuses on the verbalization of facts and less on the concepts of the domain (Bakema, Zwart & Van der Lek, 1996). These models can be further transformed into Entity Relationship (ER), UML, Relational or Dimensional models (Bakema et al., 1996).

Method structure

In an information systems development life cycle, ORM supports the requirements analysis and the design phases. A first version of the conceptual schema design procedure was formulated by Nijssen and was further extended by adding concepts such as subtyping (Halpin, 1998). This section and the remainder of the paper will describe the creation of a conceptual schema in more detail.

The Conceptual Schema Design Procedure (CSDP) consists of seven steps (Halpin, 1998) and specifies the information structure of the application in terms of the types of facts that are of interest; constraints on these; and possible derivation rules for deriving some facts from others.

#1 - Verbalize information examples
Step 1 is the most important. Examples are gathered from subject matter experts and verbalized in natural language, e.g. English or Dutch. The information analyst further transforms the information into elementary facts and applies a quality check such as inspecting if objects have been well defined or if values are defined by constants.

#2 - Draw the fact types
In this step the fact types are drawn. Each fact type has been populated with at least one fact in order to apply a population check.

#3 - Combine and derive object types
Object types which suggest they are nearly the same entity type, should be combined in a new entity type. Furthermore, fact types that can be derived from others should be added. E.g. to count the number of rooms per building, we can add the derivable counter ‘number of rooms’.

#4 - Add uniqueness constraints
Step 4 adds uniqueness constraints and checks the arity (unary, binary, ternary) of fact types. For example, a uniqueness constraint ensures that each room is allocated to at most one building.

#5 - Add mandatory role constraints
Mandatory role constraints are added in this step. This constraint is the equivalent of a ‘not null’ constraint in ER-modeling. Also, this will result in a mandatory field in an information system which a data entry clerk must complete during the data entry process.

#6 - Add value and subtyping constraints
Value constraints are added to restrict the domain for certain input values, e.g. a ‘room number’ may only contain numbers in the conceptual schema which could be depicted as a value constraint {0-9} whereas a ‘room identifier’ may also contain alphanumeric characters. Also, subtyping constraints are added which depict a subset of an object type. E.g. a university consists of employees with different roles such as a teacher, professor and a teaching professor. These roles could be a subtype of ‘Employees’, for instance if the teacher is audited by a teaching professor.

#7 - Perform final checks
Step 7 of the Conceptual Schema Design Procedure adds other constraints and performs final checks, e.g. a teacher cannot audit himself.

Example

This section illustrates the basic working of the design procedure by the means of a classroom example. The goal is to develop a conceptual model for a future database to store information about the building, rooms and facilities of the Utrecht University. The example is based on the FCO-IM method.

First of all, facts are being collected from a document containing information about the buildings and rooms. Secondly, the information analyst verbalizes the information as elementary facts which are validated by a subject matter expert. These sentences, which are natural language examples, are outlined in figure 1. One of the most important benefits is that it guarantees no redundancy. The resulting information grammar is called an Information Grammar Diagram (IGD).

Figure 1 - Classroom fact expressions

The next step is to ‘grammatically’ analyze the fact expressions. This is depicted in Figure 2 where the first example is decomposed into entity types, object types and values. This decomposition is called an expression tree.

Figure 2 - Expression tree

The other fact expressions are analyzed in a similar fashion which results in a drawing of the elementary information grammar diagram, as shown in figure 3. The modeling method has its own notation and is further explained in Bakema et al. (1996).

Figure 3 - Classroom IGD

The fact sentences can be regenerated from the information grammar diagram for validation by the subject matter experts. The information grammar diagram can also be transformed in a relational schema in BCNF with the use of an automated algorithm, usually incorporated in CASE-tools. This is dictated by ‘first order predicate logic’ which is the mathematical theory behind ORM. Other models, such as a UML class diagram can also automatically be derived from an IGD.

Generating an ER-Diagram or Class diagram with the help of a CASE-tool is considered out of scope for this paper.

Process Description

Process Deliverable Diagram

This section illustrates the Process Deliverable Diagram (PDD) of Object Role Modeling. Weerd and Brinkkemper (2008) describe the PDD as: “a technique to reveal relations between activities (the process of the method) and concepts (the deliverables produced in the process)”.

ORM can be positioned in the information analysis and design phase in the context of a complete information system life cycle. Most of the time, this is a linear process of conducting a feasibility study and designing, building, testing and implementing a new automated information system. However, ORM also adheres to the agile philosophy, e.g., by using Scrum or eXtreme Programming practices.

The PDD is depicted in figure 4 and entails two parts which are integrated with each other and illustrate the relationships. A process view is depicted on the left-hand side of the diagram. The deliverable view is portrayed on the right-hand side of the diagram. Detailed information about the activities and deliverables can be found in respectively table 1 and 2.

Figure 3 - Process Deliverable Diagram

Activity Table

An overview of all the activities and sub-activities stated in the PDD is represented in table 1, together with a description.

Table 1 - Activity table

Activity	Sub-Activity	Description
Prepare kick-off meeting		The Kick-off Meeting is the first meeting with the information analyst and the subject matter expert of the project. This meeting lays the foundation of the project and future project activities.
Information analysis	Image-forming Business Domain	A first overview of the business domain is established and requirements are expressed. Reports, documents and/or screen shots are gathered and examined.
	Split business domain into sub domains	Divide the business domain in several SUB DOMAINS to improve clarity and simplicity.
	Prioritize sub domains	Prioritize SUB DOMAINS in order to improve the business value and shorten the time-to-market.
Information modelling	Verbalize Information examples	The contents of the desired information are verbalized in a collection of natural elementary facts (sentences).
	Draw Fact types	The FACT TYPES are drawn and a population check is applied.
	Combine object types	Check for OBJECT TYPES that should be combined, and note derivations.
	Add uniqueness constraints	Add UNIQUENESS CONSTRAINTS, and check arity (e.g. unary, binary, ternary) of FACT TYPES.
	Add role constraints	Add mandatory role constraints, and check for derivations.
	Add value constraints	Add VALUE CONSTRAINTS, set comparison and subtyping constraints.
	Perform final checks	Add other constraints and perform final checks.
	Regenerate fact expressions	For validation purposes, the sentences will be regenerated and approved or rejected by the subject matter expert.
Transforming model	Group model	The derivation of a relational schema is done by carrying out three transformations on the elementary information model. The aim of grouping is to combine as many fact types as possible in the same table without introducing redundancy. This results in a Grouped Information Model (G-IM). (Bakema et al., 1996).
	Lexicalize model	The Grouped Information model is transformed by lexicalizing into a grouped and lexicalized information model (GL-IM).
	Reduce model	The grouped and lexicalized IM (GL-IM) is further transformed by reducing into a grouped, lexicalized and reduced information model (GLR-IM). This model is similar to an ER-diagram which could be implemented in a relational database if a target DBMS has been decided.

Concept Table

The definitions of the used concepts (deliverables) depicted in the PDD, are given in table 2.

Table 2 - Concept table

Concept	Description
DESIGN DOCUMENT	A DESIGN DOCUMENT consists of the REQUIREMENTS DOCUMENT and the CONCEPTUAL INFORMATION MODEL. It describes the complete solution for a new or changed information system.
REQUIREMENTS DOCUMENT	A REQUIREMENT DOCUMENT is written by the information analyst and defines the product and the requirements for one or more new features.
REQUIREMENT	A REQUIREMENT is a functional description of a new functionality that is to be implemented in the new release of a product.
DOMAIN	A DOMAIN defines the information boundaries and can be divided in several SUB DOMAINS based on, for example, their scope and complexity.
CONCEPTUAL INFORMATION MODEL	The CONCEPTUAL INFORMATION MODEL expresses the meaning of terms and concepts used by domain experts to discuss a problem and shows relationships between different concepts (Halpin, 1998). It contains the name of the project, creation and last modification date, the name of the author, the name of the information model and the description of the model. To assist creating the INFORMATION MODEL, a template has been provided in appendix A in order to list and validate the FACT EXPRESSIONS. This can be used as a spreadsheet to present the examples and share them amongst the project team members.
FACT EXPRESSION	A FACT EXRESSION is the actual verbalizations of facts by subject matter experts (Halpin, 1998).
FACT TYPE	A FACT TYPE describes a group of similar facts (Halpin, 1998).
OBJECT TYPE	An OBJECT TYPE describes an existing or real thing in the universe of discourse (Bakema et al., 1996).
UNIQUE CONSTRAINT	A UNIQUE CONSTRAINT is added to an object where no duplicate values occur (Halpin, 1998). They are depicted as arrow bars to declare that instances for that role must be unique. Multiplicity is determined using UNIQUE CONSTRAINTS when deriving an ERD.
MANDATORY CONSTRAINT	A MANDATORY CONSTRAINT distinguishes between required and optional information (Halpin, 1998) and is the equivalent of a ‘not null’ constraint in ER-modeling.
VALUE CONSTRAINT	A VALUE CONSTRAINT restricts the population of a value type to a finite set of values specified either in full (enumeration), by start and end values (range), or some combination of both (Halpin, 1998).
G-IM	A GROUPED INFORMATION MODEL is a model where as many fact types as possible are combined in the same table without introducing redundancy (Bakema et al., 1996).
GL-IM	A GL-IM is a further derivation of the GROUPED-IM where each attribute of each relation has a lexical domain, the FACT TYPES (Bakema et al., 1996).
GLR-IM	A GLR-IM is a reduced lexicalized IM where each fact type leads to a separate table, with a separate column for each role (Bakema et al., 1996).

Related Literature

An extensive overview of ORM is described by Halpin (1998) which explains the main concepts and goals. More in-depth literature about Object Role Modeling can be found in Bakema, Zwart and Van der Lek (1994) and Kristensen (1995).

The main concepts and terminology of FCO-IM are touched upon in Bakema et al. (1996). FCO-IM closely resembles NIAM in respects such as the conceptual framework, the modeling constructs, the diagramming technique and the modeling method.

A comparison between UML and ORM has been conducted by Halpin and Bloesch (1999) where the design principles are examined to identify the relative strengths and weaknesses of UML and ORM for data modeling.

Furthermore, an ORM based requirements engineering process has been constructed which aims to reduce the number of IT project failures (Evans, 2005). According to the findings, ORM can be used to create a formal definition of requirements that covers both the data and process aspects of an application which can reduce waste and help to deliver projects on time and budget.

Subsequently, an ORM schema depicting an implementation of a requirements traceability metamodel has been provided by Piprani, Borg, Chabot, and Chartrand (2008). This metamodel enables the tracking of documents and actual requirements but also provides the capability for requirements lineage.

The Meta Object Facility (MOF) defines a framework for specifying, constructing and managing technology neutral meta-models. Lemmens, Nijssen and Nijssen (2007) apply the NIAM processes for developing a conceptual schema to the MOF four-layer meta-modeling architecture.

Bronts, Brouwer, Martens, and Proper (1995) introduced a concept to build a CASE-tool supporting multiple methods. This would allow users with different methodological backgrounds to use it and view the modeled domains in terms of their favorite method.

Currently, various ORM provide automated support for conceptual modeling, such as Microsoft's Visio for Enterprise Architects. The commercial tool CaseTalk? and the freeware tool Infagon support the FCO-IM dialect. These tools all have the functionality of modeling a certain Universe of Discourse in ORM, and support the automatic generation of a consistent and normalized relational database schema.

Further research continues in the field of ontology modeling. Mustafa, Demey and Meersman (2003) propose to (re) use conceptual methodologies and tools for ontology modeling. Sharing and exchanging data semantics has risen in popularity with the internet and open connectivity environments. This allows computer systems to meaningfully communicate in order to exchange data and make transactions interoperable independently of their internal technologies.

Finally, Halpin (2007) identifies topics for future research and provides an overview of several proposals to address the current deficiencies of ORM. On-going research is being conducted to transform ORM schemas to other structures, including UML, XML schema, external forms and web interfaces. Some ORM tools already provide automated mapping to object programming code. Finally, the use of ORM for designing and reusing ontologies and transforming ORM models to, for example, OWL (Web Ontology Language) is also being researched.

References

• Bakema, G., Zwart, J., & Van der Lek, H. (1994). Fully Communication Oriented NIAM. NIAM-ISDM 1994 Conference, Albuquerque, USA, 1-35. [PDF]

• Bakema, G., Zwart, J., & Van der Lek, H. (1996). Fully Communication Oriented Information Modeling (1st ed.). The Hague: Ten Hagen Stam. [PDF]

• Bronts, G. H., Brouwer, S. J., Martens, C. L., & Proper, H. A. (1995). A unifying object role modeling theory. Information Systems, 20(3), 213-235. [PDF]

• Evans, K. (2005). Requirements Engineering with ORM. On the Move to Meaningful Internet Systems 2005: OTM Workshops, Cyprus, 646-655. [PDF]

• Halpin, T. (1998). Object Role Modeling (ORM/NIAM). In P. Bernus, K. Mertins, & G. Schmidt (Eds.), Handbook on Architectures of Information Systems (pp. 81-101). Berlin: Springer-Verlag. [PDF]

• Halpin, T. (2007). Fact-Oriented Modeling: Past, Present and Future. In J. Krogstie, A. L. Opdahl, & S. Brinkkemper (Eds.), Conceptual Modeling in Information Systems Engineering (pp. 19-38). Berlin: Springer-Verlag. [PDF]

• Halpin, T., & Bloesch, A. (1999). Data modeling in UML and ORM: a comparison. Journal of Database Management, 10(4), 4-13. [PDF]

• Kristensen, B. B. (1995). Object-Oriented Modeling with Roles. Proceedings of the International Conference on Object-Oriented Information Systems, Dublin, 4-13. [PDF]

• Lemmens, I., Nijssen, M., & Nijssen, S. (2007). A NIAM2007 Conceptual Analysis of the ISO and OMG MOF Four Layer Metadata Architectures. Proceedings of the 2007 OTM confederated international conference on On the move to meaningful internet systems, LNCS 4805, Vilamoura, Portugal, 613-623. [PDF]

• Mustafa, J., Demey, J., & Meersman, R. (2003). On using conceptual data modeling for ontology engineering. Journal on data semantics, LNCS 2800, 185-207. [PDF]

• Piprani, B., Borg, M., Chabot, J., & Chartrand, É. (2008). An Adaptable ORM Metamodel to Support Traceability of Business Requirements across System Development Life Cycle Phases. On the Move to Meaningful Internet Systems: OTM 2008 Workshops, LNCS 5333, Monterrey, Mexico, 728-737. [PDF]

• Weerd, I. van de, & Brinkkemper, S. (2008). Meta-modeling for situational analysis and design methods. In M. Syed, & S. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications (pp. 38-58). Hershey: Idea Group Publishing. [PDF]

-- SanderVanDerRijnst - 15 April 2011