Kam v analytickém modelu umístit výběrové podmínky SQL dotazů?

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á.


Uveřejněno

v

od

Značky:

Komentáře

Jeden komentář: „Kam v analytickém modelu umístit výběrové podmínky SQL dotazů?“

  1. name avatar
    name

    Za čtyřicet let v IT jsem se nesetkal s potřebou vysvětlit, co je to rozsah. Nikdy ve vztahu k uživatelům. Části programátorů je třeba vysvětlit pojmy reálného světa. (Na faktuře je dluh nebo přeplatek – pro uživatele pak může být obtížné (nepohodlné) vyplňovat interval formou min a max, pokud se jedná o položku pojmenovanou saldo.)

    Je vhodné používat pojmy komunity uživatelů.
    Programátor často bývá exot, ale v tomto případě od chyb a blbých keců mohou pomoci vhodné testovací případy nebo přesně stanovený typ údaje. (Rodné číslo nebo IČ je string, a basta, částka v účetnictví je nejen plus a mínus, ale také md a dal a to naštěstí už pomíjí význam a uplatňování aktivních a pasívních účtů.)
    Nebo FILTR. Programátor má jasno. Uživatel však filtruje atributy, které potřebuje vidět v přehledu. Hodnoty, kterých mohou vybrané atributy nabývat, však vybírá. Atd, atp.

    To jsem se už rozepsal spíš k tématu QaD.

    Vidím také drtící vliv stackoverflow programátorů. Nalezené nekriticky zařadí do kódu, který ještě kolem dokola ohnou a klidně polámou. Tato technika je zvlášť smrtící v případě interpretovaných jazyků.

    Cizí kód, který mám potřebu komentovat (nad rámec analýzy), možná funguje správně, ale určitě není dobře napsán.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *