Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
Methodology | Legends | Conventions Used in EIDX Documentation | EIDX's Use of UML Class Diagrams | Procedures and Templates

EIDX Model Legends

On this Page:


Also Recommended:


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.

Traditional EIDX Representation (Use Case)

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.


Activity Diagrams

The base activity diagram for a component model or scenario represents our best attempt at a standards-neutral, technology-neutral view.  As mentioned before, technology-specific or standards-specific views may also be presented.


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




Last updated 06 February 2003