Kdy použít v Use Case Diagramu vztah Extend a kdy Include (část 2), příklad na Extend

Tento článek je pokračováním předešlého textu, viz zde.  Ukážeme si nyní velmi názorný a vysvětlující příklad na použití vztahu Extend.

Nechť při řešení bankovního systému řešíme případ užití nazvaný jako Zaúčtování převodního příkazu. V tomto případu užití dojde ke změně zůstatku na klientově účtu. O této změně se některé jiné agendy musí dozvědět, například na tuto změnu musí zareagovat agenda úvěrů, agenda termínovaných vkladů, agenda notifikací (SMS a email apod.) a případně další.

Jednou z možností, jak vyřešit tento požadavek, je zavolání agend přímo a natvrdo. V tom případě by se ve scénáři případu užití objevilo trojí použití případů užití, nazvěme je například Reakce na změnu zůstatku v úvěrech, Reakce na změnu zůstatku v termínovaných vkladech a Reakce na změnu zůstatku notifikace.

Scénář případu užití Zaúčtování převodního příkazu by pak vypadal např. takto:

// bod po změně zůstatku účtu
dále se použijí případy užití
UC Reakce na změnu zůstatku v úvěrech,
UC Reakce na změnu zůstatku v termínovaných vkladech,
UC Reakce na změnu zůstatku v notifikacích
a tak by byl i program navržen, tj. jako trojí přímé volání buď funkcí anebo jako trojí zavolání metod nějakých objektů.

V tomto řešení by se v Use Case diagramu objevily tři interakce Include se směrem závislosti od případu užití Zaúčtování převodního příkazu směrem k reakcím:

Toto řešení je sice funkční, ale bohužel není dobře.

1. Jednak došlo k nežádoucí vazbě od agendy starající se o zaúčtování převodního příkazu ke třem různým „vzdáleným“ agendám, což je přesně proti požadované modularitě systému. Opakováním tohoto postupu vzniká v kódu tzv. „špagety efekt“ (resp. „makaron efekt“), kdy posloupnost kódu prochází spoustou agend jako špageta. Nakonec je všechen kód do sebe zašmodrchán v nepřehledných propletencích, což se nejenže špatně vyvíjí, ale i velmi obtížně testuje.
2. Agenda Převodní příkazy je v podstatě stále otevřena a nikdy není dokončena. To je pro řízení projektu a pro postupy vývoje fatální problém. V průběhu vývoje se přidávají další a další reakce na změnu zůstatku, jednak od jedné verze produktu k vyšší verzi (např. v první verzi byla navržena jen jedna reakce na změnu zůstatku, v dalších verzích systému s přidáním dalších modulů byly navrženy další reakce), ale také při samotném vývoji. Co je ale obzvlášť nepříjemné, je to, že neustálé zasahování do již existujícího hotového kódu je doslova zabijákem agilního vývoje. Například při nasazení metodiky SCRUM u každého nového sprintu se bude s každou novou agendou úplně zbytečně znovu otevírat kód již hotové agendy Převodních příkazů, bude se přeprogramovávat a testovat.

Navrhneme tedy již v analytickém modelu jiné a lepší řešení a to buď pomocí Extend anebo Generalizace. Pokud zvolíme interakci Extend, postupujeme takto:

Jako první krok zavedeme u případu užití Zaúčtování převodního příkazu tzv. Extension Point, který slouží jako styčný prvek mezi extendovanými a extendujícími  případy užití. Jedná se vlastně o zavedení již zmíněného „háčku”, ke kterému se extendující případy užití navážou svými interakcemi Extend. Tento Extension Point nazveme v našem příkladu nejlépe jako Změna zůstatku. Poté vyvedeme interakci Extend od extendujících případů užití (tj. od reakcí) k extendovanému případem užití (tj. zaúčtování) a můžeme také vyznačit, že daná extenze je přiřazena k bodu Extension Point Změna zůstatku:

Osobně však pro určitou nepřehlednost diagramu nedoporučuji malovat diagram takto striktně, ale přehledněji a jednodušeji pomocí Note takto:

Ve scénáři případu užití Zaúčtování převodního příkazu se v našem příkladu nasazení Extend objeví formulace v tomto duchu:

//bod změny zůstatku
a dále se provedou všechny případy užití, které extendují daný případ užití v bodě Extension Point = [změna zůstatku]

Všimněte si, že v této formulaci se případy užití nevyjmenovávají přímo, ale oslovují se nepřímo jako ty, které jsou v interakci Extend v „opačném garde“ přivázány k danému případu užití.

Poznámky k nástroji EA:

• Přidání prvku Extension Point najdete po kliknutí na daný případ užití pravým tlačítkem myši
• Pokud chcete smazat z diagramu daný vygenerovaný Note, který udává, ke kterému Extension Point je Extend vázán, musíte nejprve vypnout checkbox Lock po kliknutí na pravé tlačítko myši u tohoto Note

Tato formulace je také zadáním do programování, tj. programátor by měl v tomto příkladu využít některou z programovacích technik, které splní toto zadání ve smyslu požadované nezávislosti extendovaného případu užití na extendujících.

V další části článku si ukážeme několik možností, jak technologicky realizovat vztah Extend.