Wyświetlanie pakietów na diagramie

Zdarza się czasami, że osoby, które chcą prezentować na diagramach pakiety i powiązania między nimi przychodzą do mnie z pytaniem:

Jak sprawić, żeby na diagramie wyświetlona była również zawartość pakietu?

Aby odpowiedzieć na to pytanie spróbuję najpierw usystematyzować informacje.

Diagram pakietów jest jednym ze strukturalnych typów pakietów UML. Służy do prezentacji pakietów oraz powiązań miedzy nimi. Zaś sam pakiet dostarcza tzw. przestrzeni nazewniczej (ma to znaczenie głównie w inżynierii oprogramowania), jednak dla uproszczenia można traktować pakiet jako kontener grupujący elementy, które dotyczą tego samego obszaru lub są ze sobą powiązane semantycznie.

Pakiety można umieszczać na diagramach dowolnego typu. Jeśli jednak podstawową zawartością diagramu mają być tylko pakiety, wówczas powinniśmy skorzystać z dedykowanego typu: Package Diagram. Zatem z kategorii UML Structural wybieramy Diagram type: Package.

Aby umieścić istniejący pakiet na diagramie wystarczy przeciągnąć go z okna Project Browser. Nowe pakiety umieszczamy na diagramie korzystając z typu elementu Package z palety narzędzi (toolbox).

Domyślnie jednak pakiety na diagramie wyświetlane są w następujący sposób:

Aby diagram prezentował również zawartość pakietów w formie listy elementów konieczna jest zmiana ustawień diagramu. Klikamy zatem prawym przyciskiem myszy na pustym obszarze diagramu, a następnie z menu kontekstowego wybieramy opcję Properties. W oknie tym przechodzimy do zakładki Elements.

W sekcji Show Compartments odnajdujemy checkbox Package Contents i zaznaczamy go, jak na powyższym rysunku. Po naciśnięciu przycisku OK zawartość diagramu zostanie wzbogacona o pożądaną treść.

Na końcu warto jeszcze zadbać o stronę wizualną diagramu i odpowiednio rozmieścić elementy. Warto przy tym pamiętać, że dodanie nowego elementu do pakietu spowoduje automatycznie rozciągnięcie pakietu na diagramie, co może znacznie zaburzyć nasze starania o profesjonalny wygląd diagramu.
Diagram taki po zmianie opcji wyświetlania i ułożeniu jego zawartości może wyglądać, jak na poniższym rysunku.

Połączenie dwóch diagramów przez dwuklik

Niedawno otrzymałem od jednego z czytelników takie zapytanie:

Przeglądałem Pana stronę internetową na temat obsługi Enterprise Architecta, jednak nie znalazłem tam informacji na temat problemu, który próbuje rozwiązać od jakiegoś czasu, a mianowicie: czy istnieje możliwość połączenia dwóch diagramów, np. czynności poprzez dwuklik na jednym z elementów jednego, który kończąc jeden proces jest jednocześnie początkiem drugiego procesu. Byłbym bardzo wdzięczny za odpowiedz czy coś takiego jest możliwe a zarazem podpowiedz jak to zrobić.

Postanowiłem przygotować odpowiedź w postaci wpisu na blogu, gdyż może to być przydatna informacja również dla innych czytelników.

Materiały dotyczące UML

Podstawowym zastosowaniem programu Sparx Enterprise Architect jest modelowanie w UML. Sprawne poruszanie się w narzędziu nie jest jednak tak istotne, jak konsekwentne i poprawne stosowanie notacji. Znajomość UML jest warunkiem koniecznym do tego, aby tworzone diagramy były zrozumiałe dla odbiorców.

W dokumentacji EA można znaleźć wiele cennych informacji o UML. Warto zapoznać się na początku z tutorialem UML opracowanym przez Sparx Systems: http://www.sparxsystems.com/resources/uml2_tutorial/index.html.

Enterprise Architect User Guide dostarcza nieco wiedzy o różnych typach diagramów UML.
Są one podzielone na diagramy strukturalne:

i diagramy dynamiczne.

Jednakże należy mieć na uwadze, że Enterprise Architect User Guide ma za zadanie pomóc użytkownikowi w korzystaniu z narzędzia, a nie nauczyć języka UML.

Materiały w języku polskim

W mojej subiektywnej ocenie jednym z najcenniejszych źródeł wiedzy o UML w języku polskim są wykłady zatytułowane "Projektowanie systemów informacyjnych" opracowane przez dr inż. Ewę Stemposz i Jacka Płodzienia na Polsko-Japońskiej Wyższej Szkole Technik Komputerowych.
Są one dostępne dla każdego pod adresem: http://edu.pjwstk.edu.pl/wyklady/pri/scb/index.html

Wykłady w przystępny i uporządkowany sposób opisują dokładnie wszystkie aspekty związane z modelowaniem w UML.

Materiały po angielsku

Drugim cennym źródłem praktycznych wskazówek o UML jest serwis UML Diagrams dostępny pod adresem: http://www.uml-diagrams.org/. Można tam znaleźć dokładne opisy zastosowania poszczególnych typów elementów i znaczenia powiązań pomiędzy nimi. Ponadto szczególnie wartościowe są przykłady (http://www.uml-diagrams.org/index-examples.html), dzięki którym można lepiej zrozumieć zasady modelowania.

W przypadku, gdy chcemy rozstrzygnąć jakieś wątpliwości należy sięgnąć do samego źródła, jakim jest specyfikacja UML opracowana i opublikowana przez OMG (Object Management Group) dostępna pod adresem: http://www.omg.org/UML/.

Jeśli znacie i korzystacie z innych źródeł wiedzy o UML dostępnych w internecie - zapraszam do umieszczania odnośników w komentarzach.

Jak wyświetlić dwa diagramy jednocześnie?

Model zazwyczaj składa się z wielu diagramów. Można otworzyć dowolną liczbę diagramów w programie Enterprise Architect. Czasem mamy potrzebę odszukania określonej informacji na jednym diagramie, a następnie przejścia do innego diagramu i porównania informacji tam zawartych z pierwszym diagramem.

Przyciąganie do siatki na diagramie

W poprzednim artykule o wyrównywaniu elementów na diagramie pokazałem, w jaki sposób możemy wyrównywać elementy względem siebie i ustalać taką samą ich wysokość lub szerokość. Okazuje się, że aby osiągnąć takie efekty nie zawsze musimy nawet korzystać z tego typu opcji.
Otóż, sam program Enterprise Architect może zadbać o równe wielkości elementów i ich rozmieszczenie automatycznie przy wstawianiu elementów na diagram.

Wyrównywanie elementów na diagramie

Każdy autor diagramu chciałby, aby efekt jego pracy wyglądał profesjonalnie i ładnie. W tym celu zazwyczaj rozciągamy i ściągamy elementy na diagramie - aby były tej samej wielkości, przesuwamy je - aby były odpowiednio wyrównane i wyrównujemy odstępy między elementami. Takie manualne operacje na zawartości diagramu są czasochłonne, a mimo naszych usilnych starań i tak często widoczne są niedoskonałości.

Załóżmy, że mamy do czynienia z takim przykładowym diagramem.

Adresaci diagramów

Gdy tworzymy diagramy zazwyczaj skupiamy się na tym, aby wiernie odzwierciedlić rzeczywistość zgodnie z regułami zastosowanej notacji. Jednakże to nie jest wystarczające do tego, aby zostały poprawnie zrozumiane przez adresatów.

Czy zastanawialiście się nad tym, komu i do czego opracowywane diagramy mają służyć?

Zanim zaczniemy opracowywać diagramy, powinniśmy postawić się w roli adresata diagramów i spróbować sobie odpowiedzieć na poniższe pytania.

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

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.

Konektory rysowane linią krzywą

Powiązania (connectors) pomiędzy elementami mogą być prezentowane na diagramie przy użyciu różnych styli. Najczęściej stosowane style to: Custom, Direct oraz Auto Routing. Nie każdy jednak wie, że to nie wszystkie dostępne style dla powiązań. Konektory mogą być też rysowane linią krzywą.
Najpierw poświęcę trochę miejsca na opisanie standardowo dostępnych styli linii powiazań, a w dalszej części pokażę jak uzyskać linię krzywą.

Kolorowanie według stereotypów

Elementy na diagramach mogą być prezentowane przy użyciu różnych kolorów wypełnienia. Notacja UML, jak również inne notacje nie stawiają ograniczeń w tym zakresie. Narzędzie Sparx Enterprise Architect umożliwia umożliwia swobodną zmianę stylu wyświetlania elementu.

Najbardziej wygodnym sposobem na zmianę tego stylu jest zaznaczenie wybranego elementu, a następnie kliknięcie na ikonę pędzelka, która pojawia się z prawej strony zaznaczonego elementu. Wyświetlone zostaje wówczas podręczne menu, przy pomocy którego możliwa jest zmiana czcionki, koloru czcionki, kolor wypełnienia oraz kolor i grubości linii obramowania.

Najczęściej zmienianą opcją jest kolor wypełnienia elementu, gdyż za jego pomocą można rozszerzyć zakres informacyjny diagramu. Zastosowanie kilku różnych kolorów w odniesieniu do różnych elementów pozwala na wprowadzenie dodatkowego ich rozróżnienia na różne kategorie. Można w ten sposób na przykład wprowadzić kategorie przypadków użycia:

• biznesowe przypadki użycia,
• systemowe przypadki użycia,
• kluczowe przypadki użycia,
• pomocnicze przypadki użycia,
• itp.

Klasy UML można kategoryzować jako:

• klasy biznesowe,
• typy danych,
• klasy abstrakcyjne,
• itp.

 A jeśli już mowa o rozróżnianiu różnych kategorii elementów, to warto się zastanowić nad zastosowaniem stereotypów. Każdemu elementowi dowolnego typu może zostać przypisany określony stereotyp. Zmianę tę dokonujemy w oknie Properties elementu.

Co to stereotyp? 

Stereotyp pozwala rozszerzyć semantykę modelu. Jest mechanizmem wspieranym przez notację UML w odniesieniu do jakiejś grupy służącym do rozszerzenia lub zmodyfikowania:

• znaczenia,
• sposobu wyświetlania,
• bądź ich składni (atrybutów, możliwych powiązań itp.).

Stereotypy można stosować do elementów (czyli wszelkiego rodzaju obiektów, na przykład klasa czy przypadek użycia), powiązań (takich jak Dependency czy Association), atrybutów, metod oraz kilku innych pojęć. Stereotypy stanowią również podstawę do budowania profili UML. W pewnym uproszczeniu można przyjąć, że na samej górze jest zdefiniowana Metaclass (na przykład Class w notacji UML), owa metaklasa może być uszczegółowiona poprzez stereotyp (np. <<biznes>>), następnie tworzona jest klasa (np. Ocena). A idąc jeszcze dalej, np. na potrzeby diagramów interakcji mogą być tworzone obiekty danej klasy (<nazwa_obiektu>:Ocena).

Zastosowanie stereotypów do kolorowania

No dobrze, wiemy już czym jest stereotyp. Widać z tego, że idealnie nadaje się ten mechanizm do zmiany wyglądu elementów opatrzonych stereotypem.
W Enterprise Architect można stosować predefiniowane stereotypy, jak również samodzielnie definiować dowolne stereotypy, które spełniają wymagania projektowe.
Aby zdefiniować stereotyp wystarczy w oknie Properties elementu, w polu Stereotype wpisać określoną wartość, zamiast wybierać już istniejącą z listy rozwijalnej. Po wpisaniu na przykład polskiej nazwy "biznes", element taki zostaje opatrzony stereotypem <<biznes>>, a ów nowy stereotyp można odnaleźć w oknie Settings --> UML Types w zakładce Stereotypes.

Po wybraniu z listy stereotypu w sekcji Default Colors możemy zdefiniować dla niego specyficzny sposób wyświetlania elementów opatrzonych tym stereotypem. W tym przykładzie dla stereotypu <<biznes>> przypiszemy kolor wypełnienia (Fill): żółty. Zmianę zatwierdzamy przyciskiem Save.

Efektem tego będzie automatycznie pokolorowanie we wszystkich diagramach wszystkich elementów opatrzonych stereotypem <<biznes>> kolorem żółtym. Jeśli usuniemy z właściwości elementu wartość stereotypu lub zastąpimy innym stereotypem, wówczas kolor żółty zostanie zastąpiony domyślnym kolorem wypełnienia.
Ponadto, każda zmiana domyślnego koloru wypełnienia w definicji stereotypu (np. z koloru żółtego na amarantowy) spowoduje automatyczną ponownie automatyczną zmianę we wszystkich diagramach.

Podsumowanie

Dzięki zastosowaniu kolorowania według stereotypów możliwa jest automatyczna zmiana sposobu wyświetlania elementów na diagramach w zależności od ich rodzaju. Sposób ten przyspiesza pracę nad diagramami, gdyż projektant nie jest zmuszony do ręcznej zmiany kolorów, wystarczy że skupi się na poprawnym przypisaniu stereotypów, a dodatkowo konieczność zmiany kolorów dla wielu elementów wymaga tylko kilku kliknięć myszą. Poprawia się również czytelność diagramów, gdyż już na pierwszy rzut oka łatwo się zorientować w kategoriach prezentowanych elementów. Ponadto automatyczne kolorowanie według stereotypów ułatwia zachowanie spójności w modelu, gdyż każda zmiana wartości stereotypu skutkuje zmianą koloru.
Skupiłem się w tym artykule na oznaczaniu elementów poprzez zastosowanie różnych kolorów wypełnień, ale ta sama zasada stosuje się również do koloru czcionki i obramowania.
Zaawansowaną metodą wyróżniania elementów w zależności od stereotypu jest zastosowanie mechanizmu Shape Script, dzięki któremu można całkowicie zmienić kształt elementu.

Orientacja w powiązaniach na diagramie

Istnieją zalecenia dotyczące tworzenia diagramów mówiące o tym, że dobry diagram nie powinien zawierać zbyt dużej ilości elementów i powinien najlepiej mieścić w czytelnej postaci na jednej stronie formatu A4.
W praktyce okazuje się, że istnieje wiele sytuacji, gdy nie można być w zgodzie z takim zaleceniem. Projektanci tworzą diagramy zawierające dużą ilość elementów i powiązań pomiędzy tymi elementami.
Osoba, która próbuje się zorientować w zawartości skomplikowanego diagramu po jego otwarciu robi najpierw większe oczy, nabiera głęboko powietrza, a na usta jej cisną się słowa przywołania istoty najwyższej ewentualnie nazwy najstarszego zawodu świata...

Okazuje się, że Sparx, producent programu Enterprise Architect wprowadził w tym zakresie udogodnienie.
Otóż, jeśli wskażemy na diagramie, czyli klikniemy na jakiś element, a następnie naciśniemy na klawiaturze klawisz L, wówczas wszystkie powiązania (connectors) którymi jest ten element powiązany z innymi elementami na diagramie zostaną pokolorowane. Widoczne to jest na poniższym rysunku.

Kolorowanie linków po naciśnięciu klawisza L

Kolorem zielonym oznaczone są wszystkie powiązania wychodzące od tego elementu, czyli te, dla których wybrany element jest źródłem (source element).

Kolorem czerwonym oznaczone są wszystkie powiązania przychodzące do tego elementu, czyli te, dla których wybrany element jest elementem docelowym (target element).

Kolorem żółtym oznaczone są wszystkie powiązania wskazujące na siebie, czyli te, dla których wybrany element jest zarówno elementem źródłowym i docelowym.

Proste, prawda? Aby lepiej to zapamiętać, warto skojarzyć nazwę klawisza L ze słowem Link. Jeszcze prościej by było, gdyby ten skrót klawiaturowy nie był tak ukryty przed użytkownikami.

Wersjonowanie diagramów

Opisałem dotychczas kwestię wersjonowania elementów i pakietów oraz metody automatycznej aktualizacji wartości wersji. W tym artykule poruszę kwestię wersjonowania diagramów.

W jakim celu wersjonować diagramy?

Każdy diagram w momencie jego utworzenia otrzymuje domyślną wartość atrybutu Version, zapisywana jest również data jego utworzenia i ostatniej modyfikacji. Rzadko zdarza się, aby raz utworzony diagram był od razu doskonały i nie wymagał wprowadzenia modyfikacji. Tworzone modele stanowią część dokumentacji projektowej, a ta dokumentacja również podlega zmianom. W fazie wytwarzania modeli powszechne jest przesyłanie diagramów pomiędzy członkami zespołu projektowego oraz pomiędzy wykonawcą a klientem w celu zgłaszania uwag i poprawianiu ich jakości. Informacja o wersji i dacie modyfikacji diagramu zamieszczona wprost na diagramie znacząco ułatwia zorientowanie się, czy mamy do czynienia z aktualną wersją.