{"id":831,"date":"2026-02-25T10:25:15","date_gmt":"2026-02-25T10:25:15","guid":{"rendered":"https:\/\/skills.visual-paradigm.com\/es\/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\/es\/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 \u00abprocess\u00bb in DFD becomes a \u00abuse case\u00bb in UML, and a \u00abdata store\u00bb becomes a \u00abclass,\u00bb 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 \u00abCalculate Customer Balance\u00bb corresponds to a UML use case named \u00abGenerate Account Statement.\u00bb 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 \u00abCustomer\u00bb may not be a data store unless it\u2019s the primary repository. A \u00abTransaction Log\u00bb 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 \u00abBank\u00bb as an external entity in DFD becomes the \u00abBank\u00bb actor in UML. But the UML actor may also carry responsibilities like \u00abvalidate transaction\u00bb or \u00abtrigger audit,\u00bb 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 \u00abCustomer Order\u00bb becomes a message in a sequence diagram: \u00abCustomer sends Order to OrderProcessor.\u00bb In a class diagram, it appears as an association between \u00abCustomer\u00bb and \u00abOrder\u00bb 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 \u00abSubmit Claim\u00bb data flow from a \u00abPatient\u00bb external entity becomes a \u00abPatient\u00bb actor invoking the \u00abFile Insurance Claim\u00bb 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 \u00abPayment\u00bb 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