Články

  • 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?

  • Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 2. kapitola: Anonymita klienta a zavedení vzoru Singleton s inicializací

    V jedné z diskusí na našem serveru se objevil odkaz na zajímavý článek, ve kterém se autor snaží vysvětlit, proč je použití vzoru Singleton nepřípustné a proč jsou Singletony tzv. lháři (v originále “Singletons are Pathological Liars”). V tomto článku si blíže rozebereme tuto problematiku z pohledu tvorby čistého kódu.

  • Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 1. kapitola: Test na záporný bonus

    Nedávno jsem zažil jednu klasickou programátorskou situaci. Potřeboval jsem ke své analytické práci naprogramovat drobnou utilitku v C#. Základní zadání bylo jednoduché: Vytvořit Addin do Wordu, který by umožňoval psát velmi efektivně analytické dokumenty za přímé podpory CASE nástroje Enterprise Architect metodou drag and drop. Věděl jsem přesně, co potřebuji, ale vzhledem k nedostatku času […]
  • Malý test OOP a Design Patterns

    Vyzkoušejte si malý test na OOP a Design Patterns. Po zaškrtnutí všech odpovědí si porovnejte svoje odpovědi s řešením, které se odkryje po stisku tlačítka s nápisem Ukázat správné odpovědi. Test se nikde neukládá a ani výsledky se nikam neposílají.

  • 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ů). 

  • Kdy a jak má analytik zahájit vyhledávání analytických tříd?

    Účastníci našich školení a konzultací velmi často položí otázku: „Kdy a jak zahájit vyhledávání analytických tříd“? Jednoduchá šalamounská odpověď by mohla znít: „Jakmile to bude možné, protože je to pro další vývoj výhodné“. Tato odpověď je sice pravdivá, ale není nám příliš užitečná, protože sama o sobě nedefinuje přesný okamžik na časové ose vývoje a tedy neurčuje signál k vyhledávání tříd.

    Zkusme tedy tento okamžik kdy a jak začít vyhledávat třídy definovat přesně.

  • 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í.

  • Reakce na předešlý článek ohledně časté chyby při zadávání prací analytikovi

    Vždy mne potěší, když se nad články resp. příspěvky na tomto webu rozproudí diskuse a velice rád na ně také odpovídám. Proto mne potěšilo, když jsem po vydání předchozího článku s názvem O jedné časté a velmi nepříjemné chybě při zadávání prací analytikovi obdržel zajímavý mail s reakcí na tento článek. V tomto článku předkládám tento mail a následně mou odpověď i s příkladem.

  • Když není čas ostřit sekery…

    Obdržel jsem nedávno mail, z něhož cituji následující pasáž:

    U nás ve firmě se topíme ve vývoji, tj. topíme se v problémech, které popisujete v některých svých článcích. Chtěl bych některé věci změnit a snažím se si udělat jako základ v problematice trošku jasno… Pak zvažuji nějaká školení, ale nejdříve chci něco nastudovat…

    S tímto problémem jsem se setkal opravdu často. Praxe ukazuje, že ve firmě je třeba věnovat se postupům vývoje SW a pokud se tento “vývoj vývoje” neřídí správným směrem (anebo se řídí sám), nastávají v SW firmě velké problémy.

    Velice mi to připomíná situaci u dřevorubců, kteří nechtějí ztrácet čas ostřením seker. Protože velmi spěchají, tak se nechtějí takovou drobností, jakou je ostření seker, ani na chvíli zdržovat, a tak usilovně “buší” do dřeva stále tupějšími nástroji … A světe div se, práce jde stále pomaleji a pomaleji.

  • 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í.