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.

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

Definicje pojęć związanych z generowaniem raportów

W artykułach opisujących funkcjonalność generowania raportów w programie Sparx Enterprise Architect pojawia się szereg pojęć, które mogą być niejasne. W związku z tym w poniższej tabeli zaprezentowano ich definicje. Należy je traktować jako moją propozycję definicji, gdyż mogą się nieco różnić od opisów dostępnych w publikacjach Sparx Systems.

Pojęcie	Definicja
Document Artifact	Element wykorzystywany m.in. przez mechanizm Virtual Report. W tym kontekście służy do przechowywania treści statycznych w formie Linked Document.
Linked Document	Dokument w formacie RTF, który jest przyporządkowany do określonego elementu. Dokument ten można edytować lub usunąć. Informacja o tym, że element posiada Linked Document prezentowana jest na diagramie w postaci literki A w prawym dolnym rogu elementu.
Master Document	Element (package element) wykorzystywany przez mechanizm Virtual Report. Do Master Document możliwe jest przypisanie głównego szablonu RTF określającego m.in. paginę czyli nagłówek i stopkę całego dokumentu.
Model Document	Element wykorzystywany przez mechanizm Virtual Report służący do zdefiniowania sekcji dokumentu. Atrybuty Model Documentu określają treść sekcji, zaś szablon RTF formę prezentacji tej treści.
Package Template	Plik XMI zawierający szablon pakietu wraz z zawartością (podpakiety, diagramy i elementy). Szablon taki służy automatyzacji tworzenia struktury pakietowej, która może być wielokrotnie powielana. Package Template może być dystrybuowany przy użyciu MDG Technology lub importowany jako plik XMI (z zastosowaniem opcji Strip GUID).
Resource Document	Definicja całego dokumentu wyjściowego dostępna w panelu Resources. Definicja ta obejmuje wszystkie opcje takie jak nazwa pliku wynikowego, Master Document, filtry itp.
Treść statyczna	Zawartość sekcji dokumentu pochodząca z Linked Document należącego do elementu typu Document Artifact. Treść statyczna w odróżnieniu od treści dynamicznych generowanych z zawartości pakietu jest sformatowana w formacie RTF, może zawierać tabele oraz elementy graficzne.
Virtual Report	Mechanizm programu Enterprise Architect służący do generowania złożonych dokumentów w formacie RTF umożliwiający wybór, grupowanie oraz ustalenie kolejności treści pochodzących z różnych pakietów i zawierających różny zakres informacyjny.

Rodzaje raportów

Program Enterprise Architect umożliwia generowanie raportów, dzięki którym diagramy oraz opisy zawartości modelu mogą być prezentowane osobom zaangażowanym w przedsięwzięcie  bez potrzeby korzystania bezpośrednio z EA.
Poniżej został przedstawiony podział na kategorie tych raportów.

Raporty HTML

Raport w formacie HTML odzwierciedla strukturę repozytorium lub strukturę wybranego drzewa pakietów, czyli podzbioru repozytorium. Istnieje możliwość zmiany domyślnego szablonu HTML poprzez edycję styli CSS. Edycja szablonu pozwala zmienić styl wyświetlania określonych cech elementów oraz ograniczyć zakres prezentowanych w raporcie cech. Czyli na przykład możemy usunąć z raportu informację o autorze diagramu, czy dacie utworzenia i poprzestać tylko na informacjach ważnych z merytorycznego punktu widzenia. Ponadto w łatwy sposób możliwa jest zmiana logo prezentowanego w prawym górnym rogu raportu. 

Sugerowane zastosowanie tego typu raportu to udostępnienie treści zawartych w modelu kierownictwu projektu lub klientowi. 

Podstawową zaletą tego typu raportów jest łatwość dostępu, gdyż nie jest konieczne instalowanie aplikacji Enterprise Architect lub EA Viewer oraz konfigurowanie dostępu do współdzielonego modelu. 

W niektórych projektach zdefiniowany raport HTML jest generowany cyklicznie i publikowany w serwisie WWW zawierającym zbiór aktualnych informacji dotyczących całego przedsięwzięcia.

Poniższy rysunek prezentuje przykładowy raport w formacie HTML.

Raporty proste

Raporty proste to inaczej raporty w formacie RTF wygenerowane przy użyciu pojedynczego szablonu specyficznego dla jednego zakresu informacyjnego. Aby wygenerować na przykład raporty opisujące wymagania, przypadki użycia oraz model danych konieczne jest zastosowanie oddzielnych szablonów specyficznych dla każdego rodzaju elementów z uwagi na ich inny zakres informacyjny.

Sugerowane zastosowania:

• Zestawienie określonego typu elementów wraz z ich cechami - może służyć np. dalszemu przetwarzaniu w MS Excel.
• Raport roboczy dla członków zespołu projektowego - może służyć np. zebraniu w jednym miejscu wszystkich elementów spełniających określone kryteria w celu walidacji i weryfikacji zbioru danych.

Podstawową zaletą takich raportów jest ich prostota, gdyż wytworzenie pojedynczego szablonu nie jest czasochłonne, a uruchomienie generowania raportu nie wymaga żadnej konfiguracji.

Raporty proste mogą być generowane przy użyciu tych samych szablonów, które są wykorzystywane w generowaniu raportów złożonych.

Poniższy rysunek przedstawia przykład raportu prostego zawierającego zestawienie wymagań funkcjonalnych.

Raporty złożone - Virtual Reports

Raport złożony umożliwia wygenerowanie kompletnego dokumentu w formacie MS Word zgodnego z szablonem projektowym wykorzystywanym również do tworzenia dokumentacji wprost w MS Word lub Open Office. Dzięki temu cała dokumentacja projektowa posiada jednolitą i spójną formę, czyli takie same:

• style paragrafów,
• stronę tytułową,
• metrykę,
• formę spisu treści,
• oraz paginę (nagłówek i stopkę).

Dokument taki może składać się z wielu sekcji, z których każda prezentuje inny zakres informacyjny charakterystyczny dla różnego rodzaju elementów modelu. Dodatkowo część treści takiego dokumentu może stanowić tzw. treść statyczną, pochodzącą z zawartości Linked Documents, czyli dokumentów RTF przechowywanych w repozytorium EA. Dokumenty takie mogą zawierać elementy graficzne oraz tabele, które trudno byłoby umieścić w opisach elementów lub pakietów. Format zawartości Linked Document może być niezależny od zastosowanych szablonów projektowych.

Sugerowane zastosowanie to generowanie kompletu dokumentacji projektowej. Zastosowanie Virtual Reports pozwala zachować spójność treści modelu oraz dokumentów, łatwość aktualizacji oraz sprawniejsze zarządzanie dokumentacją poprzez rozdzielenie treści dokumentów od formy ich prezentacji.

Aby skorzystać z tego typu raportów konieczne jest oprócz przygotowania szablonów również opracowanie odpowiedniej struktury pakietowej oraz diagramów. Przykładowy diagram, który definiuje raport złożony przedstawia poniższy rysunek.

Mechanizm Virtual Reports umożliwia dodatkowo wygenerowanie również raportu w formacie HTML. Tego typu hybryda pozwala stworzyć raport HTML, który posiada strukturę zgodną z dokumentem w formacie RTF, a nie ze strukturą pakietową repozytorium.

Poniższy rysunek przedstawia taki przykładowy raport, którego strukturę można porównać z odpowiednikiem z zamieszczonym wyżej przykładowym raportem w formacie HTML.

Raporty Enterprise Architect jako narzędzie komunikacji

W realizacji projektów informatycznych podstawowym wyzwaniem jest kwestia szeroko rozumianej komunikacji. Najczęstszymi skutkami błędów w komunikacji jest spadek efektywności, obniżenie poziomu motywacji członków zespołu projektowego oraz popełniane błędy. Skutki te dotyczą zarówno komunikacji wewnątrz zespołu, jak również komunikacji z klientem.

Wyzwanie

Aby poprawić efektywność komunikacji stosujemy różnorodne techniki modelowania. Powszechnie znane jest chińskie przysłowie mówiące o tym, że jeden obraz wart jest tysiąca słów. Ale czy to wystarcza?
Nawet, gdy opracujemy doskonałe diagramy zgodne z przyjętą notacją, z których jesteśmy dumni może się okazać, że odbiorca ich nie rozumie. A co gorsza, nie przyzna się, że ich nie rozumie i nie sformułuje żadnych uwag.  W rezultacie przedstawimy materiał, do którego klient nie jest w stanie się odnieść i go zweryfikować.
Niby wszystko się zgadza z regułami sztuki: zamiast opisu tekstowego, który bywa niedoskonały tworzymy diagramy. Załóżmy, że taki diagram jest zgodny z wybraną metodyką oraz notacją. Więc o co chodzi? Problem jest w tym, że autor modelu posiada przygotowanie techniczne, podczas gdy odbiorca modelu może go nie posiadać. Autor modelu zna dobrze narzędzie typu CASE, w którym opracował model, a odbiorca modelu może go nie znać. Zatem brak znajomości aspektów technicznych, notacji oraz narzędzia stanowi barierę w komunikacji.

Podejście TOGAF®

Problem ten został zarysowany w ramach architektonicznych TOGAF®. Sposób, w jaki to zostało opisane bardzo mi odpowiada, dlatego też chciałbym to pokrótce omówić.
Poniższy diagram pochodzi ze strony pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html, gdzie zostało opisane zagadnienie tzw. metamodelu.

Relacje pomiędzy udziałowcami, modelami i repozytorium. Źródło: The Open Group.

Najważniejsze elementy na tym diagramie, które dotyczą komunikacji to:

• Architecture Repository (pol. Repozytorium architektoniczne) - system zarządzajacy wszystkimi danymi o korporacji, w tym modelami danych i procesów, oraz informacjami o korporacji. 
• Model - reprezentacja przedmiotu zainteresowania. Model dostarcza zmniejszonego, uproszczonego i/lub abstrakcyjnego odzwierciedlenia przedmiotu modelowanego. Tworzy się go jako środek do osiągnięcia celu. W kontekście architektury korporacyjnej, przedmiotem podlegającym modelowaniu jest całość lub część korporacji, zaś zamierzonym celem jest zdolność do konstruowania widoków odpowiadających na troski poszczególnych interesariuszy, w szczególności punktów widzenia związanych z analizowanym zagadnieniem.
• Viewpoint (pol. Punkt widzenia) - definiuje perspektywę, z której ujmowany jest widok. Jest to specyfikacja konwencji dla konstruowania i używania widoku. Widok jest tym, co widzisz; punkt widzenia jest tam, skąd patrzysz - dogodnym punktem odniesienia lub perspektywą, która określa, co widzisz.
• Stakeholder Views (pol. Widoki interesariuszy) - reprezentacja zbioru powiązanych ze sobą trosk. Widok architektoniczny może być przedstawiony jako model, aby zaprezentować interesariuszom ich obszar zainteresowania architekturą. Widok nie musi mieć postaci wizualnej lub graficznej.
• Stakeholder (pol. Interesariusz) - osoba, zespół lub organizacja (lub ich klasy) zainteresowana architekturą lub posiadająca troski związane z wynikami implementacji architektury.

Powyższe definicje zostały zaczerpnięte z dokumentu TOGAF®9 Translation Glossary: English - Polish.

Co to tak naprawdę oznacza?

Repozytorium, (które może być zarządzane przez program Enterprise Architect, ale wcale nie musi) służy do przechowywania modelu opisującego architekturę. Tak naprawdę nie ma potrzeby do ograniczania się tylko do modeli architektonicznych, można tę definicję rozszerzyć na dowolne modele. Model, (który nie jest wymieniony wprost na diagramie) przechowuje informacje, które są udostępniane (komunikowane) interesariuszom w postaci widoków, które są istotne z ich punktu widzenia.
Zatem opracowując model należy mieć na uwadze również potrzeby informacyjne interesariuszy. Zamiast publikować czy udostępniać całą zawartość modelu wszystkim zainteresowanym stronom warto zastanowić się, jakiego typu informacje kogo mogą interesować.
Ale warto pójść dalej tym tokiem myślenia. Już na etapie prac przygotowawczych do projektu warto zastanowić się, z czego powinien się składać model.
Czy wystarczy ograniczyć się do modelu danych, czy może rozszerzyć go o zakres funkcjonalny, model przypadków użycia? Czy wystarczy opisać biznesowe przypadki użycia, czy rozwinąć je w niskopoziomowe - systemowe? Czy wystarczy wymienić wymagania funkcjonalne, czy również wymagania biznesowe? Czy opisać strukturę organizacji? Czy wystarczy opisać łańcuchy wartości, czy modelować procesy biznesowe? Czy stworzyć model uprawnień? Czy opisywać aspekty wdrożeniowe? I tak dalej...
Aby odpowiedzieć sobie na tego typu pytania należy wyjść od potrzeb informacyjnych interesariuszy. Bo innego typu informacji wymaga departament informatyki, innego departamenty merytoryczne, a jeszcze innego departament bezpieczeństwa. A przy tym wszystkim warto też pamiętać o programistach, z którymi trzeba rozmawiać w inny sposób niż z biznesem.
Nie wystarczy udostępnić klientowi repozytorium i powiedzieć, że zawiera ono kompletny model rozwiązania. Klient po pierwsze może mieć trudności ze znalezieniem przeznaczonych dla niego informacji. Jeśli ich nie znajdzie, to oprócz wrażenia niedosytu może nie żądać ich dostarczenia, bo nie będzie potrafić odpowiednio sformułować wymagania.

Rozwiązanie

Jak traktować te abstrakcyjne pojęcia jak widok i punkt widzenia w praktyce?

W odniesieniu do programu Enterprise Architect widoki i punkty widzenia są realizowane przez mechanizm raportowania. EA umożliwia wygenerowanie raportów w formacie HTML oraz RTF. Ponadto część informacji może być dostarczana w innej formie za pomocą odpowiednich zapytań, czy transformacji.
Widok stanowi raport wygenerowany z repozytorium. Widok ten zawiera wybrane informacje w formie tekstowej i/lub graficznej. Raport taki może być generowany wielokrotnie, w różnych wersjach powstających w miarę dopracowywania zawartości modelu.
Aby ułatwić wielokrotne generowanie raportu można stworzyć w EA jego definicję. Definicja taka określa zakres informacyjny raportu i stanowi w praktyce określony punkt widzenia interesariusza.
Definicje raportów dostępne są w EA w oknie Resources. Poniższy rysunek zawiera przykład różnych definicji raportów przeznaczonych dla różnych odbiorców.

Dzięki opisanemu powyżej podejściu polegającemu na wyjściu od potrzeb informacyjnych różnego typu interesariuszy jesteśmy w stanie opracować dla każdego typu odbiorcy dokumenty napisane w zrozumiały przez nich sposób i nie przeładowane nadmiarem informacji. Jeśli dany odbiorca będzie odczuwał niedosyt informacji, wówczas możemy wskazać mu, że interesujące go informacje są dostępne z innego punktu widzenia, czyli w innym dokumencie, z którym może się zapoznać.
Zatem postępując według zasady "każdemu według potrzeb" z jednego modelu przy użyciu mechanizmów raportowania możemy opisywać jedno rozwiązanie z różnych perspektyw.

Oprócz samego zdefiniowania zawartości raportu poprzez określenie jego sekcji warto też określić również zakres informacyjny dotyczący opisu poszczególnych typów elementów. Na przykład w odniesieniu do wymagań funkcjonalnych dla departamentu merytorycznego może być istotne źródło wymagania, opis czy uzasadnienie. Dla departamentu informatyki może być istotny priorytet i data realizacji, zaś dla programistów sposób realizacji. Po uzgodnieniu zakresu informacyjnego z interesariuszami możemy filtrować (nie pokazywać) wybranych elementów opisu. Błędem bywa generowanie raportów opartych na domyślnych szablonach programu EA, w których prezentowane są wszystkie elementy opisu. Sprawia to, że dokument może zawierać setki stron, a istotne informacje są tak rzadko rozsiane, że zniechęcają do czytania.

Biblioteka dokumentów w EA

W artykule Import wymagań z Linked Document opisałem mechanizm tworzenia elementów modelu wprost z dokumentów składowanych w modelu w formie Linked Documents. Wykorzystanie tego mechanizmu wymaga zaimportowania dokumentów do modelu i przypisanie ich do określonych elementów typu <<document>>. Proces taki wymaga pewnego nakładu sił, co w przypadku dużych projektów może być kłopotliwe, a poza tym użytkownicy modelu i tak mają świadomość, że dokumenty te są tylko kopią dokumentów składowanych poza modelem. Aby mieć pewność, że sięgają do właściwej treści użytkownicy i tak będą korzystać z referencyjnego repozytorium dokumentów, jakim może być np. Sharepoint lub SVN.

Zatem po co tworzyć bibliotekę dokumentów w modelu Enterprise Architect?

Mogą istnieć różne przesłanki wynikające ze specyfiki projektów. Z analitycznego punktu widzenia  wartość dodaną stanowi możliwość tworzenia relacji dokumentów do innych elementów modelu (np. Dependency, Trace) oraz możliwość łączenia poprzez hiperłącza określonych słów czy fraz z dokumentu.
Ponadto model dokumentacji może służyć do wspomagania procesów tworzenia dokumentacji projektowej poprzez zastosowanie diagramów i relacji pomiędzy dokumentami. Na przykład można zamodelować zależności prezentujące informacje o tym, który dokument (lub rozdział) wynika z jakiegoś innego dokumentu. Dzięki temu łatwiej zorientować się, czy aktualizacja jednego dokumentu pociąga za sobą konieczność aktualizacji innego dokumentu.

Import wymagań z Linked Document

Enterprise Architect jest wyposażony w mechanizm, dzięki któremu możliwe jest stworzenie biblioteki dokumentów. Elementy typu Document Artifact (tak naprawdę elementy dowolnego typu, ale na potrzeby tego przykładu skupiam się tylko na elementach tego typu) mogą służyć do przechowywania w modelu kompletnych dokumentów w formacie MS Word.
W tym artykule opisuję jeden z praktycznych sposobów wykorzystania tego mechanizmu.

Opis przykładu

Naszym przykładem będzie realizacja projektu mającego na celu informatyzację biblioteki miejskiej. Do tego celu wykonawca projektu w narzędziu Enterprise Architect tworzy i utrzymuje model. Projekt jest w fazie analizy. W ramach projektu odbywa się szereg spotkań projektowych. Z każdego spotkania sporządzana jest notatka. Zapisy z notatek są istotne zarówno z  punktu widzenia kierownictwa projektu, jak również z punktu widzenia analityków. W trakcie takich spotkań mogą być zgłaszane określone wymagania. Kierownik projektu nalega na uczestników spotkań, żeby każde nowe wymaganie zgłaszane przez klienta było rejestrowane. Oczekiwanie kierownika projektu ma na celu takie zarządzanie wymaganiami, aby każda sygnalizowana potrzeba klienta była odpowiednio zaadresowana. Kierownik projektu chce uniknąć niezręcznych sytuacji, gdy po pewnym czasie, w następnych etapach projektu klient robi wyrzuty typu "Przecież już dawno mówiliśmy Wam o tym..", a analitycy odpowiadają "Nic takiego sobie nie przypominamy..." Znacie z własnego doświadczenia takie sytuacje?

Osadzanie raportów RTF w MS Word

Standardowe możliwości w zakresie generowania dokumentacji projektowej w programie Enterprise Architect są wystarczające tylko dla mało wymagających użytkowników. Każdy, kto próbował w tym zakresie osiągnąć coś więcej niż standardowa konfiguracja napotykał na szereg trudności. Trudności te są związane przede wszystkim z edycją szablonów RTF.
A ja tak na przekór wszystkim najbardziej cenię sobie właśnie funkcjonalność generowania dokumentacji. Wynika to chyba z mojej dawnej pasji, którą kiedyś było DTP. Obecnie, gdy uda mi się wyprodukować ładnie wyglądający raport z EA - pękam z radości.
Zamierzam na tym blogu w kolejnych postach dzielić się z Wami doświadczeniem związanych z raportami RTF.
Pominiemy chyba proste generowanie zwykłych raportów, bo łatwo znaleźć w aplikacji polecenie, które do tego służy. Zaczniemy od opisu możliwości osadzania raportów RTF w dokumencie MS Word.