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.

Atrybut określający wersję (version) elementu można znaleźć w oknie Properties elementu.

W podobny sposób można określić również wersję pakietu lub diagramu.

Przykłady konwencji wersjonowania

Wersjonowanie proste

Wytwarzane elementy są wersjonowane w następujący sposób: X.Y
Zera wiodące: brak
Wartość inicjalna: 1.0
Możemy zdecydować się na prostą konwencję nadawania wersji polegającą na tym, że nowo utworzony element będzie miał nadawaną wersję: 1.0, a w ramach kolejnych modyfikacji jego wersja jest inkrementowana w następujący sposób:

• miejsce przed kropką - w przypadku dużej modyfikacji,
• miejsce po kropce - w przypadku małej modyfikacji.

Ocenę co do stopnia modyfikacji (mała lub duża) można pozostawić autorowi zmiany.

Wersjonowanie formalne dwuczłonowe

Wytwarzane elementy są wersjonowane w następujący sposób: X.YY
Zera wiodące: w drugim czlonie
Wartość inicjalna: 0.01
Pierwsza wersja dokumentu w momencie jego utworzenia to: 0.01, każda kolejna wersja robocza elementu jest inkrementowana w zakresie drugiego członu numeru werji: 0.02, 0.03...
W momencie zatwierdzenia zestawu elementów zmienia się pierwszy człon wersji na: 1.00 (drugi człon wersji przyjmuje wartość: zero). Przykładem mogą być elementy typu Wymaganie, dla których wersja ustawiana jest na 1.00 w momencie zatwierdzenia produktów analitycznych i przejścia do kolejnej fazy projektu.
W takim wypadku pierwszy człon numeru wersji możemy nazywać na przykład Wersją Odniesienia, zaś drugi człon numeru wersji - Iteracją.
Element może przyjąć wersję 2.00 w zależności od ustaleń w sytuacji, gdy:

• przekazana/zatwierdzona zostaje kolejna wersja tego elementu (wchodzącego w skład jakiegoś artefaktu/produktu projektowego, lub
• ten sam element podlega zmianom w ramach innego projektu, realizowanego osobno po zakończeniu poprzedniego projektu.

W tym wypadku warto narzuć użytkownikom zmianę ustawień na stacji roboczej. W menu Tools --> Options, na zakładce Objects można zmienić domyślną wartość wersji dla nowo tworzonych elementów.

Inne konwencje wersjonowania

Brak jest jakichkolwiek przeszkód przed wybraniem dowolnej innej konwencji wersjonowania, która mogłaby stanowić jakąś wariację któregoś z wyżej opisanych wariantów. Ważne są w tej kwestii tylko następujące przesłanki:

• członkowie zespołu projektowego rozumieją zasady wersjonowania,
• członkowie zespołu akceptują zasady wersjonowania,
• członkowie zespołu stosują przyjęte zasady wersjonowania.

Warto jeszcze wspomnieć, że TOGAF (The Open Group Architecture Framework) w opisie opracowywanych produktów posługuje się wprost następującymi wersjami:

• 0.1 - produkt w wersji roboczej,
• 1.0 - produkt w wersji formalnie zatwierdzonej.

Wersjonowanie baseline

Sparx Enterprise Architect jest wyposażony w mechanizm Baseline. Jest to funkcjonalność pozwalająca na zapisanie aktualnej wersji wybranej gałęzi modelu (bądź całego modelu) w formie migawki (snapshotu). Opis tego mechanizmu nie jest przedmiotem niniejszego artykułu. W tym miejscu chcę zasygnalizować, że mechanizm ten warto sprzęgnąć z zasadami wersjonowania elementów. Zalecam, aby tworzyć nowy baseline w modelu w momentach, gdy określony fragment modelu zostaje przekazany klientowi bądź zmienia się status określonych elementów np. na Zatwierdzony czy Zaakceptowany.
Dodatkowo w momencie tworzenia baseline'a konieczne jest wpisanie jego wersji. Zasady wersjonowania można sformułować na przykład w taki sposób, aby wszystkie zmodyfikowane elementy wchodzące w skład tworzonego baseline'a miały taką samą wersję, jak baseline. Przesłanką do tego jest choćby to, że Enterprise Architect sprawdza, czy wersja nowego baseline'a jest wyższa od poprzedniej. Brak jest takiego samego sprawdzenia w przypadku zmiany wersji elementów czy diagramów, ale ma to swoje uzasadnienie w tym, że wersja elementu lub diagramu może mieć również wartość wyrażoną tekstem, a nie tylko liczbami.

Metody automatyzacji wersjonowania w modelu

Idea wdrożenia zasad wersjonowania może zjeżyć włosy na głowie niejednej osobie. Okazuje się, bowiem, że użytkownik Enterprise Architect musi zadbać nie tylko o wartość merytoryczną tworzonego modelu, ale również o kilka innych spraw, które nie przekładają się wprost na jakość wytwarzanego oprogramowania. Łatwiej zaakceptować tę ideę, gdy rozpatruje się ją w kontekście jakości dokumentacji oraz fazy utrzymania i rozwoju systemu, gdy wdrażanych jest wiele drobnych zmian, nad którymi trzeba umiejętnie zapanować.
Niemniej jednak metody automatyzacji wersjonowania są mile widziane.
W odniesieniu do wersjonowania wymagań Enterprise Architect ulega konkurencji. Produkt Borlanda do zarządzania wymaganiami: Caliber RM posiada wbudowany mechanizm wersjonowania, który powoduje inkrementację wartości wersji przy każdej zmianie treści lub dowolnego atrybutu wymagania. Bardzo mi brakuje tej funkcjonalności w Enterprise Architect i mam nadzieję, że kiedyś zostanie wprowadzona.

Grupowa aktualizacja gałęzi modelu

Najprostszą metodą jest wykorzystanie funkcji Update Package Status, która jest opisana w artykule Cykl życia elementów - grupowa aktualizacja. Dzięki temu jednym za jednym zamachem możliwe jest ustalenie nowej wartości wersji i/lub statusu dla wszystkich elementów w gałęzi.

Skrypt Workflow

Enterprise Architect od wersji 8.0 został wyposażony w nowy typ skryptów: Workflow. Producent dostarczył szczegółowy opis funkcji, które są możliwe do wykorzystania, szkielet takiego skryptu oraz umieścił na swojej stronie film instruktażowy. Brak jest jednak wskazówek co do praktycznych zastosowań tego mechanizmu. Jednym z takich zastosowań może być wdrożenie projektowych zasad wersjonowania. Tylko jak to zrobić?
Skrypt może być zdefiniowany w taki sposób, że:

• pole Version będzie walidowane na zgodność z przyjętą maską (np. X.YY)  i w przypadku próby wpisania niepoprawnej wartości użytkownikowi zostanie wyświetlony komunikat. 
• podczas aktualizacji elementu może być sprawdzane, czy status elementu odpowiada jego wersji, czyli: gdy status 'Roboczy', to wersja może przyjmować wartość tylko 0.YY, a gdy status 'Zaakceptowany', to wersja może być większa lub równa 1.YY.
• alternatywnie - dla elementu typu Requirement zwykły analityk nie może zmienić wartości statusu (np. na 'Zaakceptowany'), ale gdy uzna, że wymaganie jest już kompletne zmienia jego wersję na 1.00. Jednocześnie skrypt definiuje zapytanie (w formie Model Search), które zwraca wszystkie elementy typu Requirement z wersją 1.00 o statusie innym niż Zaakceptowany. Zapytanie takie może być uruchomione tylko Głównego Analityka lub Kierownika Projektu. Osoba pełniąca taką funkcję sprawdza każde z wymagań zwrócone przez zapytanie, sprawdza jego treść i zmienia jego status na 'Zaakceptowany', 'Sprawdzony' lub inny zgodny z przyjętymi zasadami modelowania.