Články

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