UML nie jest językiem programowania#
UML służy do opisywania i komunikowania modeli systemów, ale sam nie jest kodem, który komputer wykonuje. Diagram może pokazać klasy, ich relacje, przebieg procesu lub wymianę komunikatów. Programista może później napisać kod odpowiadający części takiego modelu.
Model i kod mogą być ze sobą powiązane, a niektóre narzędzia potrafią generować kod z diagramów albo odtwarzać diagramy na podstawie kodu. Nie oznacza to, że każdy diagram jest wykonywalny ani że można go bezpośrednio uruchomić. UML pomaga ustalić i przekazać strukturę lub zachowanie systemu; sposób implementacji zależy od technologii i decyzji projektowych.
UML nie jest metodyką pracy#
Metodyka lub proces opisuje, jak zespół organizuje pracę: jakie wykonuje czynności, w jakiej kolejności i kto za nie odpowiada. UML określa sposób zapisu wybranych informacji o systemie. Nie narzuca, czy zespół ma pracować iteracyjnie, etapami, warsztatowo ani kiedy tworzyć diagramy.
Można używać UML w różnych procesach, a także ograniczyć się do kilku diagramów tworzonych wtedy, gdy pomagają podjąć decyzję lub wyjaśnić rozwiązanie. Sama znajomość notacji nie mówi, jak prowadzić projekt ani jak zarządzać wymaganiami.
UML nie jest narzędziem#
Edytor diagramów to program, w którym można rysować lub zapisywać modele. UML jest językiem, którego elementy ten program może obsługiwać. Narzędzia różnią się funkcjami, sposobem pracy i zakresem wsparcia dla notacji. Fakt, że program oferuje kształty przypominające UML, nie gwarantuje, że powstały diagram jest poprawny lub czytelny.
Podobnie diagram zapisany w konkretnym edytorze nie staje się przez to samym UML. To widok modelu przygotowany za pomocą określonego narzędzia.
Diagram to nie cały model#
Diagram przedstawia wybrane informacje i perspektywę. Model może obejmować kilka diagramów oraz elementy, których na danym widoku nie pokazano. Dlatego nieobecność jakiegoś szczegółu na diagramie nie zawsze znaczy, że nie istnieje on w modelowanym systemie — może po prostu nie należeć do celu tego rysunku.
Poniższy schemat porządkuje te pojęcia. Strzałki pokazują tu praktyczne zależności, a nie obowiązkową kolejność działań ani pełną semantykę UML.
Model odnosi się do systemu, diagram pokazuje część modelu, a narzędzie pomaga przygotować diagram. Zespół może włączyć modelowanie do swojego procesu, zaś kod stanowi jedną z możliwych implementacji systemu. UML dotyczy języka opisu używanego przy tworzeniu modelu i diagramów — nie zastępuje żadnego z tych elementów.
UML nie jest kompletną specyfikacją systemu#
Zestaw diagramów nie musi opisywać wszystkich wymagań, decyzji, ograniczeń ani szczegółów działania. Nawet wiele diagramów może pozostawić ważne kwestie poza zakresem, na przykład reguły biznesowe, warunki wdrożenia lub kryteria akceptacji. Te informacje można zapisać innymi sposobami i powiązać z modelem, jeśli projekt tego wymaga.
W praktyce warto najpierw określić, komu diagram ma pomóc i jakie pytanie ma rozstrzygnąć. UML jest użyteczny wtedy, gdy dobrany zapis przekazuje potrzebne informacje; sam wybór notacji nie zapewnia kompletności ani jakości dokumentacji.