WPROWADZENIE

Analiza odpowiedzialności jest techniką służącą w metodyce OMNIS do opisu przebiegów przypadków użycia. Technika ta jest próbą znalezienia złotego środka pomiędzy tekstowym opisem przebiegu a już mocno technicznym opisem z wykorystaniem diagramów sekwencji. Prawie 15 lat doświadczeń z wykorzystywaniem techniki pozwalają nam stwierdzić, iż technika może być skutecznie i efektywnie stosowana w projektach.

Diagramem wykorzystywanym do prowadzenia analizy odpowiedzialności jest, budowany według określonych zasad, diagram aktywności języka UML (powiązany jako poddiagram ze specyfikowanym przypadkiem użycia). Diagram dzielony jest na partycje odpowiadające odpowiednio: działaniom aktora, usługom warstwy prezentacji oraz usługom warstwy logiki systemu. Założony poziom szczegółowości opisu ustalają przyjęte zasady definicji poszczególnych działań/akcji jako atomowych kroków algorytmu przebiegu modelowanej funkcjonalności. Działania, za realizację których odpowiedzialny jest aktor to m. in. akcje wprowadzania/modyfikacji danych, wyboru obiektu do dalszego przetwarzania, wyboru opcji czy potwierdzenia decyzji. Działania uwzględnione w partycji warstwy prezentacji to akcje związane z wizualizacją elementów interfejsu użytkownika prezentujących dane i informacje, umożliwiających edycję danych, wybór obiektów czy opcji. Zgrupowane w warstwie logiki działania są związane z realizacją logiki biznesowej systemu, są to m in. akcje odczytu i zapisu danych trwałych, weryfikacji poprawności przetwarzanych danych, transformacji danych czy wywoływania usług zewnętrznych.

Przebieg realizacji opisywanej funkcjonalności rozpoczyna się od zdarzenia odzwierciedlającego wyzwalacz przypadku użycia wskazujący biznesowy kontekst uruchamiania funkcjonalności. Uwzględnienie w przebiegu zdarzenia-wyzwalacza dodatkowo wiąże się z ukryciem sposobu dostępu do funkcjonalności (modelowanym na opisanej w dalszej części artykułu mapie nawigacyjnej przypadku użycia), a modelowaniem w przebiegu tylko akcji związanych z realizacją funkcjonalności.

Konstrukcje składowe diagramu aktywności umożliwiają modelowanie w ramach jednego diagramu wszystkich scenariuszy przebiegu przypadku użycia – głównych, alternatywnych oraz wyjątkowych. Rozdzielenie przebiegu na poszczególne scenariusze związane jest przede wszystkim z węzłami decyzyjnymi, z których część sterowana jest przetwarzanymi danymi, część wynika z wyboru przez użytkownika jednej z dostępnych opcji. W celu umożliwienia jawnego powiązania przebiegu przypadku z elementami interfejsu użytkownika odzwierciedlającymi dostępne opcje, w profilu OMNIS zdefiniowano odpowiednie stereotypy oraz związane z nimi atrybuty (prezentowany w przykładzie stereotyp «button driven» umożliwia powiązanie przebiegu sterowania z przyciskiem zaprojektowanego interfejsu użytkownika).

Opracowywane diagramy aktywności uzupełniane są o przesyłane pomiędzy poszczególnymi akcjami obiekty. W ramach prezentowanego podejścia stosowana jest notacja pinowa dla modelowania przepływu obiektów – wykorzystywaną konstrukcją są piny akcji (ang. InputPin,OutputPin). Przyjęty poziom szczegółowości modelowania danych to poziom klas modelu informacyjnego systemu (omówienie w dalszej części artykułu) – jako typy pinów wskazywane są klasy modelu odzwierciedlające przetwarzane dane. Dodatkowo, w celu zwiększenia czytelności diagramów, stosuje się szereg konwencji/rozszerzeń notacji, m. in.:

• w celu ułatwienia wielokrotnego odwoływania się do danych przetwarzanych w ramach opisywanej funkcjonalności (w szczególności wielokrotnej ‘tymczasowej’ – nie utrwalanej – modyfikacji danych) oraz zagwarantowania odwołania do aktualnych wartości, wykorzystywana jest konstrukcja składnicy danych (ang. DataStore) z nałożonym, zdefiniowanym w profilu OMNIS, stereotypem «useCase variable»;
• dane kontekstowe wykorzystywane w przebiegu (np. informacja o zalogowanym użytkowniku korzystającym z modelowanej funkcjonalności) są modelowane jako pin wartości (ang. ValuePina) bez konieczności wskazania źródłowego przepływu;
• dla akcji, której celem jest odczytanie danych trwałych definiowane są: piny wejściowe (ang. InputPin) odwzorowujące parametry służące do identyfikacji odczytywanych danych oraz piny wyjściowe (ang. OutputPin) reprezentujące odczytane obiekty;
• dla akcji, której celem jest zapisanie danych trwałych definiowane są piny wejściowe odwzorowujące zapisywane obiekty, nie są modelowane piny wyjściowe chyba, że akcja zapisu wiąże się z modyfikacją obiektu, wówczas w celu aktualizacji danych przetwarzanych w ramach przypadku użycia modelowane są również piny wyjściowe reprezentujące zapisywane i jednocześnie modyfikowane obiekty;
• dla akcji, której celem jest utworzenie/zapisanie nowych obiektów definiowane są: piny wejściowe odwzorowujące parametry służące do utworzenia obiektu oraz piny wyjściowe reprezentujące utworzone/zapisane obiekty;
• dla akcji, której celem jest przetworzenie danych (np. wyliczenie pewnych wartości lub transformacja danych) definiowane są: piny wejściowe odwzorowujące parametry stanowiące podstawę do przetworzenia oraz piny wyjściowe reprezentujące obiekty stanowiące produkt przetworzenia;
• dla akcji realizowanej w partycji reprezentującej warstwę prezentacji definiowane są tylko piny wejściowe odwzorowujące obiekty prezentowane przez elementy interfejsu użytkownika;
• dla akcji realizowanej w partycji reprezentującej działania użytkownika definiowane są tylko piny wyjściowe odwzorowujące dane wprowadzone lub wskazane przez użytkownika.

Uzupełnienie przebiegu przypadku użycia o przetwarzane w ramach funkcjonalności dane związane jest z jednej strony z weryfikacją możliwości realizacji poszczególnych działań, czyli weryfikacją czy w modelu informacyjnym uwzględnione zostały wszystkie wymagane dane oraz ich właściwości, z drugiej dostarcza danych pozwalających na przeprowadzenie wymiarowania (szacowania złożoności funkcyjnej) modelowanej funkcjonalności metodami Punktów Funkcyjnych (w tym [COSMIC] bazującej na złożoności ‘przesunięciach’ danych).

Konstrukcje diagramu aktywności są na potrzeby metodyki OMNIS rozszerzane. Przykłady rozszerzeń pojawiły się już w opisie powyżej. Innym użytecznym rozszerzeniem jest wyróżnienie akcji warstwy prezentacji związanej z prezentacją komunikatu, którego celem jest poinformowanie użytkownika np. o statusie przetwarzania danych, w tym o błędach wprowadzonych danych lub możliwych opcjach wyboru. Akcję związaną z prezentacją komunikatu przeciąża się stereotypem «presentation message», a za pomocą zdefiniowanych dla stereotypu atrybutów wskazuje typ okna dialogowego (jeden ze zdefiniowanych globalnie dla systemu) oraz treść komunikatu (w szczególności parametryzowaną).

Przedstawiony powyżej diagram przedstawia koncepcję opisu przebiegu przypadku użycia zbudowaną zgodnie z opisanymi założeniami, przy wykorzystaniu stosowanych w prezentowanym podejściu konwencji i notacji.

Rola techniki w metodyce OMNIS

Tworzenie interfejsu użytkownika, prócz wartości samej w sobie, służy do weryfikacji zgodności planowanych scenariuszy przypadków użycia z projektowanym interfejsem oraz weryfikacji zawartości modeli informacyjnego systemu / usług z zapotrzebowaniem na dane wymagane do wyświetlenia oraz pobrania informacji na interfejsie użytkownika.

Wykorzystywane języki i narzędzia

Wykorzystywanym w OMNIS środkiem wyrazu, są diagramy aktywności (UML).

UŻYTECZNE TECHNIKI