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.

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.

Modelowanie perspektyw systemu

Moment rozpoczęcia modelowania systemu można porównać do położenia na biurku czystej kartki papieru. A zatem mamy przed sobą zadanie: zamodelować system oraz puste miejsce, w którym ten model ma powstać. Jak się do tego zabrać?

W pierwszej kolejności warto zastanowić się nad odpowiednim rozplanowaniem elementów składowych modelu. Z pomocą mogą przyjść różnego rodzaju metodyki i ramy (framework). Jednym z nich jest MDA (Model-driven architecture).

Koncepcja MDA bazuje na trzech podstawowych perspektywach systemu:

1. Computation Independent Viewpoint
2. Platform Independent Viewpoint
3. Platform Specific Viewpoint

Modelujmy tylko to, co możemy zmienić

Gdy tworzymy dowolny model w obojętnie jakim języku (czy to jest Archimate, UML, czy BPMN) powinna nam przyświecać jedna generalna zasada:

Modelujemy tylko to, co możemy zmienić.

A teraz wypadałoby wyjaśnić, jak należy rozumieć tę zasadę.

Chodzi o to, że modelowaniu powinny podlegać tylko obiekty, na które mamy jakikolwiek wpływ. Żeby to lepiej wyjaśnić, skupmy się na przykładach.

e-book: Mastering Archimate

Miłośnikom notacji Archimate® oraz wszystkim tym, którzy są zaangażowani w jakimś stopniu w modelowanie architektury korporacyjnej chciałbym polecić gorąco darmowego e-booka (do użytku prywatnego) pod tytułem: Mastering Archimate.

Praca ta została przygotowana przez jedną osobę: Gerbena Wierda. Gerben pisze o sobie, że jego celem jest poprawianie wydajności IT w organizacji. Potrafi odpowiednio ocenić, które czynniki są niezbędne do osiągnięcia tego celu, w tym ograniczenia organizacyjne i zarządcze.
Ciekawe, na ile w tym pomaga mu łatwość modelowania w Archimate.

Książka ta w przystępny sposób prowadzi czytelnika od najprostszych zagadnień notacji, poprzez zastosowanie styli i prostych wzorców, aż do zaawansowanych wzorców prezentujących sposoby, w jakie należy modelować zagadnienia utrzymaniowe systemów IT, czy modelowanie ryzyka i bezpieczeństwa w organizacji.
Wielce przydatna jest również ostatnia strona, która w syntetyczny sposób przedstawia cały metamodel Archimate® 2.0.

Pozycja ta jest znacznie bardziej przystępnie napisana, niż sucha specyfikacja Archimate® 2.0, którą można znaleźć na stronie The Open Group. W prosty sposób można znaleźć w niej odpowiedzi na pytania, które się nasuwają, gdy próbujemy zrozumieć notację. Dzięki niej można zaoszczędzić sporo czasu na naukę notacji.

Z pomocą tej książki zespół architektów może dostosować metamodel Archimate® 2.0 do potrzeb danej organizacji i nadać odpowiednie znaczenie konkretnym elementom i relacjom notacji. Dzięki temu możliwe jest tworzenie modeli architektonicznych zarówno zgodnych z regułami notacji, jak również czytelnych i spójnych między sobą w całej organizacji.

E-book zaskakuje bogatą i wyważoną szatą graficzną oraz profesjonalnym układem tekstu. Widać, że autor włożył sporo wysiłku nie tylko w zawartość merytoryczną, ale również w formę książki. Z biografii autora można wyczytać, że był specjalistą od TeX/LaTeX. Takie osoby zwracają szczególną uwagę na profesjonalny skład tekstu.

E-book: Mastering Archimate jest dostępny do pobrania stąd: http://masteringarchimate.com/mastering-archimate-edition-i/. W przypadku korzystania z książki do celów prywatnych autor udostępnia książkę z darmową licencją na korzystanie, zaś w przypadku korzystania do celów komercyjnych e-book kosztuje 8,99 Euro.

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.

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.

Logowanie - w kontekście przypadków użycia

Niedawno spotkałem się z pytaniem dotyczącym modelowania przypadków użycia i diagramów aktywności. Jeden z użytkowników zastanawiał się nad kwestią umieszczenia na diagramach aktywności wielokrotnie występujących czynności, takich jak logowanie. Jego problem dotyczył tego, czy operacja logowania użytkownika może być zdefiniowana w jednym miejscu w modelu i wstawiana wielokrotnie na różnych diagramach.

Zrozumienie diagramów UML

Język UML jest od lat uznanym standardem w dziedzinie modelowania. Jeśli istnieją opory w szerszym stosowaniu UML w projektowaniu systemów informatycznych, to najczęściej wynikają one z obaw o zrozumienie modeli przez interesariuszy.
Ostatnio natknąłem się na publikację pod tytułem System Analysis and Design for Advanced Modeling Methods: Best Practices opracowaną w 2009 roku pod redakcją Akhilesh Bajaj oraz Stanisława Wrycza (ISBN 9781605663449). Książka ta stanowi zbiór wyników badań naukowych w obszarze analizy i projektowania systemów oraz metodologii.

Model UML Super Structure w EA

Europejski oddział firmy Sparx Systems kilka dni temu opublikował graficzną wersją notacji UML opartą na aktualnej obecnie specyfikacji UML 2.4.1 opracowaną przez OMG.

Model jest dostępny w formie raportu HTML pod adresem: http://umlnotation.sparxsystems.eu/

Główna strona wygląda następująco:

A poniżej przykład diagramu opisującego relację generalizacji.

Informacje zawarte w tym modelu nie wnoszą nic nowego poza oficjalną specyfikacją. Ale w przypadku, gdy przeszukiwanie oficjalnej specyfikacji UML byłoby kłopotliwe - te diagramy mogą być przydatne.

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.

Kopiowanie atrybutów i metod pomiędzy klasami

Elementy umieszczane w modelu programu Enterprise Architect, takie jak klasy UML mogą mieć przypisane jako właściwości (features) atrybuty i metody. Może się zdarzyć, że kilka różnych klas powinno mieć taki sam atrybut lub metodę lub nawet cały zestaw.

Jak skopiować atrybuty lub metody pomiędzy klasami?

Nie jesteśmy zmuszeni do wielokrotnego tworzenia tych samych atrybutów lub metod klasy.

Zamieszczony tutaj przykład pokazuje jak można skopiować istniejące atrybuty i metody (element features) z jednej klasy do drugiej.

1. Otwórz diagram zawierający klasę, do której chcesz skopiować atrybuty lub metody.
   W tym przykładzie będziemy kopiować do Class2 oraz Class3 z klasy Class1, która akurat jest na tym samym diagramie.
2. W oknie Project Browser rozwiń właściwości wybranej klasy.
   W tym przykładzie jest to Class1, tak aby widoczne były: atrybut1, atrybut2, atrybut3, get(int) oraz set(int).
3. Zaznacz właściwości, które chcesz skopiować.
   Można stosować klawisze Ctrl (do wskazania konkretnych pozycji) oraz Shift (do zaznaczenia zasięgu zaznaczenia).
4. Przeciągnij myszą zaznaczone pozycje z okna Project Browser na wybraną klasę na diagramie.
5. Program utworzy kopie tych właściwości.

Poniższy zrzut ekranowy prezentuje efekt końcowy.

W tym przykładzie z klasy Class1 do klasy Class2 został skopiowany atrybut3 oraz metody get() i set(), a do klasy Class3 atrybuty atrybut1, atrybut3 oraz metody get() i set().

Można również przenosić właściwości klasy (zamiast tworzenia kopii). Do tego celu najwygodniejsze jest przeciąganie myszą atrybutów lub metod z jednej klasy na drugą w obrębie okna Project Browser zamiast z okna Project Browser na diagram.

Zastosowanie tej metody pozwala zaoszczędzić czas na ręczne tworzenie duplikatów oraz zmniejsza ryzyko popełnienia błędów przy manualnym wprowadzaniu danych.

Kompletność modelu użycia

Model użycia (use case model) w wielkim skrócie służy do przedstawienia funkcjonalności rozwiązania poprzez zastosowanie przypadków użycia, aktorów oraz relacji pomiędzy nimi.
Z reguły początkujący analitycy dysponują przynajmniej teoretyczną wiedzą o regułach tworzenia modelu użycia. Wraz z każdym zrealizowanym projektem umiejętności te rosną, ale mimo to dostarczany model użycia często nie jest idealny. Warto zatem pokusić się o stworzenie krótkiego podsumowania w tym zakresie.

Element typu Feature

Domyślna paleta (toolbox) dla diagramu wymagań zawiera obok podstawowego typu elementu, jakim jest wymaganie (requirement) również typ elementu zwany Feature.

W języku polskim słowo feature jest tłumaczone jako cecha, właściwość, aspekt, akcent. Istnieje nawet spolszczona wersja tego słowa: "ficzer". W związku z tym rzadko element tego typu jest stosowany w modelowaniu w narzędziu Enterprise Architect. Analityk dochodzi często do wniosku, że nie ma potrzeby zajmować się jakimiś "ficzerami", podczas gdy powinien skupić się na podstawowych kwestiach. W dodatku podstawowe metodyki zarządzania wymaganiami nie wspominają o pojęciu Feature.

Mimo to, chciałbym pokazać, że zastosowanie tego elementu jest zgoła inne niż to się wydaje na pierwszy rzut oka.A element Feature może on być bardzo przydatny na przykład na wczesnym etapie zarządzania wymaganiami, czyli w procesie gromadzenia / wydobywania wymagań (requirement elicitation) oraz analizy wymagań, gdy nie nie zostały jeszcze zidentyfikowane przypadki użycia.

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.