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
