Strategiczne partnerstwo Sparx Systems oraz IIBA

Organizacja IIBA, czyli International Institute of Business Analysis, a zatem organizacja wyznaczająca standard w dziedzinie analizy biznesowej ogłosiła niedawno, że podpisała memorandum stanowiące globalne strategiczne partnerstwo z trzema organizacjami. Jedną z nich jest Sparx Systems Pty Ltd., a zatem producent narzędzia Enterprise Architect.

Co może oznaczać ten sojusz dla użytkowników EA?

W komunikacie prasowym wskazano, że Sparx Systems oraz IIBA podzielają zainteresowanie i zaangażowanie w zwiększanie wartości świadczonych dla swoich interesariuszy. Poprzez wzajemne wspieranie wysiłków w określonych obszarach dzięki nowej współpracy skorzystają zarówno członkowie IIBA, jak również klienci Sparx Systems.

Wskazano następujące konkretne inicjatywy:

• Potencjalna integracja BABOK® 3.0 z Enterprise Architect.
• Oferta dostępu do różnych zewnętrznych zasobów, narzędzi oraz rozszerzeń w celu zwiększenia produktywności i wydajności.
• Pozostałe korzyści dotyczą wzajemnego docierania do szerszych grup odbiorców, dzięki czemu IIBA będzie mogła zyskać na popularności w świecie użytkowników Sparx EA, jak również członkowie IIBA będą kojarzyć modelowanie z oprogramowaniem firmy Sparx Systems.

Osobiście uważam, że jeśli pojawią się namacalne efekty tego sojuszu, to przyczyni się do to większego ustandaryzowania w dziedzinie analizy biznesowej i systemowej. Co prawda, nie wyobrażam sobie, na czym może polegać integracja BABOK® w oprogramowaniu, które jest tak elastyczne w dziedzinie modelowania. Na pewno dużą wartość dodaną wniesie już ujednolicenie stosowanych terminów oraz stworzenie materiałów szkoleniowych, które pokazują jak prowadzić analizę zgodną z  BABOK® w Sparx EA.

IIBA zawiązała podobny sojusz jeszcze z firmami:

• BCS The Chartered Institute for IT
• IREB®
• BRMI  

Link do komunikatu na stronie IIBA: www.iiba.org/mou.aspx

Bo ten projekt jest specyficzny...

Gdy rozmawiam z ludźmi zaangażowanymi w realizację projektów informatycznych i dochodzimy do kwestii stosowania standardów, czy to ogólnie przyjętych, czy też standardów ustanowionych w organizacji, często słyszę, że w odniesieniu do tego, konkretnego projektu niemożliwe jest zastosowanie żadnego standardu, bo ten projekt jest specyficzny...
Później przychodzi refleksja, że tak naprawdę można to powiedzieć o każdym projekcie. Czy to oznacza, że każdy projekt jest specyficzny?

Otóż według metodyk zarządzania projektami projekt to przedsięwzięcie:

• jednorazowe,
• niepowtarzalne,
• złożone.

Cechy traktujące o tym, że projekt jest jednorazowy i niepowtarzalny - oznaczają de facto, że projekt w swojej naturze jest specyficzny. Z drugiej strony złożoność przedsięwzięcia skłania do posiłkowania się jakimś usystematyzowanym podejściem, aby lepiej radzić sobie z planowaniem, kontrolowaniem i sterowaniem.

Jak to zatem jest w praktyce? Przecież osoby zaangażowane w projekty z reguły znają doskonale metodyki zarządzania projektami: PMI, Prince2..., znają standardy wytwarzania oprogramowania, takie jak: SWEBOK, standardy analityczne, takie jak: BABOK. A jak przychodzi do ich stosowania w świecie rzeczywistym, to kierują się bardziej intuicją niż wypracowanym podejściem?

Zauważam często problemy w przełożeniu teorii na praktykę. Trudno powiedzieć z czego one wynikają.
Czy źródło problemu leży po stronie metodyk, ludzi czy samych przedsięwzięć? A może po części wynika z każdego z tych elementów?

Z punktu widzenia metodyk, czy też innych standardów, które warto stosować w projektach być może za słabo jest akcentowany temat dostosowania przy jednoczesnym narzucaniu szczegółowych rozwiązań...
Choć często metodyka, czy standard wyróżnia elementy obligatoryjne oraz elementy fakultatywne. Jednakże być może brakuje dostatecznego uzasadnienia dla stosowania elementów obligatoryjnych. W przypadku metodyki Prince2 powstało nawet pojęcie PINO, czyli Prince In Name Only.

A może metodyki są zbyt szczegółowe i powinny narzucać tylko ogólne pryncypia, natomiast każdy specyficzny projekt określałby rozszerzenia wykonawcze opisujące, jak takie pryncypia są realizowane?
Ale, czy w takim ujęciu metodyki byłyby w ogóle przydatne?

A może problem nie leży jednak w po stronie metodyk i standardów, tylko ludzi, którzy powinni się nimi kierować? W trakcie szkoleń ludzie zapoznają się z materiałami w stopniu umożliwiającym im zdanie egzaminu. Nawet, jeśli pytania egzaminacyjne są nakierowane na wykorzystanie zdobytej wiedzy w praktyce, to jednak taka wiedza może jest niewystarczająca...  Rzeczywistość bywa z reguły bardziej złożona od modelu, który ją opisuje. Modele opisują rzeczywistość projektową, z którymi ludzie mają do czynienia w trakcie szkoleń i egzaminów. Modele te nie są w stanie opisać w pełni rzeczywistości. W rozpatrywanych przypadkach może brakować czynników takich, jak relacje międzyludzkie, konflikty interesów, brak zrozumienia po stronie klienta, czy menedżera. A są to czynniki, które pośrednio wpływają na podejmowane decyzje. W przypadku, gdy człowiek odczuwa zagrożenie (np. ze strony szefa, kolegów, klientów) zaczyna się kierować intuicją, która ma pomóc mu zmniejszyć zagrożenie. Można to porównać do ucieczki zwierzęcia przed drapieżnikiem: takie zwierzę skupia się bardziej nad tym, żeby biec, niż nad tym - dokąd biegnie.

Podobnie bywa w "lesie projektowym". Członkowie zespołu projektowego starają się "dowieźć" projekt. Zaczynają bieg, za nimi zawsze biegnie ktoś inny. W takiej sytuacji nie ma pewności, czy biegacz będzie biegł po ścieżkach wyznaczonych standardami, czy może jednak będzie wybierać drogi, które w danym momencie wydają się lepsze. A w takim przypadku nie ma pewności, czy dobiegnie do mety, czy po drodze nie wpadnie w jakieś pułapki, których nie dostrzegł w porę.

EA WorkPlace - wszystko w jednym miejscu

Podczas niedawnej konferencji EA User Group w Monachium Jackie Mitchell, twórca eaDocX i jedna z najbardziej aktywnych osób w społeczności użytkowników Sparx Enterprise Architect - zaprezentował nową stronę: EA Workplace.

W zamyśle twórcy ma to być miejsce, gdzie można przejrzeć katalog wszystkich dodatków i narzędzi do EA, Oprócz narzędzi serwis kataloguje również szkolenia, książki, linki i inne zasoby dotyczące EA oraz kontakty do specjalistów od EA. Dodatkowo, aby ułatwić korzystanie z narzędzi i usług pochodzących od różnych dostawców serwis ma umożliwiać dokonywanie zakupów z jednego miejsca.

Entity Relationship Model w Enterprise Architect

Rdzeniem programu Enterprise Architect był od początku UML. Jednakże program ten nadaje się świetnie do modelowania przy użyciu wielu innych notacji, wśród nich jest również Entity Relationship Model. Zamiast tego pojęcia stosuje się również nierzadko Entity Relationship Diagram (ERD) zwany po polsku diagramem związków encji. Notacja ERD straciła wiele na znaczeniu w ciągu ostatnich lat, a nawet dziesięcioleci i ustąpiła pola na rzecz diagramów klas UML. ERD służy do modelowania strukturalnego, zaś UML do obiektowego. Zatem strukturalny język modelowania w wielu zastosowaniach został zastąpiony przez język obiektowy.
Nic w tym dziwnego, skoro niegdyś w inżynierii oprogramowania królowały języki strukturalne, a obecnie języki obiektowe. Modelowanie, które jest w swojej istocie powiązane z programowaniem zatem idzie w parze z tymi przemianami.

Data Dictionary w EA

Data Dictionary to jedna z technik dokumentowania danych przetwarzanych przez system. Załóżmy, że mamy do czynienia z istniejącą aplikacją, która przechowuje dane w dużej relacyjnej bazie danych. Aby lepiej poznać struktury, w których dane są przechowywane warto zapoznać się ze schematem bazy danych. Taki schemat można zaimportować do programu Enterprise Architect.

Zaimplementowana w EA funkcjonalność importu schematu bazy danych (Import DB schema from ODBC) powoduje utworzenie klas ze stereotypem <<table>> wraz z ich atrybutami. Dodatkowo możliwe jest automatyczne umieszczenie takich tabel na diagramie klas. Dzięki temu możemy się posiłkować wizualizacją samych tabel i powiązań między nimi.

Poniższy diagram prezentuje przykład prostego schematu bazy danych opracowany dla aplikacji służącej do rejestrowania i raportowania wydatków pracowniczych.

Taki diagram wygląda dość czytelnie, ale pod warunkiem, że tabel jest niewiele. W przypadku większych struktur diagram może stać się nieczytelny, a samo rozmieszczenie zawartości diagramu może okazać się czasochłonne.

Jako alternatywę można stosować technikę Data Dictionary. Technika ta służy do opisu standardowych definicji elementów danych, ich znaczeń i możliwych wartości w formie tabelarycznej. Taka forma ze swej natury nie jest jednak stworzona do wizualizacji powiązań między tabelami. Data Dictionary zawiera definicje wszystkich atrybutów i wskazuje, w jaki sposób one składają się na większe struktury, czyli tabele.

Jak zatem wyglądałby Data Dictionary dla zmieszczonego powyżej przykładu?

Jest to tabela uzyskana jako wynika odpowiedniego zapytania. Taki widok pozostawia jeszcze trochę do czynienia. Na szczęście można przeciągnąć nagłówek kolumny o nazwie Table_Name na pole oznaczone tekstem Drag a column header here to group by that column.
Po tej operacji uzyskamy następujący efekt.

Data Dictionary może być przydatny dla projektantów, analityków, testerów aby upewnić się, czy wszystkie zainteresowane strony zgadzają się co do formatu i zawartości informacji przetwarzanych przez system. Dla zespołów wsparcia i administratorów może być przydatne w rozwiązywaniu problemów z działaniem systemu. Zebranie takich definicji w repozytorium EA może sprawić, że taka informacja będzie dostępna dla wszystkich zainteresowanych w jednym miejscu.

Metoda uzyskania widoku typu Data Dictionary nie została zaimplementowana w łatwy sposób w narzędziu. Sparx Systems zawarł jedynie krótką wzmiankę na ten temat w dokumencie "Data Modeling. From Conceptual Model to DBMS". Zamieszczono tam treść zapytania SQL, które po zapisaniu w programie pozwala wygenerować odpowiedni widok.
Data Dictionary (EAP):
SELECT t_attribute.ea_guid AS CLASSGUID, 'Attribute' AS CLASSTYPE,
t_object.Name as Table_Name,
t_attribute.Name,
iif(t_attribute.IsOrdered, "PK", "") as PrimaryKey,
iif(t_attribute.IsCollection, "FK", "") as ForeignKey ,
t_attribute.Type, t_attribute.Length, t_attribute.Precision, t_attribute.Scale,
iif(t_attribute.IsStatic, "Unique", "") as isUnique,
iif(t_attribute.AllowDuplicates, "NotNull","") as NotNull
FROM t_attribute, t_object
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table"

Niestety składnia SQL jest wrażliwa na silnik bazodanowy wykorzystywany jako repozytorium dla projektów Enterprise Architect. Powyższe zapytanie działać będzie tylko w przypadku plików EAP. Jeśli zamiast pliku lokalnego korzystamy z repozytorium w postaci bazy danych, wówczas konieczne jest przebudowanie tego zapytania.
Poniżej to samo zapytanie (z jednym wyjątkiem - dodatkowo zwracane są opisy atrybutów, czyli zawartość pola Notes) przygotowane dla repozytoriów EA pod kontrolą MySQL.
Data Dictionary (MySQL):
SELECT t_attribute.ea_guid AS CLASSGUID, 'Attribute' AS CLASSTYPE,
t_object.Name as Table_Name,
t_attribute.Name,
t_attribute.Notes,
CASE WHEN t_attribute.IsOrdered THEN "PK" ELSE "" END as PrimaryKey,
CASE WHEN t_attribute.IsCollection THEN "FK" ELSE "" END as ForeignKey,
t_attribute.Type, t_attribute.Length, t_attribute.Precision, t_attribute.Scale,
CASE WHEN t_attribute.IsStatic THEN "Unique" ELSE "" END as isUnique,
CASE WHEN t_attribute.AllowDuplicates THEN "NotNull" ELSE "" END as NotNull
FROM t_attribute, t_object
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table"

Na koniec warto dodać, że gdybyśmy w jednym repozytorium EA przechowywali schematy kilku baz danych, wówczas wszystkie tabele mogłyby się ze sobą wymieszać. Aby temu zapobiec można w ostatniej linii dopisać dodatkowy warunek ograniczający zakres zwracanych tabel tylko do gałęzi pakietów wybranej w oknie Project Browser.
Ostatnia linia wyglądałaby wówczas następująco:
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table" and t_object.Package_ID In(#Branch#)

Model Search - predefiniowane definicje

W artykule wprowadzającym w temat wyszukiwania w programie Enterprise Architect opisałem podstawowe możliwości w zakresie przeszukiwania zawartości projektów EA. Takie wyszukiwanie działa de facto w oparciu o jedną z predefiniowanych definicji, które są wbudowane w aplikację. Takich definicji jest jednak więcej i chciałbym je w tym miejscu przybliżyć.

Lista tych definicji jest dostępna w oknie Model Search w postaci listy rozwijalnej opatrzonej dość intuicyjną nazwą: Search.

Predefiniowane definicje są zgrupowane w sekcji Built-In. Są to:

• Simple
• Extended
• Element Name
• Attribute Details
• Find Orphans
• Failed Internal Tests
• Method Details
• Responsibility
• Resources
• Requirements
• Find Bookmarked Elements
• Recently Modified Elements
• Recently Modified Diagrams
• My Checked Out Packages

Lista ta może się różnić w zależności od wersji programu Enterprise Architect.

Model Search - Podstawy wyszukiwania w EA

Wyszukiwanie w zwykłych dokumentach, takich jak dokumenty pakietu MS Office, czy PDF jest proste i intuicyjne. Wystarczy wywołać okno wyszukiwania (z reguły działa skrót Ctrl+F), a następnie wpisać wyszukiwaną frazę. W przypadku projektów w programie Enterprise Architect jest nieco trudniej. Ale czy jest bardzo trudno?

Zauważyłem, że gdy ktoś pragnie wyszukać określone elementy w EA najczęściej korzysta z przycisku Find in Project Browser umieszczonego na belce okna.

Rzeczywiście jest to skuteczny sposób. Po wpisaniu szukanej frazy w oknie Project Browser zaznaczany jest pierwszy element, którego nazwa, alias lub opis odpowiada kryterium wyszukiwania.
Jego wadą jest jednak to, że nie widzimy od razu wszystkich elementów. Jeśli takich elementów jest wiele, wówczas konieczne jest wielokrotne naciskanie przycisku Find.

Ja polecam wszystkim koleżankom i kolegom korzystanie z mechanizmu Model Search. Zauważyłem, że ludzie szybko przestawiają się właśnie na ten tryb.

Okno wyszukiwania Model Search możemy otworzyć na kilka sposobów:

• przy użyciu zaznaczonej poniżej ikonki z paska narzędzi,
• menu Edit --> Find in Project
• skrót klawiaturowy Ctrl+F lub Ctrl+Alt+A

Okno Model Search wygląda na skomplikowane. Widać w nim kilka przycisków, pole tekstowe, listę rozwijalną...

Jednak wykorzystanie do najprostszego zadania, jakim jest wyszukanie elementów zawierających poszukiwaną frazę jest bardzo proste. Wystarczy w polu Search Term wpisać frazę i nacisnąć Enter lub przycisk Run.
Przykładowo wpisanie słowa biblioteka zwróciło listę pakietów i elementów, w których nazwie, aliasie lub opisie znalazło się to słowo. Można zauważyć, że na liście znalazły się również pozycje ze słowem bibliotekarz. Aby wykluczyć elementy wystarczy dodać spację na końcu poszukiwanego słowa.

Listę znalezionych elementów możemy oczywiście sortować klikając na nagłówkach kolumn lub grupować po określonej kolumnie. Na przykład przeciągnięcie nagłówka kolumny Type pozwala zmienić układ widoku.

Jeśli znajdziemy na liście poszukiwaną pozycję, wówczas dwukrotne kliknięcie na takim elemencie powoduje wyświetlenie okna jego właściwości (Properties). Jeśli chcemy sprawdzić, w jakim pakiecie taki element jest umieszczony lub na jakich diagramach występuje, wówczas możemy kliknąć na nim prawym przyciskiem myszy i wybrać akcję z menu kontekstowego.

Najczęściej wybieranymi akcjami są zapewne Find in Project Browser oraz Find in Diagrams...
Dzięki temu łatwiej jest nawigować w większych projektach i łatwo wyszukiwać właściwe treści. Ponadto Model Search pomaga w znalezieniu ewentualnych duplikatów oraz ich usunięciu.

Zbliża się publikacja BABOK 3.0

BABOK®, czyli A Guide to the Business Analysis Body of Knowledge® to najlepsze obecnie kompendium wiedzy o dziedzinie analizy biznesowej. Aktualna wersja tego opracowania to 2.0, która została wydana w 2009 roku. Wydawca, czyli IIBA uznał, że po pięciu latach nadszedł czas na odświeżenie tej pozycji. W ciągu ostatniego roku kilkudziesięciu ekspertów i praktyków opracowywało szereg zmian, na podstawie których powstała wersja robocza BABOK 3.0.
Jak zapewnia IIBA na swojej stronie, wiosną tego roku wersja trzecia stanie się dostępna do przeglądu przez całą społeczność analityków biznesowych. Każdy, kto wyrazi taką chęć będzie mógł zgłaszać swoje komentarze do treści. Planuje się, że ten proces potrwa 60 dni, a po jego zakończeniu dostępna będzie finalna wersja dokumentu.

Jak podaje Rick Strempler największą zmianą będzie wprowadzenie tzw. Business Analyst Core Concept Model (BACCM). IIBA zidentyfikował sześć kluczowych pojęć dotyczących analizy biznesowej:

• Changes
• Needs
• Stakeholders
• Solutions
• Contexts
• Value

Idea wprowadzenia tego typu katalogu pojęć nie jest nowa i jest zbliżona na przykład do tematów (themes) zdefiniowanych w metodyce Prince2:

• Business case
• Organization
• Quality
• Plans
• Risk
• Changes
• Progress

Ważną zmianą jest położenie nacisku na zarządzanie zmianą. Jest to obszar, którego znaczenie wzrosło w ostatnich latach, chociażby za sprawą wzrostu popularności metodyk zwinnych (agile). Choć prawdopodobnie pojęcie zmiany należy rozumieć szerzej - jako kontrolowaną transformację organizacji, niezbędną do realizacji potrzeb biznesowych. Zatem można się spodziewać, że BABOK® będzie się uzupełniał w tym zakresie z TOGAF, którego istotą jest przeprowadzenie organizacji ze stanu bieżącego do stanu pożądanego poprzez wprowadzenie szeregu kontrolowanych zmian.

Niemniej istotną zmianą są obszary wiedzy (knowledge areas) oraz relacje między nimi.
Zmiany w nazwach obszarów wiedzy:

• Business Analysis Planning and Monitoring - bez zmian
• Elicitation - będzie: Elicitation and Collaboration
• Requirements Management and Communication - będzie: Requirements and Design Management
• Enterprise Analysis - będzie: Situation Analysis
• Requirements Analysis - będzie: Requirements and Design Analysis
• Solution Assessment and Validation - bez zmian
• Underlying Competencies - bez zmian

W wersji 2.0 wyglądało to następująco:

Relationships Between Knowledge Areas
Źródło: BABOK® 2.0, str. 7

W wersji 3.0 będzie to prawdopodobnie wyglądać następująco:

Relationships Between Knowledge Areas
Źródło: http://ig.obsglobal.com/2013/05/babok-version-3-what-business-analysts-can-expect/

Ciekawe wydaje się dodanie w nazwach dwóch obszarów pojęcia design. Według Ricka Stremplera IIBA definiuje design jako "a usable representation of a solution". Może to wskazywać na położenie większego nacisku na wytwarzanie modeli i dokumentacji, które w praktyce pochłania znaczącą część czasu analityka, a w wersji 2.0 opracowania nie zostało dostatecznie mocno zaakcentowane.

Według mnie jednak największą zmianą jest wprowadzenie nowej definicji wymagania. Dotychczasowa definicja bazuje na IEEE 610.12-1990: IEEE Standard Glossary of Software Enginnering Terminology. Nowa definicja jest znacznie prostsza i intuicyjna:

A requirement is a usable representation of a need

Dla osób przygotowujących się do zdobycia certyfikatu CBAP lub CCBA może być również istotna informacja, że po upływie 6 miesięcy od daty publicznego wydania BABOK® - pytania egzaminacyjne zostaną zmienione, aby odpowiadały nowej wersji dokumentu.

Ogólnie o BABOK

Co to jest BABOK®?

BABOK® jest zaklasyfikowany jako tzw. body of knowledge (BOK). Jest to termin używany w odniesieniu do reprezentacji kompletnego zestawu pojęć, terminów i działań, które składają się w sumie na opis określonej profesji. Termin body of knowledge jest najczęściej używany w odniesieniu do dokumentu, jednakże należy go rozumieć w szerszym zakresie, gdyż za takim dokumentem stoi najczęściej biblioteka innych dokumentów, czy kolekcja dodatkowych informacji, które uzupełniają BOK. 

Body of knowledge nie można nazwać metodyką, gdyż metodyka jest podejściem bardziej teoretycznym, nie opisuje zazwyczaj specyficznych technik, czy metod, które w praktyczny sposób są stosowane w opisywanych procesach.

+Paweł Zubkiewicz w swoim artykule BABOK po polsku - przewodnik po analizie biznesowej napisał:

BABOK® czyli Business Analysis Body of Knowledge jest najbardziej kompletnym zbiorem wiedzy na temat profesji analizy biznesowej. Spisany przez praktyków odzwierciedla aktualnie uznane i szeroko wykorzystywane praktyki analizy biznesowej. Podobnie jak w przypadku innych BOK’ów, czyli Body of Knowledge, jest stale rozwijany przez grupę ekspertów z dziedziny. Przewodnik po analizie biznesowej opisuje dziedzinę profesji analityka biznesowego. Poza opisem najlepszych praktyk, wprowadza taksonomię oraz definiuje umiejętności oraz kompetencje dobrego analityka.

Od siebie mogę tylko dodać, że jest często traktowany jako swego rodzaju "biblia" dla analityków. Wiele osób z branży analitycznej często się powołuje na tę pozycję, choć należy dodać, że niestety zdarza się to bez dogłębnego przestudiowania. Świadczy o tym, choćby fakt, że w chwili obecnej tylko 5 osób w Polsce może się pochwalić certyfikatem CBAP (Certified Business Analysis Professional), który bazuje na wiedzy zgromadzonej w BABOK®.
Zagadnienia związane z analizą biznesową są bardzo rozległe i postrzeganie analizy zależy w dużej mierze od pełnionej roli w organizacji. BABOK® opisuje procesy, zadania i techniki realizowane zarówno po stronie organizacji zlecającej projekty (zamawiającego), jak i po stronie wykonawcy. Poza tym sądzę, że wiele osób, które pracują w rolach, takich jak: Business Systems Analyst, System Analyst, Process Analyst, Consultant, Product Owner, czy innych może nawet nie być świadomym, że to, czym się zajmują to analiza biznesowa. Nierzadko również osoby, które pracują w roli eksperta dziedzinowego (Domain Subject Matter Expert), kierownika projektu, czy testera - wykonują również różne zadania ze sfery analizy biznesowej.

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.

Zastosowanie UML Profile w Enterprise Architect

W artykule UML Profile opisałem czym jest taki profil oraz do czego może służyć. W tym miejscu chciałbym przybliżyć techniczne aspekty tworzenia, a później wykorzystania takiego profilu.

Tworzenie i późniejsze utrzymanie profilu UML to zadania realizowane w tzw. metamodelu, natomiast wykorzystanie takiego profilu ma miejsce już w docelowym modelu. Aby móc korzystać z profilu konieczne jest jego wdrożenie w formie pliku XML. Zostało to przedstawione w formie graficznej 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.

Eksport danych z MS Word do EA

Enterprise Architect jest postrzegany jako świetne narzędzie do wsparcia projektów informatycznych. Jednakże jedną z jego wad jest niedostateczna ilość narzędzi, które pozwalają wymieniać dane z innymi narzędziami. W zdecydowanej większości przypadków istnieje i będzie istnieć konieczność obiegu dokumentów w formacie MS Word.

Często mamy do czynienia z dokumentami w formacie MS Word, które opracował klient lub członkowie zespołu projektowego, a treść takiego dokumentu powinna zostać umieszczona w repozytorium programu Enterprise Architect. Cóż pozostaje zrobić w takim przypadku?
Możliwe jest wykorzystanie prostego zabiegu, który opisałem w artykule Import wymagań z MS Word. Jednak nie jest to rozwiązanie satysfakcjonujące. Zatem najczęściej treść dokumentu jest po prostu skrupulatnie przepisywana.

Na szczęście społeczność użytkowników EA jest duża i można liczyć na wsparcie z ich strony. W sieci pojawiła się nowa strona: www.eawordimporter.com. Znaleźć tam można darmowe narzędzie o wiele mówiącej nazwie: EA Word Importer.

Do czego warto zastosować to narzędzie:

• import wymagań,
• import przypadków użycia,
• import przypadków testowych

Podstawowe korzyści to:

• oszczędność czasu - eliminacja potrzeby ręcznego przepisywania tekstu
• ograniczenie ryzyka pomyłek przy ręcznej edycji tekstu
• możliwość śledzenia zależności pomiędzy zaimportowanymi elementami
• wykorzystanie centra

Na początek polecam obejrzenie krótkiego filmu prezentującego ideę, jaka przyświecała twórcom: https://www.youtube.com/watch?v=caoJCVQHv2I.

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.