निःशुल्क · साइन-अप नहीं · .mmd फ़ाइलों के साथ काम करता है

Mermaid क्लास आरेख एडिटर

क्लास आरेख टाइप और उनके आपसी संबंध दिखाता है: क्या किसे समेटे है, क्या किससे विरासत लेता है, क्या किस पर निर्भर है। यह तब ठीक है जब मूल बात कोड का आकार हो — कोई डोमेन मॉडल, कोई विस्तार-इंटरफ़ेस, कोई वंशानुक्रम वृक्ष। अगर आप दिखाना चाहते हैं कि चलते समय क्या होता है, न कि टाइप आपस में कैसे बैठते हैं, तो सीक्वेंस आरेख लें।

इसे एडिटर में खोलें →गाइड पढ़ें

भुगतान डोमेन का मॉडल

एक ही आरेख में तीन तरह के संबंध: उन हिस्सों के लिए संघटन जो पूरे के बाद नहीं बचते, भुगतान-विधियों के पदानुक्रम के लिए वंशानुक्रम, और गुणकता के साथ एक साधारण सहचर्य। ध्यान दें कि हर क्लास की पहचान अंग्रेज़ी में है और दिखने वाला नाम कोष्ठक में देवनागरी में — इससे भीतर की पहचान वैध रहती है और स्क्रीन पर हिंदी बनी रहती है।

classDiagram
    class Order["ऑर्डर"] {
        +String संख्या
        +OrderStatus स्थिति
        +Money कुलयोग()
        +void पंक्तिजोड़ें(Product उत्पाद, int मात्रा)
    }
    class OrderLine["ऑर्डर पंक्ति"] {
        +Product उत्पाद
        +int मात्रा
        +Money मूल्य()
    }
    class PaymentMethod["भुगतान विधि"] {
        <<abstract>>
        +अधिकृतकरें(Money राशि) bool
    }
    class UpiPayment["यूपीआई"] {
        +String वर्चुअलपता
        +अधिकृतकरें(Money राशि) bool
    }
    class CardPayment["कार्ड"] {
        +String अंतिमचार
        +अधिकृतकरें(Money राशि) bool
    }
    class CashOnDelivery["डिलीवरी पर नकद"] {
        +Money वसूलीशुल्क
        +अधिकृतकरें(Money राशि) bool
    }

    Order "1" *-- "1..*" OrderLine : समेटे है
    Order --> PaymentMethod : इससे भुगतान
    PaymentMethod <|-- UpiPayment
    PaymentMethod <|-- CardPayment
    PaymentMethod <|-- CashOnDelivery

इसे एडिटर में खोलें

हल किए गए उदाहरण

1. एक अकेली क्लास

`+` सार्वजनिक है, `-` निजी, `#` संरक्षित। कोष्ठक वाला सदस्य विधि की तरह बनता है; कोष्ठक बिना वह क्षेत्र है।

classDiagram
    class User["उपयोगकर्ता"] {
        +String ईमेल
        -String पासवर्डहैश
        +bool जाँचें(String उम्मीदवार)
    }

एडिटर में खोलें

2. वंशानुक्रम और इंटरफ़ेस

`<|--` वंशानुक्रम है, इसे «दाईं ओर वाला बाईं ओर वाले को बढ़ाता है» पढ़ें। `<<interface>>` एक चिप्पी है, व्यवहार नहीं, पर आरेख की पठनीयता यही तय करती है।

classDiagram
    class Repository["रिपॉज़िटरी"] {
        <<interface>>
        +खोजें(String आईडी) Entity
        +सहेजें(Entity इकाई) void
    }
    class PostgresRepository["पोस्टग्रेस रिपॉज़िटरी"] {
        -Connection संबंध
        +खोजें(String आईडी) Entity
        +सहेजें(Entity इकाई) void
    }
    class MemoryRepository["स्मृति रिपॉज़िटरी"] {
        -Map भंडार
        +खोजें(String आईडी) Entity
        +सहेजें(Entity इकाई) void
    }
    Repository <|.. PostgresRepository
    Repository <|.. MemoryRepository

एडिटर में खोलें

3. संघटन बनाम समुच्चयन

फ़र्क़ जीवनकाल का है। भरा चतुर्भुज (`*--`) कहता है कि हिस्सा पूरे के साथ ही मिट जाता है: चालान हटाइए, उसकी पंक्तियाँ चली गईं। खाली चतुर्भुज (`o--`) कहता है कि हिस्सा स्वतंत्र रूप से रहता है।

classDiagram
    class Invoice["चालान"] {
        +String संख्या
    }
    class InvoiceLine["चालान पंक्ति"] {
        +String विवरण
    }
    class Customer["ग्राहक"] {
        +String कंपनीनाम
    }
    Invoice "1" *-- "1..*" InvoiceLine : से बना है
    Customer "1" o-- "0..*" Invoice : को जारी हुआ

एडिटर में खोलें

4. जेनेरिक टाइप

टिल्ड चिह्न टाइप-प्राचल देते हैं: `Repository~User~`। भीतर घोंसला बनाना भी चलता है, जो कभी-कभी ज़रूरी होता है और कम ही अच्छा विचार होता है।

classDiagram
    class Repository~T~ {
        +खोजें(String आईडी) T
        +सभी() List~T~
    }
    class Cache~K, V~ {
        +लें(K कुंजी) V
        +रखें(K कुंजी, V मान) void
    }
    class UserRepository["उपयोगकर्ता रिपॉज़िटरी"] {
        +ईमेलसेखोजें(String ईमेल) User
    }
    Repository~User~ <|-- UserRepository

एडिटर में खोलें

5. टिप्पणियाँ और दिशा

`direction LR` आरेख को बाएँ से दाएँ बिछाता है, जो वंशानुक्रम वृक्ष के लिए प्रायः डिफ़ॉल्ट बिछावट से बेहतर रहता है। टिप्पणी उस बंधन के लिए सही जगह है जो क्लास के आयत में नहीं समाता।

classDiagram
    direction LR
    class EventStore["इवेंट स्टोर"] {
        +जोड़ें(Event घटना) void
        +फिरचलाएँ(String धारा) List~Event~
    }
    class Snapshot["स्नैपशॉट"] {
        +int संस्करण
        +byte[] सामग्री
    }
    EventStore --> Snapshot : हर 100 घटनाओं पर लिखता है
    note for EventStore "सिर्फ़ जोड़ना। घटनाएँ कभी बदली या हटाई नहीं जातीं।"

एडिटर में खोलें

क्लास आरेख सिंटैक्स का सार

संबंध-तीर याद रखने लायक हैं: वही क्लास आरेख को आयतों-और-रेखाओं के चित्र से अलग करते हैं, और वे नोक से पीछे की ओर पढ़े जाते हैं, जो काफ़ी समय तक भ्रमित करता है।

सिंटैक्स	अर्थ
classDiagram	आरेख खोलता है। बड़े-छोटे अक्षरों के प्रति संवेदनशील।
class Name["नाम"] { ... }	अंग्रेज़ी पहचान के साथ देवनागरी में दिखने वाला नाम। हिंदी में यही चलन रखना चाहिए।
class Name { ... }	सदस्यों सहित क्लास। बंद करने वाला कोष्ठक अलग पंक्ति में।
+सदस्य	सार्वजनिक।
-सदस्य	निजी।
#सदस्य	संरक्षित।
+विधि(Type arg) ReturnType	विधि — इसे विधि कोष्ठक ही बनाते हैं।
<<interface>> / <<abstract>>	स्टीरियोटाइप, क्लास के भीतर पहली पंक्ति में।
A <\|-- B	वंशानुक्रम: B, A को बढ़ाता है।
A <\|.. B	साकार करना: B, इंटरफ़ेस A को लागू करता है।
A *-- B	संघटन: B, A के बाद नहीं बचता।
A o-- B	समुच्चयन: B, A के बिना भी रह सकता है।
A --> B	दिशा सहित सहचर्य।
A ..> B	निर्भरता — A, B का उपयोग करता है पर उसे रखता नहीं।
A "1" --> "0..*" B : लेबल	दोनों सिरों पर गुणकता और संबंध का लेबल।
class Repo~T~	जेनेरिक टाइप प्राचल।
note for A "पाठ"	किसी क्लास से जुड़ी टिप्पणी।
direction LR	बिछावट की दिशा बदलता है।

वे ग़लतियाँ जो क्लास आरेख को तोड़ती हैं

Mermaid 11.12.2 पर दोबारा बनाई गईं। क्लास आरेख छह प्रकारों में अपेक्षाकृत उदार है, इसलिए इनमें से आधी ग़लतियाँ चुपचाप बन जाती हैं और आपको ग़लत चित्र थमा देती हैं।

आपको क्या दिखता है

Lexical error on line N. Unrecognized text.

क्यों

क्लास का नाम देवनागरी में लिखा है। क्लास का नाम भी एक पहचान है, और फ़्लोचार्ट की नोड-पहचान की तरह यहाँ भी देवनागरी अस्वीकार होती है। मापा गया: `class आदेश` इसी त्रुटि से गिरता है।

समाधान

पहचान अंग्रेज़ी में रखें और दिखने वाला नाम कोष्ठक में दें: `class Order["ऑर्डर"]`। जाँचा हुआ — यह बनता है, भीतर की पहचान `Order` रहती है और स्क्रीन पर `ऑर्डर` दिखता है। सदस्यों के नाम देवनागरी में रह सकते हैं, क्योंकि वे पहचान नहीं हैं।

ग़लत

classDiagram
    class ऑर्डर {
        +String संख्या
    }

सही

classDiagram
    class Order["ऑर्डर"] {
        +String संख्या
    }

आपको क्या दिखता है

Parse error जो `got 'EOF_IN_STRUCT'` पर ख़त्म होती है

क्यों

क्लास का शरीर `{` से खुला और कभी बंद नहीं हुआ। इस बार टोकन का नाम सचमुच मदद करता है: वह कहता है कि फ़ाइल तब ख़त्म हुई जब हम अब भी किसी क्लास के भीतर थे।

समाधान

कोष्ठक को अलग पंक्ति में बंद करें।

ग़लत

classDiagram
    class Order["ऑर्डर"] {
        +String संख्या

सही

classDiagram
    class Order["ऑर्डर"] {
        +String संख्या
    }

आपको क्या दिखता है

Parse error जो `got 'ANNOTATION_END'` पर ख़त्म होती है

क्यों

सीक्वेंस आरेख का तीर क्लास आरेख में इस्तेमाल हुआ। `->>` का यहाँ कोई अर्थ नहीं, और पार्सर उसमें इतना भीतर चला जाता है कि भ्रमित करने वाला टोकन-नाम लौटाता है।

समाधान

क्लास आरेख के संबंध लें: सहचर्य के लिए `-->`, वंशानुक्रम के लिए `<|--`, संघटन के लिए `*--`।

ग़लत

classDiagram
    Order ->> Customer

सही

classDiagram
    Order --> Customer : का है

आपको क्या दिखता है

तीर उस दिशा में है जिसमें आप नहीं चाहते थे

क्यों

संबंध-तीर नोक से पीछे की ओर पढ़े जाते हैं। `A <|-- B` का अर्थ है कि B, A से विरासत लेता है, उलटा नहीं। उलटा लिखने पर भी वह बन जाता है — बस अब वह यह दावा करता है कि आधार क्लास अपनी ही उपक्लास को बढ़ाती है।

समाधान

इसे «दूर वाला सिरा नोक वाले सिरे को बढ़ाता है» की तरह पढ़ें। जनक को `<|--` के बाईं ओर रखें।

ग़लत

classDiagram
    CardPayment <|-- PaymentMethod

सही

classDiagram
    PaymentMethod <|-- CardPayment

आपको क्या दिखता है

जहाँ विधि की उम्मीद थी वहाँ क्षेत्र दिखता है

क्यों

विधि को क्षेत्र से सिर्फ़ कोष्ठक अलग करते हैं। `+सहेजें` सहेजें नाम का क्षेत्र है; `+सहेजें()` एक विधि है। दोनों रूप वैध हैं, इसलिए कोई चेतावनी नहीं आती।

समाधान

कोष्ठक जोड़ें, और चाहें तो उसके बाद लौटने वाला टाइप भी।

ग़लत

classDiagram
    class Repo {
        +सहेजें
        +खोजें
    }

सही

classDiagram
    class Repo {
        +सहेजें(Entity इकाई) void
        +खोजें(String आईडी) Entity
    }

आपको क्या दिखता है

संघटन और समुच्चयन पहली नज़र में एक जैसे लगते हैं और उलटी बात कहते हैं

क्यों

`*--` और `o--` में एक अक्षर का फ़र्क़ है, और वे एक असली अर्थ-भेद को दर्ज करते हैं: हिस्सा पूरे के बाद बच सकता है या नहीं। ग़लत वाला लेने पर आरेख रूप से सही और आपके डोमेन के लिहाज़ से झूठा बनता है।

समाधान

भरा चतुर्भुज `*--` जब जनक हटाने से संतान भी हट जाए। खाली `o--` जब न हटे।

ग़लत

classDiagram
    Order o-- OrderLine : समेटे है

सही

classDiagram
    Order *-- OrderLine : समेटे है

बनने के बारे में टिप्पणियाँ

Mermaid 11.12.2 पर मापा गया, वही संस्करण जो यह साइट चलाती है।

कोष्ठक वाला नाम ही हिंदी क्लास आरेख का असली रास्ता है

यह इस पन्ने की सबसे काम की बात है। `class ऑर्डर` गिर जाता है क्योंकि क्लास का नाम एक पहचान है और देवनागरी वहाँ स्वीकार नहीं होती। पर `class Order["ऑर्डर"]` जाँचा हुआ है और बनता है: निकली हुई पहचान `classId-Order` रहती है जबकि स्क्रीन पर `ऑर्डर` दिखता है। इससे भी बेहतर, ऐसे नामित क्लासों के बीच संबंध भी सामान्य रूप से काम करते हैं — दो कोष्ठक-नामित क्लासों के बीच `<|--` जाँचा गया और ठीक बना। यानी हिंदी क्लास आरेख में कहीं भी अंग्रेज़ी दिखानी नहीं पड़ती।

सदस्यों के नाम पहचान नहीं हैं, इसलिए वे देवनागरी में रह सकते हैं

पाबंदी सिर्फ़ क्लास के नाम पर है। सदस्य के नाम, प्राचल के नाम और लौटने वाले टाइप के नाम लेबल की तरह बरते जाते हैं: `+String संख्या` और `+Money कुलयोग()` दोनों वैसे ही बनते हैं जैसे लिखे गए हैं, और कोष्ठक देवनागरी नाम के साथ भी विधि बनाने का काम उसी तरह करते हैं। इसका मतलब यह कि आरेख का ज़्यादातर पाठ हिंदी में रह सकता है और सिर्फ़ क्लास की भीतरी पहचान अंग्रेज़ी होती है।

यह यहाँ के हर प्रकार से तेज़ी से ऊपर बढ़ता है

दो-दो सदस्यों वाली और वंशानुक्रम से जुड़ी क्लासों पर मापा गया: तीन क्लास लगभग 176×548 का viewBox देती हैं, चालीस क्लास 180×7726 — यानी प्रति क्लास लगभग 194 पिक्सल ऊँचाई, जो इस साइट के छह प्रकारों में सबसे तीव्र वृद्धि है। चालीस क्लास वाला आरेख सात हज़ार पिक्सल से ऊपर चला जाता है और एक ही चित्र के रूप में बेकार है। `direction LR` मदद करता है, पर लगभग पंद्रह क्लास के बाद ईमानदार हल आरेख को डोमेन की सीमाओं पर बाँटना है।

सदस्यों की संख्या चौड़ाई पर लगभग असर नहीं डालती

चौड़ाई किसी एक सदस्य के सबसे लंबे हस्ताक्षर से तय होती है, इस बात से नहीं कि कितने सदस्य हैं। बीस छोटे क्षेत्रों वाली क्लास तीन क्षेत्रों वाली से चौड़ी नहीं होती। दूसरे शब्दों में: सदस्यों पर उदार रहें और क्लासों पर कंजूस — जो सहज प्रवृत्ति के ठीक उलट है। देवनागरी हस्ताक्षर अंग्रेज़ी से सँकरे निकलते हैं, इसलिए चौड़ाई अंग्रेज़ी उदाहरण से कम रहती है।

लेबल HTML हैं, इसलिए PNG निर्यात दोबारा बनाता है

क्लास के लेबल SVG के भीतर `<foreignObject>` में बनते हैं, और ब्राउज़र उसे कैनवस पर उतारने से मना कर देते हैं। इस साइट का PNG निर्यात पहले चुपचाप विफल होकर SVG फ़ाइल लौटाता था; अब वह आरेख को पहले सादे SVG पाठ-लेबल के साथ दोबारा बनाता है। PNG सही और पूरे आकार में निकलता है, टाइपसेटिंग स्क्रीन से ज़रा-सी अलग।

कब कोई दूसरा आरेख बेहतर है

अगर आप किसी डेटाबेस का दस्तावेज़ बना रहे हैं, टाइप-प्रणाली का नहीं, तो ER आरेख लें। यह भेद मायने रखता है: क्लास आरेख व्यवहार और वंशानुक्रम का मॉडल बनाते हैं, जो तालिकाओं में होते ही नहीं, और ER आरेख कुंजियों तथा गुणकताओं का मॉडल ठीक से बनाते हैं, जिन्हें क्लास आरेख ऊपर-ऊपर से निपटा देते हैं।

अगर आरेख ज़्यादातर `-->` से जुड़े आयतों का है और उनमें सदस्य नहीं हैं, तो आप स्थापत्य बना रहे हैं, क्लास आरेख नहीं। सबग्राफ़ वाला फ़्लोचार्ट बेहतर दिखेगा और कम दावे करेगा।

और अगर क्लासों की सूची कोड से निकलती है, तो सोचिए कि आरेख भी वहीं से क्यों न निकले। हर हफ़्ते बदलने वाले कोडबेस के लिए हाथ से सँभाला गया क्लास आरेख महीने भर में झूठा हो जाता है, और ग़लत आरेख की क़ीमत आरेख न होने से ज़्यादा है।

अन्य आरेख प्रकार

लिखा Dominik Malsch · अंतिम अद्यतन: 8 सितंबर 2026

एडिटर खोलें →