V předešlém článku (viz zde) byl popsán rozdíl mezi prvky typu User Story (zavedené v agilních technikách vývoje) a prvky typu Use Case (zavedené v UML). Současně byl také vysvětlen jejich přímý vztah v souvislosti s vývojem IS.
Následující článek má za cíl ukázat, jak lze rychle a efektivně vyhledávat případy užití procesní školou (BPMN 2.0). Navíc poslouží také jako dobrý příklad na použití prvku v BPMN 2.0 zvaného Parallel Gateway.
Ukázkový příklad nemůže být příliš rozsáhlý, proto si ohledně požadavků na systém dovolíme určitá zjednodušení, která však neuberou na relevanci příkladu. Současně si ukážeme, jak uvažuje analytik v případě, že by se tento systém dále rozvíjel, tj. jaké otázky pro něj a Product Ownera vyvstávají v rámci dalších rozšiřujících funkcionalit na základě znalostí již vyřešených částí systému.
Jako příklad zvolme jednoduchý systém určený pro malá knihkupectví, která chtějí dodávat knihy na dobírku. V rámci úvodních požadavků zaznělo, že za knihy se (zatím) nebude platit ani kartou a ani pomocí převodního příkazu, ale pouze poštovní dobírkou.
Naším úkolem bude navrhnout chod procesu od objednání knih až po jejich odeslání poštou a současně odhalit funkcionality vyvíjeného systému, tj. nalézt případy užití, které budou tento chod procesu podporovat.
Jako první krok naší práce se snažíme ve spolupráci s Product Ownerem (tj. s budoucím uživatelem systému) nalézt jednoduchý děj chodu objednávky v textovém tvaru, což se někdy nazývá příznačně také jako epic (epic se chápe jako posloupnost několika User story, viz předešlý článek).
Nechť jsme se po vcelku krátké diskusi s Product Ownerem (například) shodli na následujícím textu epicu, který je zde v příkladu doplněn i o otázky, které během konzultace jakože zazněly:
Epic chodu objednávky knih na dobírku:
Zákazník pošle objednávku na knihy buď poštou, mailem, faxem resp. telefonicky, obsluha ji zadá do systému. (poznámka: Zde byl v našem modelovém příkladu opakovaně položen dotaz a následně potvrzeno, že zákazník nebude tuto objednávku vystavovat sám přes náš systém, ale činí tak obsluha, která přepisuje údaje z jiného nosiče do systému).
Při vystavení objednávky se zarezervují na skladě objednané knihy v daném počtu.
(poznámka:následuje dotaz analytika, zda se mohou vyřizovat objednávky částečně, odpověď Product Ownera: nikoliv, při zakládání objednávky obsluha uvidí stav knih na skladě a vloží se pouze taková objednávka, která může být naplněna celá rezervací všech knih, jiné čekají mimo systém. V příští verzi bude vypracován mechanismus částečných naplnění objednávky rezervacemi).
Po založení objednávky v dalším kroku současně účetní v účtárně vystaví fakturu a vytiskne ji, přitom skladník ve skladu k této objednávce vyskladní rezervované knihy, což se také zaeviduje.
Vyskladněné knihy a vytištěná faktura se poté „sejdou“ na jednom stole a dojde ke kompletaci do balíku, což se také zaeviduje.
Následně se balík odevzdá na poštu, což se také zaeviduje.(poznámka: Dotaz analytika, zda se bude evidovat „odchod na poštu“ jako jeden krok a „odeslání“ jako krok druhý, odpověď nikoliv, bude se evidovat pouze zdárné odeslání balíku)
Tímto v našem příkladu končí epik od podání objednávky až po podání knihy na poštu. Je zřejmé, že proces by pokračoval dalšími kroky (kontrola plateb za dobírku apod.), ale to je předmětem dalšího vyššího chodu procesu (např. proces nazvaný Chod zpracování odeslaných knih), který zde v tomto příkladu již neřešíme.
Máme nyní k dispozici text epicu, sice hodně nahrubo, ale už se rýsuje celková logika chodu procesu.
Nyní analytik v součinnosti s Product Ownerem rozdělí text epicu na jednotlivé „děje venku“ před voláním případů užití a na odpovídající „děje uvnitř“ případ užití, čímž vyčlení volané případy užití a dá jim odpovídající nejvhodnější název. Nechť tedy pomocí tohoto postupu po určité diskusi s Product Ownerem vznikne následující diagram v UML (BPMN + UCM), kde jsou již děje rozděleny a případy užití identifikovány:
Zpracovaný chod procesu v syntaxi BPMN i s odpovídajícími prvky Use Case
Všimněme si na předcházejícím obrázku několika zajímavých skutečností:
1. Oddělením prvků Use Case z User Story (přesněji z epicu, které jsou složené z několika po sobě resp. paralelně jdoucích User Story) vznikly první artefakty týkající se funkcionalit systému – případy užití, které se budou navrhovat v dané technologii a programovat. S trochou nadsázky řečeno „elipsy vpravo se programují“, procesy vlevo nikoliv.
2. Současně na diagramu vidíme přehledně a jasně znázorněný chod procesu podniku včetně volání prvků Use Case, takže diagram velice transparentně zobrazuje informaci pro Product Ownera ve smyslu „takto se budete chovat a přitom budete takto používat systém“.
3. Diagram odpovídá přesně danému textu epicu, ze kterého se na počátku vyšlo, takže epic se tak stává po dalším zpracování doprovodným komentářem tohoto diagramu.
4. Příklad je také zajímavou ukázkou na použití prvku Parallel Gateway a to jak při rozdělení putujících elementů „token“, tak i při jejich slití.
Jako další krok následuje bližší specifikace scénářů uvnitř případů užití. Nutná logika scénářů musí odpovídat požadavkům na další chod procesů. Například při založení objednávky musí obsluha samozřejmě zadat údaje klienta a je třeba hned na začátku úvah rozhodnout, zda se bude jednat o výběr ze seznamu klientů (viz vztah Odkaz do seznamu) anebo v jednoduché verzi o kompozici (s každou objednávkou se klient zadává znovu). Samozřejmě v objednávce se musí nějak objevit poštovní adresa (aby bylo známo kam knihy poslat), také je zřejmé, že je třeba při objednávce zadat knižní tituly, což by mělo být výběrem ze seznamu (jinak se obsluha zadávající objednávku nemusí shodnout se skladníkem) a musí se zadat počet požadovaných kusů. Navíc pokud je klient podnikající subjekt, vyžaduje se zadat i jeho účetní údaje atd.
Závěr
Všimněme si, že postup analytika v součinnosti s Product Ownerem má svou přesnou logiku: Snažíme se nejprve od Product Ownera získat takové informace, které je schopen nám dát, což je textový tvar epicu (nikoliv modely v UML), následným upřesňováním dospějeme k nalezení případů užití až po přesnou specifikaci algoritmu programu (scénáře případů užití).
Současně tímto postupem získáme nejen textový tvar chodu procesu (epic), ale také i názorný diagram, jak se bude obsluha chovat a jak přitom bude používat systém.
konec článku
Napsat komentář