Dzisiaj co nieco o filozofii i przypadkach użycia.
Dzielenie przypadków użycia na “rodzaje” zawsze budziło mój sprzeciw, w UML (w oryginale) mamy jedno pojęcie: “przypadek użycia systemu”, gdzie systemem jest coś (przedmiot opisu), czyli “analizowany/modelowany system” (patrząc na system w rozumieniu teorii systemów, tu zwracam uwagę na fakt, że UML to nie tylko IT). Wobec tego skoro system (wymiennie “przedmiot zainteresowania”, “przedmiot analizy”), zanim będzie rozpatrywany, musi być określony (granice systemu, który jest częścią “nad” (super) systemu, a składa się z podsystemów, polecam Sienkiewicz, Teoria Systemów), otrzymamy prostą rzecz: przypadek użycia ma jedną definicję, ale w danym momencie rozpatrywanym systemem (przedmiot analizy) jest np. oprogramowanie ale też może nim być np. organizacja. Tak więc przypadek użycia “oprogramowania” (np. wystawianie faktury VAT) niczym się nie różni od “przypadku użycia” firmy sprzedającej rowery “dostarczenie zamówionego roweru”, to co tu “robi różnicę” to granice systemu- kontekst: raz jest nią granica “oprogramowania” a raz “organizacji”.
Proste pojęcie przypadku użycia jest piękne bo proste. Popatrzmy do oryginalnej specyfikacji (OMG Unified Modeling Language (OMG UML), Superstructure Version 2.4.1):
16. Use Cases
16.1 Overview
Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The subject is the system under consideration to which the use cases apply. The users and any other systems that may interact with the subject are represented as actors. Actors always model entities that are outside the system. The required behavior of the subject is specified by one or more use cases, which are defined according to the needs of actors. […] Use cases, actors, and systems are described using use case diagrams.
9wytłuszczenia moje). Co my tu mamy:
- Przypadek użycia oznacza specyficzne (konkretne) oczekiwane użycie systemu. Standardowo używany jest do zbierania [J.Ż. dokumentowania] wymagań na system, planowany do użycia.
- Kluczowymi pojęciami łączonymi z Przypadkiem użycia są aktor oraz przedmiot zainteresowania (system).
- Opisywanym z pomocą przypadków użycia przedmiotem jest system, który będzie wykorzystywany zgodnie z przypadkami użycia (w tym celu).
- Użytkownik lub inny system może oddziaływać na opisywany przypadkami użycia przedmiot, nazywany jest wtedy aktorem. Aktorem jest każdy zewnętrzny w stosunku do opisywanego systemu element (byt).
- Wymagane zachowanie opisywanego przedmiotu (system) może być opisane jednym lub wieloma przypadkami użycia, definiowanymi jako potrzeby aktora (w stosunku do systemu).
- Przypadek użycia, aktor i system razem są określane jako diagram przypadków użycia.
Jak widać, nie ma tu żadnych kombinacji, dowolny system, jego otoczenie oraz interakcje tego otoczenia z nim samym opisujemy (modelujemy) z pomocą trzech pojęć pokrywających wszystkie wymagane elementy: kto/co, z czym i jakie ma interakcje.
Teraz proszę najpierw przeczytać to:
Dwie ważne rzeczy: “nie należy bez potrzeby mnożyć liczby bytujących istot” to znana bardziej jako brzytwa Ockhama zasada: “Nie należy mnożyć bytów ponad potrzebę” (Brzytwa Ockhama nazywana także zasadą ekonomii myślenia, zgodnie z którą w wyjaśnianiu zjawisk należy dążyć do prostoty, wybierając takie wyjaśnienia, które opierają się na jak najmniejszej liczbie założeń i pojęć. Tradycyjnie wiązana jest z nazwiskiem Williama Ockhama). Druga: “nie wolno niepotrzebnie umniejszać odmian bytujących istot” . Razem są zwane jako “najwyższe prawa rozumu” (filozofa, badacza).
Powyższy wklejony cytat pochodzi z rozprawy Czworaki korzeń zasady racji dostatecznej Schopenhauera. Cytuję go, gdyż gorąco polecam filozofię analitykom (uczy logicznego myślenia i analizy), tę zaś zasadę polecam szczególnie, gdyż pozwala ona uniknąć niepotrzebnego mnożenia bytów np. w postaci “różnych rodzajów przypadków użycia” (dotyczy to także aktorów). W jednej z prac innego filozofa (nie pamiętam teraz którego), można znaleźć, że łamanie powyższej zasady (nadawanie nowych nazw nowym postrzeganym rzeczom) to wraz niezrozumienia”: “czego nie rozumiem nadam mu nową nazwę”. To zła droga…
Zacytuje fragment mojego referatu z pewnej konferencji:
…wszystko to co nas otacza, samo w sobie jest naturalnie proste. Złożone są, nie poszczególne rzeczy, a to, że jest ich wiele i mają na siebie wzajemny wpływ. Pamiętajmy, że jedna z najtrudniejszych gier na świecie ? szachy ? to tylko kilkanaście figur i proste reguły ich przemieszczania, snooker – najtrudniejsza gra w bilarda – to tylko kule i kij i prawa fizyki. Nawet największą organizację można, w toku analizy, rozłożyć na skończoną liczbę ról i reguł ich postępowania by zrozumieć jej funkcjonowanie. (żr. Jarosław Żeliński, referat na konferencji o systemach ERP).
Tak więc, tylko trzy pojęcia: system, aktor i przypadek użycia zupełnie wystarczą by opisać system i jego (przyszłe, planowane) wykorzystanie czyli wymagania. I zawsze powinny wystąpić te trzy elementy na modelu. Mnożenie bytów na tym diagramie to raczej przyznanie się do porażki…
Na koniec polecam także Prezentacja (skrót) książki Rebeki Wirfs-brock. Uwaga o projektowaniu i przypadkach użycia:
What?s Missing From Use Cases:
– Use cases are descriptive, not prescriptive [przypadki użycia są opisowe a nie nakazowe]
– There is a gap between these descriptions and a design [są wypełnieniem luki pomiędzy opisem a projektem]
___
Transcendentalny – będący warunkiem (możliwości) zaistnienia czegoś. W filozofii Kanta i jego kontynuatorów dotyczący apriorycznych form poznania, teoretycznie wykraczających poza przedmiot i treść poznania, a odnoszący się do warunków poznania pełnej rzeczywistości poznawczej tzn. prawdy absolutnej pojmowanej uniwersalnie przez wszystkie podmioty poznawcze. Innymi słowy, taka forma poznania otaczającej rzeczywistości, by każdy bez względu na jego umiejscowienie w niej, mógł stwierdzić jednoznaczność poznawczą, czyli prawdę – uniwersalną dla wszystkich istot poznawczych we wszechświecie.
“There is a gap between these descriptions and a design” znaczy: “Istnieje luka pomiędzy tymi opisami (t.j. przypadkami użycia) a projektem”, a nie “[przypadki użycia] są wypełnieniem luki pomiędzy opisem a projektem”. A to zasadnicza różnica :).
Coś w tym jest, od strony językowej miałem problem z tym jak to przetłumaczyć, bo fakt (kontekst) polega na tym, że pomiędzy opisem “prozą” a projektem (np. model dziedziny) są właśnie przypadki użycia czyli pierwsza struktura wypełniająca lukę pomiędzy nieuporządkowanym opisem a projektem obiektowym. Chętnie podejmę dyskusję o tym, bo nie jest to moim zdaniem oczywiste (Twoje tłumaczenie wprost jak najbardziej poprawne)…
To prawda, że przypadki użycia są pierwszą strukturą wypełniającą lukę pomiędzy nieuporządkowanym opisem a projektem obiektowym. Jednakże poszczególne przypadki użycia są pierwotnie specyfikowane także z użyciem prozy (co prawda ustrukturyzowanej, ale zawsze prozy). Z tej opisowej natury przypadków użycia wynika powstanie luki pomiędzy nimi a projektem, którą należy wypełnić w procesie analizy i projektowania. Wydaje mi się, że właśnie tę oczywistość miała na myśli Rebecca.
?Przypadki użycia to dokumenty pisane czystym tekstem, a nie diagramy, zaś modelowanie z wykorzystaniem przypadków użycia polega na pisaniu tekstu, a nie rysowaniu diagramów.? [Larman C., ?UML i wzorce projektowe?, s. 94]
I mamy źródło “problemu”, ja “domyślnie” potraktowałem Przypadki użycia jako elementy diagramu UML…:). To tylko upewnia nas, że słownik pojęć i kontekst do podstawa jednoznacznej dokumentacji. Co do Rebeki W. to teraz nie jestem pewien o czym myślała, ale z jej książki “wnioskuję”, że chodziło jej o UML … chyba…;). Możliwe też, że miała na myśli popularną wtedy (pisała to w roku 2000) koncepcję przypadków użycia Cocbourna (której osobiście nie lubię bo wprowadza straszny zamęt ;))
Co do Larmana, to w jego książce podoba mi się tok procesu modelowania dziedziny, sekwencji itp.. poza jednak tym jak traktuje przypadki użycia: po pierwsze uznaje je za część nieformalną a po drugie uznaje, że “są dobre” w momencie powstania i nie pokazuje jak sprawdzić że “są dobre”. Myślę, że raczej postrzega je jako “user story”.
Ja zaś traktuję przypadki użycia jako pierwszy formalizm (UML i jej semantyka) w projekcie (wydaje mi się, że w książce R.W. też tak to widzi) czyli właśnie wypełnienie owej luki… ale to moja wersja 🙂
Przypadek użycia to przede wszystkim opis interakcji zachodzących między aktorem a systemem i opis ten ma charakter prozy. Często mylone są pojęcia Use Case i Use Case Diagram. Use Case zawiera w sobie cel aktora, scenariusz główny i jego rozszerzenia czyli samo sedno tego do czego służy: modelowania danej funkcjonalności w sposób który krok po kroku prowadzi do celu. Zastosowanie jedynie diagramów UML do tworzenia Use Case’ów bez pisania faktycznych scenariuszy mija się z celem.
Co do mnożenia use case’ów to należy zwrócić uwagę na poziom szczegółowości kroków use case’a i starać się tworzyć tzw. Strategic Use Case’s. O tym można poczytać w książce ‘Writing Effective Use Cases’ autorstwa Alistair’a Cockburn’a. Zbyt duża liczba use casów świadczy o konieczności większego uogólniania.
Prawdą jest, że opisów tego czym jest Przypadek użycia jest wiele, chyba “najlepsza” moim zdaniem jest prosta definicja mówiąca, że przypadek użycia to inicjowana przez aktora jego interakcja z systemem, której celem jest z góry określony rezultat. To czy przypadek użycia będzie jajeczkiem na diagramie UML czy tabelką w dokumentacji w zasadzie nie ma znaczenia (ta tabelka to jakaś dokumentacja tego przypadku użycia).
W moich oczach książka “Writing Effective Use Cases” autorstwa Alistair?a Cockburn?a to najgorsza książka o przypadkach użycia jaką czytałem (i nie jestem w tej opinii odosobniony), bo nie dość, że totalnie abstrahuje od UML mimo, że używa pojęcia UML jakim jest Use Case, to autor doprowadził to “narzędzie” do granic absurdu usiłując zastąpić swoimi metodami dokumentowania przypadków użycia wszystkie inne elementy projektu takie jak opisu dziedziny czy reguły biznesowe. Nie zmienia to faktu, że ta książka faktycznie świeci triumfy wśród nie znających UML.
Wprowadzenie różnych poziomów UC (strategiczne itp…) to już pojęciowy kosmos nie do obrony biorąc pod uwagę, że przypadek użycia to nic innego jak usługa systemu świadczona aktorowi, czyli nie ma tu żadnej hierarchii (poza priorytetami) a jest liniowa lista tego co można od systemu dostać. Poziom szczegółowości kroków to jedynie to, jak drobno rozpiszemy tę interakcję, co nie zmienia faktu, że i tak sprowadza się to do dialogu: aktor nacisnął, system zwrócił (tabelka lub diagram sekwencji). Kwestia projektanta jest to, że implementacja formularza to dialog pole po polu (bardzo pracochłonne) czy tylko “wypełnij formularz i naciśnij OK” (bardzo wygodne i mało pracochłonne).
I to co jest w tym wszystkiego najgorsze, to próby modelowania procesów biznesowych z pomocą przypadków użycia. Np. nazwanie przypadkiem użycia np. Przyjęcia zamówienia czy Stworzenie oprogramowania.
Panie Jarosławie,
nie do końca się z panem zgadzam. Wg Cockburn’a szkielet specyfikacji wymagań powinien być oparty na Use Case’ach. Jednak on sam twierdzi, że Use Case’y to tylko fragment specyfikacji, model dziedziny i reguły biznesowe to przecież jej osobna część.
Większość czytelników tej książki uważa ją za przydatną co można zobaczyć w recenzjach na amazonie: http://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/product-reviews/0201702258/ref=cm_cr_pr_hist_5?ie=UTF8&filterBy=addFiveStar&showViewpoints=0&sortBy=bySubmissionDateDescending
Jest też ona cytowana przez innych autorów np. Karl Wiegers, Larry Constantine. Jednak przede wszystkim, use case’y pisane prozą są bardzo dobrym narzędziem do modelowania funkcjonalności systemu. Istnieją co prawda lepsze metody np. Task & Support. Alistair Cockburn daje w swojej książce wiele przykładów i dobrych rad, które w praktyce są przydatne. Przykładowo to chyba on wprowadził do use case’ów pojęcie definiowania celu i radzi by każdy krok use case’a przybliżał nas do celu. Dodatkowo radzi on w tej książce jak dbać o cele interesariuszy, którzy nie są wprost aktorai w danym przypadku użycia.
Pojęcie poziomów szczegółowości i tworzenie strategicznych use case’ów jest trudne i w praktyce znajduje zastosowanie w bardzo dużych projektach. Ja osobiście zastosowałem to w jednym niezbyt dużym projekcie po to, by pomóc czytelnikom lepiej zrozumieć zakres projektu. Natomiast osobiście uważąm, że do poziomów szczegółowości znacznie epiej nadaje się modelowanie za pomocą diagramów Warniera.
Z poważaniem,
Łukasz Pasek
Doskonale wiem, że ta książka jest “powszechnie lubiana i cytowana”. Doskonale też wiem, że jest “uwielbiana za to, że wystarczą nieweryfikowalne tabelki) (UML dla wielu jest trudny, podobnie zresztą jak cały obiektowy paradygmat)… Przypadki użycia (mówię o czymś co definiuje się jako “usługa systemu dla aktora”) to prosta i płaska struktura. Komplikowanie jej np. w poziomy nie ma żadnego uzasadnienia i odzwierciedlenia w kodzie, zaś próby opisania w ten sposób “złożonego biznesu” to na dzisiaj (i to nie tylko moja opinia) nieudolne próby stosowania metod z pierwszej połowy lat 90-tych (stary RUP: biznesowe przypadki użycia, ich dziedziczenie itp.), gdy nie znano jeszcze np. metod modelowania procesów (BPMN). Proszę tego nie traktować jako “atakowanie” Pana opinii a jako porównanie ze stanem dzisiejszym wiedzy :). Cocbourn i jego przypadki użycia nie mają nic wspólnego z UML, co zresztą on sam przyznaje i momentami nawet drwi z “ludzików i jajeczek”, których on sam, moim zdaniem, po protu nie rozumie.
Przy okazji grupowania, jeżeli już grupować przypadki użycia to raczej “tematycznie” na komponenty czy moduły, i robi się to z pomocą pakietów UML.
Krytyka jaką Cockburn prowadzi wobec UMLa polega na właściwym zrozumieniu następstw tego co zacytował Pan wcześniej:
“Use cases, actors and systems are described using use case diagrams’.
Cockburn ma rację twierdząc, że diagram przypadków użycia to tylko spis treści, podczas gdy istota modelowania interakcji w jakie człowiek wchodzi z systemem może być opisana właśnie krokami.
Zbierając wymagania klienta i decydując co ma robić system, a co użytkownik potrzebujemy napisać kroki use case’a.
Celem analizy biznesowej jak i projektowania użyteczności jest by użytkownik (aktor, rola) osiągał swój cel w sposób zgodny ze swoimi intencjami i oczekiwaniami. Właśnie o to chodzi Cockburnowi i dlatego tak wiele osób docenia tę książkę. Proszę nie mylić Analizy Systemowej, którą się Pan zajmuje z określaniem wymagań, która jest przedmiotem Analizy Biznesowej. Obiektowość czy UML to świat implementacji a nie biznesu. Nie rozmawiamy z klientem o paradygmacie obiektowym ale raczej o zadaniach i pracy jaką będzie wykonywał przy użyciu oprogramowania.
Sama weryfikacja kroków przypadków użycia, zamodelowanych przez analityka biznesowego i zaakceptowanych z interesariuszami polega na czymś innym niż tworzenie struktury implementacji.
Stare nie zawsze znaczy gorsze. Pośród staroci można czasem znaleźć wysoce użyteczne narzędzia praz sposoby na rozwiązywanie problemów. Czy do modelowania logiki jest coś lepszego niż diagramy Warniera – lata 60-te i 70-te? Czy do zapewnienia jakości danych jest coś lepszego niż Output-Oriented Systems Design – sposób porzucony w latach 80-tych?
Same Use Case’y tak jak opisane wg Cockburn’a mają jednak jeden dość poważny minus. Zbyt wcześnie nast epuje decydowanie o tym co robi użytkownik a co system. Ale to temat na osobną dyskusję.
Nie chciałbym się z Panem spierać i szanuję Pana poglądy i szeroką wiedzę. Jednak proszę zauważyć, że Cockburn wyraźnie pragnie odciąć się od implementacji w swoich próbach modelowania funkcjonalności. Nieszczęście, Pana, moje i wielu ludzi polega na nazywaniu różnych rzeczy tą samą nazwą. Ludzie mylą use case’y z use case diagramami. Use case’y rzeczywiście pochodzą z czasów sprzed powstania obiektowości i jak pisze Larry Constantine były tematem tabu, w świecie obiektowości, aż do czasu, gdy Ivar Iacobson wprowadził je do UMLa.
Celem diagramu Use Case (UML) nigdy nie było modelowanie żadnych interakcji (od tego jest diagram interakcji), diagram Use Case to tylko (i aż) kontekst i zakres projektu, jego ogromną zaletą jest, zarządzanie zakresem projektu, interesariuszami. Nieoceniona role pełni w narzędziach CASE jako korzeń projektu (modeli). Nie jestem “analitykiem systemowym” w rozumieniu “tylko klasy na diagramach” i tu niestety nie mogę się zgodzić, że “obiektowość” to tylko świat UML i implementacji. Organizacje, do celów analizy, modeluje się jako zespół obiektów, jako procesy biznesowe czy jako struktury organizacyjne, to zależy od celu analizy. Dobry model obiektowy organizacji (lub jej części) jest potem doskonałym modelem dziedziny (wzorce DDD). Co do wady “Zbyt wcześnie następuje decydowanie o tym co robi użytkownik a co system.” to fakt, drugą jest przedwczesne sugerowanie architektury w tabelkach, co niesie nie raz złe konsekwencje w postaci złego modelu dziedziny. Co do mylenia to prawda, “przypadki użycia” mają niestety wiele różnych potocznych znaczeń, a tak na prawdę są to “usługi aplikacji”, jeżeli używać pełnej nazwy np. Diagram przypadków użycia, Scenariusz przypadku użycia, Interakacja aktor-system dla przypadku użycia itp. pomyłek było znacznie mniej 😉
Przy okazji diagramów Warniera i następnych: w obiektowym podejście diagramy Warniera nie mają racji bytu, one i nie tylko to próby radzenia sobie ze złożonością generowaną lawinowo przez logikę dekomponowana algorytmicznie, świetnie opisano to w Object-Oriented Analysis and Design with Applications (3rd Edition), Grady Booch (Author), Robert A. Maksimchuk (Author), Michael W. Engle (Author), Bobbi J. Young (Author), Jim Conallen (Author), Kelli A. Houston (Author). OOAD poprawnie stosowane doskonale sobie radzi ze złożonością dużych systemów (dlatego wygrywa z metodami strukturalnymi i bazami relacyjnymi).