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.

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:

• wersja (patrz: Wersjonowanie elementów),
• faza,
• status (patrz: Własny zestaw statusów).

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.

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?

Wersjonowanie diagramów

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

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.

Wersjonowanie elementów

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.

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.