PRZYPADKI UŻYCIA

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

Nie znaleziono żadnych wyników

Nie znaleziono szukanej strony. Proszę spróbować innej definicji wyszukiwania lub zlokalizować wpis przy użyciu nawigacji powyżej.

AS Przypadki Użycia

utworzone przez | kw. 27, 2022

AS Przypadki Użycia

utworzone przez | kw. 27, 2022

Plakat DMN – Modele decyzyjne

Plakat DMN (ang. Decision Model and Notation) Modele decyzyjne przedstawia konstrukcje, służące do opisu poziomów modelu decyzyjnego: poziomu wymagań decyzyjnych DRL (ang. Decision Requirements Level) oraz poziomu logiki decyzyjnej DLL (ang. Decision Logic Level). Na poziomie DRL specyfikowany jest graf DRG, przedstawiający strukturę obszarów podejmowania decyzji, zaś na poziomie DLL definiowane są wyrażenia w postaci tabel decyzyjnych (ang. Decision Table), wyrażeń tekstowych (ang. Literal expression) oraz wywołań (ang. Invokation).

Plakat języka FEEL standardu OMG DMN

Język FEEL (ang. Friendly Enough Expression Language) jest uproszczonym językiem dedykowanym opisom wyrażeń, reprezentujących logikę decyzyjną modelu decyzyjnego, opracowanego zgodnie ze standardem OMG DMN (ang. Decision Model and Notation).

Plakat BPMN 2.0

Plakat BPMN 2.0 zawiera opis konstrukcji standardu BPMN 2.0, tj. bramy (ang. Gateways), czynności (ang. Activity), w tym zadania (ang. Tasks) i podprocesy (ang. Sub-Process), przepływy komunikatów (ang. Message Flows) oraz baseny (ang. Pools).

RuleSpeak Tabulation – Primer

Słowo kluczowe RuleSpeak? ?następujące? (ang. the following) jest używane do łączenia wielu warunków w pojedyncze wyrażenie. W przeciwnym przypadku warunki musiałyby być zapisane z wykorzystaniem:
?spójników: ?i? albo ?lub” (taki zapis jest zwykle trudniejszy do zrozumienia dla specjalistów dziedzinowych) albo
?wielu wyrażeń (zwykle liczba reguł biznesowych, którymi trzeba zarządzać w organizacji jest znacząca, dlatego też, zasadne jest redukowanie tej liczby).

RuleSpeak Sentence forms

Szablonem Zdania (ang. Sentence Form) nazywamy wzorzec zdania w języku naturalnym, znajdujący zastosowanie w specyfikowaniu Wytycznych (Reguł biznesowych, Wskazówek) w sposób spójny i ustrukturyzowany. Każdy z Szablonów Zdania jest przeznaczony do konstruowania określonego rodzaju Wytycznych.