Co to jest MDG Technology?

Korzystając z programu Enterprise Architect można natknąć się na pojęcie MDG Technology. Termin ten brzmi dość zagadkowo i może być trudno rozponawalny. MDG to skrót od Model Driven Generation. Na pierwszy rzut oka może się kojarzyć z generowaniem kodu na podstawie modelu. Jednak mechanizmy związane z transformacjami zawartości modelu to zagadnienie o nazwie Model Driven Architecture.

Czym zatem jest MDG Technology?

MDG Technology umożliwia użytkownikom rozszerzenie zdolności modelowania w programie Enterprise Architect o specyficzne dziedziny i notacje. MDG Technology w sposób niezauważalny dla użytkownika wpasowuje się w EA dostarczając dodatkowe toolboxy, profile UML, szablony, wzorce i inne zasoby ułatwiające modelowanie.

Data type - typy własne

Tworząc model klas w języku UML mamy możliwość określenia typów atrybutów. W artykule Typy danych atrybutów opisałem, jakie są możliwe do wyboru primitive types w zależności od wybranego języka programowania.
W wielu przypadkach typy proste nie są wystarczające. Kod aplikacji z reguły będzie zawierać typy złożone, charakterystyczne dla danego rozwiązania.

Data type - typy danych atrybutów

Aby rozpocząć opracowanie dowolnego typu diagramu klas (class diagram) w języku UML wystarczy w programie Enterprise Architect dodać nowy diagram typu class. Jednak, gdy dochodzimy do momentu, kiedy należy stworzone klasy wzbogacić o atrybuty może się okazać, że lista dostępnych typów danych nie do końca odpowiada naszym oczekiwaniom.

Domyślnie, po instalacji EA, każda nowo zakładana klasa ma przypisany od razu język programowania: Java. 

Gdy dla takiej klasy wyświetlimy listę dostępnych typów atrybutów, to możemy znaleźć:

• boolean,
• byte,
• char,
• double,
• float,
• int,
• long,
• short. 

W każdym przypadku można również wybrać <none> lub wybrać typ spośród innych klas w modelu (w szczególności Datatype lub enumeration).

Dociekliwy użytkownik może zajrzeć do specyfikacji UML, aby upewnić się, skąd wynikają takie, a nie inne możliwe wartości. 

A w specyfikacji UML możemy wyczytać, że istnieje coś takiego, jak primitive type. W pewnym uproszczeniu jest to typ danych reprezentujący atomowe wartości, na przykład wartości, które nie posiadają żadnych części składowych lub struktury. Mogą one precyzować semantykę lub operacje zdefiniowane poza UML (np. w matematyce). Język UML sam zawiera następujące primitive type:

• Boolean,
• Integer,
• UnlimitedNatural,
• String.

Już na pierwszy rzut oka widać, że ta lista jest zgoła odmienna od tej, którą widzimy w EA. Czy EA nie jest zgodny z UML?

Nieporozumienie wynika z domyślnego języka Java przypisanego do klasy. 

Zmieńmy zatem język klasy z Java na <none> (żaden).

I zobaczmy, jakie są dostępne typy atrybutów:

Wartości na liście zmieniły się. Teraz są zgodne ze specyfikacją UML.

Okazuje się, że zanim przystąpimy do modelowania danych, warto czasem odpowiednio skonfigurować narzędzie. Bowiem, gdy w modelu istnieje już wiele klas i stwierdzimy, że trzeba zmienić ich język, a co za tym idzie - typy atrybutów, może to kosztować nieco pracy.

Istnieją w tej kwestii dwie szkoły: pierwsza z nich - purystyczna - optuje za tym, aby model domeny (zwany również modelem dziedziny) był niezależny od platformy programistycznej (PIM - Platform-Independent Model). Druga szkoła - pragmatyczna - stoi na stanowisku, że model domeny powinien być opracowany w taki sposób, aby zautomatyzować jego ewentualne przekształcenie w model specyficzny dla określonej platformy programistycznej (PSM - Platform-Specific Model). 

Jeśli chcemy tworzyć w oderwaniu od Javy, można zmienić domyślny język dla generowania kodu w ustawieniach EA.  Menu: Tools --> Options, zakładka Source Code Engineering.

Wybór wartości <none> z listy rozwijalnej sprawi, że wszystkie dodawane klasy nie będą miały przypisanego żadnego języka.

A jeśli ktoś jest ciekawy, gdzie są zdefiniowane typy danych dla poszczególnych języków, to można otworzyć okno Code Datatypes dostępne z menu Settings.

Z poziomu tego okna można również dodać definicję innego języka (Add Product) oraz modyfikować dostępne typy danych. Własne definicje można dystrybuować poprzez mechanizm Export/Import Reference Data.

Jak wybrać tylko właściwe elementy?

Ostatnio od kilku różnych osób dostałem zapytania dotyczące odfiltrowania tylko wybranych elementów do raportu RTF. Pytania te dotyczyły na przykład umieszczenia w raporcie elementów o określonym statusie lub przypisanych do określonej fazy. Pisałem już o tym w artykule Generowanie raportów RTF w EA, jednak postanowiłem bardziej przybliżyć temat pisząc o mechanizmie Element filters. Ta sama funkcja dotycząca filtrowania elementów została zastosowana w dwóch miejscach w EA:

• Model Search - alternatywnie do budowania zapytań SQL możliwe jest wyszukiwanie elementów (i nie tylko) w oparciu o filtry.
• Dokumentacja - filtry można zastosować w odniesieniu do definicji całego dokumentu (dostępnej z poziomu okna Resources --> Documents --> RTF Documents lub w odniesieniu do pojedynczych szablonów RTF.

Dalej skupię się na zastosowaniu Element Filters dla raportów RTF. 

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.

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.

Jak dodać obrazek do modelu?

Czasami zachodzi potrzeba wzbogacenia diagramów tworzonych w programie Enterprise Architect o elementy graficzne. Na przykład na stronie startowej można umieścić logo organizacji, na diagramie opisującym lokalizacje - zamienić zwykłe prostokąty na symbole budynków albo na diagramie typu deployment zamienić device na symbol routera.

Poniższy rysunek prezentuje przykład diagramu wzbogaconego o elementy graficzne.

Komponent o nazwie Klient EA 1 oraz Klient EA 2 reprezentują aplikacje klienckie Enterprise Architect zainstalowane na stacjach roboczych.

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ą?

Jak wysłać komuś link do diagramu w modelu?

Czy byliście kiedyś w sytuacji, gdy ktoś prosił o znalezienie i wskazanie konkretnego diagramu w jakimś modelu? Czasem nie wystarczy zapisać taki diagram w formie pliku graficznego (na przykład PNG) i wysłać go mailem.
Często konieczne bywa wskazanie miejsca, gdzie taki model się znajduje (może to być współdzielony plik EAP lub baza danych EA) oraz opisać miejsce, gdzie poszukiwany diagram znajduje się w strukturze pakietowej. Skomplikowane i czasochłonne, prawda? Zwłaszcza, gdy odbiorca dzwoni jeszcze z narzekaniem, że mimo wszystko nie może znaleźć albo samego modelu, albo diagramu...

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