Use Cases

  • Analytický zápis konfigurace systému s využitím Use Case diagramu a Class diagramu

    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?

  • Zajímavý ilustrativní příklad na vyhledávání případů užití pomocí procesní školy

    V předešlém článku (viz zde) byl popsán rozdíl mezi prvky typu User Story (zavedené v agilních technikách vývoje) a prvky typu Use Case (zavedené v UML). Současně byl také vysvětlen jejich přímý vztah v souvislosti s vývojem IS.

    Následující článek má za cíl ukázat, jak lze rychle a efektivně vyhledávat případy užití procesní školou (BPMN 2.0). Navíc poslouží také jako dobrý příklad na použití prvku v BPMN 2.0 zvaného Parallel Gateway.

  • Zajímavé využití možnosti nastavení stavů a hodnot u případů užití

    Scénáře případů užití (Use Case Scenario) vyjadřují posloupnost kroků programu, ať už budoucího zatím pouze navrženého, anebo již implementovaného a nasazeného u zákazníka. Mohlo by se proto na první pohled zdát, že u popisu algoritmu nemá smysl hovořit o nějakých stavech a tedy s tím souvisejícím nastavením hodnot u scénáře případů užití (podobně jako je tomu u objektů). 

  • Velmi častá chyba při vyhledávání případů užití a jak se jí vyvarovat

    Při in-house školení ve firmách anebo v rámci veřejných školení velmi často řešíme příklady přinesené přímo účastníky školení jako součást konzultace. Několikrát se mi stalo, že jsem přitom identifikoval stále tutéž opakující se chybu a proto bych se tady o ní rád tak trochu rozepsal. Dopředu musím podotknout, že se jedná o chybu velice častou a záludnou, protože souvisí s častou záměnou názvu případu užití s aktivitou v daném případu užití.

  • Do jaké míry má analytik umět programovat? 2.část

    V předešlé části článku bylo pojednáno o požadovaných znalostech analytika z oblasti technologií a základních pojmů z OOP:

    • vztah třída-instance,
    • generalizace
    • polymorfismus

    Kromě těchto nejzákladnějších znalostí by měl analytik znát navíc i některé ze vzorů Design Patterns. Důvodem je ta skutečnost, že některé z těchto vzorů mohou samy svou konstrukcí nabídnout řešení návrhu IS již na analytické úrovni. Při využití vzorů se řešení v analytické rovině navrhne pomocí vztahu Generalizace jak v CLASS MODELU, tak v USE CASE MODELU.

    V této části článku bude uveden přehled těch vzorů, které by analytik (resp. každý vývojář) měl znát a o nichž by měl vědět nejen to, jak fungují, ale také jak a kdy se používají.