Jak zdjąć blokadę z pakietu z kontrolą wersji?

W przypadku, gdy w repozytorium jest włączona kontrola wersji w oparciu o SVN lub inny system kontroli wersji może dojść do sytuacji, gdy ktoś zablokował dla siebie możliwość edycji zawartości pakietu (funkcja check-out), a my potrzebujemy pilnie otrzymać uprawnienia do modyfikacji jego zawartości i nie możemy czekać aż ten zapominalski wróci do pracy z urlopu lub ze spotkania z klientem.
Tylko co zrobić? Program Enterprise Architect uparcie zwraca nam informację, że pakiet ten jest zablokowany do edycji wyświetlając komunikat o treści: The selected package cannot be checked-out at this time. The associated XMI package file is already checked-out.

Cykl życia elementu

Inżynieria oprogramowania traktuje oprogramowanie jako produkt, który ma spełniać określone potrzeby głównie w aspektach technicznych i ekonomicznych. Definiuje w tym kontekście pojęcie cyklu życia oprogramowania oraz skupia się na narzędziach wspierających proces wytwarzania i utrzymania oprogramowania we wszystkich fazach życia produktu.





Podstawowe fazy cyklu życia, które przewijają się w różnych modelach cyklu życia to:

• Analiza (bądź specyfikacja produktu) - określenie i ustalenie wymagań,
• Projektowanie - ustalenie ogólnej architektury systemu,
• Implementacja - realizacja ustalonej architektury, czyli implementacja elementów składowych i ich połączenie,
• Integracja (bądź testowanie) - zintegrowanie poszczególnych elementów składowych w jeden systemu oraz testowanie całości rozwiązania,
• Wdrożenie - uruchomienie produkcyjne systemu,
• Utrzymanie systemu - usuwanie błędów produkcyjnych oraz rozwój systemu.

Enterprise Architect jest jednym z takich narzędzi wspierających. Element w EA posiada również zestaw atrybutów, który służy do określenia momentu w życia produktu. Są to:

• wersja (patrz: Wersjonowanie elementów),
• faza,
• status (patrz: Własny zestaw statusów).

Ponadto dużym ułatwieniem w zarządzaniu informacjami o cyklu życiu jest możliwość grupowej aktualizacji informacji, patrz: Cykl życia elementów - grupowa aktualizacja.
Zatem wskazane jest, aby ogólnie przyjęte zasady w stosowanych metodykach wytwarzania oprogramowania związane z cyklem życia produktu zastosować również w Enterprise Architect, który wspiera wytwarzanie oprogramowania. Sparx, producent Enterprise Architect nie narzuca jednak w tej kwestii żadnych reguł i daje swobodę użytkownikom. Ja osobiście określiłbym to następującym oksymoronem: "zaleta granicząca z wadą". Swoboda w definiowaniu reguł dotyczących wersjonowaniu skutkuje brakiem reguł w projekcie.
Zazwyczaj natłok zadań projektowych i napięte terminy skutkują tym, że wytworzony model jest najlepszy, jaki udało się stworzyć w ograniczonym czasie - czyli innymi słowy - daleki od doskonałości.

W tym celu zasadne wydaje się wprowadzenie projektowych zasad wersjonowania. Nie sposób sformułować uniwersalnych zasad w tej kwestii, gdyż każdy projekt jest określany jako specyficzny i posiada swoiste potrzeby i ograniczenia. W tym miejscu możliwe jest tylko wymienienie określonych przesłanek, które należy rozważyć już na etapie startu projektu. Są to:

• wyszukiwanie określonych elementów w modelu w zależności od ich wersji, etapu projektu i statusu,
• filtrowanie zawartości generowanej dokumentacji w zależności od wersji, etapu projektu i statusu,
• zakres danych niezbędny do wypełnienia wymagań dotyczących dokumentacji,
• raportowanie zmian w modelu w perspektywie czasowej (w przedziale czasu)  lub projektowej (w ramach określonej modyfikacji),
• zastosowanie mechanizmu Diagram Filters, np. do zobrazowania różnic pomiędzy stanem bazowym (AS-IS) oraz stanem docelowym (TO-BE),
• utrzymywanie i rozwój modelu przedsięwzięcia w dłuższej perspektywie czasu,
• unifikacja zasad wersjonowania produktów i artefaktów tworzonych bez użycia Enterprise Architecta, 
• potrzeba przesyłania całego modelu lub jego części pomiędzy różnymi osobami, które mogą nanosić zmiany w modelu, w sytuacji, gdy nie jest wykorzystywane współdzielone repozytorium,
• potrzeba wykorzystania mechanizmów typu Workflow do implementacji zasad projektowych,
• organizacja zawartości modelu w hierarchii pakietów,
• ograniczony czas na opracowanie modelu,
• brak możliwości wpływania na zakres wprowadzanych modeli przez członków zespołu pochodzących z innych organizacji.

Wersjonowanie diagramów

Opisałem dotychczas kwestię wersjonowania elementów i pakietów oraz metody automatycznej aktualizacji wartości wersji. W tym artykule poruszę kwestię wersjonowania diagramów.

W jakim celu wersjonować diagramy?

Każdy diagram w momencie jego utworzenia otrzymuje domyślną wartość atrybutu Version, zapisywana jest również data jego utworzenia i ostatniej modyfikacji. Rzadko zdarza się, aby raz utworzony diagram był od razu doskonały i nie wymagał wprowadzenia modyfikacji. Tworzone modele stanowią część dokumentacji projektowej, a ta dokumentacja również podlega zmianom. W fazie wytwarzania modeli powszechne jest przesyłanie diagramów pomiędzy członkami zespołu projektowego oraz pomiędzy wykonawcą a klientem w celu zgłaszania uwag i poprawianiu ich jakości. Informacja o wersji i dacie modyfikacji diagramu zamieszczona wprost na diagramie znacząco ułatwia zorientowanie się, czy mamy do czynienia z aktualną wersją.

Wersjonowanie elementów

Enterprise Architect został zaprojektowany w taki sposób, aby możliwe było określenie wersji dowolnego typu elementu, np. wymagania, przypadku użycia, komponentu, klasy czy obiektu.

Wersjonowaniu mogą podlegać na tej samej zasadzie również pakiety i diagramy.
W przypadku tworzenia modelu na zasadzie ad-hoc, czyli gdy tworzymy model "jednorazowego użytku" w odniesieniu do krótkotrwałego projektu można pominąć zagadnienie wersjonowania. Jednak ten temat staje się istotny, gdy model:

• dotyczy długiego projektu (dłuższego niż 3 miesiące),
• w grę wchodzi utrzymanie projektowanego systemu po jego wdrożeniu,
• zakłada się potrzebę generowania i aktualizowania dokumentacji,
• w projekt jest zaangażowany duży zespół.

W przypadku spełnienia choćby niektórych z powyższych kryteriów już w momencie startu projektu, na etapie definiowania projektowych zasad modelowania należy poczynić ustalenia w kwestii wersjonowania. Zalecane jest, aby zasady wersjonowania w Enterprise Architect były spójne z zasadami wersjonowania wszystkich produktów (artefaktów wchodzących w skład deliverables, lub będących deliverables) projektu. Trzymanie się tej zasady pozwala na spójne zarządzanie konfiguracją (configuration management) oraz na odzwierciedlenie w modelu określonego momentu w cyklu życia projektu.

Cykl życia elementów - grupowa aktualizacja

W swoich postach rozpisuję się o cyklu życia elementów. Piszę o wersjonowaniu, o własnej liście statusów oraz o wprowadzaniu zasad projektowych mających na celu zachowanie porządku w modelu.
Jak jednak utrzymać ten porządek w repozytorium, gdy gonią terminy i jest wiele różnych pilnych zadań do wykonania?
Z pomocą przychodzi funkcja Update Package Status, o której rzadko się pamięta i dlatego zechciałem poświęcić jej odrobinę miejsca.

Własny zestaw statusów

Każdy element w modelu posiada swój własny zestaw atrybutów. Wśród standardowych atrybutów znaleźć można trzy, które służą określeniu momentu w cyklu życia elementu. Są to:

• status,
• wersja,
• faza.

Domyślnie, w standardowej konfiguracji każdy nowo utworzony element otrzymuje status: Proposed, wersję: 1.0 oraz fazę: 1.0. Na początku najczęściej użytkownicy EA skupiają się na tym, aby opracować jak najlepsze diagramy, które wiernie odzwierciedlają specyfikę projektowanego przedsięwzięcia i są w miarę zgodne z notacją. Później zaczynają dbać o to, żeby nie tworzyć duplikatów tych samych elementów, tzn. na wielu diagramach umieszczać ten sam element, a nie jego kopię. Jeszcze później użytkownicy zaczynają się zastanawiać nad cyklem życia takich elementów, bo przecież projektowany system w którymś momencie wchodzi w fazę utrzymania i konieczne staje się ogarnięcie różnych stanów modyfikacji, faz wdrożenia, czy wydań.

Jak usunąć masowo kontrolę wersji z modelu?

Zawartość modelu może być poddana kontroli wersji przy użyciu SVN lub TFS. Zastosowanie takiego mechanizmu niesie ze sobą wiele zalet, które opiszę przy innej okazji.
Gdy model jest poddany kontroli wersji, wówczas jednak mamy ograniczone możliwości, bo możemy stworzyć kopię repozytorium w postaci pliku EAP lub testowej bazy danych - korzystając z funkcjonalności Project Transfer, ale co z tego, skoro i tak kopia repozytorium jest nadal "spięta" z tym samym systemem kontroli wersji.
Co zrobić zatem, gdy potrzebujemy przekazać klientowi kopię naszego modelu albo wykonać jakieś testy w modelu bez obaw o przypadkowe "uszkodzenie" zawartości modelu wykorzystywanego przez zespół?