Wspólny model pomaga uzgodnić znaczenie#
UML wspiera współpracę, gdy członkowie zespołu używają diagramów do uzgadniania pojęć, granic, kontraktów i zachowania. Wspólna notacja może ograniczyć różne interpretacje tekstu, ułatwić rozmowę między rolami i przekazywać wiedzę osobom, które dołączają do projektu.
Sam standard nie sprawi, że wszyscy rozumieją diagram tak samo. Zespół potrzebuje wspólnych nazw, konwencji i praktyki sprawdzania, czy odbiorca odczytuje model zgodnie z intencją autora.
Uzgodnij proste konwencje#
Zdefiniuj, jak nazywacie klasy, pakiety, komponenty i przypadki użycia; kiedy pokazujecie liczności; co oznacza brak strzałki; jak opisujecie warunki i wersje widoków. Konwencje powinny ułatwiać komunikację i być krótkie. Nie kopiuj zasad z narzędzia jako obowiązkowej semantyki UML.
Wybieraj wspólny poziom szczegółowości dla danego typu widoku. Analityczny model domenowy nie musi zawierać tych samych operacji co diagram projektu. Jeśli diagram miesza konwencje lub poziomy, nazwij perspektywę i objaśnij niestandardowe elementy.
Współtwórz diagramy#
Wspólne modelowanie podczas warsztatu pozwala ekspertom domenowym i technicznym od razu korygować założenia. Jedna osoba może obsługiwać narzędzie, ale powinna pytać o znaczenie, zamiast podejmować decyzje za grupę. Przykłady, przypadki błędów i wartości graniczne są dobrym sposobem weryfikacji.
Diagramy można przeglądać jak kod: określić zakres zmiany, sprawdzić kierunki, liczności, warunki i wpływ na wymagania. Recenzent powinien znać odbiorców i cel diagramu; bez tego może krytykować uproszczenie, które było zamierzone, albo przeoczyć brak ważnego szczegółu.
Powiąż diagram z pracą zespołu#
Włącz przegląd modelu do zmian, które naruszają opisane granice lub kontrakty. W zadaniu albo pull requeście można wskazać, które widoki zostały zaktualizowane i dlaczego inne nie wymagały zmian. Diagram tekstowy w repozytorium ułatwia wersjonowanie i diff, a model wizualny może być właściwy, jeśli zespół ma wspólne narzędzie oraz jasny proces synchronizacji.
Nie wymagaj zmiany diagramu przy każdej wewnętrznej modyfikacji kodu. Zaktualizuj go, gdy zmienia się fakt, który diagram ma przekazywać. Ustal właściciela lub zespół odpowiedzialny za poprawność modelu.
Źródła prawdy i rozbieżności#
Kod, API, diagram, dokumentacja procesu i testy mogą opisywać różne aspekty systemu. Wskaż, który artefakt jest nadrzędny dla danej informacji. Jeśli diagram jest źródłem architektury, nie oczekuj, że zostanie automatycznie odtworzony z kodu. Jeśli specyfikacja API jest nadrzędna, diagram powinien odsyłać do niej zamiast duplikować każdy szczegół.
Gdy model i implementacja są sprzeczne, ustal, czy kod jest błędny, diagram nieaktualny, czy istnieje nieopisana decyzja. Nie rozwiązuj rozbieżności przez edycję obu artefaktów bez decyzji właściciela. Zapisz wniosek i sprawdź wpływ na testy oraz integracje.
Dostępność i narzędzia#
Używaj formatu, który członkowie zespołu mogą edytować, przeglądać i udostępniać. Zapewnij tekst alternatywny, podpis i opis skrótów dla osób, które nie mogą odczytać obrazu. Diagram powinien działać w narzędziach używanych przez zespół i dać się otworzyć bez płatnej licencji, jeśli odbiorcy jej nie mają.
Automatyczne generowanie, linting i renderowanie mogą wykryć błędy składniowe, brakujące pliki albo niespójne nazwy. Nie zastępują rozmowy o semantyce. Wygenerowany diagram nadal wymaga przeglądu przez osobę znającą problem.
Kiedy diagram może przeszkadzać#
Nieczytelny lub nieaktualny diagram tworzy fałszywą pewność, a nadmiar modeli zwiększa koszty utrzymania. Jeśli nikt nie używa diagramu, nie wiadomo, kto go zmienia, albo informacje są łatwiej dostępne w kodzie, rozważ uproszczenie, archiwizację lub usunięcie.
Diagram powinien pomagać konkretnym odbiorcom. Jeżeli potrzebują oni tylko jednego warunku, krótki opis może być lepszy od pełnego modelu. Zachowuj różne widoki, gdy każdy wnosi odrębną perspektywę, a nie tylko powiela elementy.
Typowe błędy#
- Założenie, że wszyscy znają UML. Objaśnij konwencje i sprawdzaj interpretację.
- Diagram tworzony przez jedną rolę bez konsultacji. Weryfikuj treść z osobami znającymi domenę.
- Brak źródła prawdy. Ustal, gdzie aktualizować kontrakt i model.
- Wszystkie zmiany kodu wymagają diagramu. Aktualizuj widok, którego znaczenie rzeczywiście się zmienia.
- Automatyzacja uznana za recenzję semantyki. Sprawdź model z zespołem.
- Konwencje zbyt skomplikowane. Stosuj tylko zasady, które rozwiązują realny problem komunikacji.
- Rozbieżność między kodem a diagramem przemilczana. Ustal obowiązujący stan i zaktualizuj źródła.
Podsumowanie#
UML wspiera zespół, gdy członkowie wspólnie uzgadniają znaczenie diagramów, stosują proste konwencje i aktualizują modele w ramach zmian. Wyznacz odbiorców, właścicieli i źródła prawdy, a automatyzację wykorzystuj do sprawdzania plików i renderowania. Semantykę weryfikuj w rozmowie i przeglądzie.