Co to jest GUID?

Pracując z Enterprise Architect w wielu miejscach można się natknąć na pojęcie: GUID. Jest to skrót od nazwy Globally Unique Identifier, czyli globalnie unikalny identyfikator.
GUID to 128-bitowa liczba służąca do jednoznacznego oznaczenia określonych zasobów. Jest on szeroko stosowany w środowisku Microsoft Windows i wcale nie jest charakterystyczny dla EA.
Może przyjmować mniej więcej taką formę:

1CECA3FE-17EB-40ce-BAFA-13B01F5C5EDC

Myślniki są dodawane tylko w celu poprawy czytelności. Formalnie GUID jest liczbą, jednak developerzy często potrzebują traktować go jako String. Zresztą w repozytorium EA jest on przechowywany jako tekst.

Można go porównać do odcisku palca człowieka. Zakłada się, że każdy człowiek posiada niepowtarzalne odciski palców, dzięki którym można go jednoznacznie zidentyfikować. Podobnie w środowisku informatycznym opracowano odpowiedni standard, dzięki któremu można jednoznacznie wskazać dowolne obiekty. Standard ten został szczegółowo opisany w RFC 4122 A Universally Unique IDentifier (UUID) URN Namespace.

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

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.

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.

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.

Cykl życia elementu

Inżynieria oprogramowania traktuje oprogramowanie jako produkt, który ma spełniać określone potrzeby głównie w aspektach technicznych i ekonomicznych. Definiuje w tym kontekście pojęcie cyklu życia oprogramowania oraz skupia się na narzędziach wspierających proces wytwarzania i utrzymania oprogramowania we wszystkich fazach życia produktu.





Podstawowe fazy cyklu życia, które przewijają się w różnych modelach cyklu życia to:

• Analiza (bądź specyfikacja produktu) - określenie i ustalenie wymagań,
• Projektowanie - ustalenie ogólnej architektury systemu,
• Implementacja - realizacja ustalonej architektury, czyli implementacja elementów składowych i ich połączenie,
• Integracja (bądź testowanie) - zintegrowanie poszczególnych elementów składowych w jeden systemu oraz testowanie całości rozwiązania,
• Wdrożenie - uruchomienie produkcyjne systemu,
• Utrzymanie systemu - usuwanie błędów produkcyjnych oraz rozwój systemu.

Enterprise Architect jest jednym z takich narzędzi wspierających. Element w EA posiada również zestaw atrybutów, który służy do określenia momentu w życia produktu. Są to:

• wersja (patrz: Wersjonowanie elementów),
• faza,
• status (patrz: Własny zestaw statusów).

Ponadto dużym ułatwieniem w zarządzaniu informacjami o cyklu życiu jest możliwość grupowej aktualizacji informacji, patrz: Cykl życia elementów - grupowa aktualizacja.
Zatem wskazane jest, aby ogólnie przyjęte zasady w stosowanych metodykach wytwarzania oprogramowania związane z cyklem życia produktu zastosować również w Enterprise Architect, który wspiera wytwarzanie oprogramowania. Sparx, producent Enterprise Architect nie narzuca jednak w tej kwestii żadnych reguł i daje swobodę użytkownikom. Ja osobiście określiłbym to następującym oksymoronem: "zaleta granicząca z wadą". Swoboda w definiowaniu reguł dotyczących wersjonowaniu skutkuje brakiem reguł w projekcie.
Zazwyczaj natłok zadań projektowych i napięte terminy skutkują tym, że wytworzony model jest najlepszy, jaki udało się stworzyć w ograniczonym czasie - czyli innymi słowy - daleki od doskonałości.

W tym celu zasadne wydaje się wprowadzenie projektowych zasad wersjonowania. Nie sposób sformułować uniwersalnych zasad w tej kwestii, gdyż każdy projekt jest określany jako specyficzny i posiada swoiste potrzeby i ograniczenia. W tym miejscu możliwe jest tylko wymienienie określonych przesłanek, które należy rozważyć już na etapie startu projektu. Są to:

• wyszukiwanie określonych elementów w modelu w zależności od ich wersji, etapu projektu i statusu,
• filtrowanie zawartości generowanej dokumentacji w zależności od wersji, etapu projektu i statusu,
• zakres danych niezbędny do wypełnienia wymagań dotyczących dokumentacji,
• raportowanie zmian w modelu w perspektywie czasowej (w przedziale czasu)  lub projektowej (w ramach określonej modyfikacji),
• zastosowanie mechanizmu Diagram Filters, np. do zobrazowania różnic pomiędzy stanem bazowym (AS-IS) oraz stanem docelowym (TO-BE),
• utrzymywanie i rozwój modelu przedsięwzięcia w dłuższej perspektywie czasu,
• unifikacja zasad wersjonowania produktów i artefaktów tworzonych bez użycia Enterprise Architecta, 
• potrzeba przesyłania całego modelu lub jego części pomiędzy różnymi osobami, które mogą nanosić zmiany w modelu, w sytuacji, gdy nie jest wykorzystywane współdzielone repozytorium,
• potrzeba wykorzystania mechanizmów typu Workflow do implementacji zasad projektowych,
• organizacja zawartości modelu w hierarchii pakietów,
• ograniczony czas na opracowanie modelu,
• brak możliwości wpływania na zakres wprowadzanych modeli przez członków zespołu pochodzących z innych organizacji.

Wersjonowanie elementów

Enterprise Architect został zaprojektowany w taki sposób, aby możliwe było określenie wersji dowolnego typu elementu, np. wymagania, przypadku użycia, komponentu, klasy czy obiektu.

Wersjonowaniu mogą podlegać na tej samej zasadzie również pakiety i diagramy.
W przypadku tworzenia modelu na zasadzie ad-hoc, czyli gdy tworzymy model "jednorazowego użytku" w odniesieniu do krótkotrwałego projektu można pominąć zagadnienie wersjonowania. Jednak ten temat staje się istotny, gdy model:

• dotyczy długiego projektu (dłuższego niż 3 miesiące),
• w grę wchodzi utrzymanie projektowanego systemu po jego wdrożeniu,
• zakłada się potrzebę generowania i aktualizowania dokumentacji,
• w projekt jest zaangażowany duży zespół.

W przypadku spełnienia choćby niektórych z powyższych kryteriów już w momencie startu projektu, na etapie definiowania projektowych zasad modelowania należy poczynić ustalenia w kwestii wersjonowania. Zalecane jest, aby zasady wersjonowania w Enterprise Architect były spójne z zasadami wersjonowania wszystkich produktów (artefaktów wchodzących w skład deliverables, lub będących deliverables) projektu. Trzymanie się tej zasady pozwala na spójne zarządzanie konfiguracją (configuration management) oraz na odzwierciedlenie w modelu określonego momentu w cyklu życia projektu.

Cykl życia elementów - grupowa aktualizacja

W swoich postach rozpisuję się o cyklu życia elementów. Piszę o wersjonowaniu, o własnej liście statusów oraz o wprowadzaniu zasad projektowych mających na celu zachowanie porządku w modelu.
Jak jednak utrzymać ten porządek w repozytorium, gdy gonią terminy i jest wiele różnych pilnych zadań do wykonania?
Z pomocą przychodzi funkcja Update Package Status, o której rzadko się pamięta i dlatego zechciałem poświęcić jej odrobinę miejsca.