piątek, 21 grudnia 2012

Lista skrótów klawiaturowych

Dla ułatwienia korzystania z programu Enterprise Architect wprowadzono szereg różnych skrótów klawiaturowych. Korzystanie z nich pozwala oszczędzić wiele czasu na wykonywanie powtarzalnych czynności.
Tylko jak efektywnie korzystać z tych skrótów klawiaturowych, gdy tylko niektóre z nich pojawiają się w menu? W EA User Guide jest co prawda strona zawierająca ich spis, ale w formie tabeli, która nie poręczna w codziennym użytkowaniu.

W tym celu może się okazać przydatny arkusz opracowany przez niejakiego Juanjo Ramizera Amenedo. Arkusz ten został opublikowany w serwisie społecznościowym Sparx Systems i jest dostępny do pobrania pod adresem: Enterprise Architect Shortcuts Reference Card.

Myślę, że warto mieć pod ręką ten arkusz w postaci wydruku.

fragment arkusza skrótów klawiaturowych Enterprise Architect
Fragment arkusza skrótów klawiaturowych Enterprise Architect

czwartek, 20 grudnia 2012

Edycja szablonów RTF: Elementy spoza pakietu

W prosty sposób można umieścić w szablonie RTF opisy elementów znajdujących się w pakiecie objętym raportem. Wystarczy wstawić odpowiednie znaczniki, a następnie wybrać właściwe pola, które opisują znaczące cechy, takie jak nazwa (Name), czy opis (Notes).
Często jednak może być potrzebne wymienienie również innych elementów, które są powiązane z raportowanym pakietem poprzez kontekst. Dotyczyć to może elementów powiązanych relacjami lub obcych elementów umieszczonych na diagramach w raportowanym pakiecie. Dzięki temu raport może zawierać również (lub tylko) elementy pochodzące z innych pakietów niż raportowany.
Taki zabieg może być przydatny na przykład w sytuacji, gdy w rozdziale opisującym przypadki użycia chcemy nawiązać również do kontekstu procesów biznesowych lub komponentów aplikacji, które je realizują.


środa, 19 grudnia 2012

Edycja szablonów RTF

Program Sparx Enterprise Architect jest instalowany wraz z kolekcją predefiniowanych szablonów RTF. Dostęp do tych raportów jest możliwy z poziomu okna Resources. Szablony te są zebrane w grupę o nazwie System. Raport wygenerowany przy użyciu predefiniowanego szablonu jest łatwo rozpoznawalny z uwagi na zastosowanie specyficznych styli paragrafów. Chociażby wszystkie nagłówki mają odcienie koloru niebieskiego.
Taki styl może nie odpowiadać każdemu, w związku z tym sugeruję, aby traktować je jedynie jako przykłady możliwych konstrukcji, a dla celów projektowych opracować na ich podstawie własne szablony.
Jest to o tyle istotne, że predefiniowane szablony zawierają bardzo dużą ilość cech, tabel oraz pól, które mogą być nadmiarowe. Brak doświadczenia w edycji szablonów bądź po prostu ludzka niechęć do wyrzucania czegokolwiek sprawia, że wygenerowany raport przy użyciu standardowego szablonu staje się nieczytelny z uwagi na przeładowanie niepotrzebnymi informacjami.
W jednym z projektów spotkałem się z raportem wygenerowanym przy użyciu standardowego szablonu, który liczył blisko 200 stron. Ważne informacje były tak rzadko rozsiane, że samo przewijanie stawało się nieprzyjemne, a jak się pomyśli jeszcze o tym, że taki raport jest drukowany w kilku egzemplarzach, to aż żal lasów. Ten raport zamiast 200 stron bez problemu zmieściłby się na 20-30 stronach.

okno Resources - lista standardowych szablonów


poniedziałek, 17 grudnia 2012

Virtual Reports

W programie Enterprise Architect w zakresie generowania dokumentacji w formacie RTF jest możliwość generowania tzw. raportów prostych - opartych o jeden szablon oraz raportów złożonych - opartych o więcej niż jeden szablon. Zaproponowany przeze mnie podział na typy raportów został opisany w artykule Rodzaje raportów.
Metoda wykorzystania raportów złożonych, czyli Virtual Reports może nie być czytelna dla każdego, w związku z tym postanowiłem poświęcić jej nieco miejsca.


sobota, 15 grudnia 2012

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.

piątek, 14 grudnia 2012

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.
zawartość przykładowego raportu HTML z Enterprise Architect

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

spis treści przykładowego raportu złożonego - virtual report

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.
diagram dokumentacji - Virtual report


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.
przykładowy Virtual Report w formie HTML

czwartek, 13 grudnia 2012

Generowanie raportów RTF w EA

Gdy zakończymy pracę nad opracowaniem modelu w Enterprise Architect nadchodzi moment, gdy należy podzielić się wynikami pracy z innymi członkami zespołu projektowego lub z klientem. Możemy przesłać lub udostępnić repozytorium EA, ale o wiele lepszym rozwiązaniem jest opracowanie dokumentacji, która w bardziej przejrzysty i czytelny sposób prezentuje zawartość modelu. W tym celu należy skorzystać z funkcjonalności generowania raportów w EA.


piątek, 7 grudnia 2012

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.
okno Resources - Documents - RTF Documents

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.

sobota, 1 grudnia 2012

Project Integrity Check od środka

Projekt tworzony w programie Enterprise Architect jest przechowywany w formie relacyjnej bazy danych. Bez względu na zastosowany silnik bazodanowy (MS Jet w przypadku plików EAP, MS SQL, MySQL, Oracle czy inny) zastosowany jest ten sam schemat bazy danych do przechowywania modeli. Dane w relacyjnej bazie danych powinny być spójne. Spójność tę można zapewnić w sposób techniczny wprowadzając określone constraints, wówczas silnik baz danych pilnuje zgodności zdefiniowanych reguł.

Funkcja Project Integrity Check

Zapewne kierując się przesłankami wynikającymi z logiki biznesowej dotyczącej przetwarzania danych takich, jak pakiet, element, relacja, atrybut czy metoda, zdecydowano o wdrożeniu wewnątrz programu EA funkcjonalności pozwalającej z poziomu interfejsu użytkownika sprawdzić spójność projektu. Funkcjonalność ta nazywa się Project Integrity Check i jest dostępna poprzez wybór w menu aplikacji opcji Tools -> Data Management -> Project Integrity Check.


środa, 28 listopada 2012

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
 PakietKontener, 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.
 WidokPakiet na pierwszym poziomie pod pakietem typu root.
Opatrzony jest w oknie Project Browser ikonką folderu wraz z dodatkowym elementem graficznym reprezentującym jego typ.
 DiagramGraficzna reprezentacja elementów wraz z ich atrybutami oraz wzajemnymi powiązaniami.
Różne typy diagramów mogą prezentować różne aspekty rozwiązania.
 ElementStanowi podstawę zakresu informacyjnego modelu. Każdy element posiada swój typ, znaczenie, reguły oraz jest zgodny z określoną notacją.
 RelacjaDefiniuje 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:


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. Open Enterprise Architect Project
  4. Naciśnij przycisk New Project...
  5. Zostanie wyświetlone standardowe okno MS Windows służące do wskazania lokalizacji i nazwy nowo tworzonego pliku.
  6. W wybranym folderze wpisz nazwę nowego projektu (np. test) i naciśnij przycisk Zapisz.
  7. Na dysku lokalnym zostanie utworzony nowy plik z rozszerzeniem .eap (np. test.eap).
  8. 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.
  9. New model Wizard
  10. 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.
  11. Wybór szablonu zawierającego domyślny projekt przypadków użycia
  12. W rezultacie tego w oknie Project Browser powstała nowa struktura.
Zawartość okna Project Browser - przykładowy model

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ą.
diagram przypadków użycia z szablonu EA

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).
okno Properties elementu

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.
diagram interakcji przypadku użycia UseCase1

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.
use case diagram toolbox

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.
wstaiwienie notatki na diagram
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.
zaznaczony element na diagramie
tworzenie nowej relacji między elementami modelu

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.
new diagram type
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.
usuwanie relacji (connector) z diagramu

Operacja ta powoduje wyświetlenie okna dialogowego Remove Connector (o ile nie został odznaczony checkbox Don't ask again).
opcje usunięcia relacji (connector)
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.
Enterprise Architect User Guide
W dalszej kolejności warto się zapoznać się z materiałami publikowanymi na stronie Sparx Systems oraz przeszukać forum dyskusyjne.

środa, 14 listopada 2012

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

poniedziałek, 12 listopada 2012

Kopiowanie atrybutów i metod pomiędzy klasami

class icon
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.
diagram klas - class diagram

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.

piątek, 9 listopada 2012

Kompletność modelu użycia

use case
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.


czwartek, 8 listopada 2012

Biblioteka dokumentów w EA

document artifact icon
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.

środa, 7 listopada 2012

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?

czwartek, 25 października 2012

Element typu Feature

Element type - Feature
Domyślna paleta (toolbox) dla diagramu wymagań zawiera obok podstawowego typu elementu, jakim jest wymaganie (requirement) również typ elementu zwany Feature.

W języku polskim słowo feature jest tłumaczone jako cecha, właściwość, aspekt, akcent. Istnieje nawet spolszczona wersja tego słowa: "ficzer". W związku z tym rzadko element tego typu jest stosowany w modelowaniu w narzędziu Enterprise Architect. Analityk dochodzi często do wniosku, że nie ma potrzeby zajmować się jakimiś "ficzerami", podczas gdy powinien skupić się na podstawowych kwestiach. W dodatku podstawowe metodyki zarządzania wymaganiami nie wspominają o pojęciu Feature.

Mimo to, chciałbym pokazać, że zastosowanie tego elementu jest zgoła inne niż to się wydaje na pierwszy rzut oka.A element Feature może on być bardzo przydatny na przykład na wczesnym etapie zarządzania wymaganiami, czyli w procesie gromadzenia / wydobywania wymagań (requirement elicitation) oraz analizy wymagań, gdy nie nie zostały jeszcze zidentyfikowane przypadki użycia.


wtorek, 23 października 2012

Enterprise Architect 10 - wersja beta 1

Sparx Systems opublikował ostatnio nową wersję programu Enterprise Architect. Po wersji 9.3 nadchodzi wersja 10.0. Obecnie pierwsza wersja beta jest możliwa do pobrania dla zarejestrowanych użytkowników pod adresem: www.sparxsystems.com/securedownloads/beta/ea10/EA100_Reg.exe.


Możemy oczekiwać, że już niedługo będziemy w stanie korzystać z nowych usprawnień i funkcjonalności.
Najważniejsze ze zmian dotyczą:
  • Przebudowa zawartości menu i paneli na bardziej intuicyjną.
  • Zmiana wersji MDG Technology SysML na 1.3.
  • Dodanie MDG Technology GML (Geography Markup Language).
  • W przypadku wielu typów elementów przedziały (compartments) zawierające np. tagged values, constraints itp. mogą się nie pojawiać, jeśli brak atrybutów do wyświetlenia w takim przedziale.
  • Nowe możliwości dotyczące macierzy (Matrix Relationship) - wprowadzenie tzw. textual overlays. Dzięki nim możliwe jest w końcu stworzenie macierzy uprawnień CRUD (create, read, update, delete). 
  • Wprowadzono nowy typ tagged value o nazwie MatrixOverlay - wartości tych tagów mogą być wyświetlane w komórkach macierzy.
  • Usprawnienie korzystania z wyników wyszukiwania (Model Search) - znaleziony obiekt może być przeciągnięty wprost na diagram.
  • Nareszcie wprowadzono wsparcie przy tworzeniu MDG Technology. Można będzie zaoszczędzić wiele czasu na debugging dzięki wprowadzeniu szablonu (package structure) z wzajemnie powiązanym profilem UML, toolboxem i diagramem.
  • Wprowadzono możliwość debugowania skryptów JScript, VBScript i JavaScript. Będzie możliwość wstawiania breakpointów i śledzenia wykonania skryptu.
  • Wywołanie skryptów będzie kontekstowe, to znaczy, że skrypty będą dostępne w menu kontekstowym przypisanym do właściwego typu (pakiet, element, diagram).
  • Raporty RTF - dodano możliwość wołania zewnętrznych szablonów. Jestem bardzo ciekawy co to oznacza w praktyce.
  • Poprawiono wydajność repozytorium na bazie Oracle - mam nadzieję, że skorzystano również z wyników mojego dochodzenia w tym zakresie przesłanych w formie ticketu.
Poza tym ogłoszono wiele innych usprawnień i poprawek.
Pełną informację o tym wydaniu można znaleźć tutaj: www.sparxsystems.com/products/ea/10/beta/index.html.

poniedziałek, 22 października 2012

Szablony projektowe - Template Package

Jeśli tworząc model w Enterprise Architect borykasz się z uciążliwym ustawianiem tych samych opcji dla nowych diagramów i elementów, to zapoznaj się z funkcją programu Project Template Package.
Jako przykład wyobraźmy sobie, że jako analityk wprowadzasz do modelu nowe wymagania. Wymagania te są podzielone na różne kategorie (np. wymagania biznesowe, wymagania funkcjonalne, wymagania niefunkcjonalne) oraz obszary funkcjonalne (takie jak: wprowadzanie danych, realizacja zamówienia, raportowanie, administracja itp.). Każdej kategorii oraz obszarowi odpowiada określony pakiet w drzewie modelu wymagań.
W związku z tym Twoje zadanie jako analityka polega na:
  • utworzenie w każdym z pakietów diagramu typu Requirements,
  • na diagramie powinna być prezentowana legenda jako Diagram details (patrz Wersjonowanie diagramów),
  • na diagramie powinny być prezentowane wartości tagged values elementów,
  • utworzenie w każdej kategorii i obszarze zestawu wymagań odpowiadających potrzebom klienta,
  • status każdego wymagania powinien mieć wartość 'Zidentyfikowany' zamiast domyślnej wartości 'Proposed',
  • każde wymaganie na diagramie powinno mieć taką szerokość, aby poprawić czytelność opisu wymagania - czyli powinno być znacznie szersze niż standardowy kształt,
  • każde wymaganie powinno mieć tę samą szerokość na diagramie.

Problem

Realizacja tych zadań oprócz wysiłku merytorycznego polegającego na poprawnym formułowaniu treści wymagań wymaga również zmiany określonych ustawień.
Dla każdego diagramu należy w oknie Properties:
  • ustawić opcję Diagram -> Show Diagram Details,
  • ustawić opcję Elements -> Show Compartments -> Tags.
Dla każdego wymagania należy w oknie Properties:
  • ustawić wartość pola Status na Zidentyfikowany;
  • rozciągnąć element na diagramie do wymaganej szerokości.

niedziela, 21 października 2012

Import wymagań z MS Excel

W artykule Import wymagań z MS Word opisałem prostą metodę usprawniającą kopiowanie treści z edytora tekstu. Zasugerowałem, że można to wykorzystać do importu wymagań. Zaznaczyłem, że ta metoda jest przydatna, gdy dysponujemy bardzo ograniczonym czasem na wykonanie zadania. Jeśli jednak stać nas na solidne przygotowanie warsztatu pracy, spróbujmy wykorzystać VBA (Visual Basic for Applications) w MS Excel i opracujmy swój własny importer wymagań.
Zacznijmy jednak od początku...

Dlaczego mowa o imporcie wymagań?

Dlaczego mechanizmy importu zawężam tylko do wymagań, podczas gdy mechanizmy te są uniwersalne i umożliwiają importowanie elementów dowolnego typu?
Rzeczywiście można importować rozmaitego rodzaju treść do Enterprise Architect. Ja sam importowałem np. przypadki testowe, procesy biznesowe, komponenty aplikacyjne czy też urządzenia. Z punktu widzenia swojej praktyki w wielu projektach zauważam, że najczęściej potrzebny jest jednak właśnie import wymagań.
Wynika to z tego, że zanim wymagania zostaną udokumentowane, konieczne jest ustalenie ich zakresu. Treść wymagań ustala się wraz z klientem podczas spotkań lub poprzez wymianę uwag i odpowiadanie na uwagi w formie pisemnej.
Nie wyobrażam sobie, aby użytkownik z działu merytorycznego korzystał z repozytorium w narzędziu Enterprise Architect do przeglądania i czytania propozycji wymagań. Podobnie nie wyobrażam sobie edycji treści wymagań na spotkaniu bezpośrednio w Enterprise Architect.
Uważam, że do wymiany informacji z klientem, zwłaszcza z użytkownikiem merytorycznym powinny służyć dokumenty w formacie MS Word i MS Excel, gdyż są osoby merytoryczne czują się swobodnie korzystając z tych programów. W takim układzie potrzebne są mechanizmy zarówno do importu treści do modelu Enterprise Architect, jak i mechanizmy eksportu (np. raportowanie), dzięki którym będziemy w stanie "przerzucić" treści w drugą stronę.


sobota, 20 października 2012

Konektory rysowane linią krzywą

Powiązania (connectors) pomiędzy elementami mogą być prezentowane na diagramie przy użyciu różnych styli. Najczęściej stosowane style to: Custom, Direct oraz Auto Routing. Nie każdy jednak wie, że to nie wszystkie dostępne style dla powiązań. Konektory mogą być też rysowane linią krzywą.
Najpierw poświęcę trochę miejsca na opisanie standardowo dostępnych styli linii powiazań, a w dalszej części pokażę jak uzyskać linię krzywą.


piątek, 31 sierpnia 2012

Kolorowanie według stereotypów

Elementy na diagramach mogą być prezentowane przy użyciu różnych kolorów wypełnienia. Notacja UML, jak również inne notacje nie stawiają ograniczeń w tym zakresie. Narzędzie Sparx Enterprise Architect umożliwia umożliwia swobodną zmianę stylu wyświetlania elementu.

Najbardziej wygodnym sposobem na zmianę tego stylu jest zaznaczenie wybranego elementu, a następnie kliknięcie na ikonę pędzelka, która pojawia się z prawej strony zaznaczonego elementu. Wyświetlone zostaje wówczas podręczne menu, przy pomocy którego możliwa jest zmiana czcionki, koloru czcionki, kolor wypełnienia oraz kolor i grubości linii obramowania.
Element - zmiana stylu wyświetlania na diagramie
Najczęściej zmienianą opcją jest kolor wypełnienia elementu, gdyż za jego pomocą można rozszerzyć zakres informacyjny diagramu. Zastosowanie kilku różnych kolorów w odniesieniu do różnych elementów pozwala na wprowadzenie dodatkowego ich rozróżnienia na różne kategorie. Można w ten sposób na przykład wprowadzić kategorie przypadków użycia:
  • biznesowe przypadki użycia,
  • systemowe przypadki użycia,
  • kluczowe przypadki użycia,
  • pomocnicze przypadki użycia,
  • itp.
Klasy UML można kategoryzować jako:
  • klasy biznesowe,
  • typy danych,
  • klasy abstrakcyjne,
  • itp.
 A jeśli już mowa o rozróżnianiu różnych kategorii elementów, to warto się zastanowić nad zastosowaniem stereotypów. Każdemu elementowi dowolnego typu może zostać przypisany określony stereotyp. Zmianę tę dokonujemy w oknie Properties elementu.
Element properties - stereotypes list

Co to stereotyp? 

Stereotyp pozwala rozszerzyć semantykę modelu. Jest mechanizmem wspieranym przez notację UML w odniesieniu do jakiejś grupy służącym do rozszerzenia lub zmodyfikowania:
  • znaczenia,
  • sposobu wyświetlania,
  • bądź ich składni (atrybutów, możliwych powiązań itp.).
Stereotypy można stosować do elementów (czyli wszelkiego rodzaju obiektów, na przykład klasa czy przypadek użycia), powiązań (takich jak Dependency czy Association), atrybutów, metod oraz kilku innych pojęć. Stereotypy stanowią również podstawę do budowania profili UML. W pewnym uproszczeniu można przyjąć, że na samej górze jest zdefiniowana Metaclass (na przykład Class w notacji UML), owa metaklasa może być uszczegółowiona poprzez stereotyp (np. <<biznes>>), następnie tworzona jest klasa (np. Ocena). A idąc jeszcze dalej, np. na potrzeby diagramów interakcji mogą być tworzone obiekty danej klasy (<nazwa_obiektu>:Ocena).

Zastosowanie stereotypów do kolorowania

No dobrze, wiemy już czym jest stereotyp. Widać z tego, że idealnie nadaje się ten mechanizm do zmiany wyglądu elementów opatrzonych stereotypem.
W Enterprise Architect można stosować predefiniowane stereotypy, jak również samodzielnie definiować dowolne stereotypy, które spełniają wymagania projektowe.
Aby zdefiniować stereotyp wystarczy w oknie Properties elementu, w polu Stereotype wpisać określoną wartość, zamiast wybierać już istniejącą z listy rozwijalnej. Po wpisaniu na przykład polskiej nazwy "biznes", element taki zostaje opatrzony stereotypem <<biznes>>, a ów nowy stereotyp można odnaleźć w oknie Settings --> UML Types w zakładce Stereotypes.
UML Types - Stereotypes list

Po wybraniu z listy stereotypu w sekcji Default Colors możemy zdefiniować dla niego specyficzny sposób wyświetlania elementów opatrzonych tym stereotypem. W tym przykładzie dla stereotypu <<biznes>> przypiszemy kolor wypełnienia (Fill): żółty. Zmianę zatwierdzamy przyciskiem Save.

Efektem tego będzie automatycznie pokolorowanie we wszystkich diagramach wszystkich elementów opatrzonych stereotypem <<biznes>> kolorem żółtym. Jeśli usuniemy z właściwości elementu wartość stereotypu lub zastąpimy innym stereotypem, wówczas kolor żółty zostanie zastąpiony domyślnym kolorem wypełnienia.
Ponadto, każda zmiana domyślnego koloru wypełnienia w definicji stereotypu (np. z koloru żółtego na amarantowy) spowoduje automatyczną ponownie automatyczną zmianę we wszystkich diagramach.
przykład diagramu klas z kolorowaniem wg steretoypów

Podsumowanie

Dzięki zastosowaniu kolorowania według stereotypów możliwa jest automatyczna zmiana sposobu wyświetlania elementów na diagramach w zależności od ich rodzaju. Sposób ten przyspiesza pracę nad diagramami, gdyż projektant nie jest zmuszony do ręcznej zmiany kolorów, wystarczy że skupi się na poprawnym przypisaniu stereotypów, a dodatkowo konieczność zmiany kolorów dla wielu elementów wymaga tylko kilku kliknięć myszą. Poprawia się również czytelność diagramów, gdyż już na pierwszy rzut oka łatwo się zorientować w kategoriach prezentowanych elementów. Ponadto automatyczne kolorowanie według stereotypów ułatwia zachowanie spójności w modelu, gdyż każda zmiana wartości stereotypu skutkuje zmianą koloru.
Skupiłem się w tym artykule na oznaczaniu elementów poprzez zastosowanie różnych kolorów wypełnień, ale ta sama zasada stosuje się również do koloru czcionki i obramowania.
Zaawansowaną metodą wyróżniania elementów w zależności od stereotypu jest zastosowanie mechanizmu Shape Script, dzięki któremu można całkowicie zmienić kształt elementu.