Przypadek użycia

Przypadek użycia lub przypadki użycia ( „  use-case  ” w języku angielskim), definiuje inżynierii oprogramowania i systemów inżynieryjnych sposób korzystania z systemu, który ma wartość lub użyteczność dla zaangażowanych podmiotów. Przypadek użycia odpowiada zestawowi działań wykonywanych przez system w interakcji z aktorami w celu osiągnięcia celu. Zestaw przypadków użycia umożliwia zatem opisanie wymagań funkcjonalnych systemu poprzez przyjęcie punktu widzenia i języka użytkownika końcowego.

Pochodzenie i ewolucja

W 1987 roku Ivar Jacobson przedstawił pierwszy artykuł dotyczący przypadku użycia na konferencji OOPSLA '87. Opisuje, w jaki sposób ta technika opracowana w firmie Ericson może zostać wykorzystana do ujęcia wymagań systemu w formie graficznej w ramach metody projektowania i analizy zorientowanej obiektowo. W 1992 roku opublikował OOSE , metodę inżynierii systemów, która jest zorientowana obiektowo i oparta na przypadkach użycia. W 1994 roku opublikował następnie książkę o wykorzystaniu przypadków użycia w kontekście reengineeringu procesów i modeli biznesowych.

W tym samym czasie Grady Booch i James Rumbaugh pracują nad ujednoliceniem swoich metod analizy i projektowania zorientowanego obiektowo, metody Boocha i techniki modelowania obiektów (OMT) . Do nich dołączył w 1995 roku Ivar Jacobson i dały początek językowi modelowania UML , którego standaryzację powierzono konsorcjum Object Management Group (OMG) , która zakończyła się w 1997 roku. Poza językiem modelowania graficznego, Jacobson, Booch i Rumbaugh są również praca nad ujednoliconą metodą rozwoju, która będzie oparta najpierw na Objectory, a następnie wzbogacona. Metoda ta stała się w 1999 r. Ujednoliconym procesem i utrwala zasadę pilotowania przez przypadki użycia oraz określa, w jaki sposób są one wykorzystywane do wychwytywania wymagań i służą jako wspólny wątek w całym procesie rozwoju.

Idąc za Jacobsonem, kilku autorów wniosło swój wkład w technikę przypadków użycia, w tym w szczególności Alistair Cockburn, który w 2000 roku opracował podejście do przypadków użycia skoncentrowane na ich celach, a także spopularyzował opis narracyjny i tabelaryczny - realną alternatywę dla diagramów przypadków użycia - , Geri Schneider i Jason Winters, którzy opublikowali dobre praktyki w 2001 r., Kurt Bittner i Ian Spence, którzy udoskonalili praktyki analizy wymagań funkcjonalnych w 2002 r., Oraz Gunnar Overgaard, który w 2004 r. Zaproponował zastosowanie koncepcji wzorców projektowych do przypadków użycia.

W latach 90. przypadki użycia stały się jedną z najczęściej stosowanych praktyk w pracy nad relacjami funkcjonalnymi . Były szczególnie popularne w społeczności obiektowej, z której wywodzi się koncepcja przypadków użycia. Jednak ich użycie nie ogranicza się do systemów zorientowanych obiektowo, przypadki użycia nie są z natury zorientowane obiektowo.

W 2011 roku Ivar Jacobson, Ian Spence i Kurt Bittner opublikowali  elektroniczną książkę „  Use Case 2.0 ”, aby zaktualizować podejście i ułatwić korzystanie z przypadków użycia w kontekście metod zwinnych, wzbogacając je o pojęcie plastra („  fragment przypadku użycia  ”).

Zasady

Przypadek użycia to technika służąca do wychwytywania wymagań systemu i służąca jako wspólny wątek we wszystkich czynnościach niezbędnych do jego wdrożenia. Według SWEBOK są one częścią rodziny technik zbierania wymagań opartych na scenariuszach .

Według Bittner i Spence, „Przypadek użycia (...) opisuje sekwencję zdarzeń, które, wzięte razem, określają system robi coś pożytecznego . ” Zatem przypadek użycia odpowiada zestawowi działań wykonywanych przez system w interakcji z aktorami w celu osiągnięcia celu.

Kilka bardziej precyzyjnych definicji świadczy o ewolucji tego pojęcia, zaczynając od zrozumienia behawioralnego, aby dojść do wizji kierowanej przez cele:

Przypadki użycia starają się unikać żargonu technicznego i zamiast tego próbować przyjąć język użytkownika końcowego lub eksperta w dziedzinie domeny.

Różne komponenty

Przypadek użycia jest identyfikowany przez cel aktora w systemie zwany aktorem głównym. Aktor oznacza użytkownika lub inny system. Przypadek użycia może również obejmować innych aktorów, zwanych aktorami drugorzędnymi.

Każdy przypadek użycia odpowiada jednemu lub kilku scenariuszom definiującym interakcję między systemem a użytkownikami. Zwykle jest główna fabuła i możliwe odmiany. Odpowiadają one szczególnym przypadkom i wyjątkom. Scenariusze mogą obejmować inne przypadki użycia.

Każdy przypadek jest przedmiotem opisu lub specyfikacji, która przedstawia różne scenariusze.

W podejściu „przypadków użycia 2.0” początkowy opis jest zredukowany do jego najprostszej formy, bez scenariusza. Ten przypadek jest następnie wzbogacony opisem „  wycinka przypadków użycia  ”. Każdy wycinek reprezentuje scenariusz lub wariant, ale zgodnie z podziałem, który umożliwia implementację każdego wycinka podczas iteracji. Zasadniczo wszystkie transze muszą ostatecznie obejmować wszystkie scenariusze i warianty przypadku użycia.

Rodzaje

Istnieje kilka rodzajów przypadków użycia, które odpowiadają różnym zastosowaniom:

Poziomy celów i szczegółowość

Podstawowy przypadek użycia to najmniejsza jednostka czynności, która daje znaczący wynik dla użytkownika. Zwykle są to przypisane mu zadania. To także całość postrzegana przez użytkownika jako spójna, niezależna sama w sobie i użyteczna.

Alistair Cockburn opowiada się za podejściem zorientowanym na  cel  . Zwracając uwagę, że istnieje różnica między celami opisanymi na poziomie organizacji a celami zdefiniowanymi dla zadań użytkownika, wprowadził pojęcie poziomu obiektywnego:

Poziom celu Analogia z wysokością Symbol Opis poziomu
Strategiczny Chmura Goal-level-icons-cloud.png Cel i uzasadnienie systemu. Identyfikuje główne funkcje systemu dla firmy.
Latawiec Goal-level-icons-flying-kite.png Cel biznesowy firmy. Identyfikuje główne funkcje systemu dla działalności biznesowej firmy. Odpowiada działalności biznesowej obejmującej kilku użytkowników.
Użytkownik Poziom morza Goal-level-icons-waves-at-sea.png Cel realizowany przez użytkownika podczas korzystania z systemu. Odpowiada elementarnemu zadaniu użytkownika (czas trwania od 2 do 20 minut)
Funkcja wewnętrzna Ryby w morzu Goal-level-icons-fish.png Uczestnicz w osiąganiu celu użytkownika, z którym jest powiązany relacją typu włączenia
Zbyt szczegółowe Muszla na dnie morza Goal-level-icons-seabed-clam-shell.png Unikać

Zakres

Jeśli poziom celu dostarcza informacji o poziomie szczegółowości przypadku użycia, zakres wskazuje zakres działania. Wyróżnia się trzy poziomy zakresu:

Dokumentacja

Przegląd przypadków użycia może być:

Każdy przypadek użycia można udokumentować jako:

Przypadki użycia są często pisane zarówno przez analityków, użytkowników końcowych, jak i eksperta . W UML , każdym przypadku zastosowanie przedstawiono w przypadku stosowania schematu , każda z nich jest scenariuszy opisanych w analizie przez jeden lub większą liczbę dynamicznych wykresy diagramów aktywności , sekwencji , komunikacji lub stanem przejściowym schematach .

Opis graficzny

Diagramy przypadków użycia umożliwiają przedstawienie widoku rozważanego systemu, z uwzględnieniem przypadków użycia i zaangażowanych aktorów. Zwykle główni aktorzy są przedstawiani po lewej stronie, ale to nie jest norma.

Opis tekstowy

Dokumentacja tekstowa przypadku użycia zazwyczaj składa się z następujących części:

Możemy też dodać:

Alistair Cockburn sugeruje dwanaście zaleceń redakcyjnych:

  1. Zacznij od głównych funkcji i zachowaj jak najwięcej na poziomie celu użytkownika.
  2. Skoncentruj swoją uwagę na nominalnym przypadku.
  3. Zawsze określaj interesariuszy i ich interesy.
  4. Użyj obecnego orientacyjnego.
  5. Użyj aktywnej trasy, aby opisać osiągane cele podrzędne.
  6. Temat musi być łatwy do zlokalizowania.
  7. Zachowaj zwięzłość i na temat; unikaj długich dokumentów.
  8. Unikaj warunkowych i umieść alternatywne zachowania w rozszerzeniach.
  9. Zgłaszaj przypadki wtórnego zastosowania, reprezentowane przez relację włączenia „uwzględnij”.
  10. Określ właściwy cel.
  11. Zgłoś zakres.
  12. Odłóż interfejs użytkownika na bok.

Zalety i ograniczenia

Korzyści

Przypadki użycia są skuteczne w zbieraniu wymagań na podstawie przypadków użycia systemu, ponieważ koncentrują się na interakcjach aktor / system zgodnie z wyborami ich użytkowników. Umożliwiają również przygotowanie testów akceptacyjnych w oparciu o wykorzystanie systemu.

Przypadki użycia można łatwo powiązać z zadaniami i działaniami biznesowymi, jeśli są uporządkowane według poziomu celu. Ułatwia to z jednej strony komunikację z zarządzaniem użytkownikami, az drugiej zarządzanie zmianami organizacyjnymi, w tym w kontekście reengineeringu procesów. Przypadki użycia mogą zatem służyć jako podstawa podręczników i dokumentacji zorientowanych na użytkownika.

Struktura przypadków użycia zapewnia spójny obraz zbioru ściśle powiązanych wymagań. Dlatego są one łatwiejsze do odczytania niż liniowa prezentacja luźno ustrukturyzowanych wymagań. Pozwala to również na wykorzystanie kontekstu funkcji, które mają zostać opracowane, na wszystkich etapach projektu.

Limity i ryzyko

Według niektórych autorów, same przypadki użycia nie mogą napędzać procesów rozwojowych, ponieważ nie uwzględniają transwersalnych reguł biznesowych. Gdy można je uwzględnić i zintegrować z przypadkami użycia, istnieje ryzyko, że zostaną one zamaskowane przez interakcje między aktorami a systemem. Oba przypadki mogą później powodować problemy, gdy trzeba dostosować reguły biznesowe. Należy jednak spojrzeć na te ryzyka z odpowiedniej perspektywy, ponieważ wiele modeli opisu proponuje oddzielną identyfikację reguł biznesowych i wyraźne odwoływanie się do tych reguł w przypadkach użycia, gdy jest to stosowne.

Połączenie interakcji aktor / system i reguł biznesowych w przypadkach użycia powoduje również utrudnienia w kontekście ewolucji architektury zorientowanej na usługi (SOA), której usługi są oparte na przypadkach użycia. W podejściu „SOA zorientowana na cel” zaproponowano alternatywę opartą na oddzieleniu reguł biznesowych i przypadków użycia, pozwalającą odpowiednio usługom SOA na hermetyzację reguł biznesowych i skupienie się na przypadkach użycia wyłącznie na wyborach nawigacji użytkowników.

Przypadki użycia ryzykują zbyt szczegółowym opisem, aby wpłynąć na ergonomię systemu na podstawie przyjętych z góry pomysłów na kolejność działań i sposób interakcji między użytkownikiem a systemem. Ryzyko to można wyeliminować, odwołując się do niezbędnych przypadków użycia.

Według niektórych autorów przypadki użycia nie byłyby odpowiednie dla podejść zwinnych ze względu na konieczność pełnego udokumentowania wszystkich ich scenariuszy, zanim będą mogły zostać włączone do planowania iteracji. Ta recenzja jest jednak wysoce wątpliwa, ponieważ Cockburn, jeden ze współautorów manifestu zwinnego , twierdzi, że preferuje przypadki użycia. Ponadto technika „przypadków użycia 2.0”, opublikowana w 2011 r., Została opracowana specjalnie w celu ułatwienia integracji z praktykami zwinnymi. To podejście jest porównywalne z późniejszą techniką  mapowania historyjek użytkownika  , często używaną w kontekście zwinnym.

Warianty i pojęcia pokrewne

„Przypadki nadużycia” i „przypadki nadużycia” (odpowiednio przypadek nadużycia i przypadek niewłaściwego użycia w języku angielskim, gra na bliskości słów z przypadkiem użycia ) to adaptacje przypadków użycia do analizy zagrożeń, które mogą wpływać na bezpieczeństwo systemy. Użytkownicy tych przypadków są wtedy złośliwymi aktorami.

Przypadku użycia schemat jest graficznym przedstawieniem układu, a jednym lub większą liczbą przypadków użycia z podmiotów. Jest to konkretna reprezentacja przypadku użycia zdefiniowana przez UML , a nie sam przypadek użycia.

„Realizacja przypadku użycia” to sposób implementacji przypadku użycia.

„  Instancja przypadku użycia” to wykonanie przez system przypadku użycia dla danego użytkownika podczas interakcji w określonym czasie (na przykład w celu zarejestrowania transakcji biznesowej).

Konto użytkownika ( „  historia użytkownik  ” w języku angielskim) jest opis pożądanej funkcjonalności opisane z perspektywy użytkownika. Podobnie jak w przypadku użycia, historia koncentruje się na użytkowniku (roli, aktorze), musi przynosić wartość i umożliwiać rozwój i testowanie. Pierwsza różnica dotyczy omawianego tematu: przypadki użycia odpowiadają zestawowi działań, podczas gdy historie mają być bardziej elastyczne i mogą w ten sposób opisywać złożony przypadek użycia, a także elementarną funkcjonalność. Druga różnica dotyczy aktorów: historia dotyczy tylko punktu widzenia pojedynczego użytkownika, podczas gdy przypadek użycia uwydatnia wielość zaangażowanych aktorów i punkty widzenia.

Przypadek użycia odpowiada wymaganiu funkcjonalnemu, ale nie definiuje interfejsu użytkownika, który je implementuje. Dlatego ujednolicony proces zaleca używanie szkiców i prototypów zamiast przypadków użycia do reprezentowania logiki interfejsu użytkownika i przepływu ekranu.

Bibliografia

  1. "  use case  " , na gdt.oqlf.gouv.qc.ca (dostęp 30 czerwca 2019 )
  2. (en) Dr. Ivar Jacobson, Ian Spence i Kurt Bittner, „  Use-Case 2.0 ebook  ” , Ivar Jacobson International ,grudzień 2011(dostęp 12 czerwca 2019 )
  3. (en) Cockburn, Alistair. , Pisanie skutecznych przypadków użycia , Addison-Wesley,2001( ISBN  0-201-70225-8 i 9780201702255 , OCLC  44046973 , czytaj online )
  4. (en) Ivar Jacobson , „  Rozwój zorientowany obiektowo w środowisku przemysłowym  ” , SIGPLAN Not. , vol.  22 N O  12,Grudzień 1987, s.  183–191 ( ISSN  0362-1340 , DOI  10.1145 / 38807.38824 , czytaj online , dostęp 12 czerwca 2019 )
  5. (en) Jacobson, Ivar. , Inżynieria oprogramowania zorientowana obiektowo: podejście oparte na przypadkach użycia , ACM Press,1992( ISBN  0-201-54435-0 i 9780201544350 , OCLC  26132801 , czytaj online )
  6. (w) Jacobson, Ivar. i Jacobson, Agneta. , Zaleta obiektu: reengineering procesów biznesowych z wykorzystaniem technologii obiektowej , Wokingham / Reading (Mass.) / Paris itd., Addison-Wesley, © 1995, 347  str. ( ISBN  0-201-42289-1 i 9780201422894 , OCLC  32276135 , czytaj online )
  7. (in) „  About the Unified Modeling Language Specification Version 2.5.1  ” na www.omg.org (dostęp 30 czerwca 2019 )
  8. Jacobson, Ivar. , Rumbaugh, James. i Zaïm w Wirginii. ( przetłumaczone  z języka angielskiego), The Unified Software Development Process , Paryż, Eyrolles,2000, 488  str. ( ISBN  2-212-09142-7 i 9782212091427 , OCLC  45152206 , czytaj online )
  9. (en) Schneider, Geri. and Winters, Jason , Stosowanie przypadków użycia: praktyczny przewodnik , Boston, Addison-Wesley,2001, 245  str. ( ISBN  0-201-70853-1 i 9780201708530 , OCLC  45284668 , czytaj online )
  10. (w) Bittner, Kurt and Spence, Ian , modelowanie przypadków użycia , Addison Wesley,2002( ISBN  0-201-70913-9 i 9780201709131 , OCLC  50041546 , czytaj online )
  11. (en) Overgaard, Gunnar. , Przypadki użycia: wzory i plany , Addison-Wesley,2005( ISBN  0-13-145134-0 i 9780131451346 , OCLC  57361841 , czytaj online )
  12. (en-US) „  Baza wiedzy inżynierii oprogramowania (SWEBOK) | IEEE Computer Society  ” (dostęp: 6 lipca 2019 )
  13. (w) Ivar Jacobson , Kurt Bittner, Ian Spence, Modelowanie przypadków użycia , Addison Wesley Professional,2002( ISBN  0-201-70913-9 )
  14. (en) Van Harmelen, Mark. , Modelowanie obiektów i projektowanie interfejsu użytkownika , Addison-Wesley,2001( ISBN  0-201-65789-9 i 9780201657890 , OCLC  45058748 , czytaj online ) , artykuł „Struktura i styl w przypadkach użycia w projektowaniu interfejsu użytkownika” Larry L. Constantine i Lucy AD Lockwood
  15. Tłumaczenie bierze pod uwagę, że w „  zasadniczym przypadku użycia  ” „  istotne  ” odnosi się do „  przypadku  ”, a nie do „  użycia  ”
  16. (w) Constantine, Larry L. , Oprogramowanie do użytku: praktyczny przewodnik po modelach i metodach projektowania zorientowanego na użytkowanie , Addison Wesley,1999( ISBN  0-201-92478-1 i 9780201924787 , OCLC  39962434 , czytaj online )
  17. (w) „  Essential (Abstract) Use Cases: An Introduction Agile  ” na agilemodeling.com (dostęp 6 lipca 2019 )
  18. (i) Jacobson Ivar. , Booch, Grady. i Rumbaugh, Jim. , Ujednolicony proces tworzenia oprogramowania , Addison-Wesley,1999( ISBN  0-201-57169-2 , 9780201571691 i 9780321822000 , OCLC  636807532 , czytaj online ) , s.  116, 142 i 160-166, w szczególności str. 116 „Najlepszym sposobem opracowania tej specyfikacji interfejsu użytkownika jest naszkicowanie kilku wersji (...)” oraz ulotka na stronie 164 dotycząca istotnych przypadków użycia: „(... ) Specyfikatory przypadków użycia najpierw przygotowują lekkie opisy przypadków użycia, które nie zawierają żadnych niejawnych decyzji dotyczących interfejsu użytkownika. (...) Projektanci interfejsu użytkownika mogą (...) tworzyć interfejsy użytkownika bez ograniczeń wynikających z dorozumianej decyzji. "
  19. Bruce Powel Douglass , „Rozdział 4 - Agile Stakeholder Requirements Engineering” , w: Agile Systems Engineering , Morgan Kaufmann,1 st styczeń 2016( ISBN  9780128021200 , DOI  10.1016 / b978-0-12-802120-0.00004-7 , czytaj online ) , s.  147-188
  20. (en) „  Unified Modeling Language Specification Version 2.5  ” , na www.omg.org ,marzec 2015(dostęp 3 lipca 2019 )
  21. (en) Bittner, Kurt. , Modelowanie przypadków użycia , Addison Wesley,2003( ISBN  0-201-70913-9 i 9780201709131 , OCLC  50041546 , czytaj online ) , str.  Rozdział 7 zatytułowany „Struktura i zawartość przypadku użycia”
  22. „  Przypadki użycia czy historie użytkowników?  » , On InfoQ (dostęp 6 lipca 2019 r. )
  23. (w) Ed Anderson , Mike Bradley i Rosemary Brinko , „  przypadek użycia i reguły biznesowe: style dokumentowania reguł biznesowych w przypadkach użycia  ” , dodatek do konferencji ACM SIGPLAN 1997 na temat programowania obiektowego, systemów, języków i aplikacji ( Dodatek) - OOPSLA '97 , ACM Press,1997, s.  85–87 ( ISBN  9781581130379 , DOI  10.1145 / 274567.274584 , czytaj online , dostęp: 6 lipca 2019 )
  24. (in) "  Przypadki użycia i reguły biznesowe: czy mogą współpracować? > Społeczność i zasoby analityków biznesowych | Modern Analyst  ” , na www.modernanalyst.com (dostęp 6 lipca 2019 )
  25. SOA zorientowana na cele
  26. (w) Patton, Jeff (programista) , Fowler, Martin, 1963- , Cooper, Alan, 1952- i Cagan, Marty , User Story Mapping: Discover the Whole Story, Build the Right Product ,2014, 276  pkt. ( ISBN  978-1-4919-0490-9 , 1491904909 i 1491904860 , OCLC  880566740 , czytaj online )
  27. (w) Donald Firesmith, „  Security Use Cases  ” , Journal of Object Technology , ETH Zurich, Chair of Software Engineering, vol.  2 n O  3,Maj 2003, s.  53-64 ( czytaj online )
  28. „  user story  ” , na www.granddictionary.com (dostęp 3 lipca 2019 )
  29. (w) Mike Cohn , „  User Stories and User Templates Story by Mike Cohn  ” w Mountain Goat Software (dostęp: 3 lipca 2019 )
  30. (en-US) Andrew Stellman , „  Requirements 101: User Stories vs. Use Cases  ” , on Building Better Software ,3 maja 2009(dostęp 3 lipca 2019 )

Zobacz też

Powiązane artykuły

Bibliografia

Linki zewnętrzne