Článek 66

ROZDÍL MEZI VZTAHEM EXTEND A
INCLUDE V USE CASE DIAGRAMECH
3. část
RNDr. Ilja Kraval, srpen 2009
http://www.objects.cz
ÚVOD
Tento článek je pokračováním předešlých článků. Článek vysvětluje použití vztahu «extend»
v diagramech případů užití a ukazuje jeho možné technologické realizace. Jak bylo řečeno
v předešlých částech tohoto mini-seriálu, interakce «extend» se používá na rozdíl od
interakce «include» tam, kde případ užití volající (rozšiřovaný) nemá být závislý na případu
užití vyvolaném (rozšiřujícím). V praxi to znamená, že samotný scénář by neměl správně
obsahovat odkaz na rozšiřující případ užití.
Technický rozdíl ve vlastnostech obou interakcí je tedy zřejmý, zůstávají nám nyní
k zodpovězení tyto dvě otázky:
1. V jakých konkrétních analytických situacích se vztah «extend» prakticky používá?
2. Jak je tento vztah následně realizován technologicky?
http://www.objects.cz
strana 2
PRAKTICKÉ POUŽITÍ INTERAKCE «EXTEND» A NÁSLEDNÁ MOŽNÁ TECHNOLOGICKÁ
REALIZACE
Je zřejmé, že interakci «extend» nasadíme tam, kde se vyžaduje nezávislost volání případu
užití. V praxi a ve školeních jsem se setkal s těmito možnostmi zavedení interakce «extend»
v analytickém modelu:
1. Přídavné spustitelné akce nad vybraným prvkem
2. Vyvolání přídavné akce na událost vyvolanou buď systémem anebo uživatelem
3. Vyvolání zvláštního použití Helpu aplikace (tj. v kontextu použití aplikace)
4. Bonusová akce za určité podmínky, avšak podmínka a ani akce není pro požadavek
rozšiřitelnosti uvedena přímo ve scénáři pomocí konstrukce „if...else...“, ale pomocí
interakce «extend».
PŘÍDAVNÉ SPUSTITELNÉ AKCE NAD VYBRANÝM PRVKEM
Jedná se o velmi známou situaci, která se dá technologicky nejsnáze realizovat vyvoláním
pop-up menu nad prvkem pomocí klepnutí na pravé tlačítko myši. Uživatel dostává
k dispozici seznam akcí, které může následně nad prvkem vyvolat.
V analytické rovině můžeme ve scénáři případů zapsat tento seznam akcí pomocí výčtu
volání jako interakce «include», například takto:
„Obsluha má možnost nad vybraným prvkem vyvolat jeden z těchto případů
užití: A, B
, C“
Tímto se však sám scénář (tedy daný případ užití) stává závislým na těchto všech voláních.
Znamená to, že přidání nové akce znamená otevřít daný scénář a přidat další volání do
daného scénáře, což se může jevit jako nevýhoda.
Druhou možností je použít interakci «extend». V tom případě můžeme zvolit jako Extension
Point bod s názvem „je vybrán prvek“.
Pro zápis podmínky u interakce a daného bodu extenze se použije podle poslední verze UML
2.2. text v Note takto:
strana 2
http://www.objects.cz
strana 3
Condition: Obsluha chce vyvolat případ užití A
Extension Point: je vybrán prvek
«extend»
X
extension points:
j e v ybrán prv ek
A
Obrázek 1 Použití vztahu «extend» jako spuštění akcí ze seznamu akcí nad prvkem
DŮLEŽITÁ POZNÁMKA K NOTACI PODMÍNKY U «EXTEND»
V poslední verzi UML 2.2 se doslova píše:
Changes from previous UML
The notation for conditions has been changed such that the condition and the referenced
extension points may now be included in a Note attached to the extend relationship, instead
of merely being a textual comment that is located in the vicinity of the relationship.
Verze EA 7.1, kterou momentálně používám, neumí propojit link z Note na interakce, ale
pouze na prvek, a tedy neumí propojit linkem Note ani s interakcí «extend». Na předešlém
obrázku je tedy ono propojení vytvořeno uměle pomocí jiné čárkované čáry, která není
přímo v nabídce EA.
Avšak podle starší verze UML stačí umístit tento Note pouze „blízko“ k dané interakci bez
propojení s danou interakcí, což lze bez problému použít a je také myslím dostačující.
VYVOLÁNÍ PŘÍDAVNÉ AKCE NA UDÁLOST VYVOLANOU BUĎ SYSTÉMEM ANEBO
UŽIVATELEM
Jedná se o další známou situaci, kdy chceme vyjádřit, že na danou událost se spustí jedna
určitá anebo několik akcí. Existuje více možností, jak tuto situaci vyjádřit pomocí případů
užití.
strana 3
http://www.objects.cz
strana 4
První možností je přímo ve scénáři vypsat natvrdo seznam vyvolaných akcí, které se vyvolají
v daném bodu běhu scénáře (tento bod jinak odpovídá vyvolání události). Jedná se o
variantu nejméně vhodnou a nejméně flexibilní. Je zřejmé, každé další rozšíření systému o
další moduly, ve kterých se také musí vyvolat nějaká funkcionalita vyvolaná tímto bodem ve
scénáři, znamená překopat starý scénář a přidat další volání případu užití.
Jako příklad zvolme událost s názvem „po zaúčtování převodního příkazu“. Potom ve scénáři
vypadá situace nějak takto:
...bla bla bla bla
//pozn.: Nyní je převodní příkaz úspěšně zaúčtován v systému.
Dále se provedou tyto případy užití: A1, A2, a A3.
...bla bla bla
Je zřejmé, že se jedná o situaci dost nepříjemnou, protože na tento bod události budou
reagovat i jiné další budoucí moduly a tento případ užití je tedy do budoucna stále otevřen.
Druhou možností je použít interakci «extend» specifickým způsobem: Nejenom, že je bod
extenze definován v daném případu užití jako Extension Point, ale navíc se vyskytne také
v daném bodě scénáře, tj. tam se přímo explicitně uvede, například takto:
...bla bla bla bla
//Nyní je převodní příkaz úspěšně zaúčtován v systému.
Zde se nabízí bod extenze pro událost „Po zaúčtování převodního příkazu“
...bla bla bla
Další postup je již zřejmý: Extendující případy užití, které se mají spouštět na tuto událost, se
„zaháčkují“ interakcí «extend» k tomuto bodu a jsou tedy vyvolány při dosažení tohoto
bodu. Není asi třeba zdůrazňovat, že tento bod se může vyskytnout i ve větvi „if“ daného
scénáře.
V technologii se tato situace řeší buď pomocí vzoru OBSERVER (LISTENER), nebo pomocí tzv.
delegátů (např. v C#) anebo nějakým jiným událostním mechanismem.
Je však třeba se zmínit o ještě efektivnějším řešení této situace, kdy chceme analyticky
vyjádřit zpracování události v systému. Nepoužije se interakce «extend», ale generalizace
podle Vzoru Reakce, podrobně je probrán i s příklady na našich školeních. Osobně dávám
přednost řešení pomocí tohoto Vzoru Reakce, protože je i pro laika paradoxně mnohem
srozumitelnější než zápis pomocí vloženého bodu extenze a interakce «extend».
strana 4
http://www.objects.cz
strana 5
VYVOLÁNÍ ZVLÁŠTNÍHO POUŽITÍ HELPU APLIKACE (TJ. V KONTEXTU POUŽITÍ APLIKACE)
Toto použití interakce «extend» zde uvádím pro úplnost, osobně jsem se s ním v praxi
nesetkal. Najdete jej přímo jako příklad ve specifikaci UML. Jedná se o doplnění aplikace o
Help, který tzv. „může a nemusí“ být uživatelem vyvolán. Pokud je vyvolán, uživateli se
aplikace rozšiřuje o poskytování „Helpu“.
BONUSOVÁ AKCE ZA URČITÉ PODMÍNKY
Jedná se o případ obdobný již uvedenému řešení události, ale má oproti klasické události své
specifikum.
Představme si, že pomocí scénáře popíšeme situaci, kdy za určitých okolností se daný případ
užití rozšiřuje o „bonusovou akci“ v daném bodě scénáře. Můžeme tuto situaci zapsat takto
...bla bla bla
Pokud nastane <podmínka bonusu XY >, provede se ještě případ užití A
Poté se pokračuje...bla bla bla
Existuje také druhá možnost. Toto větvení se nahradí bodem extenze a podmínka se umístí
do Condition u vyvolání případu užití A pomocí extenze. Situace pak ve scénáři vypadá
takto:
...bla bla bla
Zde se nabízí bod extenze pro Bonus XY.
Poté se pokračuje...bla bla bla
A v diagramu se uvede podmínka Condition takto:
strana 5
http://www.objects.cz
strana 6
Condition: Podmínka bonusu XY
Extension Point: Bonus XY
«extend»
X
extension points:
Bonus XY
A
Obrázek 2 Použití interakce «extend» jako bonusová funkcionalita
Cílem je opět získat nezávislost toho, kdo volá, na tom, kdo je volán.
ZÁVĚR
Rozdíl mezi vztahy «include» a «extend» je zřejmý:
Interakce «include» reprezentuje „klasické“ volání jednoho případu užití druhým případem
užití a proto je volající závislý na volaném, tedy „potřebuje jej“ pro svou konzistenci.
Důsledkem je nutnost změnit scénář volaného, pokud potřebuje změnit zavolání.
Naopak interakce «extend» zabezpečí nezávislost rozšiřovaného na rozšiřovaném.
I když použití interakce «extend» je relativně výjimečnou situaci, předešlý výčet ukazuje, že ji
lze používat ve specifických situacích nejen účelně, ale i srozumitelně. Navíc není vyloučeno,
že se v praxi můžeme setkat ještě s dalšími možnými použitími této interakce.
Konec článku
Věnujte pozornost akci cenově výhodných školení OOP a UML v Praze na podzim 2009
Pobytový kurz OOP a UML podzim 2009 má volná místa
strana 6