Podstawy EA - cz. I Wprowadzenie

Dotychczas moje artykuły dotyczyły zaawansowanych mechanizmów w programie Sparx Enterprise Architect (EA) i były skierowane przede wszystkim do osób zaznajomionych z programem oraz pracujących w zespołach projektowych. Uznałem jednak, że nadszedł czas przybliżenia programu Sparx Enterprise Architect osobom, które jeszcze nie miały z nim styczności.

Czym jest Sparx Enterprise Architect?

Enterprise Architect to narzędzie typu CASE (Computer-Aided Software Engineering) służące do wspomagania projektowania oprogramowania. Narzędzie to wspomaga procesy analizy, projektowania i programowania poprzez automatyzację metod projektowania, tworzenia kodu oraz dokumentacji. Na różnych stronach internetowych łącznie z polską wersją Wikipedii (polecam porównanie zawartości polskojęzycznej strony ze stroną anglojęzyczną) można spotkać się z niesprawiedliwą informacją o tym, że Enterprise Architect to narzędzie do modelowania. Do samego modelowania równie dobrze może służyć MS Visio, a każdy kto miał styczność z obydwoma programami od razu widzi, jak wielka przepaść dzieli te dwa programy.
Przy użyciu Enterprise Architecta możliwe jest wsparcie całego cyklu wytwórczego systemu informatycznego począwszy od zarządzania wymaganiami i procesami biznesowymi poprzez modelowanie klas i aktywności w UML do zarządzania zmianami i zgłoszeniami błędów w okresie utrzymania systemu.
EA można utożsamiać z narzędziem do notacji UML, gdyż duży odsetek zastosowań to modelowanie tylko w UML, ale warto mieć świadomość, że EA umożliwia zastosowanie wielu różnych notacji, na czele z BPMN czy Archimate.
Program ten jest jednak na tyle elastyczny, że może równie dobrze służyć jednej osobie do stworzenia pojedynczego diagramu, jak i licznemu zespołowi projektowemu w dużym projekcie.

Tutorial

Załóżmy, że mamy po raz pierwszy do czynienia z programem Enterprise Architect. Słyszeliśmy, że jest to świetne narzędzie do modelowania i chcemy go poznać lub nasz przełożony sugeruje, że powinniśmy od tej pory go używać.

Po zapoznaniu się z niniejszym tutorialem będziemy w stanie:

• stworzyć nowy projekt,
• rozpocząć edycję określonego typu modelu z szablonu,
• modyfikować strukturę pakietową projektu,
• tworzyć i usuwać elementy i relacje między nimi,
• manipulować zawartością diagramów.

Aby wykonać pierwsze kroki w EA możemy skorzystać z wersji trial (30-dniowej), a być może mamy już zakupioną licencję. Zakładam, że program został już poprawnie zainstalowany, gdyż proces instalacji nie powinien nastręczać trudności. W trakcie instalacji wystarczy wybierać domyślne ustawienia i na wszystkie pytania odpowiadać twierdząco.

Podstawowe pojęcia

Zanim przejdziemy do programu zapoznajmy się z kilkoma podstawowymi pojęciami, którymi będziemy operować.

Pojęcie	Znaczenie
Pakiet	Kontener, w którym są przechowywane elementy, oprócz nich pakiet może przechowywać również inne pakiety oraz diagramy. W oknie Project Browser jest opatrzony ikonką folderu. Szczególnym pakietem jest pakiet root, czyli pakiet najwyższego poziomu. Jego domyślną nazwą jest 'Model'. Może zawierać tylko widoki.
Widok	Pakiet na pierwszym poziomie pod pakietem typu root. Opatrzony jest w oknie Project Browser ikonką folderu wraz z dodatkowym elementem graficznym reprezentującym jego typ.
Diagram	Graficzna reprezentacja elementów wraz z ich atrybutami oraz wzajemnymi powiązaniami. Różne typy diagramów mogą prezentować różne aspekty rozwiązania.
Element	Stanowi podstawę zakresu informacyjnego modelu. Każdy element posiada swój typ, znaczenie, reguły oraz jest zgodny z określoną notacją.
Relacja	Definiuje określone powiązanie pomiędzy określonymi elementami. Elementy modelu mogą wchodzić między sobą w różnego typu relacje. Relacje są prezentowane na diagramie w postaci linii, których początek i koniec jest przywiązany do elementu.

Zacznijmy od uruchomienia programu, a potem przejdźmy do części drugiej, która opisuje utworzenie nowego projektu.

Spis treści

Aby ułatwić korzystanie z tutoriala został on rozbity na kilka części:

• Część I - niniejszy artykuł stanowiący wprowadzenie.
• Część II -  utworzenie nowego projektu.
• Część III - dodawanie nowych elementów i relacji.
• Część IV - dodawanie nowych pakietów i diagramów.
• Część V - edycja modelu.
• Część VI - podsumowanie.

Podstawy EA - cz. II Utworzenie nowego projektu

Tutorial - część II

Utworzenie nowego projektu

1. Uruchamiamy program Enterprise Architect
2. Po uruchomieniu widoczne jest okno Open Enterprise Architect Project.
   Gdyby okno nie było widoczne naciśnij Ctrl+O.

3. Naciśnij przycisk New Project...
4. Zostanie wyświetlone standardowe okno MS Windows służące do wskazania lokalizacji i nazwy nowo tworzonego pliku.
5. W wybranym folderze wpisz nazwę nowego projektu (np. test) i naciśnij przycisk Zapisz.
6. Na dysku lokalnym zostanie utworzony nowy plik z rozszerzeniem .eap (np. test.eap).
7. Nowy projekt zostanie otworzony w programie EA wraz z oknem służącym do wyboru szablonu modelu (Model Wizard).
   Dzięki temu nie musimy rozpoczynać pracy "od czystej kartki". Na starcie możemy skorzystać z uniwersalnych szablonów przeznaczonych do różnego rodzaju modeli.

8. Na liście z lewej strony o nazwie Technology zaznaczamy Basic UML 2 Technology, a w prawej liście zaznaczmy Use Case. A następnie naciskamy przycisk OK.

9. W rezultacie tego w oknie Project Browser powstała nowa struktura.

Model przypadków użycia utworzony z szablonu

Teraz nasz model składa się z widoku o nazwie Use Case Model. Widok ten zawiera dwa pakiety: Actors oraz Primary Use Cases. W każdym z tych pakietów znajduje się diagram typu UseCase o nazwie takiej samej jak pakiet. Diagramy te możemy wyświetlić klikając na nich dwa razy myszą.

W pakiecie Actors utworzony został element o nazwie User typu Actor. W pakiecie Primary Use Cases istnieją dwa przypadki użycia (elementy typu UseCase). Dwukrotne kliknięcie na na nazwie takiego elementu powoduje wyświetlenie okna jego właściwości (Properties).

Przy przypadku użycia Use Case1 widoczny jest plusik, który oznacza, że element ten jest złożony i posiada dodatkową zawartość. Po rozwinięciu zawartości tego elementu widzimy, że zawiera on zagnieżdżony diagram sekwencji o nazwie Use Case1 oraz element podrzędny o nazwie Object1.

Zatem nasz model posiada teraz odpowiednią strukturę zbudowaną z pakietów. Pakiety mogą posiadać inne pakiety (pakiety podrzędne), diagramy oraz elementy. Elementy mogą być przedstawiane na diagramach przy zastosowaniu formy graficznej charakterystycznej dla ich typu. Typ elementów i diagramów jest również odzwierciedlony w oknie Project Browser przy użyciu odpowiedniej ikonki.

Podstawy EA - cz. III Dodawanie elementów i relacji

Tutorial - część III

Dodawanie nowych elementów i relacji

Dla każdego typu diagramu istnieje skojarzona z nim odpowiednia paleta (Toolbox). Wyświetlenie w obszarze roboczym diagramu typu Use Case Diagram skutkuje również przełączeniem palety na typ Use Case.

Paleta może zawierać kilka sekcji. W przypadku diagramu przeznaczonego dla przypadków użycia są to:

• Use Case - zawiera dedykowane elementy, które mogą być umieszczane na diagramie przypadków użycia. Podstawowymi elementami są Actor oraz Use Case.
• Use Case Relationship - zawiera zestaw relacji do wykorzystania na diagramie przypadków użycia.
• Use Case Patterns - wstawienie szablonu Basic Use Case powoduje umieszczenie na diagramie od razu zestawu elementów i relacji.

Dodatkowo w palecie bez względu na typ diagramu zawsze wyświetlana jest sekcja Common zawierająca elementy i relacje, które nie są związane bezpośrednio z określonym typem diagramu. Zapewne najczęściej wykorzystywaną pozycją z sekcji Common jest notatka (Note).
Poniższy rysunek prezentuje notatkę wstawioną na diagram. Notatka taka może być powiązana relacją (NoteLink) z opisywanym elementem.

Przeciągnięcie (wybór, a następnie upuszczenie na diagramie) wybranego elementu z palety sprawia, że nowy element pojawia się na diagramie (pojawia się również w oknie Project Browser w pakiecie, w którym znajduje się aktywny diagram). Jednocześnie wyświetlane jest okno właściwości (Properties) nowego elementu, w którym powinniśmy wpisać co najmniej jego nazwę.

Okno właściwości elementu daje dostęp szeregu informacji o elemencie, które nie muszą być prezentowane na diagramie.

Zawartość tego okna składa się z kilku sekcji, pomiędzy którymi można się przełączać korzystając z lewego panelu okna. Domyślnie otwierana jest zakładka General zawierająca podstawowe informacje, takie jak nazwa elementu (Name), jego stereotyp (Stereotype), opis (Notes), autora (wartość wypełniana automatycznie podczas tworzenia elementu systemową nazwą użytkownika, nazwę tę można zmienić w ustawieniach programu).
Zakładka Tagged Values służy do dodawania i edycji dodatkowych, niestandardowych właściwości elementu. Zakładkę Files można wykorzystać do przechowywania odnośników do plików lokalnych lub stron WWW bezpośrednio związanych z elementem. Zakładka Links zawiera listę relacji, którymi element jest powiązany z innymi elementami.
Element podlega określonym zasadom (Rules).  W podanym przykładzie Zakładki Requirements, Constraints oraz Scenarios są determinowane typem elementu. Na przykład scenariusze (Scenarios) są specyficzne dla przypadków użycia.
W przypadku modelowania klas UML dodatkowe właściwości są dostępne na zakładce Details, gdzie możemy określić parametry zgodne ze specyfikacją UML oraz uzyskamy dostęp do zestawu atrybutów (Attributes) oraz metod (Operations) danej klasy.

Nowe relacje pomiędzy elementami możemy wprowadzać na dwa sposoby:

• Zaznaczenie w palecie wybranej relacji, a następnie przeciągnięcie myszy pomiędzy jednym a drugim elementem na diagramie.
• Zaznaczenie wybranego elementu, następnie kliknięcie na strzałkę znajdującą się w jego prawym górnym rogu, a potem przeciągnięcie myszą na drugi element. W wyniku tego zostanie wyświetlone menu kontekstowe zawierające listę relacji, którą można zastosować do połączenia aktualnie wybranych typów elementów. Wybór pozycji z listy skutkuje stworzeniem nowej relacji.

Oprócz opisanych tu sposobów tworzenia nowych elementów i relacji istnieje jeszcze kilka innych metod. W miarę zdobywania doświadczenia można je odnaleźć i wypróbować.

Podstawy EA - cz. IV Dodawanie pakietów i diagramów

Tutorial - część IV

Dodawanie nowych pakietów i diagramów

Strukturę pakietową modelu możemy swobodnie dostosowywać do własnych potrzeb. Nowy pakiet tworzony jest jako podpakiet w aktualnie zaznaczonym pakiecie (będzie to pakiet nadrzędny). Można go utworzyć przy użyciu jednej z poniżej wymienionych metod:

• Kliknięcie na ikonkę Add a Package w oknie Project Browser

• Wybór z menu kontekstowego pakietu nadrzędnego opcji Add -> Add Package...

 

• Zaznaczenie pakietu nadrzędnego i naciśnięcie z klawiatury Ctrl+W.

W wyniku zastosowania jednej z tych metod zostanie wyświetlone okno dialogowe, w którym należy określić nazwę dla nowego pakietu.

Zaznaczenie opcji Automatically add new diagram umożliwia utworzenie wraz pakietem diagramu, którego nazwa będzie taka sama, jak nazwa pakietu, zaś typ diagramu można określić w kolejnym oknie New Diagram, które wyświetli się po naciśnięciu przycisku OK.

Typy diagramów są podzielone na odpowiednie kategorie, takie jak UML Structural, UML Behavioral itd. Po zaznaczeniu w prawej sekcji okna (Diagram Types) określonego typu diagramu poniżej wyświetlany jest krótki opis jego zastosowania.
Naciśnięcie przycisku OK powoduje zakończenie procesu dodawania pakietu i diagramu. Naciśnięcie przycisku Cancel jest jednoznaczne z rezygnacją z tworzenia diagramu, jednak w takim przypadku pakiet pozostaje utworzony.

Podstawy EA - cz. V Edycja modelu

Tutorial - część V

Edycja modelu 

Do wykonania podstawowych operacji w modelu wystarczają następujące elementu interfejsu użytkownika:

• okno Project Browser - zawiera ustrukturyzowaną zawartość modelu.
  Jeśli go nie widać należy wybrać z menu programu View -> Project Browser.
• obszar roboczy - w którym prezentowana jest zawartość diagramów
• Toolbox - paleta elementów, relacji i innych obiektów, które możemy wstawiać na diagram.
  Jeśli jej nie widać należy wybrać z menu programu View -> Diagram Toolbox.

Jeśli chcemy zmienić położenie określonego elementu lub pakietu w ramach struktury projektu należy skorzystać z okna Project Browser. W oknie tym możemy chwycić myszą i przeciągnąć taki element lub pakiet w inne miejsce. Przeniesienie elementu z jednego pakietu do innego nie skutkuje usunięciem takiego elementu z diagramu, na którym się znajduje.
Każdy diagram może zawierać elementy pochodzące z różnych pakietów. W naszym przykładzie proszę zwrócić uwagę na aktora o nazwie User. Element ten znajduje się w pakiecie Actors, a występuje aż na trzech diagramach:

• Diagram Actors::Actors
• Diagram Primary Use Cases::Primary Use Cases
• Diagram Primary Use Cases::Use Case1.UseCase1

Oznacza to, że nie ma potrzeby powielania tego samego elementu w wielu miejscach. Zamiast tworzyć duplikaty aktora User, wystarczy go przeciągnąć z okna Project Browser na obszar roboczy, na którym wyświetlony jest dowolny diagram. Dzięki temu tworzony model jest spójny, bo gdyby zaszła potrzeba zmiany nazwy elementu (np. z User na Użytkownik) wystarczy to zrobić jednokrotnie (w oknie Properties elementu). Zmiana ta zostanie automatycznie uwzględniona we wszystkich diagramach, na których ten element się znajduje.
W większości przypadków elementy na diagramie pochodzące z obcego pakietu są oznaczone przy użyciu jednej z dwóch metod:

• informacja pod elementem poprzedzona słowem From. Na przykład (from Aktorzy).
• przedrostek przed nazwą elementu oddzielony od nazwy seperatorem "::". Na przykład Aktorzy::User.

Brak takiej informacji w odniesieniu do obcego elementu może wynikać z typu elementu, typu diagramu lub zmiany domyślnych ustawień diagramu.

W związku z tym, że jeden element może być wyświetlany na wielu diagramach, usunięcie elementu z diagramu nie skutkuje usunięciem elementu z modelu. Taki element nadal można odnaleźć w oknie Project Browser. Warto o tym pamiętać, gdyż możemy się zdziwić, że po pewnym czasie odnajdujemy w modelu elementy, co do których byliśmy pewni, że już zostały usunięte.

Program nieco inaczej zachowuje się w przypadku usuwania relacji widocznych na diagramie.
Relację (connector) na diagramie możemy usunąć przy użyciu opcji Delete Connector dostępnej z menu kontekstowego po zaznaczeniu wybranej relacji lub poprzez naciśnięcie przycisku Delete na klawiaturze.

Operacja ta powoduje wyświetlenie okna dialogowego Remove Connector (o ile nie został odznaczony checkbox Don't ask again).

Jak widać mamy w tym przypadku dwie możliwości:

• Hide the connector - relacja pozostaje w modelu, jednak nie jest wyświetlana na tym diagramie. Jeśli oba połączone tą relacją elementy znajdą się na innym diagramie, wówczas ta relacja zostanie tam zaprezentowana. Jest to zachowanie analogiczne do usuwania elementu z diagramu.
• Delete the connector from the model - skutkuje trwałym usunięciem relacji z całego modelu. Relacja ta zostanie usunięta również z innych diagramów, jeśli była prezentowana na więcej niż jednym diagramie.

Podstawy EA - cz. VI Podsumowanie

Tutorial - część VI

Podsumowanie

Opisana w niniejszym tutorialu dotyczącym podstaw obsługi programu Sparx Enterprise Architect funkcjonalność dodawania nowego modelu z szablonu poprzez okno Model Wizard dostępna jest w dowolnym momencie z menu kontekstowego pakietu Add -> Add a new Model using Wizard...

Dzięki temu w jednym projekcie można rozpocząć modelowanie rozwiązania w różnych ujęciach oraz przy użyciu różnych notacji.

Korzystając z dostarczonych wraz z programem szablonów należy jednak mieć świadomość, że tworzony model powinien być zgodny w pierwszej kolejności z regułami wybranej notacji, a dopiero w drugiej kolejności polegać na zamieszczonych przykładach.

Kolejnym krokiem w poznawaniu możliwości EA mogą być własne próby i eksperymenty. Warto też poświęcić trochę czasu na zapoznanie się z możliwymi do wykorzystania polami dostępnymi w oknie Properties elementów i diagramów.
Graficzną formę prezentacji elementu na diagramie możemy modyfikować w pewnym zakresie. Zmiana koloru tła, obramowania czy zmiana czcionki nie łamie reguł zastosowanej notacji, a może służyć poprawieniem czytelności diagramu. Zmiany te można najwygodniej wprowadzać po kliknięciu na małą ikonkę "pędzelka", która pojawia się po zaznaczeniu elementu na diagramie.

Wyświetlane jest wówczas małe menu podręczne zawierające standardowe ikonki symbolizujące określone operacje. W celu ułatwienia zmiany wielu elementów możliwe jest kopiowanie stylu z jednego elementu i zastosowanie takiego stylu na innym elemencie.

Szukanie pomocy

Niniejsze opracowanie bazuje w pewnym zakresie na zawartości sekcji Getting Started z Pliku Pomocy EA (EA User Guide). W ogóle gorąco zachęcam do korzystania z pomocy programu EA, gdyż w odróżnieniu od wielu innych programów, pomoc ta bywa naprawdę przydatna. Widać, że firma Sparx Systems dokłada wielu starań w tym zakresie, a zawartość jest sukcesywnie uaktualniana tak, aby ułatwić nawigację i odnalezienie poszukiwanych informacji.

W dalszej kolejności warto się zapoznać się z materiałami publikowanymi na stronie Sparx Systems oraz przeszukać forum dyskusyjne.

Eksport modeli UML do Eclipse

Sparx, producent Enterprise Architect kilka lat temu postawił na interoperacyjność tworzonych modeli i umożliwienie wymiany danych z innymi narzędziami. Ten cel jest wspierany przez możliwość eksportu i importu modeli w formacie XMI (XML Metadata Interchange).
EA umożliwia tworzenie i obsługę formatu zgodnego ze specyfikacją UML opracowaną przez OMG oraz różnych innych wariantów wersji formatu XMI. Jednakże implemenentacja standardu XMI w jednym z najbardziej popularnych narzędzi klasy IDE, jakim jest Eclipse nieco różni się od implementacji XMI w Enterprise Architect.

Z pomocą w tym zakresie przychodzi firma LieberLieber, która znana jest z budowania różnego rodzaju rozwiązań bazujących na Enterprise Architect. Firma ta opublikowała ostatnio skrypt XSLT obudowany w formie MDG Technology. Dodatek ten umożliwia eksport modeli UML, który jest poprawnie obsługiwany przez Eclipse.

Aby wykorzystać ten dodatek należy dodać na swojej stacji roboczej wprost ze strony firmy LieberLieber poprzez menu Settings -> MDG Technologies -> Advanced -> Add URL....
Można też alternatywnie zapisać plik UMLExportTechnology_v1.xml na dysku lokalnym i korzystać z MDG bez konieczności łączenia się do strony firmy LieberLieber poprzez wybranie w ostatnim kroku Add Path... i wskazanie katalogu z wyżej wymienionym plikiem XML.

Obecnie wspierany jest eksport modelu klas i maszyn stanowych. Sądzę, że z punktu widzenia zastosowania modelu UML w Eclipse jest to wystarczający zestaw.

Adres MDG Technology do podłączenia w EA: https://demo.lieberlieber.com/downloads/UMLExportTechnology_v1.xml

Więcej informacji na stronie: blog.lieberlieber.com/2012/11/13/export-your-ea-models-for-eclipse

Kopiowanie atrybutów i metod pomiędzy klasami

Elementy umieszczane w modelu programu Enterprise Architect, takie jak klasy UML mogą mieć przypisane jako właściwości (features) atrybuty i metody. Może się zdarzyć, że kilka różnych klas powinno mieć taki sam atrybut lub metodę lub nawet cały zestaw.

Jak skopiować atrybuty lub metody pomiędzy klasami?

Nie jesteśmy zmuszeni do wielokrotnego tworzenia tych samych atrybutów lub metod klasy.

Zamieszczony tutaj przykład pokazuje jak można skopiować istniejące atrybuty i metody (element features) z jednej klasy do drugiej.

1. Otwórz diagram zawierający klasę, do której chcesz skopiować atrybuty lub metody.
   W tym przykładzie będziemy kopiować do Class2 oraz Class3 z klasy Class1, która akurat jest na tym samym diagramie.
2. W oknie Project Browser rozwiń właściwości wybranej klasy.
   W tym przykładzie jest to Class1, tak aby widoczne były: atrybut1, atrybut2, atrybut3, get(int) oraz set(int).
3. Zaznacz właściwości, które chcesz skopiować.
   Można stosować klawisze Ctrl (do wskazania konkretnych pozycji) oraz Shift (do zaznaczenia zasięgu zaznaczenia).
4. Przeciągnij myszą zaznaczone pozycje z okna Project Browser na wybraną klasę na diagramie.
5. Program utworzy kopie tych właściwości.

Poniższy zrzut ekranowy prezentuje efekt końcowy.

W tym przykładzie z klasy Class1 do klasy Class2 został skopiowany atrybut3 oraz metody get() i set(), a do klasy Class3 atrybuty atrybut1, atrybut3 oraz metody get() i set().

Można również przenosić właściwości klasy (zamiast tworzenia kopii). Do tego celu najwygodniejsze jest przeciąganie myszą atrybutów lub metod z jednej klasy na drugą w obrębie okna Project Browser zamiast z okna Project Browser na diagram.

Zastosowanie tej metody pozwala zaoszczędzić czas na ręczne tworzenie duplikatów oraz zmniejsza ryzyko popełnienia błędów przy manualnym wprowadzaniu danych.

Kompletność modelu użycia

Model użycia (use case model) w wielkim skrócie służy do przedstawienia funkcjonalności rozwiązania poprzez zastosowanie przypadków użycia, aktorów oraz relacji pomiędzy nimi.
Z reguły początkujący analitycy dysponują przynajmniej teoretyczną wiedzą o regułach tworzenia modelu użycia. Wraz z każdym zrealizowanym projektem umiejętności te rosną, ale mimo to dostarczany model użycia często nie jest idealny. Warto zatem pokusić się o stworzenie krótkiego podsumowania w tym zakresie.

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?