December 2000        Issue: 17

Journal of Conceptual Modeling
www.inconcept.com/jcm

Object-Role Modeling Wish List (Part One)
by Patrick Hallock

 Introduction

InConcept has been involved in an effort to publicly discuss a meta-model for Object-Role Modeling.  [Editor's Note: For an ongoing discussion of the development of an ORM metamodel, see the InConcept/JCM Metamodel project.] So far, two meta-models that involved ORM have been provided on our web site. The purpose of this was to start an open conversation about ORM and thereby gain some future model that included issues from the field. In order to keep that idea alive, I'd like to begin a series of articles; each article addressing a narrow part of ORM.

The goal is go get a better product in the field. InConcept is certainly interested in systems that work from a fact, rule based approach. The approach should be declarative and highly productive. I hate redundant or long complex approaches that really do not serve any purpose except creating paper.

This first article will not address any logical modeling issues, mapping issues, indexes, foreign keys, and etc. Instead, part 1 focuses on defining objects, facts, examples, and naming.

This is not an exhaustive document and several of these features already exist. These ideas are mostly an attempt to create a faster specification to implementation approach. There is, of course, a bias towards the use of ORM as the language of specification.

Conceptual Modeling and Specification

Everyone involved in modeling speaks about semantic modeling. As such, all vendors claim that they produce a semantic model. However, few actually do so, or at least they provide limited semantics in that they only relate to the relationships between entities. Further, the semantics in the model are then repeated in the specification making the specification and model two distinct steps. It would be highly desirable to capture both the conceptual model and specification, thereby having only one step.

Objects assert that something exists. Without objects we have nothing to talk about. Here are a few things that exist in the example subject area:

Thinking along the lines of a specification, what could we record at the object conceptual level?

Conceptual Name

The conceptual name is the common use name for some object real or imaginary. The most basic part of language is the ability to identify objects by name. The conceptual name should be the "real" name and not some acronym for the name (e.g. "United States Navy", not "USN"; "Internal Revenue Service", not "IRS").

Definition

I find this the hardest part. The goal is to describe some object without getting too involved in the roles the object plays. There are cases where a role is naturally required, but this is not the place to explain what an object does in great detail. If you fail to do this, the object definition and the roles an objects plays become blurred and difficult to maintain.

Examples:

Definition of "Employee": "The employee is a person that is employed by the Enterprise"
Related Objects (derived from/synchronized with the model): Employee - Person - Enterprise
Related Facts (derived from/synchronized with the model): Employee is a subtype of Person, Employee is employed by the Enterprise

Definition of "Date": "Date, which includes time, is the date-time of some event."

Note: The event can be deferred to a predicate using date (e.g. Employee hire Date, Employee birth Date)

Source

The source denotes/traces the origination of a particular piece of the model. The source should be a modeler-defined list of valid sources. Sources can be individuals; departments or external sources such as other systems or standards bodies.

Acceptance Date

The date a modeling element is accepted as part of the specification.

Examples

Since modeling efforts usually involve talking to several interested groups, two sets of examples are proposed. Consider example object instances: the business group finds example that use more common reference modes more useful (which I call "conceptual examples"), while MIS prefers to see examples of actual column populations, abbreviated/encoded where needed (which I call the "logical examples").

For example, using the object "Employee" that is identified by an Employee ID:

Note: The logical example data should be used to populate a test version of the database. Due to uniqueness issues, the conceptual example data would not work for that purpose, but I'll come back to that.

When the object type is a value type (such as a Temperature of 98.6 degrees) it is both the logical and conceptual example (ignoring for the moment that temperature also needs a unit of measure or domain).

The current standard reading as implemented by VisioModeler is more of a logical reading when examples are used. What is desired is a more flexible way to format the sentences. Providing both a logical and a conceptual reading would be useful when talking to many reviewers. For example:

Note: Underlining indicates the example, objects are bolded and the predicate is italics.

The order of object and example should be allowed in a preferred order. This option controls the object/example pair and not the entire fact.

Consider the following:

Examples for the object "Department"

Examples for the object "Employee"

Then given the fact, "Department employs Employee", we can use these readings:

Conceptual Readings:

The Finance Department employs the Employee Mike Allinder 101
The Marketing Department employs the Employee Mike Allinder102
The Finance Department employs the Employee George of the Jungle

Note: The superscript indicates the Mike Allinder identified by 101 is selected -- and not the Mike Allinder identified by 102

Logical Reading: The Department MKT employs the Employee 101.

The following table then controls the ordering of the object/example pairs:

This indicates example is first in the object/example pair and the object is first in the second object/example pair (e.g. "The Marketing Department employs the Employee Mike Allinder.")

This sure does read nice and is not as cryptic as the logical reading; examples are non-logical reference modes, like names of people or names of department, rather than their future representation of codes and ids.

The definition of an object should be done one time and in one place. It acts as the specification of the object. A real goal is to eliminate several steps between the specification at the requirement level and the implementation level. If the object is given at the specification level, we should have an expectation that a few associated facts will be completed as the model proceeds, but not in a different place.

Some specification systems have methods for collecting requirements. These are data, process and feature requirements, for example:

As a final note, we should keep the examples instances tied to the fact that uses them, but also create the list of example choices within the object itself. Keeping the conceptual and logical examples sourced from the object allows for a representative set within the object itself. This in turn becomes a selection list when assigning example instances to facts. It also allows the fact examples to easily comply with all associated constraints. If two roles are exclusionary (X), then the examples used in the facts should also be exclusionary. Note that this would be required if the logical examples where to be the source for an automated test population for the database. The examples would have to obey the rules.

To summarize, a requirements document is a very reachable goal from ORM gathered information. If ORM can be seen as a specification tool, then ORM can be used as a standard part of the requirements gathering process (e.g. if the marketplace can see this type of benefit, it should be easier to incorporate ORM into the process).

More on Naming

Naming is actually a mapping function. The conceptual naming is fine for reviews with non-MIS reviews, but often the MIS people want to know about a naming standard. The naming standard should be defined within the conceptual definitions. This allows the naming police to define the naming rules while watching over the conceptual model. The conceptual name plus some rules should result in the approved, logical name.

The fact, "Employee works for Department" has two objects, and there are several possible naming concepts.

This example specifies that:

When Employee is used a table name use Employee.
When Employee is used as a column name use Emp.
Department is always abbreviated.
When the predicate "works" for is used then the role name is "works for Dept.", which becomes the column name, "works_for_dept".

In naming, the user interface for naming control is very important. The ability to view and manage all the naming possibilities should be available prior to mapping to a logical view. Granted this is not a conceptual step, but it is part of the mapping rule set and as such, the mapping rules are a separate step in the process.

Today the various naming possibilities are in different areas of the tool. Rather, than spreading the naming possibilities across several screens, it should be done in a single interface dedicated to naming. The abbreviation list, the role names, and the reference naming are all part of naming. Ideally, this function should be redesigned to make it easier to control.

Further, the ability to override the name in the logical model (as currently implemented) causes some problems in the conceptual-to-logical model mapping. If the logical model name is overridden and then the conceptual name is changed, the overridden value remains. This overridden name is now possibly out-of-line with the new conceptual name. If any conceptual name is changed, a view needs to be presented that shows the impact of this change on over-written logical names. The modeler can then adjust these names. It may be that the over-written logical name is to remain, or maybe it is merely erased and a newly generated name will automatically be generated.

Bring Back ConQuer

That wonderful conceptual query tool is needed to answer user questions and to investigate the model in general. During a review the most common issues fit into:

The ideal answer is to navigate the model using the ConQuer tool. What better way to demonstrate the use of the model - without having any database? Show the example data as well, both conceptual and logical. What a motivation for doing the examples! They are simply the best specification documentation of intent we have.

And at last but not least, we need an open specification that supports simple interfaces. This would allow applications as simple as MS Excel or MS Access to get information and report it in any manner the modeler (or reviewer) desires.

Part 2 will concentrate on the needs for a specification approach. But for now, feel free to comment to me via the JCM discussion list.  

Patrick Hallock is a Senior Partner and Principal Consultant for InConcept. He has over 20 years of ORM/NIAM experience and is  a certified ORM consultant, trainer/train the trainer and a certified Visio trainer.

Contact Information:

Patrick Hallock
President and Co-Founder
InConcept
8171 Hidden Bay Trail N
Lake Elmo, MN 55042
path@inconcept.com
(651) 777-8484
fax: (651) 777-9634
http://www.inconcept.com

© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement.
ISSN: 1533-3825