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.

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ń.