Analityk czy architekt biznesowy?

W moich dyskusjach z analitykami, którzy są świadomi istnienia czegoś takiego jak architektura korporacyjna pojawiają się czasami następujące pytania:

Kim jest architekt biznesowy?

Czy architekt biznesowy to inna rola niż analityk biznesowy?

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

Po co architektura korporacyjna?

W ostatnich latach coraz częściej pisze się o architekturze korporacyjnej. Może to świadczyć o tym, że organizacje zaczynają powoli dostrzegać istnienie takiego zjawiska. Zastanawiam się jednak, czy firmy potrafią odpowiednio ocenić znaczenie i wagę architektury korporacyjnej.

Czasem odnoszę wrażenie, że organizacje powołują biura architektoniczne, ale w skład takiego biura wchodzą osoby na takich stanowiskach, które nie mają realnego wpływu na wyznaczanie kierunków rozwoju, czy też sposobów rozwiązywania problemów organizacji. W takiej sytuacji kierownictwo może być przeświadczone o tym, że wykorzystuje najlepsze narzędzia oraz, że zrobiło wszystko, co jest niezbędne do tego, żeby panować nad architekturą.

A jak to wygląda w praktyce? 

Zdarza się, że osoby, które wcześniej pełniły rolę architekta rozwiązań, czy wiodącego konsultanta zmieniają stanowisko na: architekta korporacyjnego jednocześnie pełniąc dotychczasowe obowiązki. Na przykład biorą nadal czynny udział w realizacji projektów informatycznych. Gdy takie osoby pytają, na czym mają polegać ich obowiązki jako architekta korporacyjnego - słyszą, że dodatkowo powinny tworzyć modele architektoniczne. Oznacza to dla nich, że zmiana stanowiska zamiast awansu w strukturze organizacyjnej polega na dołożeniu im dodatkowych obowiązków.
W rezultacie zadania polegające na tworzeniu i pielęgnacji architektury korporacyjnej są realizowane z niskim priorytetem, bo najważniejsza jest bieżąca praca przy realizacji projektów. Tradycyjnie projekty są postrzegane jako najważniejsze, gdyż to one zwiększają konkurencyjność na rynku i przekładają się na realne dochody.
Jeśli jednak architekt nie ma czasu i możliwości spojrzeć na organizację "z lotu ptaka", to może nie zobaczyć, wad, którymi takie projekty mogą być obarczone.

Może zatem warto przypominać o korzyściach płynących z architektury korporacyjnej?
+Andrzej Sobczak pisze w następujący sposób o roli architektów:

Zastanawiam się, czy architektów korporacyjnych nie można porównywać do lekarzy organizacji, a narzędzia którymi oni (tj. architekci) posługują się (tj. modele, symulacje, analizy…) do przyrządów medycznych (dzięki nim można wykazać/udowodnić “chorobę” organizacji i doradzić odpowiednie “leczenie”). Taki architekt / lekarz organizacji prowadziłby diagnostykę problemów organizacji, a następnie zalecał odpowiednią kurację :).

Myślę, że świetną ilustracją do tego jest również poniższy filmik pokazujący w humorystyczny sposób po co jest potrzebny architekt.

Walidacja czy weryfikacja?

W inżynierii oprogramowania w różnych kontekstach pojawiają się pojęcia walidacji i weryfikacji. Często te pojęcia wymieniane są razem, a przez to znaczenie każdego z tych słów bywa niejasne i różnie interpretowane. W języku angielskim istnieje nawet odpowiedni akronim dla nich: V&V (verification and validation).

Czy zastanawialiście się na przykład nad tym:

• Czy czynność polegająca na sprawdzeniu, czy wymagania funkcjonalne sformułowane przez analityka są zgodne z założonymi celami przedsięwzięcia, to - walidacja czy weryfikacja wymagań?
• Czy sprawdzenie zgodności kodu oprogramowania z przyjętymi standardami (np. konwencja nazewnictwa klas Javy), to - walidacja, czy weryfikacja kodu?
• Czy sprawdzenie zgodności komunikatu XML z XSD, to - walidacja, czy weryfikacja?
• Czy testy funkcjonalne lub niefunkcjonalne wykonywane przez testera, to - walidacja, czy weryfikacja oprogramowania?

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.

Enterprise Architect w Gartner Magic Quadrant

Firma Gartner raz do roku publikuje tzw. Magic Quadrant - obrazujący pozycję różnych narzędzi mogących służyć jako repozytorium architektoniczne w kontekście architektury korporacyjnej. Analiza ta jest przydatna dla organizacji, które stają przed wyborem narzędzia.

Enterprise Architecture Tools Magic Quadrant 2013

W bieżącym roku Gartner klasyfikuje narzędzia do architektury korporacyjnej w następujący sposób.

Widać, że Sparx Systems - jako producent Enterprise Architect jest klasyfikowany jako niszowy gracz.
Ale trzeba mieć na uwadze, że podstawowym przeznaczeniem EA jest modelowanie bazujące na języku UML. I w tej dziedzinie można uznać Sparx Systems za lidera.

Aby lepiej zrozumieć, w jaki sposób Gartner ocenia przydatność narzędzi warto zapoznać się z kryteriami oceny. Są to:

• A repository that supports, at a minimum, the business, information, technology and solution viewpoints and their relationships. The repository must also support business direction, vision and strategy, as well as business disruptions.
• Modeling capabilities that support the minimum viewpoints of business, information, technology and solutions.
• Decision analysis capabilities, such as gap analysis, impact analysis, scenario planning and system thinking.
• Presentation capabilities that are visual or interactive to meet the demands of a myriad of stakeholders.
• Administration capabilities that enable security, user management and other tasks.
• Configurability capabilities that are extensive, simple and straightforward to accomplish, while supporting multiple environments.
• Support for frameworks and standards, often used while providing the flexibility to modify the framework.
• Usability, including intuitive, flexible and easy-to-learn UIs.

W mojej ocenie EA wspiera wszystkie wymienione funkcjonalności oraz posiada ogromne możliwości w zakresie konfiguracji, czy wsparcia dla ram architektonicznych i standardów. 

Jednakże kluczowym czynnikiem, który świadczy o ułomności tego narzędzia w zastosowaniu jako repozytorium architektoniczne są:

• Nie intuicyjny i trudny do nauczenia interfejs użytkownika.
• Zmiany konfiguracji i rozszerzenia nie są łatwe do implementacji i stosowania, gdyż nierzadko konieczne jest kodowanie w formie skryptów (np. VBasic, JScript), pluginów w .NET, poznanie języka skryptowego ShapeScript, czy MDG Technology.

Przy podejmowaniu decyzji o ewentualnym wyborze Sparx EA dla celów architektury korporacyjnej warto jednak mieć na uwadze również inne kryteria, których Gartner nie bierze pod uwagę:

• Stosunek ceny do możliwości. W tym wypadku Sparx Systems byłby zdecydowanym liderem. Trudno znaleźć jakiekolwiek narzędzie, które oferowałoby tak dużą gamę funkcjonalności za tak niską cenę.
• Popularność narzędzia Enterprise Architect w Polsce. Dzięki temu możliwe jest zatrudnienie specjalistów w swojej dziedzinie, którzy doskonale znają to narzędzie. Ta cecha niweluje w pewnym stopniu wadę EA, jaką jest nie intuicyjny i trudny do nauczenia interfejs użytkownika.

Jeszcze dla porównania prezentuję poniżej poprzednie wyniki analizy Magic Quadrant z roku 2012.

Źródło

Więcej informacji na ten temat można znaleźć pod adresem: http://www.mikethearchitect.com/2013/10/gartners-2013-enterprise-architecture-tools-magic-quadrant.html

Agile lekarstwem dla zarządzania wymaganiami?

Organizacja Standish Group co roku publikuje swój sławny raport zatytułowany Chaos Report. Raport ten zawiera wyniki badań dotyczących jakości projektów informatycznych. Od kilkunastu lat Standish Group zadaje organizacjom te same pytania dotyczące liczby projektów kończących się sukcesem. Porównanie tych liczb na przestrzeni lat jest ciekawe przede wszystkim dla kierowników projektów, ale nie tylko.

Niedawno przeczytałem nie sam raport, ale wnioski z raportu za 2011 rok zaprezentowane przez Johna Parkera na blogu w artykule Why so Many IT Projects are Challenged, Under Deliver Promised Value, or Outright Fail.

Autor zamieścił tam następującą tabelkę:

Jest to porównanie liczby projektów zakończonych sukcesem (które zmieściły się w budżecie i harmonogramie i dostarczyły zamawiającemu oczekiwaną wartość), liczby projektów, które się zakończyły, ale nie zmieściły się w zaplanowanym budżecie, bądź były opóźnione lub też miały ograniczony zakres w stosunku do pierwotnych założeń oraz liczby projektów, które zostały zakończone porażką.

Z przedstawionych liczb widać, że na przestrzeni kilkunastu lat nastąpiła nieznaczna poprawa, ale mimo wszystko liczba projektów zakończonych pełnym sukcesem jest bardzo mała.

Najbardziej rzuca się w oczy jednak porównanie liczby projektów zakończonych sukcesem realizowanych według standardowej metody Waterfall - 14%, do liczby projektów zakończonych sukcesem prowadzonych według metodyk zwinnych, Agile - 42%. Różnica jest na tyle diametralna, że w samym opracowaniu raportu zamieszczono komentarz:

“The Agile process is the universal remedy for software development project failure. Software applications developed through the Agile process have three times the success rate of the traditional Waterfall method, and a much lower percentage of time and cost overruns.”

Przyznam, że nie zdawałem sobie sprawy z takiej przewagi podejścia Agile nad standardowym cyklem wytwarzania oprogramowania. Ciekawy jestem, czy firmy realizujące projekty informatyczne w ślad za tym opracowaniem w przyszłości będą stawiały jeszcze bardziej na metodyki zwinne.
W każdym bądź razie Standish Group dostarczył znaczących argumentów za tym kierunkiem rozwoju.

A dlaczego Agile miałoby być lekarstwem dla zarządzania wymaganiami?

Otóż, wg Standish Group trzy najważniejsze powody, dla których projekty nie kończą się pełnym sukcesem to:

• Lack of user input
• Incomplete requirements and specifications
• Changing requirements and specifications.

Wszystkie te czynniki są rezultatem niedostatecznej analizy biznesowej. Można wysnuć wniosek, że standardowe podejście, w którym pierwszą fazą projektu jest analiza kończąca się zatwierdzeniem specyfikacji wymagań - jest błędne. 

Ja nie spotkałem się jeszcze z projektem, w którym czas przeznaczony na analizę byłby wystarczający lub wyniki fazy analizy byłyby kompletne i zawierałyby dokładnie opisane wszystkie wymagania. Niby zakłada się, że wymagania mogą podlegać zmianom w późniejszych fazach projektu, przy czym istnieje świadomość, że im późniejsza zmiana wymagań, tym koszt jest większy. Ale najczęściej mimo wysiłku całego zespołu projektowego liczba zmian przekracza punkt krytyczny, po którym okazuje się, że sukces projektu jest zagrożony.

Czy zatem stosowanie podejścia Agile do zarządzania wymaganiami i prowadzenia całego projektu może kluczem do sukcesu? Wiele na to wskazuje. Choć w moim odczuciu potrzeba jeszcze wiele czasu, żeby się o tym przekonać na własnej skórze. Sądzę, że potrzebujemy jeszcze więcej opracowań na temat metodyk zwinnych oraz przekonania do nich organizacji i ludzi, którzy od lat realizują projekty zgodnie ze starymi i sprawdzonymi metodami.

Macierz CRUD w EA

Dla lepszego zrozumienia artykułu najpierw przypomnijmy sobie czym jest CRUD? Według Wikipedii są to cztery podstawowe funkcje w aplikacjach korzystających z pamięci trwałej, które umożliwiają zarządzanie nią. Skrót CRUD pochodzi od angielskich terminów: Create, Read, Update oraz Delete (Utwórz, Odczytaj, Aktualizuj oraz Usuń). Skrót ten może być stosowany w odniesieniu do interfejsu użytkownika większości aplikacji, które zazwyczaj pozwalają użytkownikowi na:

• utworzenie lub dodanie nowych informacji (create),
• odczytanie lub wyświetlenie istniejących informacji (read),
• modyfikowanie lub edycję istniejących informacji (udpate),
• usuwanie istniejących informacji (delete).

Praca grupowa w Enterprise Architect

Sparx Enterprise Architect posiada bogate możliwości w zakresie konfiguracji środowiska począwszy od łatwego umożliwienia pracy indywidualnej do złożonych konfiguracji pracy wielu organizacji w odniesieniu do modelowania jednocześnie wielu przedsięwzięć.

W najprostszej konfiguracji, gdy model tworzy jedna osoba wystarczy zainstalowanie programu Sparx Enterprise Architect na jednej stacji roboczej i aktualizacja modelu w pliku EAP. W takim przypadku możemy również mówić o pracy grupowej, gdyż zazwyczaj wyniki pracy prezentowane są zwykle interesariuszom przy użyciu jednej z poniższych metod:

• eksport diagramów w postaci pliku graficznego lub umieszczenie diagramów w niezależnie tworzonej dokumentacji,
• przesyłanie kopii pliku EAP lub umieszczenie go we współdzielonym repozytorium,
• generowanie dokumentacji w formacie RTF,
• generowanie raportu HTML,
• eksport modelu w formacie XMI.

Poniżej zostały opisane po krótce różne metody pracy grupowej wraz z ich zaletami i wadami.

Dołączanie grafiki do wymagań

Naturą wymagań jest ich forma tekstowa. Każde wymaganie jest formułowane w języku naturalnym. Składa się co najmniej z jednego zdania oznajmującego.

Dobrze, żeby wymaganie miało:

• swój unikalny identyfikator, do którego można referować w innych artefaktach analitycznych, 
• nazwę - która w skrótowej formie prezentuje jego charakter,
• treść - jedno lub kilka zdań; może się składać również z listy numerowanych lub wypunktowań.

A co, jeśli wymaganie dotyczy na przykład ekranu użytkownika lub kształtu raportu? 

Czy należy wówczas w formie tekstowej opisywać położenie przycisku na ekranie? 

Doświadczony analityk wie, że znacznie skuteczniej jest w wymaganiu umieścić prototyp ekranu pokazujący miejsce, gdzie taki przycisk zostanie umieszczony przez programistę.

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.

Jak uruchomić dwie wersje Enterprise Architect?

Jeśli instalujemy nowszą wersję programu Sparx Enterprise Architect jesteśmy informowani uprzejmie, że musimy odinstalować poprzednią wersję programu. Jeśli się zgodzimy, wówczas instalator wykona za nas automatycznie tę operację.

Jeśli jednak chcielibyśmy z jakichś powodów skorzystać z poprzedniej wersji programu, czy musimy każdorazowo odinstalowywać i instalować ponownie program?

Okazuje się, że na jednym komputerze mogą współistnieć dwie lub więcej wersji EA.

Mapowanie przypadku użycia

Opracowanie modelu użycia ma na celu udokumentowanie w fazie analizy szczegółowych wymagań dotyczących funkcjonalności budowanego rozwiązania. W tym celu definiowani są aktorzy, którzy wchodzą w interakcję z systemem oraz przypadki użycia, które opisują wykorzystywaną przez nich funkcjonalność.

Jednakże analiza systemów informatycznych oprócz modelu funkcjonalnego obejmuje również inne obszary, takie jak:

• zarządzanie wymaganiami,
• modelowanie procesów biznesowych,
• modelowanie danych (logiczny model danych / model domeny),
• modelowanie interfejsu użytkownika. 

Ponadto analiza nie może istnieć w oderwaniu od innych zadań projektowych, takich jak:

• zarządzanie zakresem projektu,
• zarządzanie ryzykiem,
• zarządzanie problemami,
• zarządzanie zmianą,
• projektowanie,
• implementacja,
• testy.

Częstą praktyką jest chociażby opracowywanie scenariuszy i przypadków testowych przez analityków, które są wykorzystywane przez testerów. Dzieje się tak, gdyż przypadki testowe bazują w głównej mierze na przypadkach użycia, a analityk zna je najlepiej.

Zatem, wskazane jest stworzenie i utrzymywanie określonych powiązań elementów modelu użycia z elementami innych obszarów.

Jak przenieść scenariusz do innego przypadku użycia?

W trakcie pracy nad modelem użycia często dochodzi do sytuacji, w której analityk dochodzi do wniosku, że określony scenariusz należy przenieść z jednego przypadku użycia do innego. Może tak się zdarzyć, gdy okazuje się, że scenariusz alternatywny powinien rozwidlać się jeszcze bardziej, czyli mieć jeszcze dodatkowe alternatywy.
Czasem istnieje również potrzeba stworzenia nowego przypadku użycia podobnego do już istniejącego, na przykład, gdy tworzymy kolejną specjalizację przypadku generalizującego.
Gdyby scenariusze pisane były w zwykłym dokumencie MS Word, wówczas przeniesienie czy skopiowanie kroków scenariusza byłoby banalne. Jednak jeśli zdecydowaliśmy się na zastosowanie ustrukturalizowanych scenariuszy (Structured scenario), wówczas staje się to problematyczne.
Na szczęście istnieje rozwiązanie...

Raport dla przypadków użycia

Z modelem przypadków użycia tworzonym przez analityków w programie Enterprise Architect powinno się zapoznać wielu interesariuszy projektu. Spośród nich można wymienić projektantów, programistów, ale przede wszystkim przedstawicieli klienta, takich jak kluczowi użytkownicy, eksperci dziedzinowi i inni. W związku z tym, jeśli decydujemy się na opisywanie scenariuszy przypadków użycia w formie Structured Scenario w EA - powinniśmy również zadbać o ich stronę dokumentacyjną.
Profesjonalnie przygotowany raport poprawia czytelność i odbiór wyników pracy fazy analizy.

Scenariusze przypadków użycia w EA

W Sparx Enterprise Architect od wersji 8.0 wprowadzono możliwość opisywania scenariuszy przypadków użycia w formie ustrukturalizowanej (Structured Scenario). Wcześniej scenariusz można było tworzyć tylko w postaci sformatowanego tekstu zawierającego ewentualnie listy numerowane. Od dawna możliwe było również opracowanie scenariusza w formie Linked Document dołączonego do elementu typu Use Case.
W tym artykule chciałbym przybliżyć możliwości wykorzystania mechanizmu Structured Scenario. Ten sposób posiada wiele zalet i warto się z nimi zapoznać.

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.

Archimate - wprowadzenie

Archimate® jest otwartym i niezależnym językiem modelowania stworzonym dla modelowania architektury korporacyjnej. Język ten wywodzi się ze środowisk akademickich w Holandii. Został uznany przez organizację The Open Group jako standard i obecnie jest wspierany przez wiele narzędzi, w tym Sparx Enterprise Architect.
Można chyba śmiało orzec, że obecnie jest wykorzystywany przez wiele organizacji oraz firm świadczących usługi informatyczne.
Aby móc zrozumieć, czym jest Archimate® - można skorzystać z analogii do klasycznej architektury dotyczącej budownictwa. Na projekt budynku składa się szereg rysunków technicznych. Rysunki te opisują różne aspekty, takie jak kształt i wielkość budynku, rzuty pomieszczeń, rodzaj użytych materiałów, instalacje sanitarne, elektryczne, obliczenia konstrukcyjne itp.
Podobnie Archimate® w odniesieniu do architektury korporacyjnej opisuje konstrukcje procesów biznesowych, strukturę organizacyjną, przepływ informacji, systemy IT wspierające procesy biznesowe oraz infrastrukturę techniczną niezbędną do działania systemów informatycznych.

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 usunąć pakiet pod kontrolą wersji?

Gdy pracujemy nad modelem, który jest powiązany z systemem kontroli wersji, na przykład SVN jesteśmy w stanie sprawniej kontrolować zawartość takiego modelu. Przynajmniej do czasu, gdy postanowimy pousuwać jakieś pakiety...

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.

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.

Replikacja repozytorium - jak to zrobić?

W poprzednim artykule o replikacji repozytorium wskazałem, kiedy warto zdecydować się na replikację repozytorium EAP. Podałem wady i zalety takiego rozwiązania oraz opisałem proponowany proces, który powinien moim zdaniem towarzyszyć tego typu pracy grupowej.

W tym miejscu opisuję temat replikacji od strony technicznej.

Replikacja repozytorium EAP

Gdy nie jedna osoba, a zespół ludzi pracuje nad projektem wówczas zachodzi potrzeba zorganizowania jednego współdzielonego repozytorium. W przypadku pracy z programem Enterprise Architect mamy wiele możliwości zorganizowania pracy.
Jedną z takich metod jest replikacja.

Kiedy warto stosować replikację?

Replikacja najlepiej sprawdza się, gdy użytkownicy modelu:

• pochodzą z różnych organizacji - w konsorcjum, podwykonawcy;
• pracują w różnych lokalizacjach, w różnych sieciach;
• są mobilni - pracują u klienta, z domu, z biura.

Oznaczanie zmian pomiędzy wersjami generowanych dokumentów

Dokumentacja projektowa powstaje zazwyczaj iteracyjnie. Czyli najpierw powstaje pierwsza wersja dokumentu, która jest opiniowana. Zgłoszone uwagi do dokumentu są uwzględniane przez autora (autorów) i w odpowiedzi powstaje druga wersja dokumentu i tak dalej... W innym scenariuszu, gdy dokument opisuje działający system informatyczny - zawartość dokumentów zmienia się wraz z wprowadzanymi modyfikacjami do systemu.
Gdy opisywane rozwiązanie jest małe, wówczas adresaci dokumentacji mają szanse się orientować dokładnie w zawartości dokumentów. Jednak, gdy dokumentacja dotyczy dużego i złożonego systemu, wówczas rodzi się potrzeba odpowiedniego oznaczania zmian w dokumentacji. Dzięki takim oznaczeniom osoby, które opiniują dokument mogą ograniczyć się na przykład do opiniowania tylko i wyłącznie treści dodanych lub zmienionych w odniesieniu do ostatniej wersji.

Jeśli dokumentacja projektowa powstaje wprost w MS Office, wówczas najlepszym sposobem na oznaczanie zmian pomiędzy wersjami wydaje się:

• zastosowanie Trybu Rejestracji Zmian (ang. Track Changes),
• lub oznaczanie kolorami dodanego tekstu oraz przekreślanie tekstu usuniętego.

Jeśli jednak zespół w trosce o poprawę jakości generowanej dokumentacji i ograniczenie pracochłonności, decyduje się na generowanie dokumentacji projektowej z narzędzia Enterprise Architect - wówczas wykorzystanie Trybu Rejestracji Zmian nie jest możliwe.

Co można zrobić w takiej sytuacji?

MS Office vs. Enterprise Architect

W rozmaitych okolicznościach spotykam się z zespołami projektowymi, które skomplikowane zagadnienia projektowe dokumentują w postaci dokumentów MS Word i MS Excel. Twórcy takiej dokumentacji wkładają mnóstwo wysiłku w jej wytworzenie i są często z niej dumni.
Dla przykładu spotkałem się z arkuszem MS Excel, który opisuje szczegółowo procesy biznesowe w całej organizacji z uwzględnieniem obecnego i przyszłego wsparcia przez poszczególne funkcje systemów informatycznych w dodatku z rozróżnieniem na różnice w poszczególnych jednostkach organizacyjnych. Imponujące, prawda?
Twórcy takiego arkusza szczycą się tym, że w tym jednym dokumencie opisane są najważniejsze aspekty architektury biznesowej i wsparcia jej przez systemy informatyczne. Zdaję sobie sprawę, że wypełnienie treścią tego ogromnego arkusza poprzedzone zostało wieloma godzinami pracy i konsultacji z klientem.
Ja jednak czytając tego typu dokumenty mam problem, bo zdaję sobie sprawę z tego, że autorzy oczekują podziwu dla ogromu wykonanej pracy, ale ja nie mogę przestać zadawać sobie w kółko jednego pytania: "Dlaczego oni tego nie zrobili w EA?".
Myślałem sobie, że to ja mam skrzywione spojrzenie na rzeczywistość. Na szczęście miałem okazję przeczytać ciekawy wpis Jarka Żelinskiego pod tytułem Sabotaż dokumentacyjny.
Autor przytacza w nim między innymi 10 tez dotyczących prowadzenia dokumentacji w postaci dokumentów MS Word i MS Excel. Pisze między innymi, że:

Używanie arkuszy kalkulacyjnych do zarządzania zależnościami pomiędzy wymaganiami przenosi całe ryzyko błędów na Ciebie, jest także bardzo pracochłonne.

Autor argumentuje, dlaczego dokumentacja powinna być prowadzona przy użyciu narzędzi CASE, takich jak Visual Paradigm Agilian, czy Enterprise Architect, zamiast w postaci dokumentów i arkuszy.

Jeśli nawet część członków zespołu projektowego wskazuje na chęć wykorzystania Enterprise Architecta zamiast produkowania wielu dokumentów i ich wersji, to rzadko dochodzi do skutku tego typu zmiana.

Dlaczego tak się dzieje?
Jak zwykle mamy do czynienia z wieloma czynnikami. Ja jednak niedawno natknąłem się na jeden zasadniczy problem.

Otóż, gdy zespół stoi przed decyzją: porzucić pracę w MS Office na rzecz Enterprise Architect, czy nie, wówczas taki zespół powinien umieć sformułować zestaw własnych wymagań odnośnie takiego narzędzia.
Czyli, zespół powinien być w stanie określić, co takie narzędzie powinno być w stanie zrobić, żeby oni mogli go używać. Dopiero wtedy będą w stanie wyobrazić sobie, że z niego korzystają i w jaki sposób.

Niestety osoby tworzące skomplikowane dokumenty i arkusze kalkulacyjne nie znają narzędzi CASE, bo gdyby znali, to by ich użyli. Samo zapoznanie się z dokumentacją programu nie jest również wystarczające. Poza tym, z EA można wyciągnąć o wiele więcej, niż to widać na pierwszy rzut oka poprzez umiejętną kastomizację. Do pomocy potrzebny jest ktoś, kto zna Enterprise Architecta, czy inne narzędzie CASE "od deski do deski".

Gdy członkowie zespołu stwierdzą, że potrzebują arkuszy kalkulacyjnych, bo to jest najwygodniejsza forma komunikacji z klientem, to w odpowiedzi mogą usłyszeć, że z EA można na żądanie wyeksportować dane do arkusza.
Gdy członkowie zespołu stwierdzą, że zatwierdzone ustalenia powinny mieć charakter oficjalnego dokumentu, który powinien być podpisany przez obie strony, to w odpowiedzi mogą usłyszeć, że z EA można generować tego typu dokumenty.
Gdy członkowie zespołu stwierdzą, że wprowadzanie danych do EA jest zbyt skomplikowane i mogą powstawać błędy, to w odpowiedzi mogą usłyszeć, że do wprowadzania specyficznych danych można opracować odpowiedni plugin. A do walidacji wykorzystać skrypty i zapytania SQL, które zwrócą listę elementów nie spełniających reguł projektowych.

W takiej sytuacji dyskusja przenosi się z reguły na inny poziom: Kierownik projektu musi oszacować, czy koszty opracowania szablonów raportów i kastomizacji narzędzia są akceptowalne. Oby jeszcze kierownik projektu zgodziłby się z tezą pochodzącą z wyżej cytowanego artykułu o tym, że:

Dokumenty i arkusze kalkulacyjne sprowadzają Cię do roli biurokraty. Praca z dokumentami tekstowymi i arkuszami to permanentne pisanie, wycinanie, kopiowanie, sprawdzanie spójności, stanowi to nawet 85% czasu całej analizy, pozostała wartościowa praca to 15%.

Przykład zastosowania EA - projekt z Australii

Enterprise Architect jest narzędziem nie tylko do samego modelowania, ale daje możliwość pełnego wsparcia prowadzenia projektów informatycznych. Niedawno natknąłem się na ciekawą prezentację opisującą zastosowanie EA w Australii.
Jedno z tamtejszych ministerstw (Department of Education, Employment and Workplace Relations - DEEWR) zaprezentowało podczas jednego ze spotkań tamtejszej grupy Enterprise Architect User Groups sposób wykorzystania EA do zarządzania wymaganiami i tworzenia dokumentacji projektowej.
Prezentację można znaleźć pod adresem: www.catchsoftware.com/documents/using-enterprise-architect-software-development.pdf.

W dalszej części chciałbym zwrócić uwagę na najważniejsze aspekty tego case study.

Migracja z Archimate 1.0 do Archimate 2.0

W wersji Enterprise Architect 9.3 udostępniono w formie MDG Technology możliwość modelowania z wykorzystaniem notacji Archimate 2.0. Nowa wersja wprowadziła szereg daleko idących zmian. Modelowanie z wykorzystaniem Archimate w nowej wersji znacząco rozszerza semantykę stosowanych elementów i relacji między nimi.
Jeśli organizacja posiadała już uprzednio modele w starszej wersji Archimate, wówczas przejście na nową wersję niekoniecznie musi się wiązać z przerysowaniem istniejących modeli od nowa.

Okazuje się, że Sparx Systems odpowiednio zaadresował ten problem. Migracja modeli jest możliwa z wykorzystaniem metody migrate() z klasy Project dostępnej przez interfejs programistyczny. Zatem nie znajdziemy w menu aplikacji żadnej funkcji, która to umożliwia. Nic nie stoi jednak na przeszkodzie, żeby wykorzystać gotowy skrypt VB opracowany przez producenta.

Skrypt jest dość prosty:

Sub MigrateElement (sGUID, lngPackageID)
 Dim proj as EA.Project
 set proj = Repository.GetProjectInterface
 proj.Migrate sGUID, "Archimate", "Archimate2"
 'refresh the model
 If lngPackageID<>0 Then
         Repository.RefreshModelView (lngPackageID)
 End If
End Sub
Sub MigrateSelectedItem
 Dim selType
 Dim selElement as EA.Element
 Dim selPackage as EA.Package
 selType = GetTreeSelectedItemType
 If selType = 4 Then 'means Element
               set selElement = GetTreeSelectedObject
         MigrateElement selElement.ElementGUID, selElement.PackageID
         MsgBox "Element Migration Completed",0,"Archimate2 Migration"
 ElseIf selType = 5 Then 'means Package
         set selPackage = GetTreeSelectedObject
         MigrateElement selPackage.PackageGUID, selPackage.PackageID
         MsgBox "Package Migration Completed",0,"Archimate2 Migration"
 Else
         MsgBox "Select a Package or Element in the Project Browser to initiate migration",0,"Archimate2 Migration"
 End If
End Sub
Sub Main

Dzięki temu zostaną skonwertowane wszystkie typy diagramów, odpowiednie typy elementów oraz usunięte specyficzne dla Archimate 1.0 atrybuty Tagged Value.

Dla osób, które przywykły do pierwszej wersji notacji istotne może być to, że do zmiany stylu wyświetlania elementów nie stosuje się w nowej wersji Tagged Value iconstyle, tylko korzysta się ze standardowej funkcji Use Rectangle Notation.

Polecam anglojęzyczny blog o Enterprise Architect

W grudniu ub. roku +Michał Wolski zauważył, że Enterprise Architect jest coraz bardziej popularny w sieci. Na poparcie tej tezy chciałbym polecić wszystkim czytelnikom również anglojęzycznego bloga autorstwa niejakiego Hamisha -  analityka biznesowego z Melbourne.

Pod adresem http://www.hamishking.com/category/enterprise-architect/ można znaleźć już teraz ciekawe wpisy opisujące na przykład:

• metody śledzenia zmian w dokumentach wygenerowanych w EA,
• wskazówki jak uruchomić symulację diagramu stanów,
• opis importu danych z pliku CSV,
• oraz bardzo ciekawe zastosowanie dodatku eaDocX do importu i synchronizacji wymagań z plikiem MS Excel.

Oprócz zastosowania EA, autor porusza również inne wątki, ale widać, że w ostatnim czasie sukcesywnie dodaje ciekawe wpisy dotyczące możliwości programu Enterprise Architect.

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.

e-book: Oblicza architektury korporacyjnej

Z ogromną przyjemnością chciałbym poinformować, że w dniu dzisiejszym ma miejsce premiera darmowego opracowania w formie e-booka dotyczącego tematyki architektury korporacyjnej w Polsce. Jest to przedsięwzięcie niekomercyjne zrealizowane pod redakcją prof. SGH, dr hab. Andrzeja Sobczaka w ramach jego prac w Zakładzie Systemów Informacyjnych Szkoły Głównej Handlowej w Warszawie.

Na publikację składa się 10 artykułów opracowanych przez 11 autorów, w tym dwa artykuły mojego autorstwa. Poniżej zamieszczam listę artykułów:

1. Paweł Bartusch, Piotr Materny, Waldemar Piszczewiat - Strategia rozwoju infrastruktury IT. Metodyka opisu i wizualizacji architektury technicznej.
2. Bogdan Głuszkowski - Metody zmniejszania złożoności architektury.
3. Krzysztof Gwardys - Wybrane zagadnienia związane z dostosowaniem metody ADM do potrzeb organizacji.
4. Wawrzyniec Kowalczyk - Ludzkie oblicze architektury korporacyjnej: model kapitału intelektualnego przedsiębiorstwa.
5. Andrzej Sobczak - Sposoby oceny dojrzałości praktyki architektonicznej w organizacji.
6. Sławomir Soszyński - Dlaczego CEO powinien zainwestować w architekturę korporacyjną?
7. Piotr Szabelak - Główny Architekt – lider wspierający liderów.
8. Dawid Szymański - Architekt, czyli ten, który się ciągle czepia.
9. Piotr Trętowski - Kategorie oraz mapowanie wymagań.
10. Piotr Trętowski  - Śledzenie zmian w architekturze w programie Enterprise Architect.

Wszystkich zainteresowanych zapraszam do pobrania i zapoznania się z opracowaniem, które jest dostępne na stronie: architekturakorporacyjna.pl/zapraszam-do-pobrania-e-booka-oblicza-architektury-korporacyjnej/4442/

Wykorzystanie Enterprise Architect w analizie biznesowej

Narzędzie, jakim jest Enterprise Architect posiada bardzo szeroki wachlarz możliwych zastosowań. Jednym z nich jest analiza biznesowa. W ramach analizy EA służy głównie do zarządzania i dokumentowania wymagań, modelowania danych, opracowania modelu procesów biznesowych lub modelu użycia.
Wiodącą organizacją, która wyznacza standardy w zakresie analizy biznesowej jest IIBA (International Institute of Business Analysis).
Niedawno brytyjski oddział tej organizacji opublikował raport zatytułowany IIBA UK Business Analysis Survey 2012 Top Line Results. Raport ten zawiera analizę wyników ankiety dotyczącej charakteru pracy analityka biznesowego w Wielkiej Brytanii w 2012 roku. Dodatkowo opracowane wyniki są porównane z wynikami ankiety z poprzedniego roku, dzięki temu powoli zarysowują się określone trendy.
Z mojego punktu widzenia interesujące są statystyki dotyczące wykorzystywanych narzędzi w analizie biznesowej.

Wykorzystanie narzędzi w analizie biznesowej
Źródło: IIBA UK Business Analysis Survey 2012 Top Line Results.

Na pierwszych miejscach pojawiają się narzędzia ogólnego zastosowania, takie jak MS Office, MS Visio, MS Project, czy SharePoint. Nie powinno to dziwić, bo trudno wyobrazić sobie opracowanie dokumentacji bez tego typu narzędzi. Jednak, jak wskazuje IIBA:

Quality Centre (Testing), JIRA (Agile / User Stories), Sparx Enterprise Architect (UML) and BalsamIQ Mock Ups (Mock Ups) are the only non-generalist products which are used by more than 10% of the BA community.

wśród narzędzi, które są dedykowane do pracy projektowej znalazł się Sparx Enterprise Architect.
Oznacza to, że spośród narzędzi do modelowania EA wyróżnia się pod względem wykorzystania spośród takich narzędzi, jak ARIS, IBM Blueworks Live, czy CaseComplete. Podobnie wygląda sytuacja w porównaniu z narzędziami do zarządzania wymaganiami. W tyle zostały takie produkty, jak RequisitePro, czy CaliberRM.

Tendencję wzrostową w zakresie wykorzystania EA pokazuje również następny wykres, który obrazuje zmiany w zakresie wykorzystywania narzędzi w odniesieniu do poprzedniego roku.

Zmiany w wykorzystywaniu narzędzi w analizie biznesowej (2011-2012)
Źródło: IIBA UK Business Analysis Survey 2012 Top Line Results.

Sparx Enterprise Architect wraz z HP Quality Center (Centre) oraz Borland CaliberRM odnotowały największy wzrost.

Można dyskutować o tym, czy zaprezentowane w raporcie wyniki odzwierciedlają prawidłowo rzeczywistość. Raport został opracowany na podstawie wyników ankiety przeprowadzonej tylko w Wielkiej Brytanii. Ponadto zamieszczono informację, że badana próbka to 360 osób.

A może znacie wyniki podobnych ankiet przeprowadzonych w Polsce?

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.

Dojrzałość organizacji w zarządzaniu danymi

W ramach opracowywania architektury korporacyjnej w organizacji jednym z nurtów jest architektura danych. W TOGAF zagadnienie to jest jedną z czterech domen architektonicznych:

• Business,
• Data,
• Application,
• Technology.

Słownik TOGAF® (dokument TOGAF® 9 Translation Glossary: English - Polish) definiuje, że architektura danych to:

Struktura logicznych i fizycznych danych organizacji, a także zasobów używanych do zarządzania tymi danymi.

W książce pod tytułem The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight znalazłem interesujący model dojrzałości organizacji w zarządzaniu informacjami. Model ten pokazuje w jaki sposób organizacja może rozwijać się w tym zakresie i do czego dążyć.

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.

Co to jest MDG Technology?

Korzystając z programu Enterprise Architect można natknąć się na pojęcie MDG Technology. Termin ten brzmi dość zagadkowo i może być trudno rozponawalny. MDG to skrót od Model Driven Generation. Na pierwszy rzut oka może się kojarzyć z generowaniem kodu na podstawie modelu. Jednak mechanizmy związane z transformacjami zawartości modelu to zagadnienie o nazwie Model Driven Architecture.

Czym zatem jest MDG Technology?

MDG Technology umożliwia użytkownikom rozszerzenie zdolności modelowania w programie Enterprise Architect o specyficzne dziedziny i notacje. MDG Technology w sposób niezauważalny dla użytkownika wpasowuje się w EA dostarczając dodatkowe toolboxy, profile UML, szablony, wzorce i inne zasoby ułatwiające modelowanie.

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.

Jak wybrać tylko właściwe elementy?

Ostatnio od kilku różnych osób dostałem zapytania dotyczące odfiltrowania tylko wybranych elementów do raportu RTF. Pytania te dotyczyły na przykład umieszczenia w raporcie elementów o określonym statusie lub przypisanych do określonej fazy. Pisałem już o tym w artykule Generowanie raportów RTF w EA, jednak postanowiłem bardziej przybliżyć temat pisząc o mechanizmie Element filters. Ta sama funkcja dotycząca filtrowania elementów została zastosowana w dwóch miejscach w EA:

• Model Search - alternatywnie do budowania zapytań SQL możliwe jest wyszukiwanie elementów (i nie tylko) w oparciu o filtry.
• Dokumentacja - filtry można zastosować w odniesieniu do definicji całego dokumentu (dostępnej z poziomu okna Resources --> Documents --> RTF Documents lub w odniesieniu do pojedynczych szablonów RTF.

Dalej skupię się na zastosowaniu Element Filters dla raportów RTF. 

Interfejs webowy do EA

Pełne wykorzystanie możliwości narzędzia Enterprise Architect w dużych projektach informatycznych wymaga oprócz uruchomienia współdzielonego repozytorium również przestawienia mentalnego członków zespołu projektowego na tworzenie artefaktów projektowych w EA, zamiast wielu dokumentów w formacie MS Word lub Excel. Poza tym, barierami w pełniejszym stosowaniu EA mogą być:

• konieczność konfiguracji środowiska na stacjach roboczych (instalacja EA, dostęp do klucza licencyjnego, dostęp do repozytorium, czy systemu kontroli wersji), 
• ograniczenia dostępu spoza sieci lokalnej organizacji (na przykład podczas spotkań u klienta, czy pracy z domu),
• przywiązanie użytkowników do prostszych i bardziej tradycyjnych metod pracy (pliki pakietów biurowych przechowywane lokalnie na stacji roboczej).

Metodą na eliminację dwóch pierwszych barier mogłoby być udostępnienie interfejsu WWW do repozytorium EA. Dzięki takiemu rozwiązaniu możliwe byłoby uzyskanie dostępu do zawartości repozytorium z poziomu przeglądarki internetowej. Dla określonych użytkowników, np. kierownictwa projektu, przedstawicieli klienta, eliminowałoby to potrzebę instalacji i konfiguracji klienta EA (lub EA Viewer) oraz konfiguracji dostępu. 

Można wyobrazić sobie aplikację webową umożliwiającą odnalezienie i zapoznanie się ze szczegółami modelu domeny, modelu użycia, wymagań, czy wyświetlenie zawartości diagramów. Gdyby jeszcze interfejs użytkownika byłby bardziej przystępny, przejrzysty, a w dodatku w języku polskim, wówczas moglibyśmy mieć do czynienia z przeniesieniem wykorzystania EA w nowy wymiar.

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.