Praca grupowa w Enterprise Architect

Sparx Enterprise Architect posiada bogate możliwości w zakresie konfiguracji środowiska począwszy od łatwego umożliwienia pracy indywidualnej do złożonych konfiguracji pracy wielu organizacji w odniesieniu do modelowania jednocześnie wielu przedsięwzięć.

W najprostszej konfiguracji, gdy model tworzy jedna osoba wystarczy zainstalowanie programu Sparx Enterprise Architect na jednej stacji roboczej i aktualizacja modelu w pliku EAP. W takim przypadku możemy również mówić o pracy grupowej, gdyż zazwyczaj wyniki pracy prezentowane są zwykle interesariuszom przy użyciu jednej z poniższych metod:

• eksport diagramów w postaci pliku graficznego lub umieszczenie diagramów w niezależnie tworzonej dokumentacji,
• przesyłanie kopii pliku EAP lub umieszczenie go we współdzielonym repozytorium,
• generowanie dokumentacji w formacie RTF,
• generowanie raportu HTML,
• eksport modelu w formacie XMI.

Poniżej zostały opisane po krótce różne metody pracy grupowej wraz z ich zaletami i wadami.

Integracja na bazie plików XMI

Każdy z członków zespołu projektowego może wykorzystując lokalny plik EAP opracowywać samodzielnie wydzielone fragmenty modelu, następnie efekty swojej pracy przesyłać w postaci plików XMI do wyznaczonej osoby, która scali je w jeden wspólny model. Każda aktualizacja wymaga jedynie ponownego wygenerowania pliku XMI, którego ponowny import spowoduje aktualizację zawartości wspólnego modelu.
Enterprise Architect tworzy dla każdego obiektu w modelu (w tym kontekście przez obiekt rozumiemy np. pakiet, element, diagram, powiązanie itp.) unikalny GUID, dzięki czemu możliwe jest jednoznaczne identyfikowanie obiektów bez względu na to, przez kogo i na której stacji roboczej zostały utworzone. Mimo zmiany nazwy, typu lub dowolnego innego atrybutu obiektu możliwe jest odnalezienie właściwego obiektu i jego aktualizacja we wspólnym modelu.

Ten tryb pracy, gdzie zadania są realizowane przez indywidualnych współpracowników można nazwać trybem rozproszonym. W takim przypadku wskazane jest wyznaczenie jednej osoby, która będzie utrzymywać wspólny model, który stanowi zbiór efektów pracy pochodzący z zaimportowanych plików XMI. W sposób naturalny wyznaczany jest do tego zadania zazwyczaj główny architekt, główny analityk lub kierownik projektu, czyli osoba, której zadaniem jest odpowiedzialność za cały zakres przedsięwzięcia.

Zalety:

• Prostota konfiguracji - każdy członek zespołu projektowego odpowiada za konfigurację swojej stacji roboczej, brak potrzeby utrzymywania współdzielonego repozytorium;
• Szybkość uruchomienia środowiska - praca nad wspólnym modelem może się rozpocząć natychmiast po ustaleniu podstawowych zasad projektowych i rozdzieleniu obszarów pomiędzy członków zespołu.

Wady:

• Trudność w wykorzystaniu współdzielonych elementów - katalog aktorów (w modelu użycia), komponentów lub innych elementów, do których należy utworzyć powiązania (connectors) nie może być łatwo współdzielony i każdy z członków zespołu może tworzyć samodzielnie ich kopie, co utrudnia zachowanie spójności w zawartości modelu.

Współdzielony plik EAP

Jeśli grupa osób pracuje w jednej sieci lokalnej, wówczas warto rozważyć jedno z najprostszych rozwiązań. Zamiast przechowywać plik EAP na dysku lokalnym - można go umieścić na współdzielonym udziale sieciowym. Dzięki temu wielu użytkowników będzie mogło jednocześnie pracować przy użyciu jednego repozytorium plikowego.

Zalety:

• Prostota konfiguracji - praca w modelu przebiega tak samo, jak w przypadku repozytorium na dysku lokalnym.
• Szybkość uruchomienia środowiska - wystarczy tylko skopiować plik i zapewnić odpowiednie uprawnienia do odczytu i zapisu.

Wady:

• Mała skalowalność - niewygodne w przypadku wielu jednoczesnych użytkowników.
• Ryzyko blokowania dostępu na poziomie bazy danych MS Jet.
• Większe ryzyko uszkodzenia pliku EAP - wskazane jest częste tworzenie kopii zapasowych.

Replikacja repozytorium EAP

W przypadku, gdy użytkownicy modelu pochodzą z różnych organizacji, są rozproszeni geograficznie lub są mobilni, wówczas można rozważyć zastosowanie replikacji repozytorium EAP.
To rozwiązanie zostało szczegółowo opisane w artykule Replikacja repozytorium EAP, a sposób konfiguracji w Replikacja repozytorium - jak to zrobić?.

Zalety:

• Rozproszenie geograficzne - użytkownicy mogą pracować w wielu lokalizacjach, w różnych sieciach lokalnych i organizacjach. 
• Szybkość uruchomienia - współdzielenie repozytorium można zorganizować błyskawicznie.
• Możliwość rozwiązywania konfliktów w przypadku kilku zmian tego samego elementu.

Wady:

• Zmiany wprowadzone przez innych użytkowników nie są widoczne od razu.
• Replika stanowi zrzut zawartości repozytorium na dany moment. Zmiany będą widoczne dopiero w kolejnej iteracji, gdy repliki zostaną scalone.
• Potrzeba organizacyjnego przypisania właścicieli określonych pakietów, aby uniknąć wzajemnego nadpisywania tych samych elementów.
• Nakład pracy administratora modelu na zarządzanie replikami i rozwiązywanie konfliktów.
• Edycja modelu zorganizowana w iteracje, gdzie iteracja rozpoczyna się wygenerowaniem replik a kończy ich scaleniem.

Wykorzystanie SVN do zarządzania współdzielonym katalogiem

Wadę poprzedniego rozwiązania możemy zniwelować poprzez zastosowanie systemu kontroli wersji. Z racji tego, że najczęściej wykorzystywanym systemem kontroli wersji jest SVN, używam często tej nazwy jako synonimu. Choć przyznaję, że może to być uznane przez niektórych za nadużycie, bo sam kilkukrotnie miałem do czynienia z repozytorium Enterprise Architecta wykorzystującym na przykład TFS (Team Foundation Server firmy Microsoft).
W tym rozwiązaniu każdy z członków zespołu utrzymuje samodzielnie swoje własne repozytorium, najczęściej na bazie pliku EAP, choć jeśli istnieją ku temu przesłanki repozytorium lokalne może być oparte na innym silniku baz danych.
Dane w lokalnych repozytoriach są synchronizowane z repozytorium SVN poprzez wymianę plików XML. Generowanie tych plików, przesyłanie i aktualizacja modelu odbywa się automatycznie.

Program EA jest wyposażony w mechanizmy, dzięki którym korzystanie z systemu kontroli wersji jest zautomatyzowane, a użytkownik może nie być nawet świadomy wymiany plików XML. Konieczne jest jedynie zainstalowanie na stacji roboczej klienta SVN, który może się komunikować z serwerem SVN.

Zalety:

• Skalowalne rozwiązanie - możliwość jednoczesnej pracy nawet kilkuset użytkowników.
• Rozproszenie geograficzne - użytkownicy mogą pracować w wielu lokalizacjach, w różnych sieciach lokalnych i organizacjach. Warunkiem jest tylko konfiguracja dostępu do usługi serwera kontroli wersji.
• Brak ryzyka nadpisywania zmian - zawartość każdego pakietu jest blokowana do edycji tylko dla jednego użytkownika w danym momencie.
• Możliwość śledzenia zmian - przy użyciu mechanizmów systemu kontroli wersji można śledzić kto, kiedy i jakie zmiany wprowadził do modelu. Ponadto można korzystać w EA z funkcji Compare Package with XMI File.
• Możliwość cofnięcia określonych zmian - przy użyciu mechanizmów systemu kontroli wersji możliwy jest powrót do poprzednich wersji.

Wady:

• Potrzebne jest opracowanie instrukcji konfiguracji dla użytkowników.
• W przypadku linkowania do elementów innych użytkowników lub umieszczania ich na diagramach może być potrzebna wzajemna komunikacja celem odblokowania określonych pakietów.
• Odpowiednia obsługa usuwanych elementów i relacji, które występują na diagramach innych użytkowników - w określonych przypadkach z modelu mogą znikać relacje do innych pakietów lub zamiast elementów na diagramie mogą się pojawiać tzw. "duchy".
• Narzut pracy w postaci zadań administratora modelu (patrz Funkcje administratora modelu).

Repozytorium przy użyciu zewnętrznej bazy danych

Repozytorium w postaci pliku EAP wykorzystuje silnik baz danych MS Jet. Ten sam, który jest stosowany w MS Access. Sprawdza się on doskonale w przypadku małych baz danych, z których korzysta niewielu jednoczesnych użytkowników.
Bardziej niezawodne i wydajne rozwiązanie to budowa repozytorium w oparciu o jeden z poniższych silników baz danych:

• SQL Server 2000, 2005 lub 2008,
• SQL Server Express 2005 lub 2008,
• MySQL 4 lub 5,
• PostgreSQL 7, 8 lub 9,
• Adaptive Server Anywhere 8, 9 lub SQL Anywhere 10, 11 lub 12,
• Progress OpenEdge
• Oracle 9i, 10g lub 11g

Aby to było możliwe na serwerze baz danych konieczne jest utworzenie bazy danych zasilonej schematem EA, pobranym ze strony Sparx Systems.

Każdy użytkownik musi mieć dostęp sieciowy do serwera i skonfigurować połączenie.

Taka baza danych działa wydajnie w sieci lokalnej, gdyż w trakcie pracy przesyłanych jest wiele zapytań SQL. Wydajność sieci jest kluczowa dla komfortowej pracy z modelem. W przypadku sieci rozległych możliwe jest zastosowanie komponentu Sparx WAN Optimizer, który działa jak proxy pośrednicząc w przekazywaniu zapytań z aplikacji EA.

Aby zapobiec wzajemnemu nadpisywaniu zmian w odniesieniu do poszczególnych diagramów lub elementów w pakiecie możliwe jest włączenie rygorystycznego trybu dostępu do edycji. Włączenie opcji Require User Lock to Edit oznacza, że zawartość modelu jest domyślnie tylko do odczytu i nikt nie może edytować zawartości modelu dopóki nie zablokuje określonego diagramu lub elementu. 

Jest to odpowiednik funkcji check-out przy konfiguracji z systemem kontroli wersji.
Modyfikacje wprowadzone do modelu przez innych użytkowników są widoczne niemal natychmiast.

Ponadto warto wspomnieć o funkcji Shared Repository - wprowadzonej jako nowość w wersji EA 10. Ułatwia ona centralne zarządzanie konfiguracją w przypadku jednoczesnego korzystania z wielu modeli w organizacji. Umożliwia współdzielenie takich zasobów jak: użytkownicy, grupy użytkowników, słownik (Glossary), czy Data Types.

Zalety:

• Skalowalne rozwiązanie - możliwość jednoczesnej pracy kilkuset jednoczesnych użytkowników oraz praca z bardzo dużymi modelami.
• Zaawansowane mechanizmy uprawnień - określone funkcje EA mogą być przyznawane wybranym grupom użytkowników.
• Spójność konfiguracji - zmiany w konfiguracji są wprowadzane tylko w jednym miejscu bez potrzeby dystrybucji do użytkowników. Dotyczy to na przykład: General Types (np. projektowy zestaw statusów), stereotypy, tagged values, UML Profile, UML Patterns , profile Matrix Relationship, szablony dokumentów, skrypty, makra.
• Możliwość wykorzystania funkcji Team Review.

Wady:

• Użytkownicy pracują w jednej sieci lokalnej - korzystanie z bazy danych w innej sieci jest możliwe, ale nieefektywne z uwagi na wolne działanie modelu.
• Nakład pracy administratora modelu oraz administratora baz danych na utrzymanie, w tym regularne wykonywanie kopii zapasowych.

Baza danych i system kontroli wersji

Jednoczesna konfiguracja w oparciu o zewnętrzną bazę danych oraz system kontroli wersji pozwala na korzystanie z zalet obu rozwiązań. Dzięki temu możliwe jest zapewnienie jednoczesnego dostępu wielu użytkowników do dużego modelu oraz kontrolowanie wprowadzanych zmian przy użyciu sprawdzonych funkcji SVN lub TFS.

W takim przypadku zamiast stosować blokowanie elementów modelu (Require User Lock to Edit) stosuje się polecenia Get All Latest, Check-out oraz Check-in.
Ponadto wybranym grupom użytkowników w systemie kontroli wersji można nadać uprawnienia do wybranych gałęzi modelu tylko do odczytu. Dzięki temu można zapewnić na przykład, że model architektoniczny nie zostanie przypadkowo zmodyfikowany przez analityka lub testera, a model analityczny przez kogoś, kto nie jest analitykiem.
Warto też wspomnieć o tym, że w jednym modelu mogą być widoczne i na bieżąco aktualizowane elementy pochodzące z innego modelu. Na przykład w organizacji może istnieć jeden model architektoniczny oraz kilka modeli projektowych. Elementy modelu projektowego mogą referować bezpośrednio do zaimportowanego z SVN modelu architektury (Import Controlled Model Branch).

Zalety:

• Zarządzanie kontrolą dostępu w odniesieniu do poszczególnych gałęzi modelu.
• Zalety rozwiązania przy użyciu systemu kontroli wersji.
• Zalety rozwiązania przy użyciu zewnętrznej bazy danych.

Wady:

• Wady rozwiązania przy użyciu systemu kontroli wersji.
• Wady rozwiązania przy użyciu zewnętrznej bazy danych.
• Możliwa niższa wydajność niż w przypadku tylko zewnętrznej bazy danych.

Współdzielenie modelu pomiędzy różnymi organizacjami

Wyżej wymieniona konfiguracja w oparciu o zewnętrzny serwer bazodanowy oraz system kontroli wersji doskonale się sprawdza, gdy potrzebne jest współdzielenie modelu pomiędzy organizacjami.
W takim przypadku jedna z organizacji uruchamia i utrzymuje usługę systemu kontroli wersji i udostępnia ją innym organizacjom.

Każda z organizacji, która korzysta z tej usługi odpowiedzialna jest za konfigurację tego dostępu dla swoich użytkowników. Jedna organizacja może na przykład stworzyć repozytorium w oparciu o serwer bazodanowy, który będzie współdzielony przez wszystkich użytkowników. Druga organizacja może z kolei zdecydować, że każdy z użytkowników będzie na swojej stacji roboczej korzystał z pliku EAP synchronizowanego z serwerem SVN/TFS.
W takim przypadku repozytorium systemu kontroli wersji będzie stanowić jedyny punkt do wymiany informacji pomiędzy organizacjami, a jednocześnie każda ze stron uzyskuje swobodę w samodzielnym kreowaniu repozytoriów EA zgodnie ze swoimi preferencjami.
Warto dodać, że rozwiązanie takie umożliwia przechowywanie wraz ze współdzielonym modelem również innych gałęzi modelu, których elementy posiadają relacje do elementów modelu współdzielonego. Zawartość takich gałęzi może stanowić własność jednej z organizacji i nie być udostępniana innym dzięki ustawieniom kontroli dostępu na serwerze systemu kontroli wersji..

Dalsze informacje

• White Paper: Deployment of Enterprise Architect
• White Paper: Version Control in Enterprise Architect.
• Enterprise Architect User Guide.