Własny zestaw statusów

Każdy element w modelu posiada swój własny zestaw atrybutów. Wśród standardowych atrybutów znaleźć można trzy, które służą określeniu momentu w cyklu życia elementu. Są to:

• status,
• wersja,
• faza.

Domyślnie, w standardowej konfiguracji każdy nowo utworzony element otrzymuje status: Proposed, wersję: 1.0 oraz fazę: 1.0. Na początku najczęściej użytkownicy EA skupiają się na tym, aby opracować jak najlepsze diagramy, które wiernie odzwierciedlają specyfikę projektowanego przedsięwzięcia i są w miarę zgodne z notacją. Później zaczynają dbać o to, żeby nie tworzyć duplikatów tych samych elementów, tzn. na wielu diagramach umieszczać ten sam element, a nie jego kopię. Jeszcze później użytkownicy zaczynają się zastanawiać nad cyklem życia takich elementów, bo przecież projektowany system w którymś momencie wchodzi w fazę utrzymania i konieczne staje się ogarnięcie różnych stanów modyfikacji, faz wdrożenia, czy wydań.



Wartości określające wersję i fazę można wpisać dowolne, zaś pole Status przyjmuje wartości z listy rozwijalnej. Możliwe wartości pola Status w standardowej konfiguracji to:

• Proposed - Item has been proposed,
• Approved - Item is approved,
• Validated - Approved and checked,
• Implemented - Finished,
• Mandatory - Required.

Jakby się zastanowić bliżej nad tymi możliwymi wartościami statusów, to możemy łatwo dojść do wniosku, że lista ta nie jest doskonała. Bo brakuje chociażby statusu Rejected (Odrzucony), a przecież jeśli klient nie zgodzi się na jakieś rozwiązanie lub zrezygnuje z wymagania, to warto taką informację zachować w modelu i odpowiednio ją oznaczyć, aby osoby niezorientowane nie spodziewały się, że coś takiego zostanie zaimplementowane. A jeśli mamy status Mandatory (Obowiązkowy), to gdzie status Optional (Opcjonalny)? A jak oznaczyć, że dany element jest jednocześnie Approved i Mandatory?
A zatem powyższej listy nie można uznać za wzorcową, a raczej jako punkt wyjścia do stworzenia własnego słownika statusów.

Opracowanie własnego zestawu

Na szczęście lista możliwych statusów podlega modyfikacji. Aby się do tego zabrać polecam najpierw zorganizować spotkanie projektowe, na którym zostanie omówiony temat własnego zestawu statusów. Najlepiej omówić to jeszcze przed rozpoczęciem modelowania w EA.
Poniższy został przedstawiony przykładowy zestaw statusów w formie diagramu stanów.

Diagram stanów - Własny zestaw statusów

Zobrazowanie możliwych wartości statusów oraz możliwych przejść między statusami w formie diagramu stanów ułatwia wykrycie wszystkich możliwych sytuacji, które są charakterystyczne dla danego projektu.
Podczas szkolenia zazwyczaj pojawia się w tym momencie pytanie:

A czy EA sam może dbać o walidację zmian statusów lub sam odpowiednio zmieniać wartości statusów?

Odpowiedź nie jest prosta. Bo Enterprise Architect sam nie potrafi zmieniać wartości statusów, ale możliwe jest zaimplementowanie odpowiedniego skryptu typu Workflow, który np. w przypadku próby zmiany statusu z Zatwierdzone na Zidentyfikowane wyrzuci komunikat użytkownikowi, mówiący o tym, że "Przyjęte reguły projektowe nie zezwalają na taką zmianę", albo który umożliwi nadanie statusu Zatwierdzone lub Odrzucone tylko użytkownikowi należącemu do grupy Kierownicy projektu. Owszem, jest to możliwe, ale konieczne? Sądzę, że w zdecydowanej większości przypadków wystarczy tego typu reguły wprowadzić organizacyjnie, bez wykorzystywania zaawansowanych mechanizmów.

Po dokonaniu niezbędnych ustaleń można przystąpić do wdrożenia owej projektowej listy statusów w EA. Z menu Settings --> Project Types --> General Types otwieramy okno:

Okno General Types - Lista statusów

W zakładce Status widoczna jest lista statusów, z której możemy usunąć wszystkie wartości.

Proposed - status specjalny

Ewentualnie można zastanowić się nad Proposed. Dlaczego? Bo, gdy usuniemy Proposed i samodzielnie nie nadamy statusu elementowi, wówczas taki element nie będzie miał określonego statusu. O ile jest to świadoma decyzja, to można tak zrobić. A jakie konsekwencje może mieć usunięcie statusu Proposed? Jeśli decydujemy się na określanie momentu cyklu życia elementu, to raczej po to, żeby móc później na przykład filtrować elementy o określonym statusie. Po usunięciu wartości Proposed należy pamiętać, aby w warunkach wyszukiwania uwzględniać również możliwą wartość null.
W artykule Szablony projektowe - Template package można znaleźć opis metody na tworzenie nowych elementów ze statusem innym niż domyślny - Proposed.

Wprowadzenie własnych statusów

Po usunięciu domyślnej listy można przystąpić do wprowadzania swoich własnych wartości. Dodatkową zaletą własnej listy jest to, że mogą to być polskie nazwy. Jeśli planujemy generować dokumentację w języku polskim warto unikać mieszanki polsko-angielskiej.
A zatem wprowadzamy nazwę w polu Status, opis w polu Description (bez wypełnienia tego pola zapis nie jest możliwy) oraz wybieramy kolor (Status Type Color) i naciskamy przycisk Save.

Kolorowanie wg statusów

Prezentowanie wartości statusów w formie kolorów na diagramie stanowi dużą wartość dodaną, gdyż zwiększa zawartość informacyjną diagramów. Kolorowaniu nie podlega wypełnienie lub obramowanie elementu, lecz pasek z lewej strony - w przypadku wymagań lub dodawany jest jakby "kolorowy cień" - w przypadku pozostałych elementów. Cienie te najlepiej widać na zamieszczonym powyżej diagramie stanów. Dodatkowo korzystając ze standardowej funkcjonalności EA można na diagramie umieścić legendę wyjaśniającą znaczenie tych kolorów.
Ale, aby kolorowanie według statusów było widoczne konieczne jest:

• ustawienie opcji na stacji roboczej,
• zaznaczenie danego typu elementu do kolorowania.

Opcja w ustawieniach lokalnych pokazana jest na poniższym rysunku, czyli Show status colors on diagrams:

 

A typy elementów do kolorowania wybieramy korzystając z przycisku Applies to... w oknie General Types.

Na tym rysunku widać, że oprócz wymagań (Requirement) zaznaczone są również stany (State) niezbędne do wyświetlenia kolorowych cieni statusów na diagramie stanów.

Aha, lista statusów, podobnie jak pozostałe General Types nie są rozszerzane przez mechanizm MDG, w związku z tym dystrybucja ich wśród wszystkich członków zespołu projektowego w przypadku korzystania z plików EAP może się odbywać tylko poprzez mechanizm Export/Import Reference Data.