Model to opis wybranego systemu, diagram to jego graficzny widok, a notacja to reguły i symbole, za pomocą których ten widok zapisujemy. Te pojęcia są powiązane, ale nie są zamienne: model zawiera znaczenie i relacje, diagram pokazuje wybraną część lub perspektywę, a notacja pomaga odbiorcy odczytać zapis. Rozróżnienie jest ważne, bo można narysować czytelny diagram, który błędnie przedstawia model, albo mieć poprawny model pokazany na nieczytelnym rysunku.
Model: znaczenie tego, co opisujemy#
Model jest uproszczonym, celowym opisem systemu, procesu, dziedziny lub innego problemu. Autor wybiera elementy istotne dla konkretnego pytania i pomija te, które w danym kontekście nie pomagają. Model może opisywać rzeczy istniejące, system dopiero projektowany albo zachowanie, które ma zostać zrealizowane.
Przykładowy model systemu zapisów na zajęcia może zawierać studentów, kursy i zapisy studentów na kursy. Reguła „jeden zapis dotyczy jednego studenta i jednego kursu” należy do treści modelu. Nie zależy od tego, czy przedstawimy ją diagramem, tabelą, tekstem czy danymi w narzędziu modelującym.
W formalnym UML Model ma także precyzyjne znaczenie metamodelowe: jest wyspecjalizowanym rodzajem pakietu zawierającym elementy modelu. W codziennej rozmowie słowo „model” bywa używane szerzej na określenie całościowego opisu lub jego części. W obu użyciach chodzi o treść i strukturę opisu, a nie wyłącznie o obraz widoczny na ekranie.
Model jest zawsze selektywny. Model studentów i kursów może pomijać oceny, terminy zajęć, płatności czy historię zmian, jeśli nie są potrzebne do bieżącego celu. Pominięcie nie oznacza, że dana informacja nie istnieje w rzeczywistości; oznacza, że ten konkretny model jej nie przedstawia. Gdy zakres nie jest jasny, odbiorca może błędnie uznać uproszczenie za kompletną regułę systemu.
Diagram: graficzny widok modelu#
Diagram UML przedstawia graficznie wybrane elementy modelu oraz relacje między nimi. Może pokazywać cały model albo — co częstsze w praktyce — tylko te jego części, które są ważne dla odbiorcy i konkretnego pytania. Ten sam model można przedstawić na kilku diagramach, na przykład osobno pokazać strukturę pojęć, przebieg scenariusza i rozmieszczenie komponentów.
Poniższy diagram jest jednym graficznym widokiem modelu zapisów na kursy. Nie zawiera wszystkich możliwych informacji o studentach i kursach. Pokazuje trzy klasy i powiązania, które są istotne dla przykładu.
Każdy obiekt Zapis jest w tym modelu powiązany z jednym Studentem i jednym Kursem. Student może mieć zero lub wiele zapisów; kurs może mieć zero lub wiele zapisów. Rysunek nie mówi, czy student może zapisać się na ten sam kurs ponownie ani czy kurs ma limit miejsc — takie reguły trzeba dodać, jeśli są istotne.
Diagram nie jest automatycznie osobnym, kompletnym modelem. W narzędziu modelującym kilka diagramów może korzystać z tych samych elementów modelu, podczas gdy edytor tekstu może przechowywać pojedynczy diagram i opis bez formalnego repozytorium. Dlatego przy przekazywaniu diagramu warto podać jego zakres i kontekst. Sam obraz może nie zawierać wszystkich definicji ani ograniczeń, które istnieją w pełnym modelu.
Notacja: sposób zapisu i odczytu#
Notacja to uzgodniony zestaw znaków oraz reguł ich interpretacji. Na diagramie klas prostokąt oznacza klasę, linia może oznaczać asocjację, a liczba przy końcu relacji opisuje liczność obiektów powiązanych z jednym obiektem po drugiej stronie. Umieszczenie 1 przy końcu Student oznacza, że każdy Zapis dotyczy jednego studenta; 0..* przy końcu Zapis oznacza, że student może mieć zero lub wiele zapisów.
W specyfikacji języka można rozróżnić składnię abstrakcyjną i składnię konkretną. Składnia abstrakcyjna opisuje, jakie elementy i relacje mogą tworzyć model oraz jak są ze sobą powiązane. Składnia konkretna określa, jak te elementy zapisuje się w wybranej notacji — na przykład jako prostokąty, linie, groty strzałek i etykiety. Semantyka opisuje znaczenie tych elementów i relacji. W praktyce UML definiuje zarówno strukturę modelu, jak i reguły znaczeniowe, a notacja graficzna jest jednym ze sposobów jej przedstawienia.
Wygląd diagramu może dodatkowo zależeć od konwencji zespołu lub narzędzia. Kolor, układ, kroje linii i rozmieszczenie mogą poprawiać czytelność, ale nie należy przypisywać im standardowego znaczenia UML, jeśli projekt nie zdefiniował takiej konwencji. Z kolei symbol UML ma znaczenie wynikające z notacji i nie powinien być zmieniany w sposób, który utrudnia poprawne odczytanie.
Trzy różne rodzaje poprawności#
Rozdzielenie modelu, diagramu i notacji pomaga znaleźć źródło błędu:
- Błąd modelu — zapisuje się nieprawdziwe albo nieuzgodnione założenie. Przykład: system w rzeczywistości pozwala przypisać zapis do wielu studentów, a model zakłada jednego.
- Błąd notacji lub składni — elementy zapisano niezgodnie z regułami UML albo narzędzia. Przykład: użyto symbolu generalizacji tam, gdzie opis ma oznaczać zwykłe powiązanie.
- Błąd czytelności diagramu — relacje są zasłonięte, podpisy nieczytelne albo widok zawiera nadmiar szczegółów. Znaczenie modelu może być poprawne, ale odbiorca nie odczyta go pewnie.
Renderer może pomóc wykryć błąd składni narzędzia, a kontrola modelu — niespójność elementów. Żadna z tych kontroli nie potwierdza sama, że założenia odpowiadają rzeczywistemu systemowi. Potrzebna jest także weryfikacja z osobami znającymi problem i odbiorcami diagramu.
Ten sam model, różne diagramy i zapisy#
Załóżmy, że chcemy wyjaśnić, jak działa zapis na kurs. Diagram klas pokaże pojęcia Student, Kurs i Zapis oraz ich relacje. Diagram sekwencji może przedstawić wymianę komunikatów, gdy student zapisuje się na kurs. Diagram aktywności może pokazać kroki i decyzje w procesie, na przykład sprawdzenie, czy są wolne miejsca. Te diagramy odpowiadają na różne pytania, ale mogą opisywać ten sam system.
Model można też przedstawić innym sposobem. Relację można opisać zdaniem, zapisać jako strukturę w narzędziu albo wyrazić tekstowo, na przykład w składni obsługiwanej przez PlantUML. Tekst PlantUML jest konkretnym formatem wejściowym dla narzędzia; nie jest całą definicją UML. Narzędzie przekształca go w graficzny diagram, ale nie uzupełnia automatycznie pominiętych założeń modelu.
Przy pracy z modelami używa się zarówno formalnych, szczegółowych diagramów, jak i szkiców przygotowanych na potrzeby rozmowy. Szkic może być celowo niekompletny, jeśli uczestnicy rozumieją, że pokazuje tylko wybrane kwestie. Gdy diagram staje się trwałą specyfikacją lub podstawą automatycznego przetwarzania, potrzebuje większej precyzji, spójnego zakresu i jasnych reguł interpretacji.
Częste pomyłki#
- „Diagram to cały model”. Diagram pokazuje wybrane elementy lub perspektywę; pełny model może zawierać więcej danych, ograniczeń i dokumentacji.
- „Notacja i model to to samo”. Notacja jest sposobem zapisu, model niesie treść i relacje. Zmiana graficznej postaci nie musi zmienić znaczenia modelu.
- „Jeśli da się wyrenderować, to model jest poprawny”. Renderowanie sprawdza przede wszystkim, czy narzędzie rozumie wejściowy zapis. Nie weryfikuje prawdziwości wymagań ani założeń.
- „Każdy kolor albo układ ma znaczenie UML”. Kolory i układ mogą być konwencją zespołu lub ustawieniem narzędzia. Ich znaczenie trzeba uzgodnić, jeśli ma wpływać na interpretację.
- „Jeden diagram powinien pokazać wszystko”. Łączenie wielu pytań na jednym rysunku może uczynić go trudnym do czytania. Osobne, uzupełniające się widoki bywają czytelniejsze.
Jak sprawdzić, co właśnie oglądasz?#
Zadaj trzy pytania. Jaki system i zakres opisuje model? Które elementy lub relacje pokazuje ten diagram, a które pomija? Jakie reguły notacji pozwalają odczytać symbole i połączenia? Gdy odpowiedzi są jasne, łatwiej zauważyć, czy nieporozumienie wynika z błędnej reguły, nieczytelnego rysunku czy innego rozumienia samego problemu.
Najkrócej: model jest opisem, diagram jego wybranym graficznym widokiem, a notacja językiem znaków i reguł użytym do przedstawienia tego widoku. Dobre modelowanie wymaga poprawnej treści, zrozumiałego diagramu i konsekwentnego stosowania notacji — te trzy warunki wspierają się, ale żaden nie zastępuje pozostałych.