Dlaczego współpraca nad modelem wymaga reguł#
Wspólny model UML to nie tylko plik edytowany przez kilka osób. Zawiera pojęcia, relacje, diagramy, opisy i decyzje, które mają być zrozumiałe dla określonych odbiorców. Zespół potrzebuje uzgodnić, kto może zmieniać model, jak przegląda zmiany, gdzie znajduje się wersja obowiązująca i kiedy diagram należy aktualizować.
Bez tych reguł powstają duplikaty pojęć, sprzeczne nazwy, rozbieżne widoki i diagramy o niejasnym statusie. Samo narzędzie ani kontrola wersji nie zapewniają spójności. Pomagają ją utrzymać dopiero w połączeniu z odpowiedzialnością, konwencjami i przeglądem merytorycznym.
Właścicielstwo i zakres odpowiedzialności#
Wyznacz właściciela modelu lub jego obszarów. Właściciel dba o strukturę, konwencje, aktualność i rozstrzyganie duplikatów. Nie musi sam rysować każdego diagramu. Autor zmiany odpowiada za wskazanie celu, powiązanych wymagań lub decyzji i aktualizację właściwych widoków. Recenzent sprawdza znaczenie oraz czytelność. Osoba administrująca narzędziem odpowiada za uprawnienia, kopie zapasowe i konfigurację procesu.
W małym zespole role mogą być łączone, ale odpowiedzialność powinna pozostać czytelna. Dla dużego repozytorium dziel obszary według domeny, systemu, pakietu lub zespołu. Ustal, kto zatwierdza relacje przekraczające granice odpowiedzialności i jak zgłaszać zmiany wspólnych elementów.
Wspólny przebieg zmiany#
Zmiana zaczyna się od określenia problemu i odbiorców. Autor edytuje model w uzgodnionym miejscu, opisuje istotną zmianę i sprawdza diagramy, które używają zmienionych elementów. Recenzent ocenia, czy model odpowiada decyzji lub wymaganiu, a także czy rozmiar i układ widoku są czytelne. Po akceptacji zmiana trafia do wspólnej wersji, a eksporty i dokumentacja są odświeżane.
Jeśli zmiana nie zostaje przyjęta, autor poprawia ją i ponownie zgłasza do przeglądu. Mała, częsta zmiana bywa łatwiejsza do zrozumienia niż duży jednorazowy przebudowany model. Proces może być lżejszy lub formalniejszy zależnie od ryzyka oraz wymagań audytowych.
Konwencje modelowania#
Uzgodnij nazewnictwo elementów, pakietów, diagramów, relacji i plików. Ustal język nazw, reguły skrótów, format tytułów, poziom szczegółowości oraz użycie kolorów i stereotypów. Wyjaśnij, kiedy tworzony jest nowy element, a kiedy ponownie używa się istniejącego. Dla powtarzalnych typów diagramów przygotuj przykłady lub szablony.
Konwencje nie powinny narzucać większej liczby szczegółów, niż jest potrzebna do wspólnego zrozumienia. Jeżeli zasady są zbyt skomplikowane, autorzy będą je omijać. Traktuj je jako żywy dokument: zmieniaj po zauważeniu powtarzających się problemów i informuj zespół o aktualizacji.
Organizacja repozytorium#
Struktura modelu powinna ułatwiać odnajdywanie elementów i przypisywać im sensowny zakres. Pakiety mogą odpowiadać domenom, modułom, warstwom albo innym stabilnym granicom, ale nie twórz równolegle kilku niespójnych hierarchii. Rozdziel projektowe modele od tymczasowych szkiców i wskaż, które materiały są obowiązujące.
Ustal strategię współbieżności. Niektóre narzędzia przechowują model w centralnym repozytorium i pozwalają pracować w jednym projekcie; inne wersjonują poszczególne pakiety lub pliki, a praca odbywa się przez kopie robocze. Pliki modelu mogą być trudne do scalania zwykłym narzędziem tekstowym. Sprawdź zasady blokowania, wyewidencjonowania, aktualizacji, porównywania i cofania zmian w wybranym programie.
Podziel model na zakresy, które mogą być rozwijane względnie niezależnie. Małe, logiczne pakiety ograniczają ryzyko, że wiele osób zmieni ten sam plik. Dla elementów używanych przez wiele zespołów ustal osobę lub grupę zatwierdzającą zmiany. Zapewnij kopie zapasowe, kontrolę dostępu, historię zmian i test odzyskiwania.
Jak przeglądać zmianę#
Recenzent powinien zobaczyć kontekst zmiany, a nie tylko różnicę w pliku. Zgłoszenie wyjaśnia: co się zmienia, dlaczego, jaki obszar obejmuje, z jaką wersją kodu lub wymagania jest zgodne oraz które diagramy zostały sprawdzone. Przy diagram-as-code warto dołączyć podgląd obrazu; dla plików graficznych przydatny jest zrzut lub porównanie wersji.
Kontrola obejmuje sens nazw, właściwy rodzaj relacji, kierunek, krotności, warunki i zgodność z wymaganiami. Ocenia także czytelność, kompletność dla odbiorcy, aktualność powiązanych diagramów, zgodność z konwencjami i brak przypadkowych szczegółów. Walidator narzędzia może wykryć część błędów formalnych, ale nie zastępuje recenzenta znającego domenę.
Ustal, czy zmiana wymaga zatwierdzenia jednej osoby, właściciela obszaru czy ekspertów kilku domen. Skala przeglądu powinna odpowiadać wpływowi. Drobna aktualizacja etykiety nie wymaga tego samego procesu co zmiana granic komponentów lub centralnej definicji pojęcia.
Konflikty i uzgadnianie zmian#
Konflikt może oznaczać techniczną niemożność scalenia pliku, ale również sprzeczne znaczenie dwóch zmian. Najpierw ustal, które decyzje są zamierzone i czy dotykają tego samego elementu. Porównaj kontekst obu wersji, porozmawiaj z właścicielami obszarów i dokonaj scalenia w narzędziu źródłowym. Po połączeniu zmian otwórz wszystkie dotknięte diagramy i sprawdź je wizualnie.
Nie rozwiązuj konfliktu przez bezrefleksyjne wybranie „naszej” lub „ich” wersji. Nie poprawiaj wyłącznie obrazu, jeżeli źródłem jest model, i nie kopiuj ręcznie grafik między wersjami. Zachowaj komentarz opisujący rozstrzygnięcie, jeśli przyczyna mogłaby być ważna przy kolejnym przeglądzie.
Baseline, wydania i ślad audytowy#
W ważnych momentach projektu można zachować baseline lub inną zatwierdzoną migawkę modelu. Ułatwia porównanie z późniejszym stanem, analizę zmian i przywracanie punktu odniesienia. Migawka powinna mieć nazwę, datę, cel, właściciela oraz powiązanie z wersją oprogramowania lub wydaniem.
Historia repozytorium pokazuje, jak zmieniał się model; nie zawsze wyjaśnia, dlaczego podjęto decyzję. Do istotnych modyfikacji dodawaj krótkie uzasadnienie, link tekstowy w zatwierdzeniu lub zapis decyzji w systemie projektu. Nie traktuj samego komentarza w narzędziu jako pełnej dokumentacji, jeśli zespół nie ma do niego dostępu.
Aktualność i publikowanie#
Każdy diagram powinien mieć cel, odbiorcę, właściciela i warunek aktualizacji. Zmieniaj go, gdy zmienia się decyzja, zachowanie lub architektura, którą opisuje. Nie aktualizuj formalnie modelu dla każdej kosmetycznej zmiany implementacji, jeżeli ta informacja nie jest istotna dla widoku. Z drugiej strony nie zostawiaj diagramu opisującego dawną granicę systemu, jeśli odbiorcy mogą uznać go za aktualny.
Wskaż miejsce publikacji i sposób generowania obrazów. Eksportuj z zatwierdzonej wersji, sprawdzaj podpisy i alternatywne opisy, a stare kopie wycofuj lub oznaczaj jako historyczne. Oddziel szkice, wersje robocze i materiały zatwierdzone. Zadbaj o to, by odbiorca spoza zespołu wiedział, do jakiego stanu systemu odnosi się diagram.
Jak dobrać proces do zespołu#
Dla małego projektu wystarczy repozytorium diagramów, prosta konwencja nazw, odpowiedzialny autor i krótki przegląd zmian. W wielu zespołach przydatny jest podział na pakiety, właściciele domen, recenzja techniczna i automatyczne odświeżanie eksportu. W projektach regulowanych lub o dużym ryzyku dochodzą role, audyt, formalne zatwierdzenia i kontrolowane wydania.
Zacznij od minimalnego procesu, który zapobiega duplikatom, konfliktom i nieaktualnym widokom. Rozbudowuj go dopiero wtedy, gdy pojawi się konkretny problem. Mierz, czy model poprawia komunikację, decyzje i analizę wpływu; jeśli przeglądy stają się biurokracją, usuń kroki, które nie chronią jakości ani odbiorców.