Wprowadzenie
Często jestem pytany: “Panie Jarku, czy Pan używa AI?”. Tak, np. do szybkiego przeglądu publicznie dostępnych popularnych treści. Np. zadałem tytułowe Copilotowi. Tak odpowiedział:
“PlantUML i Mermaid różnią się od klasycznych narzędzi CASE w celu, filozofii pracy, zakresie funkcji i miejscu w procesie inżynierskim. Najkrócej: PlantUML/Mermaid to języki do rysowania diagramów, a CASE to środowiska do projektowania systemów. PlantUML i Mermaid nie konkurują z CASE — one konkurują z Visio, Draw.io, PowerPointem. CASE to zupełnie inna liga: model-first, a nie diagram-first.”
(poniższy tekst wygenerowany przez Copilot w odpowiedzi na tytułowe pytanie, jedyne zmiany to formatowanie)
Najważniejsza różnica w jednym zdaniu
PlantUML i Mermaid generują diagramy z tekstu; narzędzia CASE modelują systemy, zarządzają artefaktami, zależnościami, wersjami i często wspierają cały proces inżynierski.
Czym są PlantUML i Mermaid
To tekstowe DSL-e do rysowania diagramów, które:
- generują grafiki na podstawie kodu tekstowego
- wspierają wybrane typy diagramów (UML, BPMN, ERD, sekwencje, Gantty itd.)
- są lekkie, szybkie i łatwe do integracji z repozytoriami, CI/CD, dokumentacją
- nie przechowują semantyki modelu — tylko opis rysunku
- nie walidują logiki systemu (np. spójności klas, typów, relacji)
Ich celem jest wizualizacja, a nie pełne modelowanie.
Czym są narzędzia CASE
CASE (Computer-Aided Software Engineering) to pełne środowiska modelowania, takie jak:
- Enterprise Architect
- MagicDraw / Cameo
- Visual Paradigm
- IBM Rhapsody
Ich cechy:
- przechowują modele, nie tylko diagramy
- zapewniają semantykę UML/SysML/BPMN i walidację
- wspierają traceability (np. wymagania → komponenty → testy)
- generują kod lub odwrotnie (round-trip engineering)
- obsługują repozytoria modeli, wersjonowanie, współpracę zespołową
- integrują się z procesami MBSE, architekturą korporacyjną, analizą wymagań
Ich celem jest inżynieria systemów i zarządzanie złożonością, nie tylko rysowanie.
Tabela porównawcza
| Obszar | PlantUML / Mermaid | Narzędzia CASE |
| Cel | Wizualizacja diagramów | Modelowanie systemów i procesów |
| Reprezentacja | Tekst → obraz | Model → wiele widoków |
| Semantyka UML/SysML | Minimalna lub uproszczona | Pełna, formalna, walidowana |
| Traceability | Brak | Pełne (wymagania, testy, komponenty) |
| Wersjonowanie | Git-friendly (pliki tekstowe) | Repozytoria modeli, często własne formaty |
| Generowanie kodu | Ograniczone lub brak | Często pełne (round-trip) |
| Zastosowanie | Dokumentacja, wiki, diagramy ad hoc | Architektura, MBSE, analiza, projektowanie |
| Krzywa uczenia | Bardzo niska | Wysoka |
| Koszt | Zwykle darmowe | Często komercyjne |
Kluczowa różnica filozoficzna
PlantUML/Mermaid:
- diagram = plik tekstowy, który można łatwo zmienić, zreviewować, zmergować
- brak centralnego modelu — każdy diagram żyje osobno
- idealne do dokumentacji w repozytorium, wiki, markdown
CASE:
- model = źródło prawdy, diagramy są tylko widokami
- zmiana w jednym miejscu wpływa na cały system
- idealne do dużych projektów, MBSE, architektury systemów
Kiedy używać którego podejścia
PlantUML / Mermaid — najlepsze gdy:
- dokumentujesz system w repozytorium (Git)
- chcesz szybkie, lekkie diagramy
- pracujesz sam lub w małym zespole
- potrzebujesz automatyzacji (CI/CD, generowanie dokumentacji)
- diagramy nie muszą być formalnie poprawne
CASE — najlepsze gdy:
- pracujesz w dużym projekcie (systemy krytyczne, MBSE)
- potrzebujesz spójnego modelu i walidacji
- wymagania muszą być powiązane z architekturą i testami
- potrzebujesz generowania kodu lub odwrotnej inżynierii
- zespół pracuje na jednym modelu
Nieoczywista obserwacja
PlantUML i Mermaid nie konkurują z CASE — one konkurują z Visio, Draw.io, PowerPointem. CASE to zupełnie inna liga: model-first, a nie diagram-first.
P.S. Jeżeli chcesz wejść na wyższy poziom, nauczyć się analizy i projektowania z użyciem narzędzi CASE, zapraszam na konsultacje i szkolenia?
Dodatek
Zawartość
- wprowadzenie
- model biznesowy
- modele procesów bizneswych
- wymagania
- przypadki użycia i ich realizacje
- architektura HLD i LLD, sekwencje
- analizy wpływu i rejestr zmian
Taki dokument (ok. 100 stron) opracowuje w ok. trzy miesiące, zajmuje mi to średnio 2h dziennie, reszta to oczekiwanie na materiały źródłowe i recenzje draftu opracowania.
W toku nadzoru nad realizacją stale pojawiają się drobne zmiany i nowe elementy (czas nie stoi w miejscu). Wprowadzenie nowego elementu lub jego zmiana wymaga aktualizacji wszystko powiązanych innych diagramów i ich tekstowych opisów. Na tym etapie aktualizacja diagramu (lub jeden nowy) to niecała godzina, aktualizacja pozostałych 100 stron to kilkanaście sekund bo robi to automat.
Te i takie projekty realizują w 100% zdalnie od ponad 15 lat.
(artykuł ekspercki)
