Články a seriály

Při čtení článku na serveru Lupa.cz : Pracovali jsme i na Štědrý den, ale stejně jsme za blbce… se mi vybavila velmi známá situace: Jak vypadá projekt vývoje IS řízený nedoporučovanou anti-metodikou Tunel. O tom je tento článek.

Jeden z účastníků školení Čtvrtletní kurz profesního růstu analytika vznesl následující dotaz týkající rozkladu procesů v BPMN alias procesní mapy: „Jde mi o to, jak v EA vyrobit diagram Strom rozkladu procesů tak, aby sdílel elementy s diagramem Chod procesu. Nyní mám problém, že v Project Browseru vzniká resp. zaniká strom dle toho, který z diagramů právě upravuji. Vysvětluji v dalším textu…“ Na toto téma je následující článek

Účastnici e-kurzu Čtvrtletní vzdělávací program profesního růstu analytika dostali za úkol vytvořit Use Case Diagram na základě zadání. Ve výsledném  diagramu figurovalo vícero prvků typu Actor a některé z nich jako externí systémy. Ze zadání a následně za scénáře případu užití bylo zřejmé, že tyto prvky Actor se v algoritmu scénáře použijí v určitém pořadí. Jeden z účastníků vznesl dotaz, zda lze nějak toto pořadí použití znázornit v UC Diagramu, když ho známe. Odpověď zněla: Nebývá… Více informací: Pořadí prvků typu Actor resp. include v UC diagramu (z cyklu zajímavé otázky ze školení)

Znáte to: Analytici se hodně snaží, ale nasazený systém se díky dalším změnám postupně vzdaluje od původní analýzy. Každý systém tak z pohledu analýzy stárne a jde jen o to, jak rychle… Realizovaný kód nakonec nemusí odpovídat analytické dokumentaci a díky tomu tým padá zpět do chaotického vývoje, jako by analýza ani nebyla… Jak tomuto samovolnému posunu „realizovaný kód versus analýza“ co nejvíce zabránit anebo aspoň omezit na přípustnou mez? Možná vám v agilní technice chybí… Více informací: Jak řešit problém samovolného posunu realizovaného kódu od původní analýzy?

V minulém článku bylo pojednáno o významu analýzy a o efektivních postupech její tvorby v agilním prostředí SCRUM. V této části se budeme věnovat otázce, v jakém vztahu je analýza k procesům SCRUMu zvaným Sprint review a Sprint Retrospective.

Po webináři Jak tvořit High Level Analýzu v agilních technikách (SCRUM apod.) jeden účastník vznesl tyto dvě zajímavé otázky: Měl bych dva doplňující dotazy ke vztahu UML a SCRUMu: Jaká je úloha analýzy na review sprintu? Jaká je úloha analýzy na retrospektivě ke sprintu? Zdravím, L. K. Tento článek odpovídá na obě otázky.

K tomuto článku mne inspiroval jeden komentář k předešlému článku, evidentně od programátora.

Tento článek navazuje na předešlé 2 články o číselnících a uvedeme si v něm praktické příklady týkající se této agendy.

Poznámka: Tento článek vyšel také jako doprovodný text ke stejnojmennému školení Pokud řešíte nějaký problém, tak je opravdu velice výhodné, když znáte předem řešení. O tom jsou obecně vzory v návrhu SW. Vzor totiž není nic jiného, než aplikace opětovné použitelnosti na řešení problémů. Obecně lze vzor v návrhu SW (a nejen v návrhu SW) definovat takto: Vzor je opětovně použitelné řešení na opakující se problém.

V předešlém článku jsme se zabývali možnými řešeními agendy zvané jako „číselníky“ alias „kódovníky“. Ukázali jsme si tři možná řešení s různými variantami posunu meta. V tomto článku navážeme na předešlý článek dalšími úvahami a doufám, že (podobně jako minule) také dalšími příspěvky v diskusi.

Takřka v každém evidenčním systému se vyskytují tzv. číselníky, někdy zvané také jako „kódovníky“, anglicky např. jako „Code List“. Jedná se o velmi jednoduché entity obsahující „kód + text“ (případně zkratka apod.), které pomocí odkazu přidělují daným prvkům vlastnosti jako hodnotu kódu. Většinou se tak děje ve scénáři výběrem od obsluhy. Každému kódu je přiřazen význam, což vyjadřuje obsah atributu text zobrazitelný obsluze. Jako příklady uveďme číselník barev, číselník typů bankovních služeb, číselník typů osob atd.… Více informací: Praktický příklad na „posun meta“: Agenda Číselníky, část 1

V předešlém článku bylo vysvětleno, jak se mají správně chápat případy užití prvního druhu. V definici těchto případů užití sehrává svou velmi důležitou roli stav nečinnosti, který jsme nazvali jako IDLE stav. V této části si vysvětlíme, k jakým základním až fatálním chybám dochází, pokud se tento stav opomíjí a když se hledání případů užití neprovádí korektním způsobem (i s příkladem).

Je vcelku zřejmé, že pokud mají vývojáři odevzdat dobrý a pokud možno bezchybně fungující informační systém, tak se soustředí v prvé řadě na to, co má tento systém dělat.  Věnují se tomu, jak mají vypadat algoritmy programu, jak se má program chovat, co má dělat – a to na začátku na logické a analytické úrovni a poté až po návrh výsledného kódu. Vývojáři jsou tedy vcelku pochopitelně zaměřeni na systém v jeho činnosti, tedy na to, co… Více informací: Proč je v analýze tak důležitý stav nečinnosti u informačního systému? Část 1.

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: 

Nedávno jsem obdržel tento mail (publikuji bez úprav): Vazeny pan Kraval, cital som Vas serial Quick-and-Dirty-Programming a som rad ze o tom niekto pise. Som v situacii, kde model projektu neexistuje a vsetko sa zistuje reverznym inzinieringom a samozrejme opatovne vzdy, ked sa v danej casti aplikacie robia zmeny. Frustrujuca situacia, hlavne ked sa jedna o dlhodoby projekt, ktory sa postupne vyvija. Myslim, ze problem je v tom, ze vacsinou ludia nemaju skusenosti s inym ako… Více informací: Jaká jsou úskalí Quick-and-Dirty-Programming a jak se jim vyhnout? Část 7:. Proč je v SW firmách tak rozšířen zlozvyk tvořit paskvilný SW „Dirty Code“ ?

Na nedávném in-house školení na téma Čistý kód a Design Patterns jeden účastník vznesl následující dotaz: „Někde jsem se dočetl, že čtverec nemůže být dědicem obdélníka, protože to porušuje tzv. „Liskov Substitution Principle“ (dále jen LSP). Ale když přece podědím z Obdélníka novou třídu Čtverec a současně překryji metody pro nastavení stran tak, aby byly vždy shodné, tak vše bude fungovat. Přece platí, že čtverec je speciální případ obdélníka a proto jej zavedeme jednoduše jako speciálnější… Více informací: Jaká jsou úskalí Quick-and-Dirty-Programming a jak se jim vyhnout? Část 6: Nepodceňujte LSP – Liskov Substitution Principle aneb proč čtverec není v OOP dědicem obdélníku

V předešlém článku jsme hovořili o chybách špatně umístěného kódu. Naše úvahy se opíraly o jednoduchý princip rozdělení aplikace na tři vrstvy, vrstva „levá“ (anonymní klient), naše vrstva kódu a „pravá“ vrstva kódu, kterou náš kód používá: Také jsme si vysvětlili první možnou chybu, kdy se kód, který správně patří „nalevo“, umístí do naší vrstvy a tím se naše vrstva zašpiní (tvorba slepenců, kočkopsů apod.). Nyní si vysvětlíme druhou možnou chybu – umístění kódu do naší… Více informací: Jaká jsou úskalí Quick-and-Dirty-Programming a jak se jim vyhnout? Část 5: Porušení principu jedné odpovědnosti II

Pokud se podíváme do kódu a chceme zjistit, zda je „nečistý“, tak bychom neměli o tom příliš dlouho spekulovat, ale měli bychom uvidět na první pohled, zda se jedná o paskvil nebo ne. Je to spíše obdoba „Pavlovova podmíněného reflexu“ (řádově v sekundách), než že by se jednalo o složitou a dlouhou analýzu kódu. Hlavním prohřeškem při porušení principu jedné odpovědnosti je umístění kódu tam, kam nepatří, i když přitom není narušena funkčnost programu. To je… Více informací: Jaká jsou úskalí Quick-and-Dirty-Programming a jak se jim vyhnout? Část 4: Porušení principu jedné odpovědnosti

Je zřejmé, že opuštění metody Quick and Dirty Programming přinese firmě výhody. Jenže je to dlouhá cesta k cíli, na které hrozí několik vážných úskalí. Tento článek pojednává o jednom z hlavních nebezpečí na této cestě.

V předešlém článku jsme uvedli metodu Quick and Dirty Programming. Jak bylo trefně poznamenáno v komentáři od kolegy u předešlého článku, tak není až tak relevantní otázka, kdo se s ní potkal, ale naopak, spíše ať se přihlásí ten, kdo se s touto metodou nikdy nesetkal. Kde hledat hlavní příčiny tolerance k nečistému kódu a kde je podstata tak časté preference této metody tvorby SW?

Myslím, že člověka k programování přitahuje primárně vysoká tvůrčí kreativita v tomto oboru. Vývojář má možnost jako meta-tvůrce vytvářet nový virtuální svět (jakýsi svůj „Matrix“) podle jeho takřka „božské“ libovůle. Nejhezčí na tom je, že tento svět bude skutečně takovým, jaký jej stvořitel programátor vytvoří. Časem jsem vypozoroval ještě jedno velké plus: Pokud pominu sociopatické výjimky, tak 99% vývojářů a programátorů chce odevzdávat kvalitní práci na vysoké profesionální úrovni (i když někdy nemohou) a jsou proto nadšeni… Více informací: Jaká jsou úskalí Quick-and-Dirty-Programming a jak se jim vyhnout? Část 1.

V návaznosti na předešlé články si ukážeme na konkrétním příkladu vztah mezi principem Open Closed a agilními technikami, například SCRUM. Představme si tuto situaci: Analytik-programátor vytvořil a naprogramoval nějakou metodu objektu, pojmenujme tuto metodu objektu jako A. O něco později musí vyvinout druhou metodu někde jinde, pojmenujme ji jako B. Nechť při studiu nové metody programátor zjistí, že tyto dvě metody A a B jsou téměř identické, liší se pouze ve dvou částech (tj. v odstavcích… Více informací: Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 8. kapitola: Proč je princip Open Closed důležitý pro agilní techniky

Při studiu problematiky tvorby tzv. „čistého kódu“ můžete narazit na tzv. principy. Jedná se vlastně o doporučení týkající se návrhu čistého kódu, která by se měla dodržovat. Pro lepší zapamatování a rychlejší komunikaci mezi vývojáři se tyto principy označují zkratkami. Mezi nejznámější (kromě notoricky známé zkratky SOLID) patří také v nadpisu zmíněné zkratky DRY, ADP, OCP, ISP a INI. Co tyto zkratky znamenají? Poznámky: Některé principy se v různých zkratkách vyskytují opakovaně, tj. principy se překrývají. Například zde… Více informací: Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 7. kapitola: Znáte zkratky DRY, ADP, OCP, ISP a PINI?

Na ukázkovém příkladu z předešlého článku si nyní ukážeme konkrétní praktické postupy řešení situací s nečistým kódem. Ukážeme si efektivní použití testů na čistotu kódu a také postup, jak se nečistého kódu zbavit.  

V předešlých článcích jsme si na jednoduchém příkladu vysvětlili jednu z nejčastějších chyb, kterou bychom mohli nazvat jako „zašpinění vnitřní vrstvy“. Podstatou této chyby je umístění evidované informace „příliš nízko“. Údaje o Čtenáři mají být ve Čtenáři (vyšší vrstva) a nikoliv v Osobě (nižší vrstva). Tento příklad má svou výhodu ve své jednoduchosti a průzračnosti (což je výhodou pro vysvětlení), ale musím podotknout, že situace bývají v praxi mnohem „záludnější“. Uveďme si příklad na podobné téma. Zajímavá je… Více informací: Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 5. kapitola: Ještě záludnější příklad na zašpinění vrstvy

V předešlém článku jsme předložili model se studenty, zaměstnanci, osobami, zaznělo zadání ve smyslu „evidujeme půjčování knih“ a otázka byla formulována takto: “Kam umístíme všechny požadované údaje o půjčování – zápůjčky, číslo průkazu, atd., v tomto modelu? Do studenta, do zaměstnance anebo do osoby, když i student i zaměstnanec si mohou půjčovat knihy?” V tomto článku si ukážeme analyticky čisté a správné řešení.

V knize Analytické modelování pomocí UML v praxi (volně ke stažení zde) je uveden jeden názorný příklad vysvětlující určité záludnosti objektového paradigmatu, viz kaptiola 1.3.2, strana 12. Na tomto příkladu si uvedeme jeden z nepříjemných důsledků nedodržování čistoty kódu včetně zajímavé hádanky, která v knize není uvedena.

V této části mini seriálu o interakcích Extend a Include v Use Case Diagramu si ukážeme, jak se tento vztah chápe jako zadání do technologického návrhu a programování.

U jednoho z předešlých článků se objevil jeden natolik důležitý komentář, že jsem se rozhodl odpovědět na něj přímo tímto článkem.

Tento článek je pokračováním předešlého textu, viz zde.  Ukážeme si nyní velmi názorný a vysvětlující příklad na použití vztahu Extend.

V mnoha školeních a konzultacích jsem takřka pokaždé narazil na rozepře mezi vývojáři o nasazení vztahu Extend. Jak se má tento vztah používat správně a korektně?

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)… Více informací: Analytický zápis konfigurace systému s využitím Use Case diagramu a Class diagramu

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.

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 jsem kód nechal vytvořit jednomu svému kolegovi, tehdy studentovi a začínajícímu programátorovi. Odevzdal jsem mu tedy zadání, po určité době jsem… Více informací: Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 1. kapitola: Test na záporný bonus

Při jedné konzultaci ve firmě, která vyvíjí technologické systémy, jsme narazili na zajímavý problém k řešení, který nakonec vedl k doporučení zavést logickou vrstvu aplikace a k použití vzoru BRIDGE.

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.

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

Nedávno jsme v jedné bratislavské firmě uskutečnili 2-denní workshop, jehož cílem bylo zlepšit postupy prací na analytických dokumentech. Během této konzultace jsme řešili několik zajímavých problémů. Jeden z nich považuji za natolik zajímavý, že jsem se rozhodl o něm napsat tento článek.

Úč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ě.

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

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.

Nedávno jsem se v jedné SW firmě v Čechách při školení zaměřené na analytické modelování v UML setkal s chybným postupem při zadávání prací analytikovi. Na tento problém jsem narazil již ve vícero firmách a protože jej považuji za dost závažný, pojednávám o něm zde ve formě článku.

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íce informací: Když není čas ostřit sekery…

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… Více informací: Do jaké míry má analytik umět programovat? 2.část

Velmi často se při školeních zaměřených na návrh SW pomocí OOP a UML ozve někdo z pléna účastníků a položí otázku, zda má analytik umět programovat a pokud ano, tak do jaké míry a do jaké hloubky. Právě tomuto problému je věnován následující článek.