Víme jak modelovat struktury pojmů (1)

Upoutávka na poslední díl série o modelování.

Mám-li odpovědět na otázku Dana Lessnera Jak nezprasit povinnou výuku informatiky, rozhodně nesmím vynechat konceptualizaci a konceptuální modelování. Proč zrovna konceptuální modelování? V dokumentu RVP G o něm nikde není ani zmínka.

Proč zrovna konceptuální modelování 

U nás gymnázia tradičně rozvíjela osobnosti studentů, jejich zvídavost, všeobecný rozhled, chápání v souvislostech, schopnost samostatně poznávat, tvořit si vlastní názory a přemýšlet. Studenti na gymnáziu vyzrávali (odtud maturita). Tyto cíle všeobecného vzdělávání jsou vyjádřeny i v klíčových kompetencích RVP G. Když však ŠVP gymnázia nesestavuje profesor, nýbrž dráb, rozpracuje požadované výstupy způsobem, jako by učit učivo bylo veškerým cílem a smyslem studia. To je pak výchova k nevolnictví. Pak ale učitel není profesorem, žák není studentem a závěrečná zkouška není maturitou. Nevolník neřeší problémy, nýbrž jen odstraňuje překážky (podle návodu a z donucení), nevolník nemusí ničemu rozumět (protože jen poslouchá rozkazy), nepotřebuje se vyznat ve složité problémové oblasti (protože neusiluje o řešení), nehledá informace (protože se nerozhoduje), nevymezuje pojmy a nehledá souvislosti mezi nimi, jen vykonává naučené algoritmy. Taková „škola“ může klidně ignorovat umění konceptualizace.


Kdo ale někdy řešil problém (tj. to, co někomu vadí), ten ví, že napřed musí popsat problémovou situaci pomocí adekvátních pojmů. Aby pojmy mohly být adekvátní, musí být adekvátně abstraktní (protože pojmy nemohou nebýt abstraktní) a přitom současně i výstižné (aby vystihly potřeby toho, komu problém vadí). A právě to je konceptualizace.

Proč tolik záleží na konceptualizaci, mají-li požadované výstupy přispět ke splnění cílů RVP G?

• Pokud jde o řešení problémů, tak určitě nestačí ovládat aplikace a „uplatňovat jejich nástroje, metody a vazby“. K řešení problémů potřebujeme především informatické myšlení – a to začíná právě analýzou problému, tj. konceptuálním modelováním problémové oblasti.
• Pokud jde o schopnost vzdělávat se, je informatické myšlení a systémový přístup daleko důležitější než využívání tzv. ICT. Nástroje zastarávají během několika let, principy platí trvale. Konceptualizace umožňuje porozumět základním pojmům a metodám informatiky a nejen informatiky. Konceptuální modelování je základní metoda, jak vybudovat kteroukoli oborovou ontologii. 
• Algoritmickému řešení problému musí předcházet vytvoření konceptuálního modelu. Jistěže některé jednoduché úlohy můžete algoritmizovat na základě konceptualizace intuitivní, naivní nebo konvenční. Učitelé matematiky si od nepaměti stěžují, že žáci nedokážou řešit slovní úlohy. Ale jak by mohli, když se učí předvařené vzorečky, operace a algoritmy, a nikdo je neučí klást jednoduché otázky (co komu vadí? proč mám úlohu řešit?) a pátrat po významných pojmech a souvislostech?
• U složitějších úloh (jaké se řeší v praxi) s intuicí nevystačíte. Složitost se musí zvládat systematicky a systémově, metodami konceptuálního modelování. I v případě, že se složitost podaří zvládnout intuicí nebo naražením úlohy na konvenční kopyto, nebude výsledný konceptuální model robustní – nebude snášet změny. Jenže právě robustnost je nejdůležitějším požadavkem na konceptuální model. Utkvělá představa akademických didaktiků, že problém se řeší nalezením algoritmu (viz RVP G, MO-P, KSP, Kasiopea, FIXA), je podivuhodně naivní. Algoritmus může být i blbý – ale proč nevymyslet raději nějaký chytrý? A proč řešit úlohy zrovna algoritmicky? Nealgoritmické řešení bývá jednodušší – už proto, že složitost se neskrývá jako u hierarchického rozkladu, nýbrž se opravdu zmenší. Kromě toho některé úlohy algoritmicky řešitelné vůbec nejsou. Další podrobnosti a argumenty jsem uvedl v článku Nahraďte algoritmizaci systémovým přístupem! 

Příklad vytvoření konceptuálního modelu 

Ukažme si ve zkratce příklad, na kterém studentům vysvětluji princip, jak postupovat při konceptuálním modelování. Majitel obchodu s potravinami je nespokojen, že mu kvůli neustálým chybám zaměstnanců utíkají tržby — to je problém. Pozorováním provozu zjistíme, že prodavači zbytečně odbíhají do skladu pro zboží, které tam není, nebo naopak neodbíhají a nesprávně tvrdí zákazníkům, že požadované zboží nemají, přestože ve skladu je. A zboží ve skladu nebývá, protože zásobovač je objedná pozdě, až když ho o to někdo požádá.
Našli jsme prodavače a zásobovače — dva druhy osob, které z pohledu majitele sice chybují, ale ne úmyslně — i oni vnímají současný stav jako problém, na současném stavu jim vadí něco konkrétního a umějí si představit zlepšení současného stavu (kdyby si neuměli představit zlepšení, nevnímali by současný stav jako problém). Prodavač potřebuje mít přehled o zboží na skladě, aniž by musel odbíhat od pultu. Zásobovač potřebuje dostávat signály o tom, že dochází zboží — a to s takovým předstihem, aby mohl zboží včas objednat a aby dodávka zboží dorazila do skladu dřív, než zboží dojde.

Může se stát, že se prodavačům a zásobovačům podaří splnit tyto požadavky nějakým jednoduchým způsobem, např. umístěním regálů se zbožím přímo do prodejny, příp. samoobslužným prodejem. Možná zjistí, že problém za řešení vůbec nestojí, možná časem pomine sám od sebe (např. dočasný nával zákazníků v době konání festivalu), možná by řešení přineslo víc škody než užitku (např. kvůli krádežím v samoobsluze), možná by bylo nejlepší obchod prostě zavřít (např. kvůli silné konkurenci v sousedství). Vždycky bychom se měli zamyslet, zda není lepší problém neřešit než řešit.

Přesto se může stát, že se majitel obchodu rozhodne pro radikální řešení pomocí ICT. V tom případě zadavateli (tj. majiteli obchodu) nejspíš nabídneme skladovou evidenci, která by byla průběžně přístupná pomocí terminálů na pultech prodejny a která by automaticky generovala objednávky zboží, jehož zásoba ve skladu klesne pod určitou mez. Úkolem zásobovače pak bude vyhledávat nejlepší dodavatele na trhu a vygenerované objednávky jim odesílat.

Nyní přeskočím formulace konkrétních požadavků na funkce systému, na různá omezení a pravidla, která systém musí dodržovat. Všimněme si jen toho, že požadovaný systém slouží různým druhům uživatelů k různým účelům – a ty je potřeba najít. Jde vlatně o to, že uživatelé hrají vůči systému různé role a naopak systém také musí hrát různé role vůči svým uživatelům. Při analýze požadavků je potřeba průběžně kontrolovat, aby všechny požadavky sloužily k naplnění účelu [až potud viz SAS, str. 86–168 a OOSE, str. 153–200].

To se nejlépe ukáže při analýze chování systému. Nejprve tedy modelujeme sadu reprezentativních scénářů žádoucího i nežádoucího chování (např. typický průběh prodeje nebo chování systému v případě, že bude porušeno nějaké omezení – např. nelze prodat zboží, které není ve skladu). Kontrolujeme, aby systém nedělal nic, co není požadováno, a naopak aby dělal všechno, co požadováno je. Případný nesoulad se řeší buď opravou chybného zadání nebo úpravou / doplněním / odstraněním scénáře. Takováto analýza chování systému je zároveň příležitostí k nalezení významných pojmů, jejich vztahů a struktur. Obecně platí, že analýza chování je základní empirická metoda poznávání [viz OOSE, str. 215–241 a OBA].

Obr. 1: Scénář typického chování

Na obr. 1 je zaznamenán jeden scénář typického chování systému při prodeji mléka. Kdyby nás zajímala jen pouhá specifikace chování systému navenek, stačilo by zachytit interakci prodavače s informačním systémem. V uvedeném diagramu je však scénář rozkreslen podrobně, takže v něm vidíme i interakce mezi prvky systému. Vnitřní členění systému není dáno jednoznačně, je úkolem analytika, aby navrhl robustní vnitřní strukturu systému. Vzpomeňme si na film Matrix: realita vzniká až v mysli člověka (nebo jiné bytosti). Skutečnost se nám jen jeví a fakticita jevů je pochybná (jev může být i klam). Členění světa na věci je úkolem poznávající živé bytosti. Jiný konceptuální model téhož světa si vytvoří krtek, jiný pes a jiný člověk (se svými omezenými čichovými vjemy).

Ve scénáři vidíme aktivitu jednotlivých objektů a také zprávy, které si objekty mezi sebou posílají. Analýzou reprezentativní sady scénářů se snažíme dospět ke konceptuálnímu modelu, ve kterém už nebudou nakresleny jednotlivé objekty, nýbrž obecné typy objektů, vlastnosti charakterizující typy, předpisy chování (metody) typů a struktura asociací mezi typy (asociace je typ komunikačního kanálu, zatímco konkrétní objekty jsou pak spojeny konkrétním komunikačním kanálem).

Obr. 2: Zjednodušený konceptuální model skladové evidence

Na obr. 2 je znázorněn konceptuální model skladové evidence, který by po dopracování mohl posloužit při vývoji informačního systému. Až bude rozhodnuto o způsobu implementace (např. konzolová aplikace / databázová aplikace s GUI / kombinace sdílené relační databáze s objektovými klienty / čistě objektová implementace apod.) a až budou navrženy méně podstatné podrobnosti (např. návrh uživatelského rozhraní), bude možné přistoupit k algoritmizaci metod jednotlivých objektů.

Literatura

[SAS] Habr, Jaroslav; Vepřek, Jaromír. Systémová analýza a syntéza. Praha: SNTL, 1986.

[OOSE] Jacobson, Ivar; Christerson, Magnus; Jonsson, Patrik; Övergaard, Gunnar. Object-Oriented Software Engineering: A Use Case Driven Approach. Reading, Mass., USA: Addison-Wesley, 1992. ISBN 0201403471.

[OBA] Rubin, Kenneth S.; Goldberg, Adele. Object Behavior Analysis. In CACM vol. 35, nr. 9 (September 1992).

---

Příspěvek je prvním dílem série o konceptuálním modelování od Ivana Ryanta.