• UML Class Diagrams
  • Relationships (Inheritance, Aggregation, Composition)
  • Multiplicity (Cardinality)

• EIDX Methodology
• Model Legends - Understanding EIDX Business Models
• Abbreviations and Conventions used when describing  business content standards (X12, EDIFACT, RosettaNet, OAGI, etc.)
• Tour the Clickable Business Models
• The Glossary
• Acronyms and Abbreviations
• EIDX Development Process
• Class:  Introduction to EIDX Business Model Development Process

Relationships

Purchase_Order_Document may be an abstract class that cannot be instantiated - you can't produce a "Purchase_Order_Document; it exists only to define attributes that are common to two or more other things.

You can instantiate (produce) an actual Discrete_Purchase_Order or Blanket_Order_Qty_Firm, which each inherit all the attributes of Purchase_Order_Document.

The terms "Generalization" and "Specialization" are also used.  The object on the arrow-end is a generalization, and the object(s) on the none-arrow end are specializations.  Discrete_Purchase_Order is a specialization of Purchase_Order_Document.

Multiplicity is not denoted; the relationship in inheritance is always 1:1.

The difference between aggregation and composition may be subjective, especially when dealing with groupings of data objects used in business document definitions.  Does Receipt_Data cease to exist if Line_Item_Comsumption_Plan ceases to exist?  The example below suggests that if Line_Item_Consumption_Plan is destroyed, Receipt_Data could still exist by itself.   In the second example, both Replenishment Scenarios "have" Order Model 2 in them.  If the Replenishment Scenarios are destroyed, Order Model 2 could still exist and be implemented by itself.  It could be argued, on the other hand, that Order Model 2 has no meaning except in the context of a Replenishment Scenario, and that the "composition" symbol should be used to indicate that if all the Replenishment Scenarios that use Order Model 2 are destroyed, then Order Model 2 is destroyed also.

Multiplicity is denoted per the table below.

In the example below, Order_Line_Item is part of Discrete_Purchase_Order and also part of Blanket_Order_Qty_FIrm. Order_Line_Item has no existence by itself. Discrete_Purchase_Order and Blanket_Order_Qty_FIrm are both destroyed, Order_Line_Item ceases to exist.  As long as at least one of Discrete_Purchase_Order and Blanket_Order_Qty_FIrm exist, Order_Line_Item can exist.

Multiplicity is denoted per the table below.