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.

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.

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.

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.

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.

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.

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.

Warunki początkowe i końcowe przypadku użycia

W ostatnim czasie w biurze miała miejsce krótka dyskusja dotycząca warunków początkowych (pre-condition) i końcowych (post-condition) przypadku użycia. W wielu projektach w ciągu ostatnich lat opisywaliśmy przypadki użycia i w każdym przypadku wszyscy wiedzieli w jaki sposób formułować warunki początkowe i końcowe. Niespodziewanie dyskusja została wywołana przez analityków z jednej z firm z którą współpracujemy. Dyskusja ta świadczy o tym, że warto dokładnie opisać wszelkie zasady, które na pierwszy rzut oka wydają się oczywiste.