Weryfikacja reguł projektowych w EA

Jedną z zalet tworzenia dokumentacji projektowej w narzędziu takim, jak Sparx Enterprise Architect jest konieczność stosowania się do reguł narzuconych przez notację, w jakiej jest tworzony model. W przypadku dokumentacji tworzonej w oparciu o dokumenty MS Office - nie mamy takiej możliwości. Dopiero kolejne etapy w cyklu życia projektu weryfikują poprawność założeń.

Sparx EA posiada wbudowany moduł służący do weryfikacji zgodności z regułami. Wraz z programem dostarczany jest również zestaw podstawowych reguł. Można je znaleźć wybierając z menu: Project -> Model Validation -> Configure. Wyświetlone zostaje wówczas okno z kategoriami reguł.

Więcej na ten temat można znaleźć w EA User Guide.

Jak to działa?

W dokumentacji EA podany jest przykład diagramu zawierający szereg nieprawidłowości. 

Uruchomienie procesu weryfikacji wbudowanych reguł (wybór z menu Project -> Model Validation -> Validate Selected po zaznaczeniu pakietu zawierającego diagram) skutkuje wyświetleniem następującego wyniku weryfikacji.

Dwukrotne kliknięcie na wybranym wierszu opisującym błąd skutkuje zaznaczeniem na diagramie elementu, którego dotyczy.

Jaka jest skuteczność wbudowanej weryfikacji?

Zauważmy jednak, że wbudowane reguły dla języka UML nie są zbyt rygorystyczne. Brak na przykład informacji o błędzie dotyczącego relacji typu association pomiędzy klasą (Class2) a obiektem (Object1). Brak również informacji o błędzie dotyczącym relacji generalizacji pomiędzy klasą (Class4) a aktywnością (Activity1).
Zatem wbudowane metody weryfikacji reguł nie są na tyle skuteczne, aby w praktyce mogły pomóc nam w weryfikacji jakości modelu.
EA daje możliwość definiowania własnych reguł, ale ta funkcjonalność została pomyślana jako wsparcie dla dodatkowych notacji, innych niż standardowy UML. Dlatego też można je dołączać tylko w ramach MDG Technology.

Jak mogą wyglądać reguły poprawności modelu w praktyce?

W artykule Walidacja czy weryfikacja podjąłem się próby doprecyzowania pojęć. W tym miejscu spróbujmy spojrzeć na temat weryfikacji od strony praktycznej.
Wyobraźmy sobie projekt, w którym definiowane są standardy modelowania. Wraz z tymi standardami tworzony jest katalog kryteriów jakości, które powinny być spełnione przez budowane modele. Owe kryteria jakości mogą wyglądać w następujący sposób.

Każde z kryteriów posiada swój unikalny identyfikator oraz treść. Dodatkowo można pokusić się o umieszczenie przykładów, czy bardziej precyzyjne wyjaśnienia zasady. Z uwagi na to, że kryteria te zostały przyjęte na przez wszystkich członków zespołu projektowego można je traktować jako reguły projektowe.

Jak weryfikować reguły poprawności?

Zdefiniowanie reguł projektowych, których stosowanie jest obligatoryjne to już połowa sukcesu. Od tej pory można już wprowadzić proces przeglądu jakości i zgłaszać autorom modeli błędy.
W przypadku, gdy model staje się coraz bardziej rozbudowany - ręczna weryfikacja kryteriów jakości może się okazać kosztowna dla projektu. Gdy proces przeglądu jakości jest zbyt czasochłonny można pokusić się o stworzenie mechanizmów automatycznej weryfikacji.
W tym celu można spróbować na przykład napisać zapytania SQL, których wywołanie na bazie danych repozytorium EA będzie zwracać rekordy opisujące wykryte błędy.
Na przykład dla KJ-001 Każda klasa powinna być opatrzona opisem zapytanie SQL może wyglądać w następujący sposób:

select object_id, author, object_type, name, note, ea_guid, CreatedDate from t_object where object_type in ('Class') and note is null

A dla kryterium KJ-002 Nazwa atrybutu powinna zaczynać się od małej litery:

select o.object_id, o.author, o.object_type, o.name, o.note, o.ea_guid, o.CreatedDate, a.name from t_object o, t_attribute a where o.object_type in ('Class') and o.object_id = a.object_id and mid(a.name, 1, 1) = Ucase (mid(a.name, 1, 1))

Zapytania te można uruchamiać wprost w EA przy użyciu funkcji Project Search (skrót klawiaturowy Ctrl + Alt + A), a wyniki wyszukiwania eksportować do pliku CSV lub RTF.

Narzędzie do weryfikacji poprawności modelu

Gdy realizowany projekt (projekty) stawia na jakość dokumentacji, a ewentualne koszty są uzasadnione można pomyśleć o stworzeniu narzędzia, które byłoby wywoływane cyklicznie w trakcie określonego etapu projektu, a jego celem byłoby automatyczne generowanie raportu niezgodności z projektowymi kryteriami jakości. Narzędzie to mogłoby zawierać zdefiniowany zestaw reguł, a każda z nich byłaby zaimplementowana w formie zapytań SQL takich, jak przytoczono powyżej. Raport w postaci pliku CSV lub XLSX umożliwiałby sortowanie i filtrowanie wyników weryfikacji na przykład per autor.

Firma LieberLieber zidentyfikowała już tę lukę na rynku i ogłosiła na swojej stronie powstanie dodatku o nazwie EnArValidationRules. Plugin ten zawiera kilka kryteriów jakości:

• maksymalna liczba elementów w pakiecie,
• maksymalna liczba elementów na diagramie,
• wykorzystanie na diagramach sekwencji tylko obiektów, a nie klas,
• każdy element powinien realizować co najmniej jedno wymaganie lub przypadek testowy.

Weryfikacja kryteriów odbywa się przy wykorzystaniu czytelnego interfejsu użytkownika.

Źródło: blog.lieberlieber.com