{"id":831,"date":"2026-02-25T10:25:15","date_gmt":"2026-02-25T10:25:15","guid":{"rendered":"https:\/\/skills.visual-paradigm.com\/de\/docs\/dfd-vs-uml-when-to-use-each\/dfd-uml-decision-tools\/dfo-uml-glossary-cross-notation-reference\/"},"modified":"2026-02-25T10:25:15","modified_gmt":"2026-02-25T10:25:15","slug":"dfo-uml-glossary-cross-notation-reference","status":"publish","type":"docs","link":"https:\/\/skills.visual-paradigm.com\/de\/docs\/dfd-vs-uml-when-to-use-each\/dfd-uml-decision-tools\/dfo-uml-glossary-cross-notation-reference\/","title":{"rendered":"Cross-Notation Glossary and Mapping Reference"},"content":{"rendered":"

Most analysts struggle not with the diagrams themselves, but with the mental shift between two fundamentally different ways of seeing systems. One sees data in motion; the other sees objects in action. The real challenge isn\u2019t learning both notations\u2014it\u2019s understanding how to translate them. This page isn\u2019t a dictionary of symbols. It\u2019s a practical bridge between worlds. In my 20 years working with cross-functional teams, I\u2019ve found that the single biggest barrier to successful modeling isn’t complexity\u2014it\u2019s confusion over terminology. When a „process“ in DFD becomes a „use case“ in UML, and a „data store“ becomes a „class,“ misalignment happens instantly. This glossary resolves that friction. You\u2019ll gain a shared vocabulary to align developers, business analysts, and architects. It\u2019s the essential reference for anyone building models across both DFD and UML.<\/p>\n

Core Mapping: Translating DFD Elements to UML<\/h2>\n

Understanding how elements map across notations is the key to seamless collaboration. The same system can be viewed through different lenses. Here\u2019s the foundational mapping.<\/p>\n

DFD Process \u2194 UML Use Case<\/h3>\n

A DFD process represents a transformation of data. It takes inputs, applies logic, and produces outputs. In UML, this maps directly to a use case\u2014a goal-driven interaction between a user (actor) and the system. The distinction lies in focus: DFD highlights *what* data changes, UML highlights *why* the interaction happens.<\/p>\n

Example: A DFD process labeled „Calculate Customer Balance“ corresponds to a UML use case named „Generate Account Statement.“ The function is identical, but the stakeholder intent differs.<\/p>\n

DFD Data Store \u2194 UML Class (with Persistence)<\/h3>\n

Data stores represent persistent data\u2014files, databases, or queues. In UML, this maps to a class with attributes and persistence. However, not all classes are data stores. Only those with a clear role as a data repository qualify.<\/p>\n

Key distinction: A class like „Customer“ may not be a data store unless it\u2019s the primary repository. A „Transaction Log“ file is a data store. The class representing it in UML must include persistence semantics.<\/p>\n

DFD External Entity \u2194 UML Actor<\/h3>\n

External entities are sources or sinks of data. UML\u2019s actors represent roles\u2014typically users or other systems\u2014that initiate interactions. The mapping is direct, but the intent differs.<\/p>\n

Example: A „Bank“ as an external entity in DFD becomes the „Bank“ actor in UML. But the UML actor may also carry responsibilities like „validate transaction“ or „trigger audit,“ which aren\u2019t captured in DFD.<\/p>\n

DFD Data Flow \u2194 UML Message \/ Association<\/h3>\n

Data flows are the lifeblood of DFDs. They represent data moving between processes, data stores, and external entities. In UML, this becomes a message in a sequence diagram or an association in a class diagram.<\/p>\n

When modeling interactions, a data flow like „Customer Order“ becomes a message in a sequence diagram: „Customer sends Order to OrderProcessor.“ In a class diagram, it appears as an association between „Customer“ and „Order“ with multiplicity.<\/p>\n

DFD Data Flow (in Context Diagram) \u2194 UML Use Case (in Use Case Diagram)<\/h3>\n

At the system boundary, DFD context diagrams show external entities and data flows. UML use case diagrams show actors and use cases. The data flow between a system and an external entity maps to a relationship between actor and use case.<\/p>\n

For example, a „Submit Claim“ data flow from a „Patient“ external entity becomes a „Patient“ actor invoking the „File Insurance Claim“ use case. The flow direction is preserved.<\/p>\n

Common Confusion Points: Terminology That Misleads<\/h2>\n

These terms appear similar but mean different things in context. Confusing them leads to model drift and communication breakdown.<\/p>\n

\u201cProcess\u201d vs. \u201cUse Case\u201d<\/h3>\n

Both appear as a rounded rectangle. But a DFD process is *functionally defined*\u2014it transforms data. A UML use case is *goal-oriented*\u2014it describes a user\u2019s objective. A process may not involve a user at all. A use case always involves an actor.<\/p>\n

\u201cData Store\u201d vs. \u201cClass\u201d<\/h3>\n

All data stores are classes in UML, but not all classes are data stores. A class like „Payment“ may be a data object, but unless it\u2019s persistent and stored, it doesn\u2019t map directly to a data store. The key is persistence, not just existence.<\/p>\n

\u201cData Flow\u201d vs. \u201cMessage\u201d<\/h3>\n

Data flow is a *stateless transfer of data*. Message is a *synchronous or asynchronous request* between objects. A data flow can become a message, but only when the interaction is behaviorally significant. A read from a file is a data flow. Sending an email to trigger a process is a message.<\/p>\n

Visual Paradigm Element Linking Guidance<\/h2>\n

When using Visual Paradigm, you can create live links between DFD and UML elements. This ensures consistency and enables traceability.<\/p>\n