Chapter Preview
TopBackground
A detailed treatment of early UML is provided by Rumbaugh et al. (1999). The latest specifications for UML may be accessed at www.uml.org/. The UML notation includes hundreds of symbols, from which various diagrams may be constructed to model different perspectives of an application. Structural perspectives may be modeled with class, object, component, deployment, package, and composite structure diagrams. Behavioral perspectives may be modeled with use case, state machine, activity, sequence, collaboration, interaction overview, and timing diagrams. This article focuses on data modeling, so considers only the static structure (class and object) diagrams. UML diagrams may be supplemented by textual constraints expressed in OCL. For a detailed coverage of OCL 2.0, see Warmer and Kleppe (2003). At the time of writing, the OCL specification has been upgraded to version 2.3.1 (OMG, 2012b).
ORM pictures the world simply in terms of objects (entities or values) that play roles (parts in relationships). For example, you are now playing the role of reading, and this article is playing the role of being read. Overviews of ORM may be found in Halpin (2006, 2010, 2011) and a detailed treatment in Halpin and Morgan (2008). For an overview including some history on other fact-oriented modeling approaches such as PSM (Hofstede, Proper, & van der Weide, 1993), see Halpin (2007b). Further coverage of specific topics on fact-orientation may be found in the references and additional readings.
Key Terms in this Chapter
Role: In ORM, a role is a part played in a fact type (relationship type). In UML, this is known as an association-end. For example, in the fact type Person works for Company, Person plays the role of employee, and Company plays the role of employer.
UML: The Unified Modeling Language adopted by the Object Management Group as a modeling language for object-oriented analysis and design of software systems. UML includes several sublanguages and diagram notations for modeling different aspects of software systems.
Entity Type: An entity is a non-lexical object that in the real world is identified using a definite description that relates it to other things (e.g., the Country that has CountryCode ‘US’). Typically, an entity may undergo changes over time. An entity type is a kind of entity, e.g., Person, Country. In UML, an entity is called an object, and an entity type is called a class.
ORM: Object-Role Modeling is a fact-oriented approach for modeling information at a conceptual level, using language that is easily understood by non-technical, domain experts. ORM includes rich graphical and textual languages for modeling facts and business rules, and provides procedures for creating conceptual models and queries and transforming them to lower level models and queries for implementation.
Business Rule: A constraint or derivation rule that applies to the business domain. An alethic/deontic static constraint restricts the possible/permitted states of the business, and a dynamic constraint restricts the possible/permitted transitions between states. A derivation rule declares how a fact may be derived from existing facts, or how an object is defined in terms of existing objects.
Fact Type: In ORM, a fact is a proposition taken to be true by the business community that either applies a logical predicate to a sequence of one or more objects of a given type, or simply asserts the existence of a given object. A fact type is a set of all possible instances of the same kind of fact. For example: Person smokes; Person was born in Country; Person introduced Person to Person. In UML, a non-unary fact type is an association.