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.

Czy IT umie zarządzać informacją?

Niedawno dyskutowałem w biurze z kolegą o tym, że podstawowym zadaniem branży informatycznej jest sprawne zarządzanie informacjami w organizacji oraz świadczenie usług dla biznesu. Praktyka pokazuje jednak, że sama branża informatyczna ma problem z zarządzaniem informacjami na własnym podwórku. Aby móc się sprawnie komunikować potrzebna jest platforma wspólnego porozumienia. Aby to osiągnąć powinniśmy mieć pewność, że pojęcia, których używamy są tak samo interpretowane przez wszystkich uczestników komunikacji. Czyli innymi słowy, odbiorca komunikatu tak samo jak nadawca rozumie, co się kryje pod danym pojęciem.

Czy naprawdę jest źle? 

Przecież, gdy ktoś mówi na przykład o aplikacji, to wiadomo o co chodzi.
W takim razie posłużmy się przykładem definicji pojęcia "aplikacja".

Definicja aplikacji wg ITIL® (pochodzi z "Polski glosariusz ITIL®, wersja 1.0, z dnia 15 grudnia 2011):

Oprogramowanie oferujące funkcjonalności konieczne do świadczenia usługi IT. Każda aplikacja może być komponentem więcej niż jednej usługi. Aplikacja działa na jednym lub większej liczbie serwerów lub stacji klienckich.

Definicja aplikacji wg TOGAF® (pochodzi z TOGAF® 9 Translation Glossary: English - Polish).

Aplikacja to wdrożony i działający system IT, który wspiera funkcje i usługi biznesowe. Aplikacje używają danych i wielu komponentów technicznych, ale same nie są komponentami technicznymi.

Mamy zatem do czynienia z dwoma różnymi podejściami, które patrzą na organizacje i procesy z różnych punktów widzenia. Pierwszy z wymienionych standardów stanowi, że aplikacja może być komponentem, a w drugi, że nie jest komponentem.

Jaki to ma wpływ na projekty informatyczne?

Po pierwsze, problem pojawia się już w kwestii modelowania i rodzi pytania typu: "Czy poprawnym jest umieszczenie jakiejś aplikacji w formie komponentu na diagramie?"
Ale tak naprawdę, problem jest głębszy, a kwestia definicji aplikacji jest tego przykładem. Jeśli członkowie zespołu projektowego bazują na przykład na którymś ze standardów określających ramy architektoniczne, a  osoby definiujące wymagania po stronie klienta bazują na przykład na standardzie ITIL, wówczas wymagania klienta mogą być niepoprawnie interpretowane. Takie sytuacje rodzą konflikty, a niepoprawnie zrealizowane wymagania mogą generować nawet wymierne straty czasu i pieniędzy ponoszone przez jedną lub drugą stronę.

Czy jest na to rada?

Skoro w świecie informatycznym istnieje wiele definicji tych samych pojęć, które różnią się między sobą, to musimy sobie sami poradzić.
Wydaje się, że najlepszym rozwiązaniem jest najpierw ustalenie w ramach zespołu, jakie podejście czy standard przyjmiemy za bazowy. Bazą do tych ustaleń powinny być oczekiwania klienta zdefiniowane w umowie, bądź też w formie ustnej. Kolejnym krokiem jest opracowanie słownika projektowego. Definicje zawarte w słowniku projektowym mają za zadanie rozwianie jakichkolwiek wątpliwości i powinny być sukcesywnie stosowane zarówno przez Wykonawcę, jak i Zamawiającego. Definicje w słowniku projektowym mogą pochodzić z wybranych standardów, ale powinny być ze sobą spójne.