Nedávno mi přišel mail s tímto textem: Dobrý deň, pán Kravál,
V snahe zužitkovať znalosti získané na Vašom školení analytikov a návrhárov našej firmy sme narazili na jeden problém, možno nás budete vedieť nasmerovať k jeho riešeniu. Náš produkt obsahuje rozsiahlu konfiguračnú stránku, kde je možné veľa vecí zapnúť, vypnúť, nastaviť na jednu z možností, niektoré možnosti majú zmysel, iba keď sú zapnuté iné možnosti apod. Konfigurácia sa ukladá do súboru vo formáte kľúč=hodnota (java properties) Pri behu aplikácie sa hodnoty konfigurácie udržiavajú ako hodnoty inštančných premenných singleton objektu, ostatné časti aplikácie sa na ne dopytujú cez getter metódy. Podľa tejto konfigurácie sa potom produkt správa v rôznych situáciách (scenároch). Niektoré kroky sa podľa nastavenia vynechávajú, niektoré idú jednou z možných ciest apod. Ako toto najlepšie namodelovať? Jediné, čo mi napadlo, je case-om priradiť nejaké activity diagramy, ktoré popisujú logiku (vetvenie, algoritmy) v závislosti od nastavenia. Alebo aj samotné nastavenia modelovať ako triedy a ich atribúty? Ako ich potom previazať so scenármi? Ďakujem za inšpiráciu
M.V.
Odpověď:
Existují dvě základní možnosti, jak toto znázornit.
Strukturovaný přístup
Uvedené větvení lze textově popsat ve scénáři pomocí klasického “switche”. Pokud používáte Word, můžete doplnit o barevně odlišené poznámky, o jaké větvení se jedná:
…předchozí scénář
// Větvení algoritmu ALG podle nastavení konfigurace.
pokud hodnota confALG = A potom AlgA
pokud hodnota confALG = B potom AlgB
…další scénář
Tento scénář případu užití doplníte o jednoduchý a stručný Activity diagram (tzv. vývoják). Bod větvení (Decision) označte jako určení daného algoritmu. Do Guardu dejte odpovídající dosazení parametru. V obecné rovině pak obrázek vypadá nějak takto:
Objektový přístup (vzor STRATEGY alias Výběr algoritmu – polymorfní chování)
Druhá možnost (která je flexibilnější a modernější) je využít vzor Výběr algoritmu, viz kniha Analytické modelování. Ve scénáři případu užití X se v bodě větvení konfigurace nasadí include jako použití abstraktního případu užití, který se nazývá jako zobecnění daného algoritmu, v našem příkladu např. jako ALG1. Použije se tato formulace:
…
A dále se použije UC ALG1 podle nastavené konfigurace (viz UC diagram XY).
…
Konfigurace se nevyjmenovávají, ani případy užití, ani hodnoty, to je mimo tento scénář.
V diagramu se pak musí zavést konkrétní případy užití jako potomci obecného případu užití ALG1, u každého se navíc vypíše i hodnota konfiguračního parametru:
Tento druhý zápis je flexibilnější pro přidání dalšího algoritmu (scénář X se nemění)
Znázornění konfiguračních parametrů
Zápis parametrů musí být co nejblíže tomu, jak je to nakonec naprogramováno, proto je nutná konzultace s technologem “jak to bude navrženo” (atribut třídy anebo enum, číselník apod.). Je to tedy případ od případu jiné. V našem příkladu se jedná o třídu v pozici Singleton s odpovídajícími atributy a gettery. Pokud si analytik není jistý, jak zapsat, stačí pouze textový zápis instance v Class modelu anebo nakreslení instance s hodnotami.
Poznámka na závěr:
Jako pěkná varianta (odpovídající předešlému zápisu polymorfního chování ) se mi jeví možnost vyměnit celý konfigurační objekt buď polymorfismem anebo řízeným překladem.
Detailní popis tohoto řešení je velmi dobrým námětem pro další článek
Prosperující SW firma hledá analytiky a JAVA programátory v okolí Hradce Králové
V případě zájmu pište na e-mail objects@object.cz
