Przykład zastosowania EA - projekt z Australii

Enterprise Architect jest narzędziem nie tylko do samego modelowania, ale daje możliwość pełnego wsparcia prowadzenia projektów informatycznych. Niedawno natknąłem się na ciekawą prezentację opisującą zastosowanie EA w Australii.
Jedno z tamtejszych ministerstw (Department of Education, Employment and Workplace Relations - DEEWR) zaprezentowało podczas jednego ze spotkań tamtejszej grupy Enterprise Architect User Groups sposób wykorzystania EA do zarządzania wymaganiami i tworzenia dokumentacji projektowej.
Prezentację można znaleźć pod adresem: www.catchsoftware.com/documents/using-enterprise-architect-software-development.pdf.

W dalszej części chciałbym zwrócić uwagę na najważniejsze aspekty tego case study.

Organizacja pracy

W projekcie jest wykorzystywanych wiele narzędzi, które wymieniają dane z repozytorium EA. W projekt jest zaangażowanych ponad 200 osób z różnych działów, pracujących w wielu lokalizacjach. Trudno powiedzieć, czy wszyscy członkowie zespołu projektowego korzystają z EA, ale mimo wszystko ta liczba dobrze świadczy o skalowalności zastosowania EA.

Enterprise Architect jest spięty z Borland Caliber RM (do zarządzania wymaganiami), HP Quality Center (do zarządzania testami), AllFusion(R) Gen (narzędzie CASE), Visual Studio (programowanie) oraz z bazami danych SQL Server i DB2.

Zawartość repozytorium

W EA przechowywane są modele reprezentujące trzy perspektywy:

• Business Model,
• Logical Model,
• Technical Model.

Taki podział jest dość naturalny i jest zgodny zarówno z metodykami modelowania, jak również ramami architektonicznymi. Można jedynie dyskutować o tym, czy prawidłowo przyporządkowano poszczególne elementy modelu. Na przykład, czy prawidłowym krokiem jest zakwalifikowanie przypadków użycia do modelu biznesowego. Skrót BDO oznacza business data object, czyli klasy z modelu encji biznesowych, które są wykorzystywane w przypadkach użycia zgodnie z regułami biznesowymi (Business Rules) poprzez odpowiednie formatki interfejsu użytkownika (User Interface) wyświetlane zgodnie z regułami (Display Rules). Projekt interfejsu użytkownika zawiera wygląd formatek (screen layout). Ponadto przebiegi przypadków użycia są wzbogacone o diagramy aktywności. 

Zarządzanie wymaganiami

Projekt był realizowany w modelu iteracyjnym, gdzie dla każdego release'u definiowane były odpowiednie artefakty. Artefakty te dostarczane były w postaci odpowiednich dokumentów (deliverables).

W projekcie ustalono klasyfikację wymagań dostosowaną do specyfiki przedsięwzięcia.

Zakres każdego z wydań (release) był określony w postaci zestawu wysokopoziomowych wymagań (High Level Requirements).

Do każdego wymagania wysokopoziomowego przyporządkowano zestaw wymagań szczegółowych (Master Functional Areas).

Na taki główny obszar funkcjonalny składają się następujące typy wymagań:

• Actors - Aktorzy (wykorzystani w Modelu Użycia),
• Use Cases - Przypadki użycia,
• Diagrams (Optional) - Diagramy (np. diagramy aktywności, procesów biznesowych, diagramy stanów i inne),
• Business Objects - model encji biznesowych i reguł biznesowych,
• User Interface Objects - model interfejsu użytkownika,
• Process Entities - przyznam, że nie wiem, czym to się różni od Business Objects,
• Warehouse Reports - specyfikacje raportów.

Struktura pakietowa w kontekście organizacji projektu

Jak wspomniałem wyżej, produkty były dostarczane w postaci wielu tzw. release. W takim przypadku należy odpowiednio zaplanować strukturę pakietową repozytorium. Z jednej strony mamy potrzebę zorganizowania treści w taki sposób, aby opisać tworzone rozwiązanie. Wymusza to potrzebę chociażby trzymania w jednym miejscu wszystkich obszarów funkcjonalnych (Master Functional Area). Z drugiej strony wybrane artefakty z obszarów funkcjonalnych składają się na poszczególne wydania (release). Aby to osiągnąć należałoby wybrane artefakty z niektórych obszarów funkcjonalnych przechowywać w strukturze danego wydania.

Rozwiązanie tego problemu prezentuje poniższy slajd.

Otóż każde wydanie projektu opatrzone jest unikalnym identyfikatorem i stanowi oddzielną gałąź w modelu. Każda gałąź ma taką samą strukturę.
Zawartość stanowią tylko same diagramy (wyjątek stanowią elementy typu <<document>>, które przechowują treści potrzebne do umieszczenia w generowanych dokumentach, takich jak Requirements Specification, czy User Interface Specification).
Na diagramach umieszczonych w tych pakietach znajdują się elementy (wymagania opisane powyżej jako High Level Requirements oraz Master Functional Areas). W ten sposób z katalogów wymagań opisujących system wybierane są tylko te, które są implementowane w określonym wydaniu.
A zatem struktura pakietowa została tak opracowana, aby mogła się przełożyć na rozdziały i podrozdziały w generowanym dokumencie. Zaś zawartość rozdziału stanowią nazwy i opisy elementów umieszczonych na diagramach w określonych pakietach.
Dodatkowo, dzięki opcjom takim jak Include/Exlude Diagrams from RTF Documents (opcje diagramu) oraz Document / not document elements on diagrams (opcje szablonu) można sterować zakresem treści dokumentu.

Pluginy

Sparx Enterprise Architect jest narzędziem, które posiada duże możliwości konfiguracji i "kastomizacji". Jednym ze sposobów na takie dopasowanie jest zastosowanie pluginów.

W tym projekcie wytworzono i zastosowano wiele dodatków, których nie ma w standardowej instalacji EA.

• CaliberRM Load - służący do importu i aktualizacji wymagań wprowadzonych w Caliber RM.
• Requirements Validator - przeprowadzający walidację wymagań zgodnie z zestawem projektowych reguł.
• Structured Scenario Creator - dzięki niemu możliwe w bardziej wygodny sposób możliwe jest stworzenie przebiegów przypadków użycia z plików tekstowych.
• UI MDG - MDG Technology rozszerzający możliwości standardowego UI MDG Technology zgodnie z wymaganiami projektowymi.
• Project Tracker Linker - narzędzie, które tworzy automatycznie relacje nowych elementów do wydania projektu.
• Grid Editor - umożliwia tworzenie tabel w EA (zapewne w projekcie interfejsu użytkownika).
• Push to Quality Center - eksport wymagań do Quality Center (na rynku istnieje tego typu konektor, w tym wypadku nie skorzystano z niego).
• Generate Business Reports - mechanizmy raportowania, korzystające między innymi z zapytań SQL wybierających elementy do raportów spełniające określone kryteria.
• Tagged Value Editor - dodatek umożliwiający edytowanie Tagged Values jednocześnie dla wielu elementów.
• Package Copier - mechanizm do kopiowania pakietów. W EA można łatwo skopiować wybraną gałąź, jednak ten dodatek odpowiednio traktuje wartości Tagged Values, aby ograniczyć ryzyko wystąpienia błędów "Kopiego Pejsta".
• Project Setup - mechanizm do struktury pakietowej nowego wydania (release) projektu.
• Manage User Groups - ułatwienie dla administratora modelu dotyczące zarządzania uprawnieniami użytkowników
• ESG Custom Search - ułatwienie w korzystaniu z mechanizmu audytu EA. Służy wyszukaniu poprzednich wartości atrybutów elementów, które zostały zmienione przez użytkowników.
• ESG Floating Toolbar - umożliwiający łatwy dostęp do wyżej wymienionych dodatków.

Reguły walidacji wymagań

Zastosowane w tym projekcie reguły walidacji wymagań są godne uwagi, gdyż są potencjalnie re-używalne.

• Check for duplicates - sprawdza unikalność nazw elementów.
• Check missing suffixes - sprawdza, czy element posiada identyfikator w określonym formacie.
• Check for unnambered display rules - sprawdza, czy reguły są ponumerowane.
• Check for unnambered business/process rules - sprawdza, czy reguły są ponumerowane.
• Check names and stereotypes - sprawdza poprawność nazw i zastosowanych stereotypów.
• Check use cases - sprawdza przypadki użycia, np. czy posiada scenariusze.
• Check package contents - sprawdza poprawność zawartości pakietu, np. czy występują tylko elementy określonego typu.

Nazwy elementów, które nie są zgodne z regułami prezentowane są w postaci listy. Bezpośrednio z tego miejsca można przejść do edycji takiego elementu w celu np. dodania identyfikatora.

Podsumowanie

Opisany tu projekt jest unikalny, ale tylko ze względu na to, że zdecydowano się publikację w internecie wielu szczegółów od kuchni. Wiem, że istnieje wiele projektów realizowanych w różnych organizacjach, również w Polsce, które wykorzystują wiele cennych dodatków. Wymiana doświadczeń i pomysłów na kastomizację EA mogłaby być przydatna dla innych. 

Mam nadzieję, że ten artykuł będzie inspiracją do opracowania własnych autorskich rozwiązań na wzór tego australijskiego projektu.