{"id":797,"date":"2026-02-25T10:24:58","date_gmt":"2026-02-25T10:24:58","guid":{"rendered":"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/"},"modified":"2026-02-25T10:24:58","modified_gmt":"2026-02-25T10:24:58","slug":"external-entity-vs-uml-actor","status":"publish","type":"docs","link":"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/","title":{"rendered":"DFD External Entities vs. UML Actors: Stakeholder Modeling"},"content":{"rendered":"<p>When I walk into a requirements workshop and see a diagram where every external system is drawn as a box with a label, I pause. That\u2019s often a DFD external entity. But when I see a sketch of a person or role with a stick figure and a name like \u201cCustomer\u201d or \u201cAdmin,\u201d I know we\u2019re in UML actor territory. The difference isn\u2019t just visual\u2014it\u2019s philosophical.<\/p>\n<p>Most teams don\u2019t realize that choosing between DFD external entities and UML actors isn\u2019t about preference\u2014it\u2019s about intent. The former asks: \u201cWhere does the data come from and go to?\u201d The latter asks: \u201cWho triggers what, and why?\u201d If your goal is to trace a transaction from start to finish across systems, DFD\u2019s simplicity wins. But if you must capture user goals, system triggers, or exception flows, UML\u2019s actor role becomes essential.<\/p>\n<p>I\u2019ve seen teams try to model a healthcare portal using only DFD externals. The result? A list of data sources\u2014\u201cPatient Portal,\u201d \u201cInsurance Provider,\u201d \u201cLab System\u201d\u2014but no way to say *what action* the patient takes, or how the system responds. That\u2019s where UML actors add meaning. They bring in the *behavioral intent* behind a stakeholder\u2019s interaction.<\/p>\n<p>This chapter dives into the real-world trade-offs. You\u2019ll learn when to use clean, minimal external entities and when to dive into the richer, goal-driven modeling of UML actors. You\u2019ll also uncover how boundary analysis determines which method fits your project\u2019s context\u2014no fluff, just practical judgment grounded in 20 years of system design.<\/p>\n<h2>Data Source vs Behavioral Role: Core Difference<\/h2>\n<p>The confusion between DFD external entities and UML actors often starts with semantics. But the real divide lies in their purpose.<\/p>\n<p><strong>Data source vs behavioral role<\/strong> is not a minor distinction\u2014it\u2019s the foundation of how you model interactions.<\/p>\n<ul>\n<li><strong>DFD External Entities<\/strong> are passive: they are sources or sinks of data. They don\u2019t act. They don\u2019t have goals. They simply exchange information.<\/li>\n<li><strong>UML Actors<\/strong> are active: they represent roles that trigger system behavior through specific goals. They have intentions, responsibilities, and often participate in use cases.<\/li>\n<\/ul>\n<p>Think of a grocery store checkout. In DFD, \u201cCustomer\u201d and \u201cPayment Gateway\u201d are external entities. They represent data inputs: \u201cCustomer pays via credit card.\u201d But in UML, the \u201cCustomer\u201d actor is not just a data source\u2014it\u2019s the one who *initiates* a \u201cPay for Items\u201d use case. The system responds, and that\u2019s where the model becomes actionable.<\/p>\n<h3>When Simplicity Is Enough: DFD External Entities<\/h3>\n<p>Use DFD external entities when your primary focus is on data flow and system boundaries. This works best in:<\/p>\n<ul>\n<li>Regulatory or compliance environments (e.g., SOX, HIPAA) where end-to-end data lineage matters.<\/li>\n<li>Legacy system modernization where you\u2019re reverse-engineering a mainframe or batch process.<\/li>\n<li>Early-stage requirements with business analysts who need clarity on data movement, not object behavior.<\/li>\n<\/ul>\n<p>In a financial reporting system, you might model \u201cTax Authority\u201d and \u201cBank\u201d as external entities. Their role is clear: they receive or send data. No need to define what the bank *does* beyond sending a payment confirmation. That\u2019s a detail for later.<\/p>\n<h3>When Behavior Matters: UML Actors<\/h3>\n<p>Choose UML actors when your system involves user interaction, goal-driven workflows, or complex triggers.<\/p>\n<p>Consider an e-commerce platform. The \u201cCustomer\u201d isn\u2019t just a data point\u2014it *adds items to cart*, *checks out*, and *files a dispute*. Each of these is a *use case*, and the customer is the actor who *initiates* them. You can\u2019t model this meaningfully with just a data source.<\/p>\n<p>Use UML actors when:<\/p>\n<ul>\n<li>Multiple user roles exist with distinct goals (e.g., \u201cAdmin,\u201d \u201cSupport Agent,\u201d \u201cCustomer\u201d).<\/li>\n<li>System behavior is activated by specific user actions, not just data arrival.<\/li>\n<li>You need to model exceptions, alternative flows, or pre\/post-conditions tied to user intent.<\/li>\n<\/ul>\n<p>For example, in a healthcare system, \u201cNurse\u201d and \u201cDoctor\u201d aren\u2019t just data sources\u2014they are actors who *order tests*, *review results*, and *sign discharge papers*. Their responsibilities define system behavior.<\/p>\n<h2>Boundary Analysis: Where to Draw the Line<\/h2>\n<p>Understanding the boundary between data flow and behavioral roles comes down to one question: <strong>Is this interaction defined by data exchange or by action?<\/strong><\/p>\n<p>When the system responds to a *trigger*\u2014a button click, a login, a payment confirmation\u2014behavior dominates. When it responds to a *data arrival*\u2014a file upload, a batch job completion\u2014data flow dominates.<\/p>\n<p>Here\u2019s a simple decision guide:<\/p>\n<table>\n<thead>\n<tr>\n<th>Scenario<\/th>\n<th>Best Model<\/th>\n<th>Why<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Monthly payroll file sent from HR system<\/td>\n<td>DFD External Entity<\/td>\n<td>Passive data transfer. No user action required.<\/td>\n<\/tr>\n<tr>\n<td>Customer logs in to view account balance<\/td>\n<td>UML Actor<\/td>\n<td>User triggers a goal: \u201cView Balance.\u201d Behavior matters.<\/td>\n<\/tr>\n<tr>\n<td>Invoice data received from supplier via EDI<\/td>\n<td>DFD External Entity<\/td>\n<td>System processes data; no user behavior involved.<\/td>\n<\/tr>\n<tr>\n<td>Customer files a refund request<\/td>\n<td>UML Actor<\/td>\n<td>Initiates a business process. Goal-driven.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Notice the pattern: when a human user *initiates* an action, UML actors are needed. When the system *responds* to a data packet, external entities suffice.<\/p>\n<h2>Practical Case: Insurance Claims Processing<\/h2>\n<p>Let\u2019s say you\u2019re modeling a claims system. The business says: \u201cWe receive claim data from the insured, verify it with the provider, and pay the claim.\u201d At first glance, this seems like a pure DFD scenario.<\/p>\n<p>But dig deeper: who *files* the claim? The insured. Who *approves* the verification? The claims adjuster. Who *disputes* the decision? The insured again.<\/p>\n<p>With only DFD external entities, you\u2019d label \u201cInsured\u201d and \u201cProvider\u201d as data sources. But you can\u2019t capture:<\/p>\n<ul>\n<li>How a claim is *initiated*.<\/li>\n<li>What happens if the adjuster *rejects* the claim.<\/li>\n<li>How the insured *responds* to a rejection.<\/li>\n<\/ul>\n<p>This is where UML actors become essential. You model:<\/p>\n<ul>\n<li><strong>Insured<\/strong> \u2192 \u201cFile Claim\u201d<\/li>\n<li><strong>Claims Adjuster<\/strong> \u2192 \u201cReview Claim\u201d<\/li>\n<li><strong>System<\/strong> \u2192 \u201cNotify Rejection\u201d<\/li>\n<\/ul>\n<p>Now you have a complete behavioral model. The DFD shows the flow of the claim form. The UML actors show who *does what*, and when.<\/p>\n<p>So here\u2019s my rule: if you can describe the interaction in one sentence using \u201cX sends data to Y,\u201d use DFD. If you need \u201cX does Y to achieve Z,\u201d use UML actors.<\/p>\n<h2>Hybrid Approach: When Both Are Needed<\/h2>\n<p>Here\u2019s a pro tip: <strong>you don\u2019t have to choose only one<\/strong>. In many projects, I\u2019ve used a layered approach:<\/p>\n<ol>\n<li>Start with a DFD context diagram to define system boundaries and data sources\/sinks.<\/li>\n<li>Then, use UML use case diagrams to model *who interacts with the system* and *what goals they pursue*.<\/li>\n<li>Map DFD external entities to UML actors where they trigger use cases.<\/li>\n<\/ol>\n<p>This gives you both clarity and depth. The DFD says: \u201cThis system receives data from the bank.\u201d The UML says: \u201cThe customer initiates a \u2018Transfer Funds\u2019 use case.\u201d Together, they cover the full picture.<\/p>\n<p>For example, in a government benefits portal:<\/p>\n<ul>\n<li>DFD: \u201cCitizen\u201d and \u201cSocial Security Administration\u201d are external entities.<\/li>\n<li>UML: \u201cCitizen\u201d is an actor who triggers \u201cApply for Benefits\u201d and \u201cCheck Status\u201d use cases.<\/li>\n<\/ul>\n<p>This hybrid model is common in regulated environments where audit trails (DFD) and user workflows (UML) are both required.<\/p>\n<h2>Frequently Asked Questions<\/h2>\n<h3>Can one external entity become multiple UML actors?<\/h3>\n<p>Yes. A single DFD external entity like \u201cCustomer\u201d may represent different roles\u2014\u201cBuyer,\u201d \u201cSupport Requester,\u201d \u201cRefunder.\u201d Each should be modeled as a separate UML actor if they trigger distinct goals. Never conflate roles in UML; clarity comes from separation.<\/p>\n<h3>Is UML actor modeling always more complex than DFD external entities?<\/h3>\n<p>Not inherently. The complexity comes from intent. If your system has no user interaction\u2014just data pipelines\u2014DFD external entities are simpler. But if the system is driven by user actions, UML actors add value without extra overhead.<\/p>\n<h3>How do I know if I should use a UML actor or just a data source?<\/h3>\n<p>Ask: \u201cDoes this external entity initiate a goal, or just exchange data?\u201d If it triggers a process (e.g., \u201cSubmit Application\u201d), use a UML actor. If it only sends or receives data (e.g., \u201cIRS Database\u201d), use DFD external entity.<\/p>\n<h3>Can I use DFD for systems with strong user interaction?<\/h3>\n<p>Yes\u2014but only at the boundary level. DFD can show \u201cUser\u201d as an external entity for data flows. But to model user goals, exception flows, or state transitions, you must use UML. DFD alone won\u2019t capture behavioral intent.<\/p>\n<h3>What about roles that aren\u2019t human\u2014like a system or external API?<\/h3>\n<p>For non-human roles, use DFD external entities if the interaction is purely data-based (e.g., \u201cPayment Gateway API\u201d). If the system triggers a specific action (e.g., \u201cSystem initiates reconciliation\u201d), model it as a UML actor with a goal like \u201cTrigger Reconciliation.\u201d<\/p>\n<h3>Does UML actor modeling increase development time?<\/h3>\n<p>Only if you over-model. The key is to focus on *relevant* actors\u2014those who interact with the system in meaningful ways. Don\u2019t model every data sender as an actor. Use actors only when behavior, goals, or triggers are involved. Overuse leads to clutter. Underuse misses critical workflows.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>When I walk into a requirements workshop and see a diagram where every external system is drawn as a box with a label, I pause. That\u2019s often a DFD external entity. But when I see a sketch of a person or role with a stick figure and a name like \u201cCustomer\u201d or \u201cAdmin,\u201d I know [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":792,"menu_order":4,"template":"","meta":{"_acf_changed":false,"inline_featured_image":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"doc_tag":[],"class_list":["post-797","docs","type-docs","status-publish","hentry"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.2 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>External Entity vs UML Actor<\/title>\n<meta name=\"description\" content=\"Compare DFD external entities vs UML actors in stakeholder modeling. Learn when data source\/sink abstraction suffices vs when behavioral role modeling is essential. Practical guidance for project teams.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"External Entity vs UML Actor\" \/>\n<meta property=\"og:description\" content=\"Compare DFD external entities vs UML actors in stakeholder modeling. Learn when data source\/sink abstraction suffices vs when behavioral role modeling is essential. Practical guidance for project teams.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/\" \/>\n<meta property=\"og:site_name\" content=\"Visual Paradigm Skills Fran\u00e7ais\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\n\t<meta name=\"twitter:data1\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/\",\"url\":\"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/\",\"name\":\"External Entity vs UML Actor\",\"isPartOf\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/fr\/#website\"},\"datePublished\":\"2026-02-25T10:24:58+00:00\",\"description\":\"Compare DFD external entities vs UML actors in stakeholder modeling. Learn when data source\/sink abstraction suffices vs when behavioral role modeling is essential. Practical guidance for project teams.\",\"breadcrumb\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/skills.visual-paradigm.com\/fr\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Data Flow Diagrams vs. UML: When to Use Each\",\"item\":\"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Detailed Diagram Type Comparisons\",\"item\":\"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/\"},{\"@type\":\"ListItem\",\"position\":4,\"name\":\"DFD External Entities vs. UML Actors: Stakeholder Modeling\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/fr\/#website\",\"url\":\"https:\/\/skills.visual-paradigm.com\/fr\/\",\"name\":\"Visual Paradigm Skills Fran\u00e7ais\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/fr\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/skills.visual-paradigm.com\/fr\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/fr\/#organization\",\"name\":\"Visual Paradigm Skills Fran\u00e7ais\",\"url\":\"https:\/\/skills.visual-paradigm.com\/fr\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/fr\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/skills.visual-paradigm.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/02\/favicon.svg\",\"contentUrl\":\"https:\/\/skills.visual-paradigm.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/02\/favicon.svg\",\"width\":70,\"height\":70,\"caption\":\"Visual Paradigm Skills Fran\u00e7ais\"},\"image\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/fr\/#\/schema\/logo\/image\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"External Entity vs UML Actor","description":"Compare DFD external entities vs UML actors in stakeholder modeling. Learn when data source\/sink abstraction suffices vs when behavioral role modeling is essential. Practical guidance for project teams.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/","og_locale":"fr_FR","og_type":"article","og_title":"External Entity vs UML Actor","og_description":"Compare DFD external entities vs UML actors in stakeholder modeling. Learn when data source\/sink abstraction suffices vs when behavioral role modeling is essential. Practical guidance for project teams.","og_url":"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/","og_site_name":"Visual Paradigm Skills Fran\u00e7ais","twitter_card":"summary_large_image","twitter_misc":{"Dur\u00e9e de lecture estim\u00e9e":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/","url":"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/","name":"External Entity vs UML Actor","isPartOf":{"@id":"https:\/\/skills.visual-paradigm.com\/fr\/#website"},"datePublished":"2026-02-25T10:24:58+00:00","description":"Compare DFD external entities vs UML actors in stakeholder modeling. Learn when data source\/sink abstraction suffices vs when behavioral role modeling is essential. Practical guidance for project teams.","breadcrumb":{"@id":"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/external-entity-vs-uml-actor\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/skills.visual-paradigm.com\/fr\/"},{"@type":"ListItem","position":2,"name":"Data Flow Diagrams vs. UML: When to Use Each","item":"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/"},{"@type":"ListItem","position":3,"name":"Detailed Diagram Type Comparisons","item":"https:\/\/skills.visual-paradigm.com\/fr\/docs\/dfd-vs-uml-when-to-use-each\/dfd-vs-uml-diagram-comparison\/"},{"@type":"ListItem","position":4,"name":"DFD External Entities vs. UML Actors: Stakeholder Modeling"}]},{"@type":"WebSite","@id":"https:\/\/skills.visual-paradigm.com\/fr\/#website","url":"https:\/\/skills.visual-paradigm.com\/fr\/","name":"Visual Paradigm Skills Fran\u00e7ais","description":"","publisher":{"@id":"https:\/\/skills.visual-paradigm.com\/fr\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/skills.visual-paradigm.com\/fr\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Organization","@id":"https:\/\/skills.visual-paradigm.com\/fr\/#organization","name":"Visual Paradigm Skills Fran\u00e7ais","url":"https:\/\/skills.visual-paradigm.com\/fr\/","logo":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/skills.visual-paradigm.com\/fr\/#\/schema\/logo\/image\/","url":"https:\/\/skills.visual-paradigm.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/02\/favicon.svg","contentUrl":"https:\/\/skills.visual-paradigm.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/02\/favicon.svg","width":70,"height":70,"caption":"Visual Paradigm Skills Fran\u00e7ais"},"image":{"@id":"https:\/\/skills.visual-paradigm.com\/fr\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/skills.visual-paradigm.com\/fr\/wp-json\/wp\/v2\/docs\/797","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/skills.visual-paradigm.com\/fr\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/skills.visual-paradigm.com\/fr\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":0,"href":"https:\/\/skills.visual-paradigm.com\/fr\/wp-json\/wp\/v2\/docs\/797\/revisions"}],"up":[{"embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/fr\/wp-json\/wp\/v2\/docs\/792"}],"wp:attachment":[{"href":"https:\/\/skills.visual-paradigm.com\/fr\/wp-json\/wp\/v2\/media?parent=797"}],"wp:term":[{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/fr\/wp-json\/wp\/v2\/doc_tag?post=797"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}