ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH

Transkript

1 ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH 3. část RNDr. Ilja Kraval, srpen Ú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?

2 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

3 strana 3 Condition: Obsluha chce vyvolat případ užití A Extension Point: je vybrán prvek «extend» X extension points: je 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

4 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 //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. 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 //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 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

5 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 Pokud nastane <podmínka bonusu XY >, provede se ještě případ užití A Poté se pokračuje 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: Zde se nabízí bod extenze pro Bonus XY. Poté se pokračuje A v diagramu se uvede podmínka Condition takto: strana 5

6 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