• Model Legends - Understanding EIDX Business Models
  • Traditional EIDX Representation (Use Case)
  • UML Activity Diagrams

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

Understanding EIDX Business Models

There are a number of ways of representing a business process graphically.  Many organizations are adopting the Unified Modeling Language (UML) for representing business processes.  The most commonly used are:

• Use Case Diagram - Defines the scope of the process, who the players are, and what the activities are
• Activity Diagram - a/k/a "Swim Lane" diagram, defines the flow of activities, with one swim lane per "actor" (party); shows where one actor hands off the process to another, and guard conditions the cause a decision to be made about taking one path vs. another.
• Sequence Diagram - Defines information flows; one limitation is that this type of diagram cannot represent concurrent activities.
• Class Diagram - Describes objects (such as a purchase order), their data attributes and operations that may be requested for a given object.

The EIDX community is made up of both business and technical constituents, and, as mentioned earlier, EIDX models are conceptual.  EIDX is using some UML, as described here.

Although UML notation is not used, the traditional EIDX representation is still considered to be very understandable to business people, and it serves the same function as a UML Use Case, i.e. to illustrate the scope of a process, the players, and the basic activities.

Context Diagrams

EIDX uses the term "context diagram" for lack of a better term -- be aware that some people use the term differently.  EIDX uses the term for a diagram that represents best-practice relationships between the component and scenario models. 

• Other ways of combining component models are technically possible, but if they are not shown on the context diagram, it's because they are not identified by EIDX as best practices.  Implementation costs can be reduced by agreeing on ways in which processes can be combined to create scenarios, instead of expecting companies to support every possible combination.

Each context diagram is from the perspective of one component or scenario model. 

• Example:  Compare context diagrams below for Forecast Model 3, Order Model 2, and Order Model 3A.   All three diagrams show all three component models, but each model is slightly different because each describes only that component model's relationships with other models.

Forecast Model 2	Order Model 2	Order Model 3A