Před nedávnem jsem obdržel tento mail s dotazem (cituji dotaz doslovně bez diakritiky):
Neviem, ale ako zapísať detaily, ktoré by sa dali pouzit aj pri testovani, napriklad logika vyhladavania instancii podla cenoveho rozsahu:
Entita ma vlastnosti CenaMin, CenaMax.
Vyhladavam na tento cenovy rozsah podla nasledovnej logiky:
min cena instancie nemoze byt vacsia ako max vyhladavana cena
a zaroven
max cena instancie nemoze byt mensia ako min vyhladavana cena
Neviem ci pouzit aktivity diagram, alebo tieto informacie ukladat len ako poznamku? Pripadne akou inou formou toto popisat v analytickom modeli, nie v implementacnom?
Dakujem a prajem Vam krasny den,
K.F.
Předkládám zde odpověď rozpracovanou do formy článku.
Pro popis realizace vnitřku případů užití upřednostňuji psaní scénářů, které ale musí podléhat poměrně dosti přísným pravidlům (podobně jako dodržování syntaxe v klasickém programování). Výhodou psaní scénářů je dobrá čitelnost a také určitá „univerzálnost zápisu“, protože slovním popisem chodu algoritmu vystihneme opravdu libovolnou situaci (nelze totiž naprogramovat něco, co nelze popsat slovně 🙂 ).
Mnohokrát se mi při školeních (např. při školení Analytické modelování anebo Efektivní Use Case techniky) stalo, že účastník vznesl tento dotaz:
„A jak bych prosím ve scénáři zapsal tu složitou situaci, že …“
a následuje vysvětlení toho, co chce zapsat jako scénář.
Moje odpověď v těchto případech většinou zní:
„Škoda, že jsme neměli puštěný diktafon, protože to, co jste zde v dotazu zformuloval, vystihuje přesně to, co chcete zapsat do scénáře. Nehledejte v tom žádnou složitost. Jediné, co by se při zápisu vyžadovalo, aby se vámi vyslovené věty upravily tak, aby výsledný scénář případu užití byl napsán korektně podle pravidel pro psaní scénářů… “
Zde v emailové korespondenci nastala velmi podobná situace.
Evidentně se tento dotaz s výběrovou podmínkou uplatní v algoritmu vyhledávání, kdy se vlastnosti prvků porovnávají se zadanými parametry vyhledávání. Je třeba jen popsat danou situaci jako scénář, např. nějak takto:
Obsluha zadá min a max cenu vyhledávání (… případně další parametry vyhledávání).
Vytvoří se seznam prvků pro zobrazení takto:
… a následují různé podmínky např.
Pokud <podmínka>, tak se prvek vybere, jinak nikoliv.
anebo naopak:
Pokud <podmínka>, tak se prvek nevybere…
Problém je v tom, že mnoho vývojářů pracují dlouhodobě s SQL příkazy jako takovými přímo v relační databázi a tak si při tvorbě analytických modelů mnohdy neuvědomí, že SQL příkaz má také jako každá jiná část programu svůj analytický obraz ve slovním vyjádření, který se uplatní ve scénářích případu užití.
Je třeba ještě podotknout, že pokud se tento algoritmus výběru opakuje v několika případech užití (a tedy ve vícero scénářích), tak je třeba jej vytknout pomocí interakci include. Zde je možné nasadit jeden ze vzorů psaní scénářů, který využívá možnosti nastavit atributy u případu užití, o čemž bude pojednávat některý z příštích článků.
Podobně, pokud je výběrová podmínka příliš dlouhá, lze ji „vytknout“ pomocí interakce include za účelem vyšší přehlednosti a lepší čitelnosti scénáře případu užití bez opětovné použitelnosti.
Závěr
Nejlepší způsob zápisu výběrových podmínek vidím v napsání scénáře a to do té pozice, kde se výběrová podmínka uplatní.
Pokud se výběrová podmínka opakuje, pak je nutné nasadit interakci include. Tuto interakci lze nasadit také pro zpřehlednění scénáře, pokud je podmínka dlouhá a složitá.
Napsat komentář