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.


wtorek, 21 sierpnia 2012

Polski słownik w Enterprise Architect

Program Sparx Enterprise Architect dzięki modułowi do generowania raportów może posłużyć za narzędzie do opracowania kompleksowej dokumentacji projektowej. Przy użyciu możliwości generowania raportów RTF można tworzyć dokumentację wprost w Enterprise Architect zamiast przy użyciu MS Word lub Open Office. Takie rozwiązanie w warunkach polskich jest niestety obarczone poważną wadą. Enterprise Architect nie został wyposażony w polski słownik do sprawdzania poprawności pisowni.
Na forum Sparxa pojawiają się prośby o dodanie polskiego słownika do programu. Ja długo żyłem nadzieją, że producent zlituje się nad polskimi użytkownikami, bo mam wrażenie, że program Sparx Enterprise Architect cieszy się w Polsce dużą popularnością i już dawno wiedzie prym w kategorii narzędzi typu CASE.
Rozpocząłem własne badanie w jaki sposób możliwe byłoby samodzielne dodanie takiego słownika. Najpierw udało mi się ustalić, że słownik jest zdefiniowany w plikach z rozszerzeniem .clx oraz .tlx. Na przykład słownik dla języka angielskiego (amerykańskiego) znajduje się w plikach ssceam2.clx oraz ssceam.tlx. Pierwszy z tych plików zawiera słownik w wersji skompilowanej, dzięki czemu sprawdzanie pisowni jest znacząco szybsze od sprawdzania w oparciu o plik tekstowy ssceam.tlx.
Sprawdzanie pisowni w oparciu o plik tekstowy .tlx przebiega sprawnie, jeśli ilość słów nie przekracza kilku tysięcy.
Dodatkowo słowa dodawane do słownika przez użytkownika umieszczane są w pliku %AppData%\Roaming\Sparx Systems\EAuserdic.tlx.
Pliki te są obsługiwane przez program WSpell oferowany przez firmę Wintertree software. Zatem Sparx korzysta z silnika Sentry Spelling Checker Engine firmy Wintertree software.

Na stronie producenta znajduje się szczegółowa dokumentacja przeznaczona dla developerów, w której jest opisane dokładnie, w jaki sposób działa ich produkt.
Znalazłem doskonały słownik języka polskiego w formacie .txt pozbawiony jakichkolwiek dodatkowych znaczników, które są wykorzystywane przez alternatywny program do sprawdzania pisowni Aspell. Słownik ten zawiera blisko 120 000 słów (od "AA" do "żyźnie") i sprawdziłby się idealnie jako słownik do sprawdzania pisowni. Przy pomocy programu Gżegżółka przekonwertowałem ten słownik ze strony kodowej Windows 1250 na ISO 8859-2 (Europa Środkowa).
Znalazłem w sieci również program WL2Dic, który umożliwia konwersję z pliku tekstowego do pliku .clx. Program ten działa poprawnie, umożliwia wskazanie pliku źródłowego, pliku docelowego oraz kodu języka. Możliwe jest wybranie kodu dla języka polskiego, jednak w takim przypadku program uprzejmie informuje, że w takim wypadku należy wybrać opcję tworzenia słownika w formacie Unicode.
Cannot create non-unicode dictionary for this language.
Please specify -u switch
Niestety program WL2Dic wykorzystuje wersję biblioteki Sentry Spelling Checker Engine w wersji 5.14.
A niestety Sentry Spelling Checker Engine do wersji 5.14 nie umożliwiał skorzystania z kodowania znaków w ISO-8859-2 (czyli środkowoeuropejski).
Na stronie SSCE Revision History widnieje informacja:
The Sentry engine can now support Unicode through a build option. Currently, this support is limited to the SSCE Source SDK. As part of this support, SSCE can now process single-byte characters from the Latin 1 (ISO-8859-1) character set or Unicode. Character sets ISO-8859-2 through ISO-8859-10 are no longer supported (use Unicode instead). The lexicon-compression API (SSCE_CompressLex*) creates a Latin 1 or Unicode compressed lexicon depending on how the engine was built. The Unicode engine can read both Unicode and Latin 1 compressed lexicons, but the Latin 1 engine cannot read Unicode compressed lexicons.
W historii wersji 5.15 zapisano:
The Sentry engine now supports all ISO-8859 character sets. Two new functions, SSCE_GetCharSet and SSCE_SetCharSet have been defined for this purpose. The default character set is ISO-8859-1, which was the only ISO-8859 character set supported previously. The character set is a "global" setting, meaning a change to the character set affects all sessions. A set of language-id constants for each major language covered by ISO-8859 character sets has been defined.

A w rejestrze systemowym (HKEY_CURRENT_USER\Software\Wintertree\SSCE) dodano klucz CharSet, który służy do zmiany strony kodowej od ISO-8859-1 do ISO-8859-10. Wartość tego klucza mogłaby się zmieniać automatycznie po wyborze polskiego słownika.
Enterprise Architect korzysta z wersji 5.16, która umożliwia teoretycznie obsługę polskiego słownika. Przypuszczam, że przygotować poprawnie działający polski słownik może tylko Sparx Systems lub inna firma, która zakupiła pełną wersję SDK od firmy Wintertree software. Testowa wersja tego SDK pozwala tylko na generowanie słownika zawierającego nie więcej niż 1000 słów.

Istnieje również możliwość skorzystania z kodowania unicode, jednak jest on obsługiwany tylko w przypadku korzystania z  silnika Sentry Spelling Checker Engine dla Javy, a nie dla Windows (czyli w programach napisanych w C/C++, Delphi, Visual Basic, VB.NET, C# lub ASP).

Co zatem można zrobić?

Próbowałem obejść ten problem oszukując moduł sprawdzania pisowni, twierdząc że kompilowany przeze mnie słownik dotyczy języka angielskiego. Plik docelowy o nazwie ssceam2.clx wygenerował się poprawnie i osiągnął wielkość 509 kB. Słownik ten jest poprawnie interpretowany w Enterprise Architect, ale niestety nie w pełnym zakresie. Efekt jest połowiczny - nie są obsługiwane słowa zawierające polskie znaki.
Podobny efekt udało się uzyskać Michałowi Wolskiemu, który udostępnia taki słownik na swojej stronie: http://www.michalwolski.pl/2009/06/sprawdzanie-pisowni-w-enterprise-architect-polski-slownik/
Ja jednak uznałem, że rozwiązanie częściowe mnie nie satysfakcjonuje. Oznaczałoby to, że i tak mniej więcej połowa wyrazów byłaby podkreślana na czerwono.

Podsumowanie

Nie mam dobrych wieści w temacie sprawdzania pisowni w języku polskim w Enterprise Architect. Dopóki Sparx Systems nie zmieni silnika do sprawdzania pisowni niemożliwe jest wykorzystanie słownika języka polskiego.
Obecnie mamy dwie alternatywy:
  • korzystanie ze słownika bez poprawnej obsługi polskich znaków diakrytycznych,
  • wyłączenie opcji sprawdzania pisowni (menu Tools --> Options --> Objects --> Disable spelling).

wtorek, 14 sierpnia 2012

Import wymagań z MS Word

requirement icon
W przypadku, gdy w projekcie podjęto decyzję o zarządzaniu i dokumentowaniu wymagań w oparciu o narzędzie Sparx Enterprise Architect zazwyczaj dochodzi do sytuacji, że zestaw wymagań zostaje wypracowany w jakimś innym narzędziu. Najczęściej wymagania dokumentowane są przy użyciu programu MS Word lub MS Excel.
Jest to naturalna sytuacja, gdyż wymagania są opisywane przy użyciu języka naturalnego oraz zachodzi konieczność łatwego komunikowania ich klientowi. Poprawki w treści wymagań często są nanoszone w trakcie spotkań z klientem, bądź przesyłane pocztą elektroniczną. Zastosowanie do tego celu programu MS Word wydaje się najlepszym rozwiązaniem, zwłaszcza gdy w grę wchodzi wykorzystanie trybu rejestracji zmian w MS Word.
Problem zaczyna się, gdy uzgodnioną już treść wymagań należy przenieść do Enterprise Architecta. Gdy wymagań jest niewiele, możliwe jest ich manualne przekopiowanie, jednak w złożonym projekcie wymagań bywa ich kilkaset lub kilka tysięcy. W dodatku w praktyce czas na stworzenie rejestru wymagań w modelu Enterprise Architecta jest bardzo ograniczony, gdyż ważniejszym zadaniem jest zapewnienie określonej wartości merytorycznej artefaktów, niż ich forma.
W niniejszym artykule opisane zostało ułatwienie w przenoszeniu treści wymagań z MS Word. Już na początku chcę wyraźnie zaznaczyć, że nie jest to preferowana przeze mnie metoda. Jeśli to jest możliwe, to zalecam importowanie wymagań przy wykorzystaniu makra w Visual Basicu w programie MS Excel. Opiszę tę metodę przy innej okazji.
Wracając do importu wymagań z MS Word, jej największą zaletą jest prostota. Poza tym nie jest potrzebne opracowywanie jakiegokolwiek narzędzia czy interfejsu do MS Office.

poniedziałek, 13 sierpnia 2012

Orientacja w powiązaniach na diagramie

UML Class diagram
Istnieją zalecenia dotyczące tworzenia diagramów mówiące o tym, że dobry diagram nie powinien zawierać zbyt dużej ilości elementów i powinien najlepiej mieścić w czytelnej postaci na jednej stronie formatu A4.
W praktyce okazuje się, że istnieje wiele sytuacji, gdy nie można być w zgodzie z takim zaleceniem. Projektanci tworzą diagramy zawierające dużą ilość elementów i powiązań pomiędzy tymi elementami.
Osoba, która próbuje się zorientować w zawartości skomplikowanego diagramu po jego otwarciu robi najpierw większe oczy, nabiera głęboko powietrza, a na usta jej cisną się słowa przywołania istoty najwyższej ewentualnie nazwy najstarszego zawodu świata...

Okazuje się, że Sparx, producent programu Enterprise Architect wprowadził w tym zakresie udogodnienie.
Otóż, jeśli wskażemy na diagramie, czyli klikniemy na jakiś element, a następnie naciśniemy na klawiaturze klawisz L, wówczas wszystkie powiązania (connectors) którymi jest ten element powiązany z innymi elementami na diagramie zostaną pokolorowane. Widoczne to jest na poniższym rysunku.
orientacja w linkach na diagramie Enterprise Architect
Kolorowanie linków po naciśnięciu klawisza L
Kolorem zielonym oznaczone są wszystkie powiązania wychodzące od tego elementu, czyli te, dla których wybrany element jest źródłem (source element).
Kolorem czerwonym oznaczone są wszystkie powiązania przychodzące do tego elementu, czyli te, dla których wybrany element jest elementem docelowym (target element).
Kolorem żółtym oznaczone są wszystkie powiązania wskazujące na siebie, czyli te, dla których wybrany element jest zarówno elementem źródłowym i docelowym.

Proste, prawda? Aby lepiej to zapamiętać, warto skojarzyć nazwę klawisza L ze słowem Link. Jeszcze prościej by było, gdyby ten skrót klawiaturowy nie był tak ukryty przed użytkownikami.

piątek, 10 sierpnia 2012

Jak zdjąć blokadę z pakietu z kontrolą wersji?

W przypadku, gdy w repozytorium jest włączona kontrola wersji w oparciu o SVN lub inny system kontroli wersji może dojść do sytuacji, gdy ktoś zablokował dla siebie możliwość edycji zawartości pakietu (funkcja check-out), a my potrzebujemy pilnie otrzymać uprawnienia do modyfikacji jego zawartości i nie możemy czekać aż ten zapominalski wróci do pracy z urlopu lub ze spotkania z klientem.
Tylko co zrobić? Program Enterprise Architect uparcie zwraca nam informację, że pakiet ten jest zablokowany do edycji wyświetlając komunikat o treści: The selected package cannot be checked-out at this time. The associated XMI package file is already checked-out.

czwartek, 9 sierpnia 2012

Warunki początkowe i końcowe przypadku użycia

W ostatnim czasie w biurze miała miejsce krótka dyskusja dotycząca warunków początkowych (pre-condition) i końcowych (post-condition) przypadku użycia. W wielu projektach w ciągu ostatnich lat opisywaliśmy przypadki użycia i w każdym przypadku wszyscy wiedzieli w jaki sposób formułować warunki początkowe i końcowe. Niespodziewanie dyskusja została wywołana przez analityków z jednej z firm z którą współpracujemy. Dyskusja ta świadczy o tym, że warto dokładnie opisać wszelkie zasady, które na pierwszy rzut oka wydają się oczywiste.


środa, 8 sierpnia 2012

Cykl życia elementu

Inżynieria oprogramowania traktuje oprogramowanie jako produkt, który ma spełniać określone potrzeby głównie w aspektach technicznych i ekonomicznych. Definiuje w tym kontekście pojęcie cyklu życia oprogramowania oraz skupia się na narzędziach wspierających proces wytwarzania i utrzymania oprogramowania we wszystkich fazach życia produktu.





Podstawowe fazy cyklu życia, które przewijają się w różnych modelach cyklu życia to:
  • Analiza (bądź specyfikacja produktu) - określenie i ustalenie wymagań,
  • Projektowanie - ustalenie ogólnej architektury systemu,
  • Implementacja - realizacja ustalonej architektury, czyli implementacja elementów składowych i ich połączenie,
  • Integracja (bądź testowanie) - zintegrowanie poszczególnych elementów składowych w jeden systemu oraz testowanie całości rozwiązania,
  • Wdrożenie - uruchomienie produkcyjne systemu,
  • Utrzymanie systemu - usuwanie błędów produkcyjnych oraz rozwój systemu.
Enterprise Architect jest jednym z takich narzędzi wspierających. Element w EA posiada również zestaw atrybutów, który służy do określenia momentu w życia produktu. Są to:
Ponadto dużym ułatwieniem w zarządzaniu informacjami o cyklu życiu jest możliwość grupowej aktualizacji informacji, patrz: Cykl życia elementów - grupowa aktualizacja.
Zatem wskazane jest, aby ogólnie przyjęte zasady w stosowanych metodykach wytwarzania oprogramowania związane z cyklem życia produktu zastosować również w Enterprise Architect, który wspiera wytwarzanie oprogramowania. Sparx, producent Enterprise Architect nie narzuca jednak w tej kwestii żadnych reguł i daje swobodę użytkownikom. Ja osobiście określiłbym to następującym oksymoronem: "zaleta granicząca z wadą". Swoboda w definiowaniu reguł dotyczących wersjonowaniu skutkuje brakiem reguł w projekcie.
Zazwyczaj natłok zadań projektowych i napięte terminy skutkują tym, że wytworzony model jest najlepszy, jaki udało się stworzyć w ograniczonym czasie - czyli innymi słowy - daleki od doskonałości.

W tym celu zasadne wydaje się wprowadzenie projektowych zasad wersjonowania. Nie sposób sformułować uniwersalnych zasad w tej kwestii, gdyż każdy projekt jest określany jako specyficzny i posiada swoiste potrzeby i ograniczenia. W tym miejscu możliwe jest tylko wymienienie określonych przesłanek, które należy rozważyć już na etapie startu projektu. Są to:
  • wyszukiwanie określonych elementów w modelu w zależności od ich wersji, etapu projektu i statusu,
  • filtrowanie zawartości generowanej dokumentacji w zależności od wersji, etapu projektu i statusu,
  • zakres danych niezbędny do wypełnienia wymagań dotyczących dokumentacji,
  • raportowanie zmian w modelu w perspektywie czasowej (w przedziale czasu)  lub projektowej (w ramach określonej modyfikacji),
  • zastosowanie mechanizmu Diagram Filters, np. do zobrazowania różnic pomiędzy stanem bazowym (AS-IS) oraz stanem docelowym (TO-BE),
  • utrzymywanie i rozwój modelu przedsięwzięcia w dłuższej perspektywie czasu,
  • unifikacja zasad wersjonowania produktów i artefaktów tworzonych bez użycia Enterprise Architecta, 
  • potrzeba przesyłania całego modelu lub jego części pomiędzy różnymi osobami, które mogą nanosić zmiany w modelu, w sytuacji, gdy nie jest wykorzystywane współdzielone repozytorium,
  • potrzeba wykorzystania mechanizmów typu Workflow do implementacji zasad projektowych,
  • organizacja zawartości modelu w hierarchii pakietów,
  • ograniczony czas na opracowanie modelu,
  • brak możliwości wpływania na zakres wprowadzanych modeli przez członków zespołu pochodzących z innych organizacji.

poniedziałek, 6 sierpnia 2012

Forum Sparx - nowa tendencja

W momentach, kiedy w pracy mam spokojniejsze chwile, a wszystkie pilne zadania zostały wykonane, wówczas staram się wykorzystać czas do tego, żeby się czegoś nowego dowiedzieć. W takich chwilach odwiedzam forum Sparx i czytam zamieszczone posty, bo - a nuż ktoś odkrył coś ciekawego i postanowił się tym podzielić z innymi.
Zauważyłem przy okazji, że to forum coraz częściej zaczyna służyć jako miejsce do reklamowania swoich własnych produktów związanych z Enterprise Architectem, takich jak ebooki, czy add-ins (pluginy).
Ktoś zadaje na przykład pytanie dotyczące tego, w jaki sposób na raporcie RTF umieścić coś tam, w odpowiedzi otrzymuje tylko informacje: sprawdź mój produkt, który służy do generowania raportów z EA, on z pewnością rozwiąże Twój problem.
Albo ktoś pyta, jak napisać skrypt, który ma coś zrobić, bo mu nie wychodzi, wówczas dostaje odpowiedź: sprawdź mojego ebooka, któy traktuje o pisaniu skryptów w EA.
Czytając tego typu odpowiedzi mam wrażenie, że osoby, które się reklamują nawet nie tracą czasu na wczytywanie się w istotę problemu i nie wnikają, czy rzeczywiście ich produkt potrafi rozwiązać opisany problem.
Chyba idea forum jest nieco inna... Ludzie korzystają z forum z przeświadczeniem, że znajdzie się jakaś dobra dusza, która bezinteresownie wskaże sposób rozwiązania problemu. A dobra dusza pomaga, bo myśli, że gdy sama będzie miała jakiś problem, to znajdzie się ktoś inny, kto jej również pomoże. A tu taka komercjalizacja...
Podobnie zresztą wygląda sytuacja z Community community.sparxsystems.com. Pojawia się tam coraz więcej artykułów reklamowych. Czyli ludzie, którzy chcą zarobić na popularności EA otrzymali do dyspozycji darmową formę reklamy.
Ale może ja się po prostu czepiam?

sobota, 4 sierpnia 2012

Wersjonowanie diagramów

wersjonowanie diagramówOpisałem dotychczas kwestię wersjonowania elementów i pakietów oraz metody automatycznej aktualizacji wartości wersji. W tym artykule poruszę kwestię wersjonowania diagramów.

W jakim celu wersjonować diagramy?

Każdy diagram w momencie jego utworzenia otrzymuje domyślną wartość atrybutu Version, zapisywana jest również data jego utworzenia i ostatniej modyfikacji. Rzadko zdarza się, aby raz utworzony diagram był od razu doskonały i nie wymagał wprowadzenia modyfikacji. Tworzone modele stanowią część dokumentacji projektowej, a ta dokumentacja również podlega zmianom. W fazie wytwarzania modeli powszechne jest przesyłanie diagramów pomiędzy członkami zespołu projektowego oraz pomiędzy wykonawcą a klientem w celu zgłaszania uwag i poprawianiu ich jakości. Informacja o wersji i dacie modyfikacji diagramu zamieszczona wprost na diagramie znacząco ułatwia zorientowanie się, czy mamy do czynienia z aktualną wersją.

piątek, 3 sierpnia 2012

Brak polskich znaków - rozwiązanie

Jeśli otwierasz na swojej stacji roboczej plik .eap i zamiast polskich znaków diakrytycznych widzisz krzaczki - ten post zawiera rozwiązanie Twojego problemu.
Najgorsze jest to, że jak sam wstawisz dowolny polski znak, wówczas jest on wyświetlany poprawnie, ale przecież nie będziesz zmieniać w tych wszystkich miejscach polskich znaków!
Plik .eap jest w porządku, tylko Twoja stacja robocza wymaga niewielkiej zmiany konfiguracyjnej.

czwartek, 2 sierpnia 2012

Wersjonowanie elementów

wersjonowanie elementów w Enterprise Architect
Enterprise Architect został zaprojektowany w taki sposób, aby możliwe było określenie wersji dowolnego typu elementu, np. wymagania, przypadku użycia, komponentu, klasy czy obiektu.

Wersjonowaniu mogą podlegać na tej samej zasadzie również pakiety i diagramy.
W przypadku tworzenia modelu na zasadzie ad-hoc, czyli gdy tworzymy model "jednorazowego użytku" w odniesieniu do krótkotrwałego projektu można pominąć zagadnienie wersjonowania. Jednak ten temat staje się istotny, gdy model:
  • dotyczy długiego projektu (dłuższego niż 3 miesiące),
  • w grę wchodzi utrzymanie projektowanego systemu po jego wdrożeniu,
  • zakłada się potrzebę generowania i aktualizowania dokumentacji,
  • w projekt jest zaangażowany duży zespół.
W przypadku spełnienia choćby niektórych z powyższych kryteriów już w momencie startu projektu, na etapie definiowania projektowych zasad modelowania należy poczynić ustalenia w kwestii wersjonowania. Zalecane jest, aby zasady wersjonowania w Enterprise Architect były spójne z zasadami wersjonowania wszystkich produktów (artefaktów wchodzących w skład deliverables, lub będących deliverables) projektu. Trzymanie się tej zasady pozwala na spójne zarządzanie konfiguracją (configuration management) oraz na odzwierciedlenie w modelu określonego momentu w cyklu życia projektu.

środa, 1 sierpnia 2012

Do czego może służyć wysyłanie maili w Enterprise Architect?

Enterprise Architect od wersji 9.0 wraz z wieloma innymi nowinkami został wyposażony w funkcjonalność usprawniającą komunikację między członkami zespołu projektowego. Funkcja ta została nazwana Internal Mail i polega w skrócie na możliwości wymiany korespondencji mailowej między użytkownikami modelu.
Można odnieść pierwsze wrażenie, że to niepotrzebne wymyślanie koła na nowo. Przecież zespół projektowy na ogół i tak korzysta z jakiegoś systemu pocztowego.
No dobrze, ale przyjrzyjmy się tej funkcjonalności bliżej.