Przypadki użycia to temat niekończących się debat. Diagram przypadków użycia może mieć swój początek bez przypadków użycia (Udziałowcy projektu…). Ale czym one, przypadki użycia, są?
Alistair Cockburn jest “use case guru” dla wielu analityków i projektantów, pisze:
Wyróżniamy 3 poziomy szczegółowości przypadków użycia:
- nieformalny opis ? kilka luźnych zdań ogólnie opisujących przypadek
- formalny opis ? kilka paragrafów, podsumowanie
- pełen opis ? formalny dokument
Przypadek użycia (źr. WIKI) powinien:
- opisywać w jaki sposób system powinien być używany przez aktora w celu osiągnięcia konkretnego celu
- być pozbawiony szczegółów dotyczących implementacji oraz interfejsu użytkownika
- opisywać system na właściwym poziomie szczegółowości
- Functional requirements: Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
- Non-functional requirements: Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
- Domain requirements: Requirements that come from the application domain of the system and that reflect characteristics of that domain.
Definicja Sommerville’a, wymagań funkcjonalnych: wymaganie funkcjonalne to usługa świadczona przez system. Jest to praktycznie tożsame z definicją przypadku użycia systemu (parz zakończenie artykułu) i taki jest właśnie ich sens. Idąc tym tropem…
W 1986 Ivar Jacobson, informatyk zaangażowany w tworzenie [[Unified Modeling Language]] (UML) oraz [[Rational Unified Process]] (RUP) opisał technikę do specyfikowania przypadków użycia. Z początku używał określeń: scenariusz użytkowania (usage scenarios) i przypadki użytkowania (usage case). I tu widzę światełko w tunelu. Wymagania są dzielone na następujące kategorie (źr. WIKI):
- Wymagania funkcjonalne opisują funkcjonalność, którą system ma realizować, na przykład formatowanie tekstu lub modulowanie sygnału. Czasami są znane jako możliwości.
- Wymagania pozafunkcjonalne specyfikują kryteria osądzania działania systemu. Są one znane jako wymagania jakościowe.
- Wymagania ograniczeń określają granice rozwiązania. Niezależnie od tego jak problem jest rozwiązany, ograniczenia muszą być respektowane.
W 2006 roku napisałem:
Po wielu podejściach do tworzenia przypadków użycia uznałem, że należy najpierw opisać co jest w ogóle celem tworzenia tego systemu, co on ma wspomagać lub automatyzować. Jak? Należy najpierw zamodelować tę wspomaganą czynność w zupełnym oderwaniu od systemów. Jak już zdefiniujemy i zoptymalizujemy samą czynność można zabierać się do wyszczególniania przypadków użycia czyli tak na prawdę zaprojektować tę ?druga stronę lustra?. (Przypadki użycia i UML | Analiza biznesowa i projektowanie – Jarosław Żeliński – blog).
Po kilku latach kolejnych doświadczeń upewniam się, że proste jest piękne: przypadek użycia to pojedyncza, elementarna kompletna usługa świadczona przez System dla jego użytkownika. Usługa ta jednak może mieć warianty.
Przykład: jeżeli jakiś system, miedzy innymi, umożliwia wprowadzanie danych z formularza, wzorów formularza jest kilkadziesiąt to ile mamy przypadków użycia? Jeden, który pozwala na wprowadzanie danych do “jakiegoś” formularza, to jaki to jest formularz to parametr. Scenariusz ma między innymi krok: wyświetl formularz do wypełnienia. jaki formularz? Wynika to albo z kontekstu, który może być efektem poprzednio wykonanych operacji albo z bezpośredniego wyboru Aktora. Tak więc dobry projekt raczej nie ma odrębnego przypadku użycia dla każdego wzoru formularza. Dobry projekt ma jeden przypadku użycia, wzór formularza to efekt wyboru np. w poprzednim kroku. Jak taki przypadek użycia jest realizowany? Opisze to kiedyś 🙂 przy okazji wzorca Strategia i praktyk projektowania DDD.
Jaki z tego ma pożytek sponsor projektu? Koszt, projekt ma kilkanaście lub kilkadziesiąt a nie setki przypadków użycia i jest łatwiejszy w implementacji.
A gdzie przypadki systemowe? Nie ma takich. Pojęcie Aktora ma jasną definicję (osoba lub inny system mający interakcję z Systemem), pojęcie przypadku użycia także (specyfikacja działań Systemu w odpowiedzi na działania aktora lub innego podmiotu “zainteresowanego” Systemem) (źr.: OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.3). Wymyślanie nowych definicji nie tylko psuje standard bo nie pasuje do spójnej przestrzeni nazw. Wymyślanie swoich znaczeń po protu psuje zrozumiałość, niszczy role komunikacyjną modeli (języka ich tworzenia). Niestety Pan Cockbourn jest w moich oczach takim “dorabiaczem” i psującym sens prostego i jak widać trudnego zarazem, narzędzia jakim jest model przypadków użycia systemu.
O tym jak można psuć i komplikować proste rzeczy (Pan Cockbourn) napisałem w Po brzytwie… (diagram poniżej to wręcz antywzorzec… 😉 a widuje takie niestety w projektach). Zaryzykuję nawet tezę, że ktoś kto poprawia wypracowany system pojęciowy jakim jest np. UML po prostu nie rozumie ani tego systemu ani tego czym jest system pojęciowy i język modelowania. UML, owszem, można rozszerzać (stereotypy), ale to wymaga zrozumienia go, bo samo mnożenie stereotypów bez zachowania pewnych zasad rządzących przestrzenią nazw jaką się UML, prowadzi to bełkotu.
Mnożenie bytów na diagramach to poniższa “[[puszka pandory]]”. Za coś podobnego jak poniżej nie płacimy!
Jarku zgadzam się z Tobą w 100%. Nie mniej jednak jest trudno czasem wytłumaczyć czytelnikom takiego giganta jak Alistair Cockburn, że “guru” od przypadków użycia jest w błędzie i “olał” specyfikację UML, która powinna być i jest wyznacznikiem znaczenia poszczególnych elementów notacji UML.
Ja im, jego czytelnikom, niczego nie tłumaczę, on nie jest w błędzie, on nie używa UML 🙂 , używa pojęcia “przypadek użycia” w innym znaczeniu niż zdefiniowane w UML. To po prostu “przypadkowa zbieżność nazw” ale niestety wprowadza w błąd… 😉
Dokładnie tak. Cockburn dopiero około 180 strony swojej książki pt.: “Jak pisać efektywne przypadki użycia” pisze, że koncepcja przypadków użycia, którą on prezentuje stała się podstawą/inspiracją do przypadków użycia znanych z UML. Pisząc wcześniej “olał” miałem na myśli iż jego koncepcja przypadków użycia nie jest tożsama z przypadkami użycia znanymi ze specyfikacji języka UML.
No niestety, ale wielu ludzi utożsamia przypadki użycia Cockbourn’a i UML… co jest jednak błędem…
Witam,
Od niedawna zacząłem się interesować analizą biznesową, więc możliwe, że moję myślenie jest błędne, ale zastanawia mnie co tak dokładnie jest złego w zaprezentowanym powyżej “antywzorze”? Nie znam co prawdą języka w którym napisany jest ten diagram, ale wydaje mi się, że jeśli każda wymieniona funkcjonalność jest unikalna to nie mamy do czynienia ze zbytnim mnożeniem bytów, tylko po prostu system jest bardzo duży. Może chodzi Panu o przejrzystość diagramu i możliwość podzielenia go na kilka z podziałem na dziedzinę, ale nie jest to wyjaśnione. Mógłby Pan to mi nieco doprecyzować?
Pozdrawiam
Na początek nie mylmy “funkcjonalności” z “przypadkiem użycia”, ten drugi tu usługa systemu.
Diagram przypadków użycia ma sens (jest czytelny i jest modelem) pod warunkiem, że posłużymy się “określoną definicją” przypadku użycia. Definicja UML to (w uproszczeniu) usługa systemu mająca określony wymagany stan początkowy i tworząca określony, przydatny dla aktora, stan końcowy czyli produkt. Jest ona niemalże tożsama z definicją procesu biznesowego: “przekształca stan wejściowy w stan końcowy”. Stany pośrednie nie są więc przypadkami użycia (nie istnieje ich hierarchiczna gradacja) a jedynie krokami scenariusza. Innymi słowy, przypadki użycia to w zasadzie elementy menu, które aktor może wywołać (usługi systemu) by coś uzyskać. Tak więc np. wystawienie faktury to jeden przypadek użycia (stan początkowy wymaga wiedzy komu i za co tę fakturę wystawić, stan końcowy to poprawna faktura, kompletowanie tych danych to kroki scenariusza a nie osobne przypadki użycia), nie są nimi “wstawienie produktu” czy “wybór kontrahenta”.
Przypadków użycia raczej nie dzielimy dziedzinowo, a raczej grupujemy na moduły systemu (lub odrębne podsystemy). jeżeli na jednym diagramie jest ich wiele to sygnał, że tego podziału nie dokonano (a pamietajmy, że dobra praktyka jest podział dużych systemów na podsystemy). Dalej: nie bardzo ma sens tworzenie diagramów pozbawionych ramy System, gdyż wyznacza ona zakres projektu (granice systemu), najsilniejszy element zarządzania zakresem projektu. Bez tego niemożliwe jest modelowanie integracji.
W książkach można spotkać inne niż w UML (niezgodne z nim), definicje przypadkow uzycia (np. popularny A.Cocborn) jednak używanie ich wprowadza zamęt w dokumentacji i utrudnia korzystanie z popularnych systemwów CASE. jeżeli jednak już stosujemy diagramy UML, to dla unikania nieporozumień, należy na nich zachowac deficniję z UML. Jest to o tyle korzystne, ze OMG harmonizuje notacje (np. BMN, BMM) dzięki czemu możliwe jest wzajemne mapowanie np. elementarne procesy w BPMN na przypadki użycia, jest to zresztą zalecana metoda ich – przypadków użycia – identyfikacji. Diagram “zbyt duży” z zasady jest zły, bo pokazuje, że autor nie panuje nad złożónościąprojektu.
Dziękuję za szybką odpowiedź.
Mam tylko jedną wątpliwość. Użyłem słowa “funkcjonalność”, ponieważ na wcześniejszym diagramie (który raczej nie jest antywzorcem) jest napisane w notatce, że “Przypadki użycia to funkcjonalności mającego powstać Systemu.[…]. Więc jak to jest? Usługa systemu/Przypadek użycia to nie funkcjonalność systemu?
Używam pojęcia “funkcjonalność” w rozumieniu “funkcja systemu” jako pojęcia tożsamego z jego “przypadkiem użycia”. Ta zbieżność to także konsekwencja harmonizacji notacji jaką robi OMG (organizacja zarządzająca specyfikacjami tych notacji). Dzieje się do niedawna i w moich starszych artykułach pojęcia te nie były tak rygorystycznie utożsamiane. Potoczne (słownikowe w sensie j.polskiego) znaczenie słowa to ?funkcjonowanie lub funkcja czegoś w jakimś systemie?. Jeżeli uznamy, że funkcja systemu (tu aplikacji) to usługa jakiej od niego oczekujemy, to są to zgodne pojęcia. Jednak w potocznym rozumieniu “funkcjonalność” jest faktycznie szerszym pojęciem i warto te pojęcia uporządkować w dokumentacji projektowej.
Tożsamość pojęć “funkcja systemu”, “usługa systemu” i “przypadek użycia (systemu)” (w kategorii analizy i projektowania obiektowego) wynika także ze specyfikacji SOA i Architektury Korporacyjnej, gdzie właśnie usługa systemu z perspektywy aktora jest jego przypadkiem użycia, zaś elementarny (zwany czasem atomowym) proces biznesowy jest wspierany konkretną usługą systemu (jest to jego przypadek użycia).
Dlatego napisałem, że “wystawianie faktur” to funkcjonalność systemu, ale “możliwość wstawienia wielu produktów na fakturze” to już nie odrębna funkcjonalność a cecha formatki faktury.
Witam,
Z tego co zrozumiałem warianty przypadku użycia powinny znajdować się w tym samym przypadku.
Czy w przypadku gdy mamy trzy warianty dodania czegoś do systemu(tworzenie od podstaw, ze wzorca i skopiowanie już istniejącego elementu) przedstawiamy jeden z wariantów jako scenariusz główny, a reszta wariantów w scenariuszach alternatywnych?
Czy tak samo będzie w przypadku gdy daną rzecz możemy procesować na dwa różne sposoby?
Nie za bardzo czuję przypadki użycia, która mają kilka wariantów procesowania.
Pozdrawiam
Bardzo ważne jest to co rozumiemy pod pojęciem “procesowania”, jeżeli to sekwencja różnych czynności to nie jest to przypadek użycia a proces (być może biznesowy). Przypadek użycia to z zasady jedna usługa aplikacji dająca jako efekt jeden konkretny rezultat (produkt). Przypadkiem użycia będzie np. tworzenie dokumentu faktury. Jeżeli faktura ma kilka etapów zatwierdzania to jest to jeden proces biznesowy mający kilka różnych aktywności: tworzenie nowej faktury, kontrola merytoryczna, zatwierdzenie. Przypadek użycia jest jeden: zarządzanie fakturą (przypadek typu CRUD).
Warto też pamiętać, że jeden przypadek użycia może mieć alternatywne scenariusz i alternatywne ich przebiegi….
Dziękuje za odpowiedź.
Czy można zastosować takie podejście, że proces biznesowy rozpisujemy w BPMN, natomiast czynności tego procesu za pomocą Przypadków Użycia? Przyjmijmy, że mam proces tworzenia faktury z kontrolą merytoryczna i zatwierdzaniem na różnych szczeblach organizacji. Proces BPMN opisuje mi ogólny schemat tego procesu (utwórz->sprawdź>akceptuj->akceptuj->koniec). Natomiast przypadki użycia wchodzą w szczegóły tych czynności, np PU wyjaśnia jak czynność utworzenia faktury się odbywa?
Jako podstawę warto przyjąć ścisłą separację modelu CIM (Computing Independent Model, źr. http://www.omg.org/mda) od modelu PIM aplikacji (oprogramowanie) będącej narzędziem w procesie biznesowym. Jeżeli więc model procesu w notacji BPMN to model CIM, a pod pojęciem “przypadek użycia” rozumiemy tu jego scenariusz opisujący interakcję z narzędziem (szczegóły pracy z GUI), to jest to skuteczna droga. Warto uporządkować stosowanie pojęć proces (biznesowy), scenariusz UC, interakcje itp. bez czego nawet zrozumienie Pana pytania staje się wyzwaniem :). Jeżeli pod pojęciem “czynność utworzenia faktury” rozumiemy szczegóły pracy aktor-system to tak.
Mam pytanie odnośnie tego czy gdy mamy 1 przypadek użycia i mamy do niego kilka ścieżek alternatywnych to czy możemy potem tworzyć następne ścieżki alternatywne dla powstałych już ścieżek alternatywnych głównego scenariusza. Czy nie będzie to wtedy zbyt rozbudowany przypadek użycia? Jest sposób na upraszczanie takich sytuacji czy po prostu rozbudowujemy go tak długo aż wyczerpiemy temat?
Przede wszystkim należy sobie zdefiniować pojęcie “Przypadek użycia”: inną definicję przyjął A.Cockburn, inną swego czasu przyjęto w RUP (to są lata 90-te) i inna jest w obecnym UML (polecam jednak oryginalną specyfikację a nie książki!). Jeżeli projekt ma być cały w UML i ma być spójny, nie pozostaje nic innego jak uznanie definicji UML. Tu zaś sprawa się upraszcza, bo skoro przypadek użycia to “użycie aplikacji w celu osiągnięcia określonego rezultatu” (tu zwracam uwagę, że cel ma człowiek, oprogramowanie daje jakiś rezultat) to scenariusz będzie “raczej” jeden, z ewentualnymi wariantami wynikającymi z tego, że narzędzie jakim jest aplikacja, może zareagować wariantowo. Tu często ludzie wpadają w pułapkę mieszania kontekstu biznesowego z kontekstem aplikacji, typowy przykład to przypadki użycia nazywane CRUD, czyli jeden przypadek użycia i cztery konteksty jego wykorzystania. (tu więcej o przypadkach użycia CRUD)
Kolejna ważna rzecz: z zasady dialog aktor-system posługuje się “jednym bytem” jakim jest formatka ekranowa a nie pojedyncze jej pole, więc “standardowy” scenariusz ma trzy kroki: inicjacja przypadku użycia, wypełnienie formatki ekranowej wyświetlonej przez system i potwierdzenie, system potwierdza, że przyjął lub wyświetla listę błędów do poprawy. Jeżeli z jakiegoś powodu “zbieranie danych” na jednej formatce nie satysfakcjonuje nas, tylko ten jeden krok (cała formatka na raz) dzielimy na mniejsze (wprowadzany dane partiami). tu mogą się pojawić alternatywne ścieżki, ale nadal jest to jeden przypadek użycia mający jeden początek i jeden rezultat.
Tu znowu zwracam uwagę, że rezultatem jest postać danych a nie konkretne dane (rezultatem wprowadzania danych o kliencie jest zawsze kolejna nowa kartoteka klienta a nie konkretna firma) czyli ten przypadek użycia ZAWSZE daje taki sam rezultat.
Dziękuję za odpowiedź.
Zastanawiałem się po prostu w jaki sposób opisać przypadek “Logowanie do systemu”, w którym w zależności od różnych ustawień użytkownika system odpowiada w bardzo różnoraki sposób. I jeśli nie rozbije się tego na kilka uszczegółowionych przypadków (np. logowanie do systemu użytkownika z danym uprawnieniem lub posiadającym dane urządzenie uwierzytelniające) to powstanie jeden bardzo rozbudowany z wieloma ścieżkami alternatywnymi (oprócz ustawień różnych ustawień użytkownika dochodzi przecież jeszcze walidacja).
Logowanie jako takie nie jest usługą dla aktora a implementacją wymagania “dopuszczamy do pracy wyłącznie autoryzowanych użytkowników”. To zaś a jaki sposób system zareaguje na zachowania użytkownika zależy od reguł biznesowych czyli stanów określonych obiektów w systemie. Gdyby nawet logowanie było UC, to kończy się on w momencie podania hasła bez błędu. Kolejne akcje (odpowiedź systemu) mogą zależeć od tego kto jest zalogowany czyli kto żąda obsługi i efekty mogą być zależne od iluś tam reguł. Co do zasady reguły biznesowe nie sa procesami (ani scenariuszami), polecam stronę: BRGroup.