Zastosowanie UML Profile w Enterprise Architect

W artykule UML Profile opisałem czym jest taki profil oraz do czego może służyć. W tym miejscu chciałbym przybliżyć techniczne aspekty tworzenia, a później wykorzystania takiego profilu.

Tworzenie i późniejsze utrzymanie profilu UML to zadania realizowane w tzw. metamodelu, natomiast wykorzystanie takiego profilu ma miejsce już w docelowym modelu. Aby móc korzystać z profilu konieczne jest jego wdrożenie w formie pliku XML. Zostało to przedstawione w formie graficznej na poniższym rysunku.

UML Profiles

W tym artykule opisuję zastosowanie mechanizmu UML Profile. Dowiesz się, do czego można to zastosować i jak samodzielnie przygotować.

Co to jest UML Profile?

UML Profile to mechanizm, dzięki któremu można dostosować język modelowania do potrzeb projektowych. Skrót "UML" w nazwie pojawia, gdyż ten mechanizm został zdefiniowany w ramach samej specyfikacji UML. W tej specyfikacji napisano, że:

The Profiles package contains mechanisms that allow metaclasses from existing metamodels to be extended to adapt them for different purposes.

A zatem, ogólny metamodel UML możemy uszczegółowić poprzez zastosowanie odpowiedniego pakietu, aby w lepszym stopniu odpowiadał specyfice modelowanego problemu, rozwiązania, czy też technologii.
Inaczej mówiąc: profile UML rozszerzają semantykę modelu. Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami. Czyli profil UML pozwala wprowadzić nowe oznaczenia i nadać im znaczenie, przy czym stosując taki profil nadal jesteśmy zgodni z ogólną składnią UML.

Profil UML bazuje na stereotypach. Oznacza to, że profil zawiera definicje dla określonych stereotypów, które są przypisywane standardowym typom elementów lub relacji UML.

Na przykład dla elementu typu Class można zdefiniować stereotypy:

• biznes - oznaczający byt mający znaczenie z biznesowego punktu widzenia,
• web page - oznaczający byt, który jest związany z interfejsem użytkownika,
• control - oznaczający byt, który kontroluje zachowanie i cykl życia bytów biznesowych, których zmiana inicjowana jest przez użytkownika.

Gdybyśmy mieli model klas pozbawiony tych stereotypów, trudniej byłoby nam się zorientować w znaczeniu tych klas. Jest to szczególnie ważne, gdy czyta się model stworzony przez kogoś innego.

UML Profile to nie jedyny mechanizm rozszerzalności UML, ale jest najbardziej złożony i kompleksowy. Dla każdego ze zdefiniowanych stereotypów możliwe jest również:

• zmodyfikowanie sposobu wyświetlania elementu na diagramie poprzez przypisanie określonego koloru lub symbolu graficznego,
• przypisanie określonych wartości etykietowanych, czyli tagged values: składających się ze słowa kluczowego i wartości,
• dodanie ograniczeń, czyli constraints oznaczających warunki i reguły, zgodnie z którymi obiekt opatrzony danym stereotypem funkcjonuje.

Po co mi UML Profile?

Rozszerzenie semantyki modelu można uzyskać poprzez zdefiniowanie stereotypów (patrz na przykład: Kolorowanie według stereotypów). Taki sposób w większości prostych przypadków sprawdza się doskonale i nie ma potrzeby zawracać sobie głowy profilami UML.
Są jednak przypadki, gdy zastosowanie profili ma sens. Można sobie wyobrazić wiele projektów, gdzie w modelowanie zaangażowanych jest wiele osób, a jednocześnie chcemy zapewnić wysoką jakość modelu. Manualne przypisywanie stereotypu do elementu wiąże się z ryzykiem pojawiania się błędów, np. zamiast stereotypu "web page", ktoś może wpisać "webpage". A przecież może się pojawić konieczność wygenerowania raportu zawierającego kompletną listę elementów o stereotypie "web page". Błędna nazwa stereotypu w jednym przypadku sprawi, że raport nie będzie kompletny.
Bazując tylko na wiedzy teoretycznej o profilach UML trudno sobie zdać sprawę, że ten mechanizm służy również usprawnieniu i ułatwieniu pracy. Otóż, wyobraźmy sobie sytuację, że mamy za zadanie utworzyć model zawierający 100 elementów opatrzonych danym stereotypem, z których każdy powinien mieć przypisane po trzy tagged values wraz z ich wartościami.

Zastosowanie profilu UML w Enterprise Architect pozwala jednym ruchem już w momencie tworzenia elementu na:

• przypisanie właściwego stereotypu,
• dodaniu do elementu nazw tagged values wraz z domyślnymi wartościami.

W takim przypadku wystarczy tylko ręcznie nadać elementowi nazwę, zweryfikować poprawność domyślnych wartości tagged values i ewentualnie uzupełnić pozostałe atrybuty elementu, a dopisanie stereotypu oraz dodanie tagged values program EA wykona za nas automatycznie. Korzystając z profilu oszczędzamy czas i minimalizujemy ryzyko pomyłek, czy pominięć.

W jakich przypadkach sprawdza się UML Profile?

Z mojej praktyki wynika, że nie zawsze zastosowanie UML Profile ma sens. Przede wszystkim warto stosować ten mechanizm wtedy, gdy do elementów opatrzonych określonym stereotypem zastosowane będą tagged values. 

Przykładem zastosowania mogą być diagramy wdrożeniowe (deployment diagrams), które pokazują rozmieszczenie komponentów i obiektów na węzłach. Element typu node można na przykład opatrzyć stereotypami, które odpowiadają fizycznym typom maszyn. Np. "MacBook Pro" lub "HP Proliant BL460c", a dla każdego ze stereotypów przypisać nazwy tagged values: 

• Core - oznaczające liczbę rdzeni procesów, które mogą być ważne z punktu widzenia wydajności sprzętu lub warunków licencyjnych,
• RAM - zawierające wartości odpowiadające ilości wykorzystywanej pamięci, np. 8GB,
• HDD - zawierające wartości odpowiadające pojemności dysków twardych, np. 500GB, 1TB.

Innym przykładem zastosowania może być zarządzanie wymaganiami, gdy definiujemy kilka różnych kategorii wymagań dla elementu typu requirement. Mogą to być np.:

• Wymaganie biznesowe,
• Wymaganie wysokopoziomowe,
• Wymaganie funkcjonalne,
• Wymaganie niefunkcjonalne.

Dla takich kategorii wymagań w formie stereotypów można zdefiniować również katalog wartości etykietowanych, np.:

• Źródło -  dokument, departament lub osobę, która zgłosiła wymaganie,
• Właściciel - osoba lub departament, która potrzebuje wymagania albo będzie jego biznesowym właścicielem po wdrożeniu rozwiązania na środowisku produkcyjnym.

W artykule Zastosowanie UML Profile w Enterprise Architect zamieściłem szczegółową instrukcję opisującą jak opracować samodzielnie profil oraz pokazałem, jak korzystać z takiego rozszerzenia.

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.

Oznaczanie zmian pomiędzy wersjami generowanych dokumentów

Dokumentacja projektowa powstaje zazwyczaj iteracyjnie. Czyli najpierw powstaje pierwsza wersja dokumentu, która jest opiniowana. Zgłoszone uwagi do dokumentu są uwzględniane przez autora (autorów) i w odpowiedzi powstaje druga wersja dokumentu i tak dalej... W innym scenariuszu, gdy dokument opisuje działający system informatyczny - zawartość dokumentów zmienia się wraz z wprowadzanymi modyfikacjami do systemu.
Gdy opisywane rozwiązanie jest małe, wówczas adresaci dokumentacji mają szanse się orientować dokładnie w zawartości dokumentów. Jednak, gdy dokumentacja dotyczy dużego i złożonego systemu, wówczas rodzi się potrzeba odpowiedniego oznaczania zmian w dokumentacji. Dzięki takim oznaczeniom osoby, które opiniują dokument mogą ograniczyć się na przykład do opiniowania tylko i wyłącznie treści dodanych lub zmienionych w odniesieniu do ostatniej wersji.

Jeśli dokumentacja projektowa powstaje wprost w MS Office, wówczas najlepszym sposobem na oznaczanie zmian pomiędzy wersjami wydaje się:

• zastosowanie Trybu Rejestracji Zmian (ang. Track Changes),
• lub oznaczanie kolorami dodanego tekstu oraz przekreślanie tekstu usuniętego.

Jeśli jednak zespół w trosce o poprawę jakości generowanej dokumentacji i ograniczenie pracochłonności, decyduje się na generowanie dokumentacji projektowej z narzędzia Enterprise Architect - wówczas wykorzystanie Trybu Rejestracji Zmian nie jest możliwe.

Co można zrobić w takiej sytuacji?

Migracja z Archimate 1.0 do Archimate 2.0

W wersji Enterprise Architect 9.3 udostępniono w formie MDG Technology możliwość modelowania z wykorzystaniem notacji Archimate 2.0. Nowa wersja wprowadziła szereg daleko idących zmian. Modelowanie z wykorzystaniem Archimate w nowej wersji znacząco rozszerza semantykę stosowanych elementów i relacji między nimi.
Jeśli organizacja posiadała już uprzednio modele w starszej wersji Archimate, wówczas przejście na nową wersję niekoniecznie musi się wiązać z przerysowaniem istniejących modeli od nowa.

Okazuje się, że Sparx Systems odpowiednio zaadresował ten problem. Migracja modeli jest możliwa z wykorzystaniem metody migrate() z klasy Project dostępnej przez interfejs programistyczny. Zatem nie znajdziemy w menu aplikacji żadnej funkcji, która to umożliwia. Nic nie stoi jednak na przeszkodzie, żeby wykorzystać gotowy skrypt VB opracowany przez producenta.

Skrypt jest dość prosty:

Sub MigrateElement (sGUID, lngPackageID)
 Dim proj as EA.Project
 set proj = Repository.GetProjectInterface
 proj.Migrate sGUID, "Archimate", "Archimate2"
 'refresh the model
 If lngPackageID<>0 Then
         Repository.RefreshModelView (lngPackageID)
 End If
End Sub
Sub MigrateSelectedItem
 Dim selType
 Dim selElement as EA.Element
 Dim selPackage as EA.Package
 selType = GetTreeSelectedItemType
 If selType = 4 Then 'means Element
               set selElement = GetTreeSelectedObject
         MigrateElement selElement.ElementGUID, selElement.PackageID
         MsgBox "Element Migration Completed",0,"Archimate2 Migration"
 ElseIf selType = 5 Then 'means Package
         set selPackage = GetTreeSelectedObject
         MigrateElement selPackage.PackageGUID, selPackage.PackageID
         MsgBox "Package Migration Completed",0,"Archimate2 Migration"
 Else
         MsgBox "Select a Package or Element in the Project Browser to initiate migration",0,"Archimate2 Migration"
 End If
End Sub
Sub Main

Dzięki temu zostaną skonwertowane wszystkie typy diagramów, odpowiednie typy elementów oraz usunięte specyficzne dla Archimate 1.0 atrybuty Tagged Value.

Dla osób, które przywykły do pierwszej wersji notacji istotne może być to, że do zmiany stylu wyświetlania elementów nie stosuje się w nowej wersji Tagged Value iconstyle, tylko korzysta się ze standardowej funkcji Use Rectangle Notation.

Obrazek w Shape Script

Opisałem dotychczas dwie metody pozwalające na zmianę sposobu wyświetlania elementów na diagramach w zależności od przypisanego stereotypu.

Są to:

• kolorowanie według stereotypów - pozwalające zmienić kolory wypełnienia i obramowania oraz zastosowaną czcionkę
• przypisywanie obrazków do stereotypów - umożliwiające zastąpienie standardowego kształtu elementu plikiem graficznym.

Istnieje jeszcze jedna metoda, która cechuje się największą elastycznością i daje niemal nieograniczone możliwości modyfikacji sposobu wyświetlania elementów. Jest to Shape Script.

Edycja szablonów RTF: Elementy spoza pakietu

W prosty sposób można umieścić w szablonie RTF opisy elementów znajdujących się w pakiecie objętym raportem. Wystarczy wstawić odpowiednie znaczniki, a następnie wybrać właściwe pola, które opisują znaczące cechy, takie jak nazwa (Name), czy opis (Notes).
Często jednak może być potrzebne wymienienie również innych elementów, które są powiązane z raportowanym pakietem poprzez kontekst. Dotyczyć to może elementów powiązanych relacjami lub obcych elementów umieszczonych na diagramach w raportowanym pakiecie. Dzięki temu raport może zawierać również (lub tylko) elementy pochodzące z innych pakietów niż raportowany.
Taki zabieg może być przydatny na przykład w sytuacji, gdy w rozdziale opisującym przypadki użycia chcemy nawiązać również do kontekstu procesów biznesowych lub komponentów aplikacji, które je realizują.

Edycja szablonów RTF

Program Sparx Enterprise Architect jest instalowany wraz z kolekcją predefiniowanych szablonów RTF. Dostęp do tych raportów jest możliwy z poziomu okna Resources. Szablony te są zebrane w grupę o nazwie System. Raport wygenerowany przy użyciu predefiniowanego szablonu jest łatwo rozpoznawalny z uwagi na zastosowanie specyficznych styli paragrafów. Chociażby wszystkie nagłówki mają odcienie koloru niebieskiego.
Taki styl może nie odpowiadać każdemu, w związku z tym sugeruję, aby traktować je jedynie jako przykłady możliwych konstrukcji, a dla celów projektowych opracować na ich podstawie własne szablony.
Jest to o tyle istotne, że predefiniowane szablony zawierają bardzo dużą ilość cech, tabel oraz pól, które mogą być nadmiarowe. Brak doświadczenia w edycji szablonów bądź po prostu ludzka niechęć do wyrzucania czegokolwiek sprawia, że wygenerowany raport przy użyciu standardowego szablonu staje się nieczytelny z uwagi na przeładowanie niepotrzebnymi informacjami.
W jednym z projektów spotkałem się z raportem wygenerowanym przy użyciu standardowego szablonu, który liczył blisko 200 stron. Ważne informacje były tak rzadko rozsiane, że samo przewijanie stawało się nieprzyjemne, a jak się pomyśli jeszcze o tym, że taki raport jest drukowany w kilku egzemplarzach, to aż żal lasów. Ten raport zamiast 200 stron bez problemu zmieściłby się na 20-30 stronach.

Virtual Reports

W programie Enterprise Architect w zakresie generowania dokumentacji w formacie RTF jest możliwość generowania tzw. raportów prostych - opartych o jeden szablon oraz raportów złożonych - opartych o więcej niż jeden szablon. Zaproponowany przeze mnie podział na typy raportów został opisany w artykule Rodzaje raportów.
Metoda wykorzystania raportów złożonych, czyli Virtual Reports może nie być czytelna dla każdego, w związku z tym postanowiłem poświęcić jej nieco miejsca.

Project Integrity Check od środka

Projekt tworzony w programie Enterprise Architect jest przechowywany w formie relacyjnej bazy danych. Bez względu na zastosowany silnik bazodanowy (MS Jet w przypadku plików EAP, MS SQL, MySQL, Oracle czy inny) zastosowany jest ten sam schemat bazy danych do przechowywania modeli. Dane w relacyjnej bazie danych powinny być spójne. Spójność tę można zapewnić w sposób techniczny wprowadzając określone constraints, wówczas silnik baz danych pilnuje zgodności zdefiniowanych reguł.

Funkcja Project Integrity Check

Zapewne kierując się przesłankami wynikającymi z logiki biznesowej dotyczącej przetwarzania danych takich, jak pakiet, element, relacja, atrybut czy metoda, zdecydowano o wdrożeniu wewnątrz programu EA funkcjonalności pozwalającej z poziomu interfejsu użytkownika sprawdzić spójność projektu. Funkcjonalność ta nazywa się Project Integrity Check i jest dostępna poprzez wybór w menu aplikacji opcji Tools -> Data Management -> Project Integrity Check.

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.

Wyszukiwanie w wybranej gałęzi

Enterprise Architect jest wyposażony w funkcjonalność Model Search, która pozwala na wykonanie standardowych zapytań w modelu, bądź opracowanie własnych zapytań i ich wykonanie. Zapytania te z racji swej natury przeszukują cały model, jednakże model EA jest hierarchiczny i składa się z pakietów i podpakietów.
Na szczęście producent daje możliwość ograniczenia wyszukiwania tylko do wybranej gałęzi bez potrzeby żmudnego budowania zapytania SQL odzwierciedlającego zagnieżdżenia pakietów.

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