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

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.

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.

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

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

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.

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.

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.

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.

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.

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