Współpraca wielu użytkowników w czasie rzeczywistym z linkami do udostępniania
Automatyczne generowanie grafiki z tekstu z ulepszaniem stylu
Wbudowane motywy z pełną personalizacją
Obsługa ikon, obrazów, etykiet, formuł LaTeX, bloków kodu, linków, załączników
Eksport: PNG, VISIO, PDF, SVG | Import: VISIO, Mermaid
Przechowywanie w chmurze w czasie rzeczywistym, synchronizacja wielourządzeniowa, historia wersji i bezpieczeństwo danych
Klasa zazwyczaj składa się z nazwy, atrybutów i operacji, przedstawiana jest w postaci prostokątnego pola podzielonego na trzy warstwy: pierwsza warstwa to nazwa klasy, druga to atrybuty klasy, a trzecia to operacje klasy.
W praktyce istnieją trzy formy przedstawiania: „nazwa klasy”, „nazwa klasy” + „atrybuty klasy”, „nazwa klasy” + „operacje klasy”.
Nazwa klasy powinna być rzeczownikiem, każde słowo powinno zaczynać się wielką literą, a nazwy klas, które można instancjować, powinny być pisane prostą czcionką, podczas gdy nazwy klas abstrakcyjnych powinny być pisane kursywą.
Składnia definicji atrybutu klasy: [widoczność] nazwa atrybutu [:typ danych] [=wartość początkowa] [{łańcuch atrybutów}]
Zawartość w nawiasach [] jest opcjonalna.
Ograniczenia klasy określają jedno lub więcej reguł, które klasa musi spełniać. W UML ograniczenia są przedstawiane jako informacje tekstowe ujęte w nawiasy klamrowe.
Relacja implementacji: przedstawiana jako puste trójkątne strzałki + linia przerywana, od klasy implementującej do klasy interfejsu.
Relacja generalizacji: przedstawiana jako puste trójkątne strzałki + linia ciągła, od klasy podrzędnej do klasy nadrzędnej.
Relacja asocjacji: przedstawiana jako strzałki z linii ciągłej, od klasy odwołującej się do klasy odwoływanej.
Relacja agregacji: przedstawiana jako puste romby + linia ciągła, od klasy częściowej do klasy całościowej.
Relacja kompozycji: przedstawiana jako pełne romby + linia ciągła, od klasy częściowej do klasy całościowej.
Relacja zależności: przedstawiana jako strzałki z linii przerywanej, od klasy odwołującej się do klasy zależnej.
Diagramy klas nie są całkowicie niezależne, powinny być abstrahowane z diagramów przypadków użycia w celu określenia klas encji, kontroli i granic, oraz powinny być semantycznie zgodne z diagramami przypadków użycia, diagramami aktywności, diagramami sekwencji itp.
Klasa powinna zachować jedną odpowiedzialność, można podzielić duże klasy i przypisać odpowiedzialności do wielu klas, aby uniknąć wysokiego stopnia sprzężenia, wyraźnie określić granice i zgodnie z zasadami projektowania obiektowego.