OPISYWANIE PROCESÓW BIZNESOWYCH Z WYKORZYSTANIEM PRZYPADKÓW U!YCIA *

Transkrypt

1 Nowoczesne systemy informatyczne dla sektora MSP Jerzy NAWROCKI!ukasz OLEK Instytut Informatyki Politechniki Pozna"skiej OPISYWANIE PROCESÓW BIZNESOWYCH Z WYKORZYSTANIEM PRZYPADKÓW U!YCIA * Streszczenie. Przypadki u#ycia s$ wykorzystywane najcz%&ciej do opisu wymaga" funkcjonalnych systemów informatycznych. Eksperymenty przeprowadzone na Politechnice Pozna"skiej pokaza'y, i# mog$ by( one z powodzeniem wykorzystane do opisu procesów biznesowych jako alternatywa dla notacji graficznych. Przypadki u#ycia s$ pó'formalne: proces biznesowy jest wyra#ony jako sekwencja kroków, a ka#dy krok jest opisany w j%zyku naturalnym. Procesy biznesowe z regu'y trwaj$ d'u#ej ni# wykonywanie poszczególnych wymaga" funkcjonalnych. Pojawia si% wi%c potrzeba zmodyfikowania tego opisu tak, aby odpowiada' naturze takich procesów. W artykule dokonano omówienia bada" dotycz$cych zastosowania przypadków u#ycia do modelowania procesów biznesowych. Przedstawiono pewne rozszerzenia przypadków u#ycia, które zosta'y uznane za interesuj$ce podczas przygotowywania opisów procesów biznesowych. Rozszerzenia te pozwalaj$ wyrazi( metamorfoz% aktorów oraz pokaza( kroki, które musz$ by( wykonane przed g'ównym scenariuszem. 1. Wprowadzenie Istniej$ dwa najwa#niejsze podej&cia do opisywania procesów biznesowych: diagramy i tekst. Prawdopodobnie najbardziej popularny w obszarze opisywania modeli biznesowych jest j%zyk UML [13]. W roku 2004 zaproponowano kolejn$ notacj%, diagramy BPMN [3], które wydaj$ si% bardzo interesuj$ce i staj$ si% coraz bardziej popularne. Je&li chodzi o notacje tekstowe, to z punktu widzenia opisu procesów biznesowych, najwa#niejsze wydaj$ si% przypadki u#ycia. Koncepcj% przypadków u#ycia stworzy' Ivar Jacobson [8], który pocz$tkowo wykorzystywa' je do opisu systemów telekomunikacyjnych. Najpopularniejsz$ form$ opisu przypadków u#ycia jest sekwencja kroków wykonywanych * Praca wykonana w ramach grantu BW

2 2 Autor przez aktorów. Ka#dy krok jest wyra#ony w j%zyku naturalnym. Przypadki u#ycia zosta'y w'$czone do j%zyka UML (jako diagramy przypadków u#ycia) [6] oraz do Rational Unified Process [9]. Dzi%ki temu sta'y si% bardzo popularne. Technika ta zosta'a dopracowana przez Cockburna [4] oraz Adolpha, Bramblea i innych [1]. Cockburn, Adolph i Bramble zaproponowali wiele przydatnych wskazówek dotycz$cych pisania czytelnych przypadków u#ycia. Opis procesów biznesowych ma szczególne znaczenie w przypadku tworzenia systemów informatycznych dla skomplikowanych dziedzin biznesowych. W takiej sytuacji bardzo po#$dane jest przygotowanie dokumentu Koncepcja Dzia'ania (ang. Concept of Operations), który opisuje zastan$ sytuacj%, uzasadnienie potrzeby zmian oraz proponowany system [7]. Zastana sytuacja mo#e by( opisana przy u#yciu notacji tekstowej lub diagramowej. W celu sprawdzenia jako&ci, opis ten powinien by( zaprezentowany nie tylko informatykom, lecz równie# reprezentantom klienta i przysz'ym u#ytkownikom systemu. Tak wi%c wa#ne jest, aby notacja by'a czytelna dla szerokiego grona odbiorców. Na Politechnice Pozna"skiej przeprowadzili&my w 2005 roku eksperyment maj$cy na celu porównanie przypadków u#ycia z diagramami BPMN. Okaza'o si%, i# 'atwiej jest wyszukiwa( b'%dy w przypadkach u#ycia ni# w diagramach BPMN. Podczas przygotowywania procesów biznesowych za pomoc$ przypadków u#ycia zaobserwowali&my pewne wzorce opisowe, które mog$ by( u#yteczne z punktu widzenia opisów procesów biznesowych. Przypadki u#ycia prezentowane w literaturze s$ dedykowane do opisu interakcji cz'owieka z komputerem.. Ten poziom opisu dotyczy stosunkowo krótkich sesji trwaj$cych minuty lub godziny. Na poziomie procesów biznesowych przedzia'y czasowe mog$ trwa( nawet tygodnie lub lata. W rezultacie mo#na zaobserwowa( nowe zjawiska, nie wyst%puj$ce na poziomie interakcji cz'owiek-komputer, np. przekszta'canie jednego aktora w drugiego (metamorfoza aktora). Nast%pny rozdzia' zawiera krótkie wprowadzenie do przypadków u#ycia. Zaobserwowane zjawiska dotycz$ce aktorów s$ przedstawione w rozdziale 3. W trakcie pracy nad procesami biznesowymi bardzo wa#n$ spraw$ jest zrozumienie celu ka#dego procesu i jego kroków. W rozdziale 4 zaproponowali&my przypadek u#ycia z prologiem, w celu wyra#enia kroków, które s$ logicznie po'$czone z danym przypadkiem u#ycia, lecz musz$ by( wykonane przed jego g'ównym scenariuszem. Rozdzia' 5 omawia narz%dzie UC Workbench rozwijane na Politechnice Pozna"skiej, które s'u#y do wygodnego zarz$dzania przypadkami u#ycia.

3 Tytu' referatu 3 2. Przypadki u"ycia Przypadek u#ycia opisuje j%zykiem naturalnym interakcj% pomi%dzy aktorami. Najcz%&ciej jest to interakcja pomi%dzy systemem, a jego u#ytkownikami. Wtedy mamy do czynienia z opisywaniem wymaga" funkcjonalnych. W podobny sposób mo#emy zapisywa( procesy biznesowe. Przypadki u#ycia mog$ przyjmowa( ró#n$ form%. Najprostsza forma, to pojedyncze zdania opisuj$ce jedynie cel przypadku u#ycia. Z drugiej strony przypadek u#ycia mo#e by( w pe'ni ustrukturalizowany, opisuj$cy nie tylko zachowanie, lecz równie# zakres, warunki wst%pne, wyzwalacze, priorytety, czas odpowiedzi itp. (zobacz [1]). W kontek&cie procesów biznesowych nast%puj$ce informacje wydaj$ si% by( najwa#niejsze: - Nazwa przypadku u#ycia, okre&laj$ca cel biznesowy - Aktorzy bior$cy udzia' w przypadkach u#ycia (aktorem mo#e by( cz'owiek, urz$dzenie lub inny system) - G!ówny scenariusz opisuj$cy krok po kroku najcz%stsze zachowanie - Rozszerzenia dodaj$ce do kroków pewne zdarzenia, wraz z krokami alternatywnymi odpowiadaj$cymi tym zdarzeniom. Ta forma przypadków u#ycia wydaje si% by( najpowszechniejsza (por. [8,6,1,16]) Przyk'ad przypadku u#ycia jest zaprezentowany na rys. 1. Nazwa tego przypadku u#ycia brzmi: Zaliczanie semestru. Posiada on takich aktorów jak: Student i Dziekan (w rozdz. 3 omówimy ró#nice pomi%dzy aktorami g'ównymi i wspieraj$cymi). G'ówny scenariusz sk'ada si% z 5 kroków i towarzyszy mu jedno rozszerzenie. UC-1: Zaliczanie semestru G#ówny scenariusz 1. Student ucz%szcza na zaj%cia. 2. Dziekan wyznacza termin z'o#enia indeksów w Dziekanacie. 3. Student zalicza przedmioty i zdaje egzaminy. 4. Student odbywa praktyk% zawodow$. 5. Student oddaje indeks do Dziekanatu w terminie wyznaczonym przez Dziekanat. Rozszerzenia 4a. W danym semestrze nie ma praktyki zawodowej 4a1. Nast%puje przej&cie do kroku 5. Rysunek 1. Przypadek u#ycia opisuj$cy zaliczanie semestru przez studenta. Przypadek u#ycia sk'ada si% ze zbioru scenariuszy posiadaj$cych wspólny cel biznesowy. Ka#de rozszerzenie opisuje inny scenariusz. Przypadki u#ycia w formie przedstawionej na rys. 1 s$ pó'formalne. Maj$ posta( sekwencji kroków, dzi%ki czemu mo#na je automatycznie animowa( (zobacz [11,20]), lecz s$ wyra#one j%zykiem naturalnym, przez co staj$ si% bardziej zrozumia'e dla ludzi nie b%d$cych ekspertami w informatyce.

4 4 Autor Czytelnik mo#e si% zastanawia(, dlaczego przedstawia( procesy biznesowe za pomoc$ opisu tekstowego, zamiast zastosowa( notacje diagramowe, np. BPMN ([19,20]) lub UML ([23])? Z eksperymentów przeprowadzonych na Politechnice Pozna"skiej w 2005 roku wynika, i# przypadki u#ycia opisuj$ce procesy biznesowe s$ prostsze do zrozumienia ni# diagramy BPMN ([3]), tak wi%c ich zastosowanie wydaje si% by( uzasadnione. Przypadki u#ycia s$ czasem mylone z diagramami przypadków u#ycia w j%zyku UML (diagram pokazuje jedynie aktorów i nazwy przypadków u#ycia, lecz pomija g'ówny scenariusz i rozszerzenia) Dobre praktyki dotycz$ce przypadków u"ycia Pisanie dobrych przypadków u#ycia jest sztuk$ wymagaj$c$ do&wiadczenia. Mo#na jednak skorzysta( z dobrych zasad dot. przypadków u#ycia ([1]), aby ustrzec si% podstawowych b'%dów. Wybrane zasady zosta'y zamieszczone poni#ej. - Ma#yZespó#Autorów (ang. SmallWritingTeam). Wielko&( zespo'u pisz$cego przypadki u#ycia to najwa#niejszy czynnik wp'ywaj$cy na ich jako&(. W wi%kszo&ci sytuacji 2-3 osoby powinny by( wystarczaj$ce. - Udzia#Publiczno%ci (ang. ParticipatingAudience). Analitycy rzadko kiedy s$ ekspertami w dziedzinie, któr$ modeluj$. W zwi$zku z tym dobry model wymaga sprz%#enia zwrotnego ekspertów po stronie klienta. Takie osoby patrz$ na model z innej perspektywy i b%d$ w stanie znale)( wi%cej potencjalnych problemów. - Ró"neFormy (ang. MultipleForms). Przypadki u#ycia mog$ przyjmowa( ró#ne formy (patrz rozdz. 2). W zale#no&ci od potrzeby stopnia sformalizowania modelu mo#na wybra( zarys przypadku u#ycia, lub form% w pe'ni ustrukturalizowan$. - Szeroko%&PrzedG#'boko%ci$ i RozwójSpiralny (ang. BreadthBeforeDepth i SpiralDevelopment). Pozyskiwanie wymaga" jest procesem odkrywczym. Pisanie kompletnych przypadków u#ycia ju# na samym pocz$tku jest strat$ energii, gdy# jest du#e prawdopodobie"stwo i# takie przypadki u#ycia b%d$ si% cz%sto zmienia(. Zamiast tego nale#y zacz$( od pewnego tylko zarysu przypadku u#ycia i stopniowo dodawa( szczegó'ów, co pewien czas prosz$c klienta o sprz%#enie zwrotne. - Przegl$dDwupoziomowy (ang. TwoTierReview). Przegl$dy s$ konieczne do zapewnienia wysokiej jako&ci modelu. Model, stworzony przez analityków, musi by( przegl$dany przez szerokie grono recenzentów, zarówno po stronie dostawcy jak i klienta. W zwi$zku z tym warto przeprowadzi( przegl$dy dwupoziomowe. Pierwsze wewn%trzne, s$ przeprowadzane jedynie przez kilka osób, lecz powoduj$ znalezienie wi%kszo&ci defektów. Dzi%ki temu przegl$d zewn%trzny b%dzie si% odbywa' du#o sprawniej, gdy# wtedy recenzenci mog$ si% skupi( jedynie na istotnych b'%dach nie wykrytych wcze&niej.

5 Tytu' referatu 5 - FrazaCzasownikowaWNazwie (ang. VerbPhraseName). Nazwa przypadku u#ycia powinna w jak najlepszy sposób opisywa( jego tre&(. W zwi$zku z tym nie powinno si% stosowa( ogólnych, niewiele znacz$cych nazw (np. G'ówny przypadek u#ycia), lecz fraz% czasownikow$ (np. Przebieg projektu InMoST, Publikowanie artyku!ów) 3. Aktorzy Powszechnie wiadomo, w jaki sposób stosowa( przypadki u#ycia do opisu interakcji pomi%dzy cz'owiekiem a systemem (HCI, ang. Human-Computer Interaction) na poziomie funkcjonalnym (zobacz np. [4,1]). Jednak#e jest znaczna ró#nica pomi%dzy HCI, a modelami biznesowymi. Procesy HCI trwaj$ kilka minut (w niektórych sytuacjach kilka godzin), natomiast procesy biznesowe mog$ trwa( tygodnie, miesi$ce lub nawet lata (Cockburn nazywa poziom procesów biznesowych poziomem podsumowania [4]). W trakcie tworzenia przypadków u#ycia do opisu procesów biznesowych, zaobserwowali&my ró#nego rodzaju zjawiska dotycz$ce aktorów. Te zjawiska chcieli&my opisa( w bie#$cym rozdziale Aktorzy g#ówni i wspieraj$cy Przypadki u#ycia poziomu HCI zawieraj$ aktorów dwojakiego rodzaju: g'ównych i pobocznych. G'ówny aktora, to aktor który pragnie co& uzyska( od systemu w danym momencie [1]. Aktor poboczny to najcz%&ciej urz$dzenie lub system zewn%trzny (np. us'ugi WebServices). Podobne rozró#nienie mo#na zrobi( dla biznesowych przypadków u#ycia. U#yteczne okaza'o si% rozró#nienie na aktorów g'ównych i wspieraj$cych. Za'ó#my, i# pewna osoba my&li o zbudowaniu systemu informatycznego dla gabinetu dentystycznego. Analityk biznesowy zidentyfikowa' trzy role: dentysta, pacjent i sekretarka. Prawdziwa interakcja na poziomie biznesowym zachodzi pomi%dzy dentyst$, a pacjentem sekretarka ma rol% wspieraj$c$. Tak wi%c dentysta i pacjent byliby aktorami g'ównymi, natomiast sekretarka wspieraj$cym. Rozró#nienie pomi%dzy aktorami g'ównymi, a wspieraj$cymi pozwala 'atwiej zrozumie( i zamodelowa( procesy, zanim system komputerowy zostanie wyspecyfikowany i zaimplementowany. G'ówni aktorzy s$ niezast$pieni i nie mog$ by( usuni%ci po wprowadzeniu systemu informatycznego, natomiast rola aktorów wspieraj$cych nie jest wymagana i mo#e by( 'atwo zmieniona lub nawet wymieniona na now$ technologi%.

6 6 Autor 3.2. Aktorzy zbiorowi Na poziomie HCI wyst%puje tylko jedna osoba w danym momencie. W momencie specyfikowania modeli biznesowych, pojawiaj$ si% wiele sytuacji w których krok jest wykonywany przez grup% osób. Przyk'adowo na uniwersytecie wiele decyzji jest podejmowanych przez Rad% Wydzia'u Aktorzy tworzeni dynamicznie Na poziomie HCI aktorzy s$ statyczni. Aktor istnieje zanim dany przypadek u#ycia jest wywo'any i zostaje w systemie do ko"ca wykonywania tego przypadku u#ycia. Poziom biznesowy opisuje procesy, które trwaj$ du#o d'u#ej, zdarzaj$ si% wi%c przypadki u#ycia, w trakcie których powstaje nowy aktor. PRINCE2 to bardzo popularna metodyka zarz$dzania projektami [10]. Mapa procesów PRINCE2 jest przedstawiona na rys. 2. Rysunek 2. Mapa procesów dla metodyki PRINCE2 (zgodnie z [10]). Pierwszy problem jaki si% pojawia: w jaki sposób ten 2-wymiarowy opis przedstawi( za pomoc$ sekwencji kroków przypadków u#ycia. Nale#y pami%ta( i# modelowanie jest &ci&le zwi$zane z uogólnianiem. Sztuk$ jest pomijanie nieistotnych detali. W tym przypadku nale#y si% skupi( na sekwencji procesów SU + IP + (SB & CS) + CP. Wtedy odpowiadaj$cy przypadek u#ycia mo#e wygl$da( nast%puj$co: UC-1: Prowadzenie projektu wg metodyki PRINCE 2 G#ówny scenariusz 1. Rozpocz%cie projektu (SU). 2. Inicjacja projektu (IP). 3. Wykonywanie etapu. 4. Zamykanie projektu (CP) Rozszerzenia 3a. Jest potrzebny dodatkowy etap. 3a1. Krok 3 jest powtarzany. Rysunek 3. Przypadek u#ycia opisuj$cy zarz$dzanie projektem wg PRINCE2.

7 Tytu' referatu 7 Najwa#niejsza wada przypadku u#ycia z rys. 3. to fakt, i# nie specyfikuje on, kto powinien wykona( dany krok. Mo#na dopisa( Kto& na pocz$tku ka#dego kroku, lecz by'aby to tylko sztuczka syntaktyczna. Inna mo#liwo&( to dopisanie Zespo'u Zarz$dzania Projektem (PMT ang. Project Management Team). Lecz PMT jest tworzony podczas fazy Rozpocz%cia projektu (SU). Nie mo#e wykonywa( tego kroku, skoro jeszcze nie istnieje. Aby znale)( rozwi$zanie nale#y przyjrze( si% fazie SU. Pokazana jest ona na rys. 4. Rysunek 4. Rozpocz%cie projektu (SU) w PRINCE2. Skrót PM oznacza kierownika projektu (ang. Project Manager). Jednak#e, zwi%kszenie poziomu szczegó'owo&ci i opisywanie ka#dego z podprocesów jako krok (SU1,..., SU6, IP1,..., IP6 itd.) skutkowa'oby bardzo d'ugimi scenariuszami g'ównymi (zgodnie ze wzorcami przypadków u#ycia [1] g'ówny scenariusz powinien zawiera( od 3 do 9 kroków). Aby rozwi$za( ten problem mo#na wy'$czy( podprocesy SU1, SU2 i SU3 z procesu SU oraz umie&ci( je na wy#szym poziomie w przypadku u#ycia UC-1 (podprocesy SU2 i SU3 zosta'y po'$czone w jeden krok), tak jak pokazano to na rys. 5. UC-2: Prowadzenie projektu wg metodyki PRINCE 2 G#ówni aktorzy: Klient, Dostawca Aktorzy wspieraj$cy: Przew.Komitetu Steruj$cego, Kierownik Projektu, Zespó' Zarz$dzania G#ówny scenariusz 1. Klient i Dostawca powo'uj$ Przew. Komitetu Steruj$cego i Kierownika Projektu (SU1). 2. Przewodnicz$cy i Kierownik Projektu kompletuj$ Zespó' Zarz$dzania (SU2, SU3). 3. Zespó' Zarz$dzania kontynuuje rozpocz%cie projektu (SU4 SU6). 4. Zespó' Zarz$dzania inicjuje projekt (IP). 5. Zespó' Zarz$dzania kontroluje etap. 6. Zespó' Zarz$dzania zamyka projekt (CP). Rozszerzenia 5a. Jest potrzebny jeszcze jeden etap. 5a1. Krok 5 jest powtarzany. Rysunek 5. Poprawiona wersja przypadku u#ycia z rys. 3.

8 8 Autor 3.4. Metamorfoza aktorów Za'ó#my, i# budujemy system zarz$dzania informacj$ dla uniwersytetu. Jednym z g'ównych aktorów b%dzie osoba chc$ca uzyska( dyplom na uniwersytecie. Na pocz$tku osoba ta jest tylko kandydatem, nast%pnie jest ona przyj%ta a# w ko"cu staje si% studentem (po otrzymaniu indeksu i legitymacji studenckiej). Po zdaniu wszystkich egzaminów i obronieniu pracy dyplomowej staje si% absolwentem. Na Politechnice Pozna"skiej istniej$ równie# wolni s'uchacze. Taki s'uchacz mo#e sta( si% normalnym studentem od drugiego roku. Je#eli student nie wywi$#e si% ze swoich zobowi$za" mo#e zosta( skre&lony z listy studentów. Taka metamorfoza mo#e by( przedstawiona za pomoc$ automatu sko"czonego z rys. 6, natomiast rys. 7 przedstawia odpowiadaj$cy przypadek u#ycia. Rysunek 6. Automat sko"czony pokazuj$cy mo#liwe przekszta'cenia aktora. UC-3: Uzyskanie dyplomu G#ówni aktorzy: Aktorzy {Kandydat alias Przyj%ty alias Student alias Absolwent alias Wolny Student alias Usuni%ty} Wspieraj$cy aktorzy: Senat, Rektor, Komisja Rekrutacyjna, Uniwersytet G#ówny scenariusz 1. Senat okre&la regu'y dotycz$ce przyjmowania studentów. 2. Rektor powo'uje Komisj% Rekrutacyjn$. 3. Uniwersytet organizuje drzwi otwarte. 4. Kandydat sk'ada podanie. 5. Komisja Rekrutacyjna obwieszcza list% osób przyj%tych. Kandydat zostaje Przyj%ty. 6. Osoba Przyj%ta zaczyna studiowa(. Osoba przyj%ta staje si' Studentem. 7. Student ko"czy pomy&lnie semestry Student podchodzi do egzaminu dyplomowego. Student zostaje Absolwentem. 9. Absolwent otrzymuje dyplom. Rozszerzenia 5a. Kandydat nie mo#e by( przyj%ty z powodu ograniczonej liczby miejsc. 5a1. Kandydat studiuje jako Wolny Student. Powrót do kroku 8. Rysunek 7. Przypadek u#ycia z metamorfoz$ aktorów.

9 Tytu' referatu 9 4. Scenariusze z prologiem W modelowaniu biznesowym procesy s$ g'ówn$ cz%&ci$ opisu (pozosta'e elementy to aktorzy i obiekty informacyjne). Zrozumienie opisu biznesowego wymaga nie tylko zrozumienia w jaki sposób procesy s$ wykonywane, lecz równie# dlaczego. Adolph [1] pisze: system jest niew!a"ciwy je#eli nie dostarcza us!ug, które s$ warto"ciowe dla u#ytkowników. Parafrazuj$c to zdanie mo#na powiedzie(, #e procesy biznesowe s$ niew'a&ciwe, je#eli nie dostarczaj$ us'ug warto&ciowych dla g'ównych aktorów. Dobry sposób zapisu procesów biznesowych powinien wi%c wspiera( zrozumienie celu ka#dego procesu. Z tego punktu widzenia klasyczne przypadki u#ycia maj$ pewne s'abo&ci przedyskutowane poni#ej. Za'ó#my, #e chcemy kontynuowa( rozwój modelu biznesowego dla uniwersytetu, zarysowanego w roz. 3.4 (zobacz przypadek u#ycia UC-3). Za'ó#my, #e chcemy opisa( krok 8 (zaliczanie semestru). Opis móg'by zawiera( kroki z g'ównego scenariusza przypadku u#ycia UC-4 (rys. 8). Jednak#e ta sekwencja kroków nie pokazuje czynno&ci, jakie musz$ by( wykonane zanim student zaczyna semestr. Proponujemy rozszerzenie formy opisu przypadku u#ycia poprzez dodanie prologu. Prolog okre&la sekwencj% czynno&ci, jakie musz$ by( wykonane przed g'ównym scenariuszem (mo#na równie# pomy&le( o symetrycznym rozszerzeniu epilogu lecz do tej pory nie znale)li&my przyk'adu pokazuj$cego u#yteczno&( takiego rozszerzenia). Rysunek 8 opisuje zaliczenie semestru oraz, w formie prologu, wszystkie czynno&ci, jakie musz$ by( wcze&niej wykonane. UC-4: Zaliczanie semestru G#ówny aktor: Student lub Wolny S'uchacz Aktorzy wspieraj$cy: Rektor, Kierownik Jednostki, Rada Wydzia'u Prolog 1. Rada Wydzia'u uchwala program studiów. 2. Dziekan przydziela zaj%cia do zainteresowanych jednostek i ustala osoby odpowiedzialne za przedmiot. 3. Co najmniej tydzie" przed rozpocz%ciem semestru Dziekan og'asza szczegó'owy rozk'ad zaj%( G#ówny scenariusz 4. Student lub Wolny S'uchacz ucz%szcza na zaj%cia. 5. Dziekan ustala termin z'o#enia indeksów w dziekanacie. 6. Student lub Wolny S'uchacz zdaje egzaminy i zdobywa punkty. 7. Student lub Wolny S'uchacz odbywa praktyk% zawodow$. 8. Student lub Wolny S'uchacz sk'ada indeks w dziekanacie. Rozszerzenia 7a. Na danym semestrze nie ma obowi$zkowej praktyki zawodowej. 7a1. Przej&cie do kroku Rysunek 8. Przypadek u#ycia z prologiem.

10 10 Autor 5. UC Workbench UC Workbench to narz%dzie rozwijane od dwóch lat na Politechnice Pozna"skiej. Pocz$tkowo mia'o s'u#y( wspomaganiu pracy analityka podczas edycji wymaga" u#ytkownika, czyli pomaga( w edycji przypadków u#ycia, generowaniu prototypu funkcjonalnego, szacowaniu pracoch'onno&ci wymaga" [15]. Podczas edycji wymaga" analityk mo#e pod'$czy( pod poszczególne kroki przypadków u#ycia szkice ekranów aplikacji i na tej podstawie wygenerowa( makiet% wymaga". T$ sam$ funkcjonalno&( mo#na wykorzysta( podczas pracy nad biznesowymi przypadkami u#ycia. Tym razem zamiast szkiców projektów ekranów mo#emy do'$czy( diagramy (np. BPMN, UML) obrazuj$ce poszczególne procesy biznesowe (rys. 9). Rysunek 9. Makieta procesu biznesowego z odpowiadaj$cym diagramem BPMN. Dodatkowo UC Workbench umo#liwia wygenerowanie papierowej dokumentacji procesów biznesowych, na podstawie przypadków u#ycia. Taki dokument zawiera nast%puj$ce rozdzia'y: 1. Wprowadzenie 2. Aktorzy 3. Procesy biznesowe 4. Obiekty informacyjne G'ówn$ zalet$ takiego podej&cia jest wystarczy zmieni( jaki& przypadek u#ycia, a system automatycznie zmieni makiet% i dokument.

11 Tytu' referatu Podsumowanie Artyku' przedstawia pewne problemy zwi$zane z opisywaniem procesów biznesowych z wykorzystaniem przypadków u#ycia. Eksperymenty przeprowadzone na Politechnice Pozna"skiej pokaza'y, i# przypadki u#ycia s$ prostsze do zrozumienia ni# diagramy BPMN, wi%c ich wykorzystanie wydaje si% by( uzasadnione. Podczas przygotowywania modeli biznesowych zauwa#yli&my wiele zjawisk dotycz$cych aktorów. D'ugo&( trwania procesów biznesowych jest zdecydowanie wi%ksza od d'ugo&ci trwania sesji interakcji pomi%dzy cz'owiekiem a systemem (ang. HCI Human- Computer Interaction), dlatego mo#na zaobserwowa( np. aktorów tworzonych dynamicznie lub metamorfoz% aktorów (rozdz. 3). Kolejnym zaproponowanym rozszerzeniem jest prolog, który umo#liwia pokazanie kontekstu dla danego przypadku u#ycia. LITERATURA 1. Adolph S., Bramble P., Cockburn A., Pols A.: Patterns for Effective Use Cases. Addison- Wesley (2002) 2. Burns, A., Wellings, A. J.: HRT-HOOD: a structured design method for hard real-time systems, Real-Time Systems, Volume 6, Issue 1, p , January Business Process Modeling Notation Version 1.0, May 2004 ( 4. Cockburn A.: Writing Effective Use Cases. Addison-Wesley (2000) 5. Douglas C.: Introduction to Statistical Quality Control, Third Edition. Wiley & Sons (1997) 6. Fowler M., Scott K.: UML Distilled. Addison-Wesley (2000) 7. IEEE Guide for Information Technology System Definition Concept of Operations (ConOps) Document, IEEE Std , March Jacobson I., Christerson M., Jonsson P., Overgaard G.: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, Reading MA (1992) 9. Kruchten, P.: The Rational Unified Process: An Introduction (2nd Edition). Addison- Wesley (2000) 10. Managing Successful Projects with PRINCE2. The Stationery Office Books (2002) 11. Nawrocki J., Olek!.: A Tool for Use-Case Engineering. Extreme Programming and Agile Methodologies 2005, Lecture Notes in Computer Science 3556, OMG Unified Modeling Language Specification Version 1.5, March 2003 (

12 12 Autor 13. Penker M., Eriksson H. E.: Business Modeling With UML: Business Patterns at Work. Addison-Wesley (2000) 14. Reisig W.: Petri Nets, An Introduction. EATCS, Monographs on Theoretical Computer Science, W.Brauer, G. Rozenberg, A. Salomaa (Eds.), Springer Verlag, Berlin (1985) 15. Ribu K.: Estimating Object-Oriented Software Projects With Use Cases. Master of Science Thesis. University of Oslo (2001) 16. Schneider G., Winters J. P.: Applying Use Cases: A Practical Guide. Addison-Wesley (1998) 17. Harel D.: Statecharts: A visual formalism for complex systems. Weizmann Institute of Science, Dept. of Computer Science (1986) 18. White S.: BPMN and Business Process Management: Nawrocki J., Olek L.: Use Cases Engineering with UC Workbench. in Zielinski K., Szmuc T. (eds): Software Engineering: Evolution and Emerging Technologies, IOS Press 2005, Nawrocki J., N%dza T., Ochodek M., Olek!.: Describing Business Processes with Use Cases, 9th International Conference on Business Information Systems, Lecture Notes in Computer Science, in print. 22. Pilone D., Pitman N.: UML 2.0 in a Nutshell. O Reilly (2005).