{"id":942,"date":"2026-02-25T10:32:34","date_gmt":"2026-02-25T10:32:34","guid":{"rendered":"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/"},"modified":"2026-02-25T10:32:34","modified_gmt":"2026-02-25T10:32:34","slug":"uml-naming-conventions-visibility-access","status":"publish","type":"docs","link":"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/","title":{"rendered":"Naming Conventions, Visibility, and Access Levels"},"content":{"rendered":"<p>Many developers start drafting UML class diagrams by labeling classes and methods without pausing to consider how those names will affect future maintainability. I\u2019ve seen teams ship systems where a simple misstep in naming\u2014like using &#8220;getInfo()&#8221; for a method that modifies state\u2014led to months of confusion. The real issue isn\u2019t the tool or syntax; it\u2019s the lack of a consistent naming strategy that reflects both responsibility and intent. That\u2019s where UML naming conventions come in\u2014not as rigid rules, but as shared language to support collaboration and clarity.<\/p>\n<p>When you move from CRC cards to formal UML, your goal isn\u2019t just to transpose handwritten notes into boxes and lines. You\u2019re translating responsibility-driven design into a structured API. This chapter guides you through naming conventions, visibility rules, and encapsulation strategies\u2014tools that ensure your class diagram doesn\u2019t just look right, but behaves correctly in practice. You\u2019ll learn how to make every name meaningful, every access level intentional, and every boundary well-defined.<\/p>\n<h2>Why Naming Conventions Matter in UML<\/h2>\n<p>Names are the first point of contact with your design. A poorly chosen class name like \u201cDataHandler\u201d or \u201cManager\u201d invites ambiguity. A good name, like \u201cOrderValidator\u201d or \u201cCreditCardProcessor,\u201d conveys intent and scope. UML naming conventions are not arbitrary; they\u2019re rooted in the principle that a class\u2019s name should answer: \u201cWhat role does this play in the system?\u201d<\/p>\n<p>Consider a team modeling a banking system. One developer names a class \u201cBank.\u201d It sounds simple. But when the model grows, you\u2019re left wondering: Is this the entire bank? A banking service? A customer record? The ambiguity creates friction in code reviews and testing.<\/p>\n<p>UML best practices recommend naming classes with nouns or noun phrases that reflect a specific responsibility. Use singular terms unless the class represents a collection. Avoid verbs in class names\u2014those belong in method names.<\/p>\n<ul>\n<li><strong>Use descriptive, singular class names.<\/strong> \u201cCustomer\u201d instead of \u201cCustomersManager\u201d<\/li>\n<li><strong>Apply camelCase in lower case for package names.<\/strong> \u201cbanking.transaction\u201d instead of \u201cBanking.Transaction\u201d<\/li>\n<li><strong>Use full, meaningful names.<\/strong> \u201cPaymentProcessor\u201d over \u201cPayProc\u201d or \u201cP\u201d<\/li>\n<\/ul>\n<p>These aren\u2019t preferences\u2014they\u2019re decisions that reduce cognitive load across teams. A well-named class doesn\u2019t need documentation to be understood. Every line of code written against it becomes more predictable.<\/p>\n<h2>Visibility and Access Levels in UML<\/h2>\n<p>Visibility is where abstraction and encapsulation begin. UML defines four visibility levels, each with a clear purpose in controlling access:<\/p>\n<table>\n<tbody>\n<tr>\n<th>Symbol<\/th>\n<th>Name<\/th>\n<th>Scope<\/th>\n<th>Use Case<\/th>\n<\/tr>\n<tr>\n<td>+<\/td>\n<td>Public<\/td>\n<td>Accessible from everywhere<\/td>\n<td>APIs, service methods<\/td>\n<\/tr>\n<tr>\n<td>&#8211;<\/td>\n<td>Private<\/td>\n<td>Only visible within the class<\/td>\n<td>Internal state, temporary logic<\/td>\n<\/tr>\n<tr>\n<td>#<\/td>\n<td>Protected<\/td>\n<td>Class and subclasses<\/td>\n<td>Base class behavior, inheritance<\/td>\n<\/tr>\n<tr>\n<td>~<\/td>\n<td>Package<\/td>\n<td>Same package only<\/td>\n<td>Shared internal logic<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>When translating CRC responsibilities to UML, ask: \u201cDoes this attribute or method need to be accessible beyond this scope?\u201d If not, don\u2019t expose it. Overexposure leads to tight coupling and fragile code.<\/p>\n<p>For example, a CRC card might list \u201cTrack transaction status\u201d as a responsibility. In UML, this becomes a method like <code>updateStatus()<\/code>. But what visibility should it have? If it\u2019s only used by the class itself to manage internal logic, mark it as private. If it\u2019s accessed by subclasses, use protected. If it\u2019s part of a public interface, make it public.<\/p>\n<p>My rule: default to private unless there\u2019s a clear reason to expose. This aligns with the principle of <strong>encapsulation UML<\/strong>\u2014data and behavior that don\u2019t need external access should stay inside the class.<\/p>\n<h3>Practical Guidance for Visibility<\/h3>\n<p>Here\u2019s how to apply visibility in real design:<\/p>\n<ol>\n<li><strong>Start with private.<\/strong> All instance variables and helper methods begin private.<\/li>\n<li><strong>Expose only what\u2019s needed.<\/strong> If a method is only called by another method in the same class, keep it private.<\/li>\n<li><strong>Use protected for inheritance.<\/strong> Only expose for extension, not for arbitrary access.<\/li>\n<li><strong>Use package visibility for shared components.<\/strong> When multiple classes in the same package use a utility, make it package-private.<\/li>\n<li><strong>Public is for interaction.<\/strong> Only public methods are part of the public API.<\/li>\n<\/ol>\n<p>This approach ensures your class diagram isn\u2019t just a visual layout\u2014it\u2019s a boundary definition that enforces design discipline.<\/p>\n<h2>Translating CRC Responsibilities into UML Attributes<\/h2>\n<p>One of the most frequent translation errors I see: treating every CRC responsibility as a method, even when it\u2019s actually a data state. A CRC card might say \u201cStore customer details.\u201d That\u2019s not a method\u2014it\u2019s an attribute.<\/p>\n<p>When you see a responsibility like \u201cHold balance amount\u201d or \u201cTrack expiration date,\u201d ask: Is this state? Then, map it to an attribute. For example:<\/p>\n<pre><code>class Account {\n  - double balance\n  - LocalDate expirationDate\n  + void deposit(double amount)\n  + boolean isValid()\n}<\/code><\/pre>\n<p>Here, <code>balance<\/code> and <code>expirationDate<\/code> are private attributes\u2014because they\u2019re internal state. The methods <code>deposit<\/code> and <code>isValid<\/code> are public because they define observable behavior.<\/p>\n<p>This distinction is critical. You\u2019re now aligning <strong>CRC to UML attributes<\/strong> correctly: state goes in, behavior goes out. When you reverse this, you risk exposing internal data or hiding critical behavior.<\/p>\n<h3>Attribute Naming Best Practices<\/h3>\n<p>Attributes should be precise, unambiguous, and consistent. Use descriptive names that reflect both purpose and type.<\/p>\n<ul>\n<li><code>customerName<\/code> \u2013 clear and specific<\/li>\n<li><code>amount<\/code> \u2013 too vague; better: <code>transactionAmount<\/code><\/li>\n<li><code>isPaid<\/code> \u2013 good for boolean; avoids <code>paidStatus<\/code> or <code>status<\/code><\/li>\n<\/ul>\n<p>Never use abbreviations unless they\u2019re standard (e.g., <code>id<\/code> for identifier, <code>addr<\/code> is less clear). Clarity trumps brevity.<\/p>\n<h2>Encapsulation UML: More Than Just Visibility<\/h2>\n<p>Encapsulation in UML isn\u2019t just about visibility\u2014it\u2019s about control. A class that exposes its data via public fields is not encapsulated, no matter how many private methods it has.<\/p>\n<p>True encapsulation means: data is internal, access is controlled, and changes are isolated. Use getters and setters not as boilerplate, but as gates. For example:<\/p>\n<pre><code>class BankAccount {\n  - double balance\n\n  + getBalance(): double\n  + deposit(amount: double): void\n  + withdraw(amount: double): boolean\n}<\/code><\/pre>\n<p>Now, if you later decide to add interest calculation, you can do it in <code>getBalance()<\/code> without breaking existing code. If <code>balance<\/code> were public, every access point would need to be updated.<\/p>\n<p>Encapsulation prevents unintended side effects. It turns a data holder into a responsible entity. This is what <strong>encapsulation UML<\/strong> means in practice: design with intent, not convenience.<\/p>\n<h2>Final Checklist: From CRC to UML<\/h2>\n<p>Before finalizing your class diagram, run through this checklist:<\/p>\n<ul>\n<li>Are all class names descriptive and singular?<\/li>\n<li>Are all attributes private unless shared across packages?<\/li>\n<li>Are methods public only when they form part of the public interface?<\/li>\n<li>Are there any public fields? If yes, consider replacing with getters\/setters.<\/li>\n<li>Have you reviewed visibility in the context of inheritance and package boundaries?<\/li>\n<li>Does every name reflect a clear responsibility or state?<\/li>\n<\/ul>\n<p>These aren\u2019t just good practices\u2014they\u2019re the foundation of a design that can evolve, test, and scale.<\/p>\n<h2>Frequently Asked Questions<\/h2>\n<h3>What\u2019s the best way to name a class derived from CRC?<\/h3>\n<p>Start with the CRC responsibility: \u201cManage user accounts\u201d becomes \u201cUserAccountManager.\u201d But ask: is this a service or a domain object? If it\u2019s a central entity, use \u201cUserAccount.\u201d If it\u2019s a utility, \u201cAccountManager\u201d may be clearer. Prioritize clarity over brevity.<\/p>\n<h3>Can I use protected access for all methods in a class?<\/h3>\n<p>No. Protected access is for inheritance, not for all internal logic. Use private for internal helpers. Reserve protected for methods that subclasses must override or extend. Overusing protected breaks encapsulation and increases coupling.<\/p>\n<h3>How do I handle boolean attributes in UML?<\/h3>\n<p>Use a clear, positive name like <code>isActive<\/code>, <code>isVerified<\/code>, or <code>hasPermission<\/code>. Avoid <code>active<\/code> or <code>verified<\/code> alone, as they\u2019re ambiguous. Always prefix with \u201cis\u201d or \u201chas\u201d for boolean attributes.<\/p>\n<h3>Why should I avoid public fields in UML?<\/h3>\n<p>Public fields break encapsulation. They allow direct modification, making it impossible to add validation, logging, or transformation later. Treat every public field as a design flaw\u2014replace it with a getter\/setter pair or a method that controls access.<\/p>\n<h3>What if a CRC responsibility doesn\u2019t map to a method or attribute?<\/h3>\n<p>Revisit your interpretation. Every CRC responsibility should map to a method (behavior) or an attribute (state). If it doesn\u2019t, you may have misunderstood the responsibility. Ask: \u201cWhat does this entity own? What does it do?\u201d If it doesn\u2019t answer one of those, re-express the responsibility.<\/p>\n<h3>How do I ensure naming best practices across a team?<\/h3>\n<p>Establish a shared naming convention early. Use your CRC sessions to agree on terms. Document them in a style guide. Use tools like Visual Paradigm to enforce consistency. Regular design reviews should include a naming audit.<\/p>\n<p>Design isn\u2019t about writing code. It\u2019s about creating a shared language. When you get naming right, visibility right, and encapsulation right, you\u2019re not just building a diagram\u2014you\u2019re building a system that speaks clearly to its future maintainers.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Many developers start drafting UML class diagrams by labeling classes and methods without pausing to consider  [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":940,"menu_order":1,"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-942","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>UML Naming Conventions: Best Practices for Design Clarity<\/title>\n<meta name=\"description\" content=\"Master UML naming conventions, visibility, and encapsulation best practices to ensure CRC responsibilities become clear, maintainable APIs. Learn how to align design intent with formal modeling.\" \/>\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\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/\" \/>\n<meta property=\"og:locale\" content=\"ja_JP\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"UML Naming Conventions: Best Practices for Design Clarity\" \/>\n<meta property=\"og:description\" content=\"Master UML naming conventions, visibility, and encapsulation best practices to ensure CRC responsibilities become clear, maintainable APIs. Learn how to align design intent with formal modeling.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/\" \/>\n<meta property=\"og:site_name\" content=\"Visual Paradigm Skills\u65e5\u672c\u8a9e\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"\u63a8\u5b9a\u8aad\u307f\u53d6\u308a\u6642\u9593\" \/>\n\t<meta name=\"twitter:data1\" content=\"7\u5206\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/\",\"url\":\"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/\",\"name\":\"UML Naming Conventions: Best Practices for Design Clarity\",\"isPartOf\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/ja\/#website\"},\"datePublished\":\"2026-02-25T10:32:34+00:00\",\"description\":\"Master UML naming conventions, visibility, and encapsulation best practices to ensure CRC responsibilities become clear, maintainable APIs. Learn how to align design intent with formal modeling.\",\"breadcrumb\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/#breadcrumb\"},\"inLanguage\":\"ja\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/skills.visual-paradigm.com\/ja\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"From CRC Cards to Class Diagrams\",\"item\":\"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Refining and Validating the Design\",\"item\":\"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/\"},{\"@type\":\"ListItem\",\"position\":4,\"name\":\"Naming Conventions, Visibility, and Access Levels\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/ja\/#website\",\"url\":\"https:\/\/skills.visual-paradigm.com\/ja\/\",\"name\":\"Visual Paradigm Skills\u65e5\u672c\u8a9e\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/ja\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/skills.visual-paradigm.com\/ja\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"ja\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/ja\/#organization\",\"name\":\"Visual Paradigm Skills\u65e5\u672c\u8a9e\",\"url\":\"https:\/\/skills.visual-paradigm.com\/ja\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"ja\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/ja\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/skills.visual-paradigm.com\/ja\/wp-content\/uploads\/sites\/12\/2026\/02\/favicon.svg\",\"contentUrl\":\"https:\/\/skills.visual-paradigm.com\/ja\/wp-content\/uploads\/sites\/12\/2026\/02\/favicon.svg\",\"width\":70,\"height\":70,\"caption\":\"Visual Paradigm Skills\u65e5\u672c\u8a9e\"},\"image\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/ja\/#\/schema\/logo\/image\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"UML Naming Conventions: Best Practices for Design Clarity","description":"Master UML naming conventions, visibility, and encapsulation best practices to ensure CRC responsibilities become clear, maintainable APIs. Learn how to align design intent with formal modeling.","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\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/","og_locale":"ja_JP","og_type":"article","og_title":"UML Naming Conventions: Best Practices for Design Clarity","og_description":"Master UML naming conventions, visibility, and encapsulation best practices to ensure CRC responsibilities become clear, maintainable APIs. Learn how to align design intent with formal modeling.","og_url":"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/","og_site_name":"Visual Paradigm Skills\u65e5\u672c\u8a9e","twitter_card":"summary_large_image","twitter_misc":{"\u63a8\u5b9a\u8aad\u307f\u53d6\u308a\u6642\u9593":"7\u5206"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/","url":"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/","name":"UML Naming Conventions: Best Practices for Design Clarity","isPartOf":{"@id":"https:\/\/skills.visual-paradigm.com\/ja\/#website"},"datePublished":"2026-02-25T10:32:34+00:00","description":"Master UML naming conventions, visibility, and encapsulation best practices to ensure CRC responsibilities become clear, maintainable APIs. Learn how to align design intent with formal modeling.","breadcrumb":{"@id":"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/#breadcrumb"},"inLanguage":"ja","potentialAction":[{"@type":"ReadAction","target":["https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/uml-naming-conventions-visibility-access\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/skills.visual-paradigm.com\/ja\/"},{"@type":"ListItem","position":2,"name":"From CRC Cards to Class Diagrams","item":"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/"},{"@type":"ListItem","position":3,"name":"Refining and Validating the Design","item":"https:\/\/skills.visual-paradigm.com\/ja\/docs\/crc-cards-to-class-diagrams\/refining-and-validating-the-design\/"},{"@type":"ListItem","position":4,"name":"Naming Conventions, Visibility, and Access Levels"}]},{"@type":"WebSite","@id":"https:\/\/skills.visual-paradigm.com\/ja\/#website","url":"https:\/\/skills.visual-paradigm.com\/ja\/","name":"Visual Paradigm Skills\u65e5\u672c\u8a9e","description":"","publisher":{"@id":"https:\/\/skills.visual-paradigm.com\/ja\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/skills.visual-paradigm.com\/ja\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"ja"},{"@type":"Organization","@id":"https:\/\/skills.visual-paradigm.com\/ja\/#organization","name":"Visual Paradigm Skills\u65e5\u672c\u8a9e","url":"https:\/\/skills.visual-paradigm.com\/ja\/","logo":{"@type":"ImageObject","inLanguage":"ja","@id":"https:\/\/skills.visual-paradigm.com\/ja\/#\/schema\/logo\/image\/","url":"https:\/\/skills.visual-paradigm.com\/ja\/wp-content\/uploads\/sites\/12\/2026\/02\/favicon.svg","contentUrl":"https:\/\/skills.visual-paradigm.com\/ja\/wp-content\/uploads\/sites\/12\/2026\/02\/favicon.svg","width":70,"height":70,"caption":"Visual Paradigm Skills\u65e5\u672c\u8a9e"},"image":{"@id":"https:\/\/skills.visual-paradigm.com\/ja\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/skills.visual-paradigm.com\/ja\/wp-json\/wp\/v2\/docs\/942","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/skills.visual-paradigm.com\/ja\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/skills.visual-paradigm.com\/ja\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/ja\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":0,"href":"https:\/\/skills.visual-paradigm.com\/ja\/wp-json\/wp\/v2\/docs\/942\/revisions"}],"up":[{"embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/ja\/wp-json\/wp\/v2\/docs\/940"}],"wp:attachment":[{"href":"https:\/\/skills.visual-paradigm.com\/ja\/wp-json\/wp\/v2\/media?parent=942"}],"wp:term":[{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/ja\/wp-json\/wp\/v2\/doc_tag?post=942"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}