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.
Posun v názoru
Hned úvodem musím podotknout, že můj názor na tuto problematiku se zkušenostmi z praxe časem dost výrazně posunul. Relativně dávno (přesněji v minulém století minulého tisíciletí), když jsem začínal jako analytik a nastupoval poprvé do jedné SW firmy, tak jsem byl přesvědčen (mimo jiné také díky ubezpečování zaměstnavatele, který mne „lanařil“), že jako analytik nemusím vůbec umět programovat. Jenže časem jsem dospěl k závěru, že tato úvaha není úplně správná , a to hned ze dvou důvodů, které si nyní probereme.
Pasivní znalost základů technologie je pro analytika nezbytná
Během tvorby analytických dokumentů jsem celkem záhy zjistil, že nemohu odevzdávat kvalitní práci analytika při neznalosti základních principů programování a technologie v daném prostředí. Analytik je na tom podobně jako architekt, který navrhuje domy: Pokud architekt nezná základy technologie staveb, nemůže navrhnout správnou konstrukci domu. Podobně i analytik by měl znát (avšak samozřejmě pouze pasivně) základy technologie a programování v daném prostředí, jednak proto, aby mohl navrhovat odpovídající korektní analytické konstrukce programu (proto se velmi často a takřka denně radí s technologem), a jednak proto, aby při rozhovoru s technology nebyl takříkajíc „úplně mimo“ a rozuměl jim. Samozřejmě analytik není expertem na danou technologii, tj. nežádá se po něm kreativní práce v tomto směru. Je opravdu velký rozdíl mezi postupem „sám něco kreativně vymyslet a vytvořit až do fungujících detailů“ anebo „nechat si to pouze vysvětlit již hotové a vymyšlené“.
Pokud analytik nastupuje do nového projektu a nemá v něm potuchy o nějaké nové technologii resp. prostředí, měl by si prostudovat některou z knih např. typu „for dummies“ a seznámit se tak aspoň se základy dané technologie. Mohu jen potvrdit, že pokud jsem pracoval (resp. externě pracuji) v pozici hlavního analytika v projektech, tak se mi vždy osvědčilo, když jsem od podřízených analytiků v týmu vyžadoval tuto „minimální znalost“ technologie.
Existuje však ještě jedna dost důležitá a podstatná oblast technologie, kterou by neměl analytik zanedbat a měl by jí rozumět a dobře chápat: Jedná se o znalost základů objektově orientovaného programování a některých vzorů z Design Patterns. Některé z těchto vzorů totiž analytikovi nabízejí svou konstrukcí řešení situací, se kterými se často setkává.
Neznalost základů OOP jako analfabetismus analytika
Objektové programování má jednu nespornou výhodu: Principy této technologie jsou velmi blízké analytickému modelování, dokonce mnohdy se analytické modely mapují do OOP postupem 1:1. Objektové programování ukazuje přímo a v praxi (a navíc velmi názorně) až do kódu, jak chápat základní pojmy z analytického modelování, jakými jsou:
- Dichotomie třída – instance
- Generalizace
- Polymorfismus
Dovolím si tvrdit, že nepoužívání nebo zanedbávání těchto principů v analýze považuji nejenom za slabinu analytika, ale přímo za základní neznalosti principů tvorby analytického CLASS DIAGRAMU.
Samozřejmě nikdo po analytikovi nechce, aby excelentně programoval v OOP. Měl by však minimálně umět vytvořit v daném objektovém prostředí prototypy, ve kterých by se v nějakých pěkných a názorných příkladech vyskytlo jak zavedení třídy, tak vznik instance voláním konstruktoru, tak použití vztahu dědičnosti (inheritance) a samozřejmě také polymorfismus (překrytí metody).
Zanedbání těchto znalostí v praxi má pro práci analytika následující fatální následky:
Neznalost vzoru Dichotomie třída instance
Pokud analytik nechápe přímo v praxi a nevidí v kódu jeden z nejzákladnějších principů návrhu IS zvaný „dichotomie třída instance“, jeho analýzy jsou tak říkajíc „ujeté“, postrádají základní logickou konstrukci a stávají se snůškou nesmyslných „miš maš“ tvrzení. Mimochodem mezi programátory, kteří by měli podle tohoto zadání programovat, se tyto dokumenty hanlivě nazývají „nezávazným pokecem o systému“. Analytik není schopen vyhledávat a navrhovat vztahy mezi informacemi v systému pomocí analytického CLASS MODELU a pochopitelně nezná velmi účinné „tipy a triky“ vypomoci si ve složitějších situacích instančním modelem.
Neznalost vztahu Generalizace a Inheritance
OOP a UML oproti strukturovanému přístupu zavádí nový typ opětovné použitelnosti (re-use) založený na principu zobecnění pojmů – tzv. vztah Generalizace. Jedná se o vztah nikoliv pouze zobecňující ve smyslu nějaké mlhavé filosofické abstrakce, ale jde o vztah velmi praktický, který umožňuje zavést silnou a flexibilní opětovnou použitelnost jako další nový typ vztahu mezi prvky v systému (zde mezi třídami).
Jednoduše řečeno, zavedeme-li v programu naprogramované pojmy (tj. třídy) Kočka a Pes a podaří se nám navrhnout program pro jejich zobecněný pojem Zvíře, potom je tento program opětovně použitelný pro každý nový subtyp Zvířete. Není nad to, když si analytik použití tohoto vztahu umí nejenom představit v abstrakci, ale vidí jej přímo a konkrétně jako příklad v technologii OOP!
Již se mi v praxi několikrát stalo, že analytik, který se nikdy v praxi nesetkal s Generalizací a nepochopil její základní poslání (neboli že se jedná o re-use zobecněním pojmů s vysokou mírou flexibility) se pozastavoval nad tím, proč mají fyzická osoba a právnická osoba společného předka, když nemají ani jeden údaj společný…
Neznalost polymorfismu a překrytí metody
Analytik by měl umět psát kvalitní efektivní scénáře případů užití a tak navrhovat algoritmus pro zadání do programování. Podívejme se na následující názorný příklad:
V analytickém modelu bankovního systému byl navržen vztah mezi Klientem a Subjektem takto:
Obrázek 1 Vztah „Klient je Subjektem“
Na předešlém diagramu je jak vidno aplikován vzor Party neboli řešení agendy subjektů. Třída Typ Subjektu zde reprezentuje tzv. Diskriminátor (viz například zmíněná kniha Analytické modelování).
Z požadavků od zákazníka vyplynulo, že určitá část scénáře, jehož případ užití nazvěme symbolicky X, by měla podle jeho laických slov fungovat tak, že obsluha zadá číslo klienta, podle zadaného čísla se nalezne klient v seznamu klientů a zobrazí se laicky řečeno „údaje klienta“.
Nejprve si uveďme, jak by tento scénář napsal analytik vyznávající strukturovaný přístup:
…
Obsluha zadá číslo klienta, podle něj se v seznamu klientů nalezne klient.
(pozn.: tok scénáře v Exception Flow nyní neřešíme).
Pokud je Typ subjektu subjektu klienta fyzická osoba, potom se zobrazí údaje fyzické osoby klienta, viz UC Zobrazení údajů FO.
Pokud je Typ subjektu subjektu klienta právnická osoba, potom se zobrazí údaje právnické osoby, viz UC Zobrazení údajů právnické osoby.
…atd…
Analytik zavedl „klasický switch“, nepoužívá polymorfismus a tedy ani žádný ze vzorů Design Patterns.
Existuje jiný možný zápis scénáře:
Obsluha zadá číslo klienta, podle něj se v seznamu klientů nalezne klient.
Dále se zavolá UC Zobrazení údajů osoby podle Typu subjektu subjektu klienta.
Paradoxně laik lépe rozumí druhému objektovému přístupu, protože ten je bližší zdravému selskému rozumu.
Považuji za opravdu velmi přínosné, pokud je analytik vybaven praktickými poznatky a znalostmi z OOP (nemusí povinně jako expert, stačí na úrovni prototypů), protože pak je schopen představit si konstrukce objektové analýzy přímo v praxi až do kódu a velmi názorně. Pokud však nezná tyto principy a nevidí je, není schopen tvorby „té pravé“ objektové analýzy.
Kromě výše uvedených základních znalostí objektového přístupu (tj. dichotomie třída instance, generalizace, polymorfismus) by měl být analytik seznámen s některými vzory Design Patterns, protože jejich konstrukce se mohou objevit přímo v analýze. Jedná se zejména o tyto vzory: COMMAND, OBSERVER, COMPOSITE, STRATEGY, INTERPRETER, BRIDGE, TEMPLATE METHOD, a VISITOR.
O této problematice bude pojednáno v příští části článku.
Napsat komentář