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.