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.

Replikacja repozytorium - jak to zrobić?

W poprzednim artykule o replikacji repozytorium wskazałem, kiedy warto zdecydować się na replikację repozytorium EAP. Podałem wady i zalety takiego rozwiązania oraz opisałem proponowany proces, który powinien moim zdaniem towarzyszyć tego typu pracy grupowej.

W tym miejscu opisuję temat replikacji od strony technicznej.

Replikacja repozytorium EAP

Gdy nie jedna osoba, a zespół ludzi pracuje nad projektem wówczas zachodzi potrzeba zorganizowania jednego współdzielonego repozytorium. W przypadku pracy z programem Enterprise Architect mamy wiele możliwości zorganizowania pracy.
Jedną z takich metod jest replikacja.

Kiedy warto stosować replikację?

Replikacja najlepiej sprawdza się, gdy użytkownicy modelu:

• pochodzą z różnych organizacji - w konsorcjum, podwykonawcy;
• pracują w różnych lokalizacjach, w różnych sieciach;
• są mobilni - pracują u klienta, z domu, z biura.

Interfejs webowy do EA

Pełne wykorzystanie możliwości narzędzia Enterprise Architect w dużych projektach informatycznych wymaga oprócz uruchomienia współdzielonego repozytorium również przestawienia mentalnego członków zespołu projektowego na tworzenie artefaktów projektowych w EA, zamiast wielu dokumentów w formacie MS Word lub Excel. Poza tym, barierami w pełniejszym stosowaniu EA mogą być:

• konieczność konfiguracji środowiska na stacjach roboczych (instalacja EA, dostęp do klucza licencyjnego, dostęp do repozytorium, czy systemu kontroli wersji), 
• ograniczenia dostępu spoza sieci lokalnej organizacji (na przykład podczas spotkań u klienta, czy pracy z domu),
• przywiązanie użytkowników do prostszych i bardziej tradycyjnych metod pracy (pliki pakietów biurowych przechowywane lokalnie na stacji roboczej).

Metodą na eliminację dwóch pierwszych barier mogłoby być udostępnienie interfejsu WWW do repozytorium EA. Dzięki takiemu rozwiązaniu możliwe byłoby uzyskanie dostępu do zawartości repozytorium z poziomu przeglądarki internetowej. Dla określonych użytkowników, np. kierownictwa projektu, przedstawicieli klienta, eliminowałoby to potrzebę instalacji i konfiguracji klienta EA (lub EA Viewer) oraz konfiguracji dostępu. 

Można wyobrazić sobie aplikację webową umożliwiającą odnalezienie i zapoznanie się ze szczegółami modelu domeny, modelu użycia, wymagań, czy wyświetlenie zawartości diagramów. Gdyby jeszcze interfejs użytkownika byłby bardziej przystępny, przejrzysty, a w dodatku w języku polskim, wówczas moglibyśmy mieć do czynienia z przeniesieniem wykorzystania EA w nowy wymiar.

Strona startowa modelu

W przypadku modeli opracowywanych przez wiele osób mamy zazwyczaj do czynienia z rozbudowaną strukturą pakietową. Im większa złożoność modelu, tym trudniej coś w nim znaleźć. Z problemami w odnalezieniu właściwych treści borykają się zazwyczaj nowi członkowie zespołu projektowego oraz osoby, które korzystają z modelu sporadycznie - czyli kierownictwo projektu i oczywiście klient.

Wyobraźmy sobie frustrację klienta, któremu zlecono zaopiniowanie modelu podczas odbiorów produktu. Nie dość, że klient może nie czuć się komfortowo ze zrozumieniem notacji UML, BPMN czy Archimate, to jeszcze musi znaleźć właściwe diagramy i zrozumieć, w jaki sposób składają się one w całość. Bywa, że taka frustracja znajduje swoje odzwierciedlenie w zgłaszanych uwagach. A każda zgłoszona uwaga może wpływać na opóźnienia w odbiorach, a opóźnienia przekładają się już wprost na koszty projektu. Może zatem warto poświęcić trochę czasu na opracowanie odpowiedniej struktury pakietowej, a później na ułatwienie nawigacji w modelu?
Poza tym o modelu, w którym zadbano odpowiednio o wsparcie w poruszaniu się po zawartości można powiedzieć, że jest dopracowany i przemyślany. Brak jakichkolwiek elementów nawigacyjnych może sprawiać wrażenie, że nie wykazano troski o jego budowę, może zatem nie wykazano również troski o zawartość merytoryczną?

Środowisko pracy - zestawy robocze

W poprzednim artykule o organizacji środowiska pracy w programie Enterprise Architect, czyli Środowisko pracy - układ okien opisałem sposób, w jaki można skonfigurować układ wyświetlanych okien (workspace layout) zgodnie z osobistymi preferencjami.
Zatem, skoro udało nam się ustalić odpowiednią formę dla wyświetlanych treści w programie, nadszedł czas na usprawnienia dotyczące samych treści.


Wyobraźmy sobie sytuację, że pracujemy żmudnie nad jakimś tematem korzystając jednocześnie z kilku diagramów (na przykład czerpiemy informacje z diagramu wymagań wysokopoziomowych oraz wymagań funkcjonalnych, edytujemy diagram przypadków użycia w którymś obszarze funkcjonalnym). W pewnym momencie musimy przerwać pracę, aby następnego dnia powrócić do tematu. W tym celu, w kolejnym dniu, będziemy zmuszeni ponownie otworzyć model i odnaleźć te same diagramy, z których korzystaliśmy ostatnio.

Z pomocą przychodzi mechanizm o nazwie Working set. Umożliwia on zapamiętanie wszystkich otwartych diagramów i innych widoków (takich jak matrix relationship, search)  na koniec danej sesji korzystania z programu Enterprise Architect. A następnie możliwe jest wczytanie takiego zestawu roboczego w dowolnym momencie.
Można by to porównać również z tzw. "twórczym bałaganem" na biurku. Gdy mamy w swoim środowisku pracy (workspace) pootwieranych wiele widoków i dokumentów, możemy je zapamiętać w postaci zrzutu (snaphsot). A następnego dnia w jednym momencie odtworzyć swój "twórczy bałagan", w którym się doskonale odnajdujemy.
Poza tym Working set sprawdza się doskonale w odniesieniu do najważniejszych diagramów, z których często korzystamy. Zamiast wielokrotnie przedzierać się przez zawartość okna Project Browser - zawsze możemy mieć je pod ręką.

Środowisko pracy - układ okien

Od czasu do czasu podczas pracy z programem Enterprise Architect zdarza się, że próba kliknięcia na jakimś obiekcie w którymś z wielu okien, skutkuje nieplanowaną zmianą położenia takiego okna. Na przykład, gdy chcemy przeciągnąć element z okna Project Browser na diagram i klikniemy niechcący w niewłaściwym miejscu, to okno odpina się ze swojego miejsca i staje się pływające (floating) lub w ogóle znika z pola widzenia.
Jak na złość, takie zachowanie aplikacji zdarza się zwykle, gdy zależy nam na czasie. A skutkuje tylko frustracją użytkownika.
Dodatkowo ponowne próby przypięcia takiego pływającego okna we właściwe miejsce również może nie być proste, zwłaszcza dla początkującego użytkownika aplikacji.

Szablony projektowe - Template Package

Jeśli tworząc model w Enterprise Architect borykasz się z uciążliwym ustawianiem tych samych opcji dla nowych diagramów i elementów, to zapoznaj się z funkcją programu Project Template Package.
Jako przykład wyobraźmy sobie, że jako analityk wprowadzasz do modelu nowe wymagania. Wymagania te są podzielone na różne kategorie (np. wymagania biznesowe, wymagania funkcjonalne, wymagania niefunkcjonalne) oraz obszary funkcjonalne (takie jak: wprowadzanie danych, realizacja zamówienia, raportowanie, administracja itp.). Każdej kategorii oraz obszarowi odpowiada określony pakiet w drzewie modelu wymagań.
W związku z tym Twoje zadanie jako analityka polega na:

• utworzenie w każdym z pakietów diagramu typu Requirements,
• na diagramie powinna być prezentowana legenda jako Diagram details (patrz Wersjonowanie diagramów),
• na diagramie powinny być prezentowane wartości tagged values elementów,
• utworzenie w każdej kategorii i obszarze zestawu wymagań odpowiadających potrzebom klienta,
• status każdego wymagania powinien mieć wartość 'Zidentyfikowany' zamiast domyślnej wartości 'Proposed',
• każde wymaganie na diagramie powinno mieć taką szerokość, aby poprawić czytelność opisu wymagania - czyli powinno być znacznie szersze niż standardowy kształt,
• każde wymaganie powinno mieć tę samą szerokość na diagramie.

Problem

Realizacja tych zadań oprócz wysiłku merytorycznego polegającego na poprawnym formułowaniu treści wymagań wymaga również zmiany określonych ustawień.
Dla każdego diagramu należy w oknie Properties:

• ustawić opcję Diagram -> Show Diagram Details,
• ustawić opcję Elements -> Show Compartments -> Tags.

Dla każdego wymagania należy w oknie Properties:

• ustawić wartość pola Status na Zidentyfikowany;
• rozciągnąć element na diagramie do wymaganej szerokości.

Polski słownik w Enterprise Architect

Program Sparx Enterprise Architect dzięki modułowi do generowania raportów może posłużyć za narzędzie do opracowania kompleksowej dokumentacji projektowej. Przy użyciu możliwości generowania raportów RTF można tworzyć dokumentację wprost w Enterprise Architect zamiast przy użyciu MS Word lub Open Office. Takie rozwiązanie w warunkach polskich jest niestety obarczone poważną wadą. Enterprise Architect nie został wyposażony w polski słownik do sprawdzania poprawności pisowni.
Na forum Sparxa pojawiają się prośby o dodanie polskiego słownika do programu. Ja długo żyłem nadzieją, że producent zlituje się nad polskimi użytkownikami, bo mam wrażenie, że program Sparx Enterprise Architect cieszy się w Polsce dużą popularnością i już dawno wiedzie prym w kategorii narzędzi typu CASE.
Rozpocząłem własne badanie w jaki sposób możliwe byłoby samodzielne dodanie takiego słownika. Najpierw udało mi się ustalić, że słownik jest zdefiniowany w plikach z rozszerzeniem .clx oraz .tlx. Na przykład słownik dla języka angielskiego (amerykańskiego) znajduje się w plikach ssceam2.clx oraz ssceam.tlx. Pierwszy z tych plików zawiera słownik w wersji skompilowanej, dzięki czemu sprawdzanie pisowni jest znacząco szybsze od sprawdzania w oparciu o plik tekstowy ssceam.tlx.
Sprawdzanie pisowni w oparciu o plik tekstowy .tlx przebiega sprawnie, jeśli ilość słów nie przekracza kilku tysięcy.
Dodatkowo słowa dodawane do słownika przez użytkownika umieszczane są w pliku %AppData%\Roaming\Sparx Systems\EAuserdic.tlx.
Pliki te są obsługiwane przez program WSpell oferowany przez firmę Wintertree software. Zatem Sparx korzysta z silnika Sentry Spelling Checker Engine firmy Wintertree software.

Na stronie producenta znajduje się szczegółowa dokumentacja przeznaczona dla developerów, w której jest opisane dokładnie, w jaki sposób działa ich produkt.
Znalazłem doskonały słownik języka polskiego w formacie .txt pozbawiony jakichkolwiek dodatkowych znaczników, które są wykorzystywane przez alternatywny program do sprawdzania pisowni Aspell. Słownik ten zawiera blisko 120 000 słów (od "AA" do "żyźnie") i sprawdziłby się idealnie jako słownik do sprawdzania pisowni. Przy pomocy programu Gżegżółka przekonwertowałem ten słownik ze strony kodowej Windows 1250 na ISO 8859-2 (Europa Środkowa).
Znalazłem w sieci również program WL2Dic, który umożliwia konwersję z pliku tekstowego do pliku .clx. Program ten działa poprawnie, umożliwia wskazanie pliku źródłowego, pliku docelowego oraz kodu języka. Możliwe jest wybranie kodu dla języka polskiego, jednak w takim przypadku program uprzejmie informuje, że w takim wypadku należy wybrać opcję tworzenia słownika w formacie Unicode.

Cannot create non-unicode dictionary for this language.

Please specify -u switch

Niestety program WL2Dic wykorzystuje wersję biblioteki Sentry Spelling Checker Engine w wersji 5.14.
A niestety Sentry Spelling Checker Engine do wersji 5.14 nie umożliwiał skorzystania z kodowania znaków w ISO-8859-2 (czyli środkowoeuropejski).
Na stronie SSCE Revision History widnieje informacja:

The Sentry engine can now support Unicode through a build option. Currently, this support is limited to the SSCE Source SDK. As part of this support, SSCE can now process single-byte characters from the Latin 1 (ISO-8859-1) character set or Unicode. Character sets ISO-8859-2 through ISO-8859-10 are no longer supported (use Unicode instead). The lexicon-compression API (SSCE_CompressLex*) creates a Latin 1 or Unicode compressed lexicon depending on how the engine was built. The Unicode engine can read both Unicode and Latin 1 compressed lexicons, but the Latin 1 engine cannot read Unicode compressed lexicons.

W historii wersji 5.15 zapisano:

The Sentry engine now supports all ISO-8859 character sets. Two new functions, SSCE_GetCharSet and SSCE_SetCharSet have been defined for this purpose. The default character set is ISO-8859-1, which was the only ISO-8859 character set supported previously. The character set is a "global" setting, meaning a change to the character set affects all sessions. A set of language-id constants for each major language covered by ISO-8859 character sets has been defined.

A w rejestrze systemowym (HKEY_CURRENT_USER\Software\Wintertree\SSCE) dodano klucz CharSet, który służy do zmiany strony kodowej od ISO-8859-1 do ISO-8859-10. Wartość tego klucza mogłaby się zmieniać automatycznie po wyborze polskiego słownika.
Enterprise Architect korzysta z wersji 5.16, która umożliwia teoretycznie obsługę polskiego słownika. Przypuszczam, że przygotować poprawnie działający polski słownik może tylko Sparx Systems lub inna firma, która zakupiła pełną wersję SDK od firmy Wintertree software. Testowa wersja tego SDK pozwala tylko na generowanie słownika zawierającego nie więcej niż 1000 słów.

Istnieje również możliwość skorzystania z kodowania unicode, jednak jest on obsługiwany tylko w przypadku korzystania z  silnika Sentry Spelling Checker Engine dla Javy, a nie dla Windows (czyli w programach napisanych w C/C++, Delphi, Visual Basic, VB.NET, C# lub ASP).

Co zatem można zrobić?

Próbowałem obejść ten problem oszukując moduł sprawdzania pisowni, twierdząc że kompilowany przeze mnie słownik dotyczy języka angielskiego. Plik docelowy o nazwie ssceam2.clx wygenerował się poprawnie i osiągnął wielkość 509 kB. Słownik ten jest poprawnie interpretowany w Enterprise Architect, ale niestety nie w pełnym zakresie. Efekt jest połowiczny - nie są obsługiwane słowa zawierające polskie znaki.
Podobny efekt udało się uzyskać Michałowi Wolskiemu, który udostępnia taki słownik na swojej stronie: http://www.michalwolski.pl/2009/06/sprawdzanie-pisowni-w-enterprise-architect-polski-slownik/
Ja jednak uznałem, że rozwiązanie częściowe mnie nie satysfakcjonuje. Oznaczałoby to, że i tak mniej więcej połowa wyrazów byłaby podkreślana na czerwono.

Podsumowanie

Nie mam dobrych wieści w temacie sprawdzania pisowni w języku polskim w Enterprise Architect. Dopóki Sparx Systems nie zmieni silnika do sprawdzania pisowni niemożliwe jest wykorzystanie słownika języka polskiego.
Obecnie mamy dwie alternatywy:

• korzystanie ze słownika bez poprawnej obsługi polskich znaków diakrytycznych,
• wyłączenie opcji sprawdzania pisowni (menu Tools --> Options --> Objects --> Disable spelling).

Brak polskich znaków - rozwiązanie

Jeśli otwierasz na swojej stacji roboczej plik .eap i zamiast polskich znaków diakrytycznych widzisz krzaczki - ten post zawiera rozwiązanie Twojego problemu.
Najgorsze jest to, że jak sam wstawisz dowolny polski znak, wówczas jest on wyświetlany poprawnie, ale przecież nie będziesz zmieniać w tych wszystkich miejscach polskich znaków!
Plik .eap jest w porządku, tylko Twoja stacja robocza wymaga niewielkiej zmiany konfiguracyjnej.

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

Dostęp do modelu w trybie tylko do odczytu

W przypadku, gdy zespół projektowy zastanawia się nad wykorzystaniem Enterprise Architecta, jednym z pierwszych pytań jest:

Czy możliwy jest dostęp do modelu tylko do odczytu?

Odpowiedź brzmi:

Tak, oczywiście.

Pytanie jest jak najbardziej zasadne, gdyż w przypadku każdego projektu istnieją interesariusze, którzy nie uczestniczą w tworzeniu i utrzymaniu modelu, a mogą być zainteresowani jakimiś jego aspektami.  Przede wszystkim taki dostęp może potrzebować kierownictwo projektu i klient.
Mamy w tej kwestii kilka możliwości opisanych poniżej.