by Jerry E. Stembridge

Unified Modeling Language (UML)

Integrated Computer Aided Manufacturing (ICAM) Definition Language (IDEF1x)

In the UML the Class Diagram is used to model data requirements

A UML class is modeled as a box and two solid horizontal lines are used to separate the box into three sections. The top section contains the class name, the middle section contains the class attributes and the bottom section contains the methods or behavior supported by the class.

The major difference between a UML class and an IDEF1x entity is the presence of methods in a class. A method represents a service that can be requested of a class to affect its behavior (i.e., perform operations on its attributes). An IDEF1x entity can be thought of as a UML class without operations.

The UML is an Object Oriented (OO) modeling language and as such it uses the object paradigm of an Object Identifier (OID) to uniquely identify instances of a class (objects). Key inheritance and the use of a Primary Key are concepts that do not exist in the UML.

An entity represents a set of "things" such as persons, places, abstractions, or things that are relevant to a business and about which data is collected and maintained. These things share a set of characteristics by which they can be uniquely described. An individual member of the set is referred to as an entity instance.

In IDEF1x an entity is modeled as a box and a single solid horizontal line is used to separate the box into two sections. The top section contains one or more attributes which comprise the unique identifier (primary key) for the entity. The bottom section contains the non-primary key attributes, which characterize the entity. Each entity is assigned a unique name, which is placed above the box.

IDEF1x is an Entity-Relationship (ER) modeling language and as such it uses the concept of a primary key, which is borrowed from the Relational Model, to uniquely identify instances of an entity. The primary key of an entity is defined as one or more attributes, whose value uniquely identifies every instance of the entity. For example, the entity person might have the attributes: person-identifier, person-name and person-address, where person-identifier is the primary key.

In the UML a relationship is called an association. An association is modeled using a solid line that connects two classes.

The UML uses object identifiers to uniquely identify instances of a class (objects) and does not support the concepts of key inheritances, primary keys and foreign keys.

A relationship is an association between two or more entities that reflects a relevant business rule. In IDEF1x a relationship is modeled as a line drawn between entity boxes, with a dark circle on one end of the line. The entity touched by the dark circle is called the child entity and the entity at the other end of the line is called the parent entity. The relationship lines differ in appearance based on the idea of primary key inheritance.

Key inheritance is defined as follows: If a relationship exists between two entities, the attributes that form the primary key of the parent entity are inherited as attributes of the child entity. These inherited attributes are referred to as foreign keys.

If an instance of a child entity is uniquely identified by its association with the parent entity, then the relationship is said to be an identifying relationship, and the relationship line is a modeled as a solid-line.

If every instance of a child entity can be uniquely identified without knowing the associated instance of the parent entity, then the relationship is said to be a non-identifying relationship, and the relationship line is modeled as a dashed-line.

In the UML cardinality is called multiplicity. Multiplicity refers to the number of objects in one class that can be related to one object in the related class.

In the UML multiplicity is modeled as follows:

- A range, like 1..12, or

- A single value, like 4, or

- An interval, like 1,4,8,32, or

- A combination of a range and an interval, like 1..5,9,14

In the UML multiplicity can be used on both sides of an association line. An asterisk (*) is used to denote a multiplicity of "many". The symbols 0..* and the * by itself are read as "zero, one or more". An association line without any multiplicity is read as "many to many" (note this differs from an IDEF1x relationship line without any cardinality adornments, which is read as "one to one").

In an IDEF1x data model relationships between entities are constrained by adornments at each end of the relationship line. These constraints are called cardinality.

Cardinality represents the maximum number of times an entity instance in one entity can be related to the set of entity instances in another entity.

In IDEF1x cardinality is modeled as follows:

- Each parent entity instance may have zero; one or more associated child entity instances, or

- Each parent entity instance must have at least one or more associated child entity instances, or

- Each parent entity instance can have none or at most one associated child instance, or

- Each parent entity instance is associated with some exact number of child entity instance

In the UML an IDEF1x dependent entity is modeled with an association class. The associative class is modeled as a class (box) connected to an association line (that is a solid line), with a dashed line.

In IDEF1x the child entity in a relationship is said to be existence dependent upon the parent entity in that an instance of the child entity can only exist if the associated instance of the parent entity exists. For example, in a relationship between the entities customer and policy, a customer is the insured-party for zero, one, or more policies and each policy must insure exactly one person.

In IDEF1x a dependent entity is modeled as a box with rounded corners.

An N-ary association is an association between three or more classes. In the UML an N-ary association is modeled by connecting each class that participates in the N-ary association to a large diamond using an association line (that is a solid line).

In IDEF1x an N-ary relationship is modeled using a dependent entity where the dependent entity is dependent upon all of the entities that participate in the relationship.

In the UML an IDEF1x category is modeled as a subtype class. In both the UML and IDEF1x the supertype of a set of subtypes is referred to as a generalization and the constructs used to represent a subtype / supertype relationship is referred to as a generalization hierarchy. The child or subtype in the hierarchy inherits all of the characteristics of the parent or supertype. In the UML a subtype / supertype association is modeled by connecting each subtype class to the supertype class with a block arrowhead

Entities represent things about which we need to collect and keep information. Some entities are categories of other entities. For example a bank collects and keeps information about customer accounts. Some accounts are checking and some are savings. Some of the information collected about accounts is applicable to both checking and saving accounts, e.g., owners name and address. However, some information is unique to either checking or savings accounts. Therefore, the entities saving-account, and checking-account are categories of the entity account. In IDEF1x these entities are modeled using a categorization relationship, which is also called a subtype, or an "is-a" relationship.

In IDEF1x a category is modeled using a circle on the line that connects the supertype to its subtypes. The name of the generic entity attribute used as the discriminator is written beside the circle. Either one or two solid horizontal lines are drawn under the circle. A single lines means the that there may be more subtypes, for this supertype hierarchy, than those shown in the data model. Two lines means that the supertype hierarchy is complete and there are no other subtypes than those shown in the data model.