WPROWADZENIE

Jednym z pierwszycgh etapów analizy systemowej  krokiem w metodyce OMNIS jest precyzyjne określenie rzeczywistych oczekiwań w stosunku do cech funkcjonalnych systemu, czyli sprecyzowanie wymagań w terminach zadań, jakie przyszli użytkownicy docelowego systemu będą mogli w tym systemie wykonać – wymagań, które definiowane są z perspektywy użytkowników tworzonego systemu i realizują wyspecyfikowane na etapie analizy biznesowej wymagania biznesu.

Wykorzystywanym w prezentowanym podejściu narzędziem, które umożliwia zdefiniowanie zakresu funkcjonalności tworzonego systemu jest model przypadków użycia, wyrażony za pomocą diagramu przypadków użycia języka UML. Aktorzy modelu reprezentują przyszłych użytkowników systemu oraz inne systemy zewnętrzne współpracujące z modelowanym. Wymagania funkcjonalne wobec systemu są odwzorowywane w przypadki użycia. Uwzględnione w modelu zależności aktor – przypadek specyfikują dostępność funkcjonalności systemu dla poszczególnych użytkowników.

Aktorzy modelu przypadków użycia są wyprowadzani z uczestników procesów biznesowych odpowiedzialnych za realizację tych akcji, które stanowią źródło zidentyfikowanych wymagań biznesu. Identyfikacja aktorów umożliwia spojrzenie na system z perspektywy użytkowników i zadań jakie będą realizowali z użyciem systemu, a w konsekwencji – identyfikację przypadków użycia. 

Liczba przypadków użycia zależy od przyjętej metodyki, ponieważ ta przekłada się na ich granulację. Wśród stosowanych podejść można wyróżnić dwa najczęściej stosowane. W pierwszym z podejść poszczególnym akcjom (dodawania, modyfikacji, itd.) odpowiadają osobne przypadki. W drugim podejściu przypadek odpowiada zestawowi operacji wykonywanych na danym pojęciu, niekiedy w określonym stanie, dociążonym uprawnieniami określonego aktora. Z punktu widzenia aktora jest to skoncentrowanie usług na określonym pojęciu – przedmiocie pracy (np. obsługa wniosku o rejestrację). W pierwszym podejściu mamy większą liczbę przypadków użycia, ale każdy z przypadków jest opisany prostszym scenariuszem/diagramem. Dodatkowo konsekwencją częstych powtórzeń wspólnych fragmentów przebiegów i zastosowania relacji include/extend do reprezentacji tych powtórzeń, jest jeszcze większa liczba przypadków użycia. W drugim podejściu liczba przypadków oraz relacji jest zdecydowanie mniejsza aczkolwiek przebiegi są dużo bardziej złożone. Co jest lepsze? To zależy. Wybór podejścia stanowi aspekt procesowy realizacji metodyki – każdorazowo zależy od specyfiki prowadzonego przedsięwzięcia. W praktyce firmy AION zdecydowanie częściej stosowane jest podejście drugie – bardziej treściwe przypadki użycia. Jest to związane z, omówionym w dalszej części rozdziału, wykorzystaniem diagramu aktywności do wyrażenia przebiegów przypadków.

Niezależnie od zastosowanego podejścia liczba przypadków użycia rzeczywistego systemu biznesowego jest zwykle odpowiednio duża. Aby ułatwić pracę z modelem i zarządzanie przypadkami, dokonuje się podziału modelu. Stosowanym kryterium podziału jest definicja diagramu dla każdego z aktorów (lub kilku aktorów z mniejszą liczbą przewidzianych dla nich funkcjonalności) oraz dodatkowego diagramu prezentującego przyjętą hierarchię dziedziczenia aktorów.

Diagram przypadków użycia jest najprostszym diagramem UML (z najmniejszą liczbą konstrukcji składowych), ale jednocześnie jednym z najtrudniejszych diagramów języka – budzącym największe kontrowersje wśród praktyków. Źródłem największych problemów jest nieprecyzyjna definicja relacji zdefiniowanych pomiędzy przypadkami użycia (include, extend oraz generalizacji).

Diagramy przypadków użycia, opracowywane w ramach pierwszej iteracji  nie uwzględniają relacji pomiędzy przypadkami użycia. Te pojawiają się na diagramach dopiero w wyniku strukturalizacji diagramów aktywności stanowiących zapis przebiegów przypadków użycia. Diagramy aktywności mają bowiem konstrukcję umożliwiającą wyodrębnienie fragmentu przebiegu (w szczególności części wspólnej kilku diagramów) i późniejsze odwoływanie się do niego. Konstrukcja pozwala na zamodelowanie odpowiedniej zależności jedynie na diagramach aktywności i nie wymaga jej przeniesienia na poziom diagramu przypadków użycia. Przyjęte rozwiązanie w praktyce okazało się bardziej użyteczne i czytelne. Prezentowany odbiorcy systemu diagram zawiera bowiem jedynie ‘czyste’ przypadki użycia niosące rzeczywistą, zauważalną/mierzalną wartość dla aktorów.

Rola techniki w metodyce OMNIS

Diagram przypadków użycia w metodyce OMNIS służy do uchwycenia projektowanej funkcjonalności z punktu widzenia użytkowników systemu oraz stanowi podstawę do podziału prac pomiędzy analitykami systemowymi. 

Wykorzystywane języki i narzędzia

Wykorzystywanym w OMNIS środkiem wyrazu, są diagramy przypadków użycia (UML).

UŻYTECZNE TECHNIKI