UML diagramy prípadov použitia

Diagram prípadov použitia je mapa rozsahu. Pomenúva ľudí a systémy, ktoré komunikujú s tým, čo staviate, ciele, s ktorými k tomu prichádzajú, a čiaru medzi vnútrom a vonkajškom. To je všetko, čo robí, a práve jeho zdržanlivosť je zmyslom.

Nehovorí nič o poradí. Nič o obrazovkách, poliach či algoritmoch. Nič o tom, ako čokoľvek funguje. Každé z toho je iný diagram a pokušenie prepašovať ich na tento je to, čo vyrába rozbujnené a nepoužiteľné diagramy prípadov použitia, ktoré tejto notácii urobili zlé meno.

Zoznam vám nikto nedá. Diagram vyššie vyzerá po nakreslení samozrejme a predtým samozrejmý vôbec nebol; medzeru medzi prázdnym papierom a tým obrázkom vyplnia štyri otázky, ktoré sa v miestnosti dajú položiť za dvadsať minút.

1. Kto tu niečo začína? Každý z nich je kandidát na primárneho aktéra. Pýtajte sa na rolu, nie na meno - človek, ktorý povedal „to robím ja“, je jedným nositeľom roly, ktorá ho prežije.
2. Kto alebo čo niečo dostáva bez toho, aby o to žiadal? Reporty, súbory, notifikácie, zúčtovacie behy. Toto sú podporní aktéri na pravej strane hranice a je to tá polovica diagramu, ktorá väčšine prvých návrhov chýba.
3. Čo tam musí byť, aby to fungovalo? Platobní poskytovatelia, identitné služby, mainframe, protipodvodný engine. Čokoľvek, kvôli čomu by ste zakladali ticket inému tímu, je mimo hranice a patrí na diagram - jeho nakreslenie býva okamihom, keď si niekto uvedomí, že tá závislosť nikdy nebola dohodnutá.
4. Čo sa deje preto, že ubehol čas? Nočná rekonciliácia, štrnásťdňová expirácia, mesačná fakturácia. Čas je aktér, kreslí sa ako panáčik s popisom Clock alebo Scheduler, a procesy, ktoré ho vynechajú, končia s prípadmi použitia, ktoré zdanlivo nikto nezačína.

Potom pomenujte každý cieľ z aktérovej strany pultu, slovesom napred, jeho slovníkom: Submit payment, nie Payment submission handling a už vôbec nie PaymentController. Ak názov dáva zmysel len niekomu, kto videl kód, je to krok v prípade použitia, nie prípad použitia.

Tieto dva sú dôvodom, prečo sa diagramy prípadov použitia kreslia zle. Oba sú prerušované šípky s kľúčovým slovom a ukazujú opačnými smermi.

«include» ukazuje od základného prípadu k tomu, čo vždy robí. Čítajte to ako „volá“. V diagrame vyššie Submit payment zahŕňa Authorize payment: nedá sa odoslať bez autorizácie. Existuje na to, aby vyňal správanie zdieľané viacerými prípadmi - a presne preto ho zahŕňa aj Refund payment.

«extend» ukazuje od nepovinného doplnku späť k základnému prípadu. Čítajte to ako „môže prerušiť“. Log audit trail rozširuje Refund payment: refundácie fungujú aj bez neho a deje sa za istej podmienky. Základný prípad o svojich rozšíreniach nevie.

Diagram je obsah knihy. To, z čoho sa naozaj stavia, je popis prípadu použitia za každou elipsou - a projekt, ktorý nakreslí diagram a popisy nikdy nenapíše, vyrobil obrázok práce namiesto jej špecifikácie. Práve o tejto časti notácia nehovorí nič, a preto toľko tímov zostane pri obrázku.

Existujú tri užitočné hĺbky a výber je rozhodnutie projektu, nie modelovania. Stručný popis sú dve vety v backlogu. Voľný je odsek na scenár. Plne rozvinutý má polia nižšie a oplatí sa pri tej hŕstke prípadov, ktoré nesú skutočné peniaze alebo skutočné riziko.

• Názov. Popis elipsy, sloveso napred: Authorize payment.
• Primárny aktér. Ten, kto chce výsledok. Merchant.
• Zainteresovaní a ich záujmy. Komu ďalšiemu na tom záleží a čo z toho potrebuje. Akvizičná banka chce platný autorizačný kód; protipodvodný tím chce mať pokus zaznamenaný bez ohľadu na to, či uspel. V tomto poli sa objaví väčšina chýbajúcich požiadaviek.
• Predpoklady. Čo už platí, keď sa prípad začína - obchodník je prihlásený, objednávka existuje. Nie zoznam krokov, ale zoznam záruk.
• Hlavný úspešný scenár. Očíslovaná šťastná cesta, krok aktéra a potom krok systému, v jazyku biznisu. Niekde medzi piatimi a dvanástimi krokmi; viac znamená, že prípad použitia sú v skutočnosti dva.
• Rozšírenia. Očíslované podľa kroku, z ktorého sa vetvia - 4a, 4b, 7a - každé s podmienkou a s tým, čo sa stane. Toto je pole, kvôli ktorému sa formát oplatí, lebo je systematickou pobádkou pre každý spôsob, akým šťastná cesta zlyhá.
• Následné podmienky. Čo platí potom, pri úspechu aj pri každom zlyhaní. „Autorizácia je zaznamenaná a prostriedky sú blokované“ sa dá otestovať spôsobom, akým „platba je spracovaná“ nie.

Rozpracované v malom pre Authorize payment: hlavný úspešný scenár je (1) obchodník odošle platbu, (2) systém overí sumu objednávky, (3) systém požiada akvizičnú banku o autorizáciu, (4) banka vráti schválenie, (5) systém zaznamená blokáciu a potvrdí. Práca je v rozšíreniach - 3a banke vyprší čas, 4a banka zamietne, 4b banka si vyžiada dodatočné overenie - a každé z nich je rozhovor, ktorý by inak niekto viedol o šesť týždňov neskôr pri triáži chýb.

Užitočný diagram prípadov použitia sa zmestí na jednu stranu a má niekde medzi tromi a desiatimi elipsami. Je to obsah, nie kniha. Detail patrí do popisov prípadov použitia - očíslovaného hlavného toku a jeho alternatív - alebo, ak je tok dosť vetviaci na to, aby sa oplatilo ho nakresliť, do diagramu aktivít na každý prípad.

1. Funkčný rozklad. Dvadsať elíps pomenovaných podľa tlačidiel. Prípady použitia sú ciele; ak to nie je niečo, čo aktér chce, nepatrí to sem.
2. Aktéri pomenovaní podľa ľudí alebo pozícií z organigramu. Modelujte rolu. Jeden človek môže byť viacerými aktérmi a jeden aktér môže byť dávková úloha.
3. Prehodené šípky «include» a «extend». Ukazujú opačne. Použite test odstránenia z vyššie uvedeného.
4. Aktéri vnútri hranice. Hranica je to, čo staviate. Aktér je z definície mimo nej.
5. Poradie naznačené zvislou pozíciou. Diagram prípadov použitia nemá časovú os. Nič na rozložení nehovorí, čo sa deje skôr.