3 Současný pohled na jednotlivé směry SWI 3.1 Úvod Chaotický a překotný vývoj programů vedl ke stavu, označovaném jako KRIZE PROGRAMOVÁNÍ. Poučení z krize bylo v několika směrech. Jedním z nich byl směr, který chtěl vnést do vývoje programů jistý řád na základě metodik, které obsahují metody, techniky programování, nástroje programování a potom vlastní řízení projekční činnosti. Byly velmi rychle vysloveny požadavky na kvalitu programů v těchto směrech: 1. 2. 3. 4.
přehlednost a čitelnost, přijatelná strukturovanost, spolehlivost a verifikovatelnost, snadná modifikovatelnost.
Postupně se mezi metody (jako myšlenkové postupy) začalo zařazovat: 1. 2. 3. 4.
programování SHORA – DOLŮ a obráceně, metoda abstrakce, hierarchické uspořádání programů a postupné zjemňování programů.
Techniky programování byly rozšířeny o možnosti výstavby programů na základě nově přicházejících technologií (význam tohoto pojmu je doslovný – vše pro výrobu – produkci). Tak začala vznikat skupina velmi užitečných metod, které tyto techniky používají: 1. 2. 3. 4. 5.
Strukturované programování. Modulární programování. Procedurové programování. Logické programování. Normované programování.
Tyto metody jsou spojeny se speciálními technikami a nástroji na úrovni programovacích jazyků
K těmto metodám se později připojily v 80. - 90. létech další metody programování: 6. 7. 8. 9.
Objektové programování. Událostní programování. Komponentové programování. Programování na základě vzorů.
Některé z metod a technik byly spojeny s teoretickým výzkumem, který pochopitelně dopředu posunul význam jejich implementace. V dalším textu se postupně zmíníme o některých vybraných metodách a technikách.
3.2 Metody programování- přehled Všechny metody programování vznikaly v době ustupující dominance jednoduchých programů. To bylo dáno objektivně požadavkem společnosti na komputerizaci složitějších
-1-
fyzických systémů. Všechny tyto metody byly jednoduchým návodem – myšlenkovým postupem pro vývoj jednoduchých, resp. přechodových programů, které již bylo nutno členit na dílčí celky. Jinými slovy, jednalo se o metody dekompozice vlastního programu nebo zpracovávaných dat. Protože tyto metody představují obecné principy pro strukturalizaci a dekompozicirozklad programů, jejich platnost jaksi ještě nezanikla (vycházely již z poznatků systémového inženýrství). Na základě jednotlivých metod byla podána obecná metodika spočívající v následujícím:
Rozložit komplexní program na části tak, abychom získali prvky přijatelné složitosti. Vybrat ten způsob rozkladu, který zaručuje vazby nejjednodušší povahy.
METODA POSTUPU SHORA-DOLŮ Je to dekompoziční postup pod vlivem Systémového inženýrství. Rozkládáme jak informační problém, tak i program na postupně jednodušší celky. Zastavíme se na přijatelné úrovni. METODA ABSTRAKCE Metoda abstrakce nás poučuje zajímat se především o věci podstatné a oddělit je od věcí nepodstatných. Metoda abstrakce se může dotýkat jak informačního problému (problém komputerizace fyzického systému), tak i samotného programu. Je jistě spojena s metodou postupného zjemňování, tedy odstraňování abstrakce. Při aplikaci na program se abstrakce nejčastěji dotýká:
funkcionality programu, řízení v programu a reprezentace dat.
Při abstrakci funkcionality začínáme jejím obecným pojetím "Solve the Job" a postupně ji zjemňujeme. K tomu můžeme použít zcela abstraktní programovací jazyk, např. jazyk formálních specifikací funkcionality. Při abstrakci dat začínáme jejich obecnou představou a zjemňováním končíme na výběru konkrétních datových struktur programu. Vedle toho se abstrahujeme od detailního pojetí operací nad daty. Abstrakce řízení je spojena s rozkladem programu na prvky a předávání řízení mezi nimi. Problémem metody abstrakcí je právě vlastní zavedení "správných " abstrakcí. METODA HIERARCHICKÉHO USPOŘÁDÁNÍ PROGRAMŮ Jde o stromovité uspořádání částí programu a organizací přechodů mezi těmito částmi. Nezvažovalo se, že části budou samostatné a tím nebylo potřebné řešit datovou a komunikační integritu. METODA POSTUPNÉHO ZJEMŇOVÁNÍ PROGRAMŮ Metoda je myšlenkovým postupem, ve kterém napíšeme funkcionalitu programu velmi abstraktně. Postupně zjemňujeme abstraktní příkazy, až se dostaneme na úroveň cílového programovacího jazyka. Funkcionální abstrakce můžeme zřizovat pomocí
-2-
prázdných příkazů a poznámek v nich. Které části zapsat abstraktně a které rovnou programovat v cílovém programovacím jazyku rozhodne programátor sám.
3.3 Strukturované programování Na strukturované programování se můžeme dívat jako na logicky skloubený, místy teoreticky podložený souhrn jistých zásad pro tvorbu programu, jejichž aplikace přivádí programátory k tvorbě přehledně strukturovaných, snadno modifikovatelných a poměrně snadno verifikovatelných programů. Strukturované programování přináší především praktické rady. Samotné je založeno na:
metodě abstrakce, programování SHORA-DOLŮ, modulárním programování, hierarchickém uspořádání programů, postupném zjemňování programů.
Z uvedeného je zřejmé, že jde skutečně o souhrn aplikovaných metod a některých dalších technik, které je možno zkoumat i samostatně. GO TO LESS PROGRAMMING Nadměrné používání GO TO příkazu, začal odmítat informatik Dijkstra již v roce 1968. Vede totiž k nepřehlednosti, nestrukturovanosti a nesnadné modifikovatelnosti programu. Důsledkem je nesoulad mezi statickou a dynamickou strukturou programu ve smyslu vzájemné korespondence (viz definici jednoduchého programu ). To je potřeba odstranit. Přesto ale většina imperativních programovacích jazyků příkaz GO TO obsahuje. ŘÍDÍCÍ STRUKTURY, ZÁKLAD STRUKTUROVANÉHO PROGRAMOVÁNÍ Pro začátek je potřebné upozornit, že základem komputerizce fyzického systému je komputerizace aktivit a zpracování dat. Algoritmus/-my je možno zapsat mnoha způsoby. Všechny vedou na model algoritmu. Je potom jedno, jestli jde o příkazy a program nebo vývojové diagramy. Z hlediska vizualizace postupu komputerizace algoritmu jsou příjemné zejména vývojové diagramy. Pomocí vývojových diagramů byly zakresleny tři základní řídící struktury navržené Dijsktrou v 60. létech: sekvence, větvení a cyklus (často jen α, β, γ).
-3-
cyklus
Řídící struktury α, β, γ mají jednu zvláštnost. Mají totiž jen jeden vstup a jeden výstup. To zachová velmi přehlednou strukturu programu. Porušení této zásady bylo odepřeno především cyklům (abnormální zakončení cyklu – mimořádné východy) a potom větvení. Získat složitější struktury bylo možné jen na základě tzv.vnořování. Použitím zmíněných struktur byly získány následující výhody:
statická a dynamická struktura byly v jednoduchém vztahu, nebylo nutné používat Goto. Algoritmy, resp. programy zapsané v těchto strukturách byly označeny jako dobře
strukturované. Nebylo dokázáno, zda všechny algoritmy jsou zapsatelné dobře strukturovaně, ale bylo ukázáno, že síla těchto řídících struktur není větší než síla jiných, v praxi používaných struktur (CO JE SÍLA ŘÍDÍCÍCH STRUKTUR?). Zápis některých algoritmů dobře strukturovaně není efektivní (např. zjišťování symetričnosti čtvercové matice). V některých publikacích byly mezi uvedené struktury ještě řazeny varianty větvení a cyklů.
-4-
Tyto řídící struktury neporušují požadavky postavené na původní α, β a γ, ale pravděpodobně mají větší sílu v zápisu algoritmů. Ovšem, řada informatiků již uvažuje, že jde ne o dobrou strukturovanost, ale jen o strukturovanost. Jestliže se přidají ještě některé další řídící struktury, např. obecné větvení, cykly s postrannými východy, potom již jde o nestrukturovaný zápis algoritmů. Následující ukázka zapisuje jistý algoritmus v nestrukturované a dobře strukturované formě.
-5-
Zápis algoritmu v programovacím jazyku by neměl atributy dobře strukturovaného zápisu narušovat. Proto výzkum programovacích jazyků přinesl i odpovídající notace příkazů (viz např. Pascal).
-6-
Příklad 1
Následující formální fragment jistého algoritmu je zapsán dobře strukturovaně nejen ve vývojovém diagramu, ale i v programu.
Pojetí řídících struktur je spojeno s teoretickou otázkou jejich "síly", tj. množství algoritmů, které se jimi dají přirozeně popsat. Které řídící struktury jsou silnější, které slabší ? Tuto teoretickou otázku řešil v roce 1980 japonský informatik Kosaraju viz (Kosaraju, 1980). Kosarajova klasifikace řídících struktur (základy) Kosaraju ukázal, že je možné porovnání tříd řídících struktur převést na porovnání jimi generovaných programů. Jsou-li R1, R2, dvě třídy řídících struktur, potom T1(R1), T2(R2) jsou jim náležící třídy programů, které jsou jednotlivými třídami generovány. Místo porovnání R1 a R2 Kosaraju porovnává třídy T1 a T2. Porovnání ale založil na jistých transformacích jedné třídy programů na druhou. Jaké to vlastně transformace jsou? Buď P program, a jeho primitivní akce (např. přiř. příkaz, příkaz v/v dat, volání procedury), p jeho predikát a h jeho jedna výpočetní historie (posloupnost akcí a predikátů).
-7-
Kosaraju zavedl čtyři vlastnosti programů, označené V1, …, V4 , které jsou definovány takto:
-8-
Diskuse
Výsledek:
-9-
Poznámka:
- 10 -
- 11 -
Závěr: Hlavním cílem strukturovaného programování bylo dodržet lineární korespondenci mezi statickou a dynamickou strukturou programu. To mělo podpořit přehlednost, čitelnost, snadnou modifikovatelnost a snadnou verifikovatelnost. Pochopitelně, žádalo se vyřazení použití příkazu Goto z množiny příkazů imperativních programovacích jazyků, což se ale nepodařilo. Ačkoliv v programovacích jazycích je podmnožina řídících struktur, které vedou na dobře strukturovaný program, přesto jsou další struktury jen pro obyčejnou strukturovanost a dokonce zůstávají i příkazy vedoucí na nestrukturovaný zápis. V současné době se chybně této problematice již nevěnuje tak velká pozornost. Je na tvůrcích programu, jestli alespoň pro sebe, se snaží mít program s požadovanými strukturálními kvalitami.
3.4 Modulární programování Modulární programování je technika vybízející programátora k rozložení programu na jednodušší celky tzv. moduly se zachováním jejich celkového vzájemného kontextu (vazby). Členění programu na moduly by mělo sledovat především dekompozici funkcionality programu. Obecně se do modulů dekomponuje nejen funkcionalita, ale i další atributy programů:
funkcionalita komplexního programu, která je zapsána pomocí specifikací na požadavky žadatele, data a jejich datové vazby, řízení přechodů mezi moduly, řídící vazby, kompetence na data a operace s nimi.
Moduly jsou základní prvky modulárního programování – strukturální prvky komplexního programu. Obecně mohou mít následující složení: deklarace lokálních datových struktur
S modulárním systémem jsou spojeny některé zvláštnosti: definování konkrétních vazeb mezi moduly, (datové, řídící a kompetenční vazby),
výkonná část modulu, procedury modulu
vizuální reprezentace všech typů vazeb mezi moduly.
lokální data globální data modulu
Poznámka: 1. Globální data modulu M jsou přístupná všem procedurám ostatních modulů. 2. V každé proceduře modulu M se mohou používat trojí data: a. Lokální data, přístupná všem procedurám modulu M b. parametry procedur (formální-skutečné parametry), c. nelokální data modulu M (globální data ostatních modulů a globální data modulu M).
- 12 -
Vzhledem k tomu musely být v souvislosti s modulárním programováním řešeny i teoretické otázky. Postupně se v odborné literatuře objevily články o sémantickém systému vhodných relací mezi moduly, pomocí kterých byly reprezentovány známé vazby. Výzkum pokročil koncem 80. let tak daleko, že nad modulární strukturou byla zavedena teorie s axiomy, užitečným jazykem, logikou a velmi schopnou algebrou operací. To vše umožnilo komputerizovat vývoj modulárního systému a vytvořit potřebné vývojové prostředí. Základem byly relace použití........
přístup.......
A
B.......Volání, odkaz a distribuce modulu B z podnětu modulu A. Jde o to, že procedury modulu A se obrací na procedury modulu B.
A
B......Procedury modulu A používají globální data modulu B jako svá nelokální data (čtení/změna globálních dat modulu B).
A
B......Modul A má jen přístup (jen čtení) na globální data modulu B.
A
B......Modul B je chráněn před zásahy z modulu A. Procedury modulu A nemohou používat globální data modulu B jako svá nelokální data.
na globální data
ochrana......
Graf modulárního systému je tvořen uzly-moduly a hrany jsou vazby mezi moduly. Jednotlivé relace mají vlastnosti, které se dají vyšetřovat. Nad modulární strukturou se dá vybudovat teorie s axiomy, jazykem a logikou. Mluvit obecně o řízení v modulárním systému, je stejné jako mluvit o typech řídících struktur, o způsobech návratů v řízení ... Pro orientaci v modulární struktuře je potřebné nakreslit alespoň dva grafy: 1. G1 , pro globální modulární strukturu programu, se zaměřením na vazby mezi moduly, na disponibilitu modulů (uzly jsou moduly). 2. G2 , pro strukturu každého z modulů (uzly jsou procedury modulu).
Příklad 2 Nechť jsou dány čtyři moduly A,B,C a D. Jejich graf G1 má následující tvar:
- 13 -
Je zřejmé, že modul A musí být k dispozici vždy, když to žádá kterýkoli z modulů C a D. Rovněž modul C musí být k dispozici modulu B a modul B k dispozici modulu A. Modul D je chráněn od zásahů modulu B.
- 14 -
Definice
- 15 -
Definice
A
*
A
*
C
C C
B
ti A nelze
A
- 16 -
*
C
B pro-
Poznámka
- 17 -
- 18 -
Koncepce řídících vazeb v modulárním systému Řídící vazby mezi moduly se zobrazují pomocí grafu řízení. Uzly tohoto grafu jsou moduly a nebývají kresleny tak jako běžné uzly grafu (často je to obdélník). Existuje několik struktur řídících vazeb, např.: 1. Přísná struktura s jediným řídícím modulem M0 (šipka je zde řídící vazba). M0
M1
M2
M3
Modul M0 zajišťuje všechna logická rozhodnutí, ale neprovádí žádná zpracování. Vedle toho zprostředkuje přenos dat mezi moduly a vstup/výstup dat do/ze systému modulárních systémů. Zpracovatelské moduly (nižší úroveň) 2. Přísná struktura s jediným řídícím modulem M0 a zpracovatelskými moduly do hlubší úrovně.
Pro danou strukturu řízení můžeme nakreslit graf G1 .
- 19 -
3. Stromovitá struktura s řídícími návraty o jednu úroveň výše. Tato struktura odpovídá grafu se speciálními návraty.
Některá reálná pojetí Modulárního programování Mezi nejznámější reálně fungující implementace Modulárního programování patří: •
Modulární programování založené na Windows formulářích v technologii vývoje Microsoft desktopových aplikací.
•
Modulární programování založené na pojetí DHTML stránek a jejich formulářů na platformě WWW služby Internetu.
•
Modulární programování založené na pojetí komponenty na bázi Objektového programování a platformě WWW služby Internetu.
•
Modulární programování založené na pojetí aplikace jako komponenty balíku aplikací IS podniku (tzv. „Aplikační architektura“).
Téměř ke všem z těchto reálných implementací se v přednáškách dostaneme a při výkladu budeme sledovat především základní atributy obecného modulárního programování: • Co je považováno za modul. • Jaká je struktura modulu. • Jak jsou interpretovány obecné relace
- 20 -
Závěr Modulární programování sehrálo první roli metody a techniky zaměřené na přijatelnou strukturalizaci programu. Jeho dobou byly 80. léta. Vzniklo několik vývojových systémů, které pracovaly na bázi modulárního programování. Byla rovněž snaha zabudovat framework modulárního programování do operačních systémů a zorganizovat potřebnou podporu. Nástupem Internetu se změnil i pohled na strukturalizaci software, ale mnohé z užitečných myšlenek modulárního programování byly převzaty do nového kabátu. Rovněž algebra a návrh teorie modulárního programování nezůstal později bez povšimnutí. Důležité je ovšem to, co modulární programování přineslo: • • • •
zavedení strukturysoftware pomocí základního strukturálního prvku - modulu, interpretaci pojetí modulárního programování v praxi, nutnost klasifikovat vazby mezi základními prvky - moduly, najít formální aparát pro zaznamenání kvality software rozloženého do základních prvků - modulů.
Dnešní strukturalizace software se neustále vyvíjí a patří sem jak pohledy završené tzv. vrstvenou strukturou (prezentační, aplikační a datová vrstva), tak i pohledy uznávající distribuované objekty a dokonce ucelené komponenty vedoucí na hlubší vrstevnost software. V každém případě je snaha formálně obsáhnout jak popis strukturálních částí, tak i jejich vzájemné vazby. Sleduje se to, aby části do sebe "zapadly", aby se daly snadno vyměňovat za jiné - lepší a aby byla zabezpečena integrace ve všech možných směrech (datovém, komunikačním, procesním, řízení, …).
3.5 Procedurové programování Procedurové programování je jednou z metod, která nebyla dodnes odmítnuta, ba právě naopak, její role stoupla se skriptováním a objektovým programováním. Procedurové programování se stalo základem výstavby software všech typů. Můžeme vyslovit následující definici. Definice Procedurové programování je metoda nutící programátora rozdělit funkcionalitu software do samostatných celků – procedur. Procedury se potom stávají stavebními kameny funkcionality programu. Jejich voláním se realizuje požadovaná funkcionalita celého programu. Stavebním kamenem je tedy procedura. Tento kámen však vystupuje téměř na nejnižší úrovni strukturalizace software. Jinými slovy, vždy se vše nakonec "promítne" do procedur. S použitím této metody souvisí několik požadavků: 1. Programovací jazyk musí umožnit formální konstrukci procedury a koncipovat vzájemné souvislosti mezi formálními a skutečnými parametry. Skutečné a formální parametry jsou datovým komunikačním interface s okolím, ze kterého je procedura vyvolána. 2. Programovací sytém (programovací jazyk a jeho překladač) musí zabezpečit vše co souvisí se záměnou formálních parametrů parametry skutečnými (kontrola datových typů, ... ).
- 21 -
3. Vývojový systém musí umožnit tvorbu knihovny procedur, jejíž využití napomáhá inženýrskému způsobu tvorby software. Těmto požadavkům hoví většina současných procedurových programovacích systémů (Pascal, Java, PERL, PHP, Visual Basic, C jazyk, …).
Původ procedur je v podprogramech z Assemblerů. Podprogramy se zabalily do roucha vyšších programovacích jazyků a vznikly procedury. Mnoho překladačů vyšších procedurových programovacích jazyků překládá procedury právě do podprogramů jazyka Assembler. Dokonce pro vývojové diagramy byla navržena speciální značka pro podprogramy, kterou můžeme úspěšně použít i pro procedury a přizpůsobit potřebné zápisy jejich funkcionalitě.
Většinou se procedury člení na tzv. funkční a obecné. Procedury mohou a nemusí mít vstup, mohou a nemusí mít výstup. Existují jisté principy pro komunikaci formálních a skutečných parametrů, které je potřebné nastudovat pro konkrétní procedurový programovací jazyk. Detaily práce se skutečnými a formálními parametry, tvorba a vyvolání procedur ve zvoleném programovacím jazyku: Diskuse. Závěr Procedurové programování je mezi metodami tvorby software stálicí. Doznalo za celou dobu software jen nepatrných změn. Procedurové pojetí struktury současného webového software má zásadní význam.
Příklad 3 Následující program v jazyku Pascal používá několik procedur.
- 22 -
- 23 -
3.6 Úvod do objektového programování (Textový materiál, který následuje, je zakoupen od Ilji Kravara, který je autorem)
Pro lepší studium této problematiky doporučujeme obsáhlejší materiál - knihu Základy objektově orientovaného programování od Ilji Kravara, jejíž titulní stranu vidíte na obrázku:
Definice Objektové programování je metoda, která nutí programátora zavést stavební kameny – objekty a na základě vzájemného posílání zpráv mezi objekty realizovat potřebnou funkcionalitu programu. Základem funkcionality jsou metody zapouzdřené v objektech a spouštěné pomocí zpráv. Dále se pokusíme podstatu této definice objasnit.
- 24 -
3.6.1 Jak se uvádějí nesprávně základní vlastnosti objektového prostředí Otázka této kapitoly zní jednoduše: Co je vlastně dodržování principů OOP a co je jeho porušením? Který jazyk nebo prostředí více vyhovuje požadavkům objektového principu a který méně? A jaké jsou vlastně požadavky na OOP? Často se uvádějí následující pojmy definující principy OOP:
Zapouzdření, Polymorfismus, Dědění.
Podle uvedeného (nepřesného) výčtu, jazyky a softwarové technologie, u kterých lze identifikovat tyto tři pojmy, jsou objektovými a naopak u těch jazyků a technologií, u kterých alespoň jedna ze tří uvedených vlastností chybí, do OOP nepatří. Tato tříčlenná charakteristika je sice objektovému přístupu většinou vlastní, ale není prioritní a axiomatická. Je odvozená od jiných, základnějších pojmů OOP. Není to tedy přesné vymezení, protože základní vlastnosti OOP jsou trochu odlišné a nyní si je uvedeme.
3.6.2 Základní postuláty OOP Prostředí resp. jazyk nebo technologie splňuje objektově orientovaný princip, pokud dovoluje vytvářet struktury nazývající se objekty a tyto mají následující vlastnosti:
Objekt je definován jako v programu uzavřená struktura, která: 1. obsahuje vnitřní paměť, tj. má vlastnost si něco pamatovat. Tato vnitřní paměť se někdy nazývá atributy objektu. Důležité je, že vnitřní paměť objektu je zvnějšku objektu nepřístupná. Je jeho soukromou záležitostí, co si objekt pamatuje a jak. 2. obsahuje metody objektu, což jsou procedury nebo funkce, resp. obecněji posloupnost kódu programu - někdy také nazývané skripty objektu, které vykonávají nějakou činnost nad vnitřní pamětí objektu a pouze nad ní. Metody objektu jsou zvnějšku také neviditelné a nepřístupné. Nemůžeme metodu objektu zavolat přímo. Vnitřní paměť a vnitřní metody téhož objektu jsou vůči sobě plně viditelné. Metoda objektu má v dosahu své viditelnosti vnitřní paměť a naopak. Jinými slovy, metoda objektu je to, co je schopno pracovat s vnitřní pamětí objektu a nic jiného. Můžeme si představit, že metoda objektu je jedinou možností jak zpracovat vnitřní paměť objektu. 3. je strukturou, která je nějakým mechanismem schopna přijmout a zpracovat zprávu zvnějšku. V každém jazyce a použité technologii je tato schopnost zpracovat zprávu implementována nějak jinak. Mechanismus zpracování zprávy je takový, že každý objekt v sobě obsahuje tzv. protokol zpráv, což je přiřazení zprávy versus metoda objektu. Můžeme si to představit jako převodník mezi zprávou a metodou. Každá zpráva v protokolu zpráv má přiřazenu právě jednu metodu objektu. Přijmout a zpracovat zprávu pro objekt znamená, že objekt v protokolu zpráv nalezne odpovídající zprávu, k ní nalezne odpovídající přiřazenou metodu a spustí ji se vstupními přijatými parametry a po vykonání metody vrátí zprávě výstupní parametry. Jedinou možností, jak spolupracovat s objektem, je poslat mu zprávu. Jinými slovy při použití objektu jako uživatel zvně se nezajímáme o vnitřní strukturu objektu, o uspořádání metod a atributy (které stejně nevidíme), ale o „reakce“ objektu na zprávy. 4. může obsahovat jiné objekty, kterým je schopen poslat zprávy a tak řídit jejich činnost. Tímto vznikají sekvence zasílání zpráv od objektu k objektům a vzniká tak tok činnosti programu.
- 25 -
Tyto čtyři základní postuláty jsou základními postuláty OOP. Uvedené čtyři postuláty lze znázornit pomocí následujícího obrázku: Definice objektu
objekt Zpráva
Metody
Protokol zpráv Vnitřní paměť
objekt objekt objekt
Důležité je, že tento seznam je pro další odvozování vlastností prvků v OOP dostačující, je axiomatický (jsou to principy OOP). Při tomto vysvětlení OOP je třeba uvést tyto důležité termíny, jinak by mohlo dojít k nedorozumění: • • • • •
"volání metody objektu", zapouzdření, polymorfismus, třída, dědění.
3.6.3 Pojem „volání metody objektu“ je pouze zkratkou pro delší větu Většinou se při spolupráci s objektem hovoří o volání metody objektu. V předešlém výčtu se však hovoří o nějakém zasílání zpráv. Který výraz je tedy ten správný - „poslat zprávu“ nebo „volat metodu“? Podle principů OOP z předešlé kapitoly takovéto „přímé volání metod objektu“ není přípustné, ale hovoří se o posílání zpráv, tj. podle postulátů OOP se zavádí mechanismus zasílání zpráv objektu, což znamená, že se objektu nejprve pošle zpráva. Teprve na základě
- 26 -
této zprávy se v protokolu zpráv nalezne odpovídající metoda a spustí se tato metoda nalezená v protokolu zpráv. Spouštění metod podle zaslaných zpráv je základní princip práce objektu a vystihuje jeho podstatu! Protokol zpráv má tedy význam jakéhosi převodníku mezi zprávou a metodou, přičemž převodník je ve vztahu jedna zpráva ku jedné metodě. A jak je to tedy s voláním metody? Copak všichni, kdo používají slovní spojení „volat metodu objektu“, se mýlí? Pokud bychom měli být důslední, tak v podstatě ano, protože OOP zná pouze „zaslat zprávu objektu“ a nezná „volat metodu objektu“! Udělejme tedy kompromis: Pokud použijeme slovního spojení „přímé volání metody objektu“, máme tím na mysli zkratku pro delší slovní spojení „poslání zprávy objektu a vyvolání metody objektu“. V určitém momentu dalšího výkladu upozorníme na důležité zachování tohoto principu zasílání zpráv. Je třeba podotknout, že mechanismus zasílání zpráv objektu je závislý na použité technologii a na objektovém jazyce a liší se případ od případu. Jak si takový převodník zpráva-metoda můžeme představit konkrétně? Příkladem může být jednoduchá tabulka v paměti - seznam názvů zpráv a k nim přiřazených počátečních adres metod, kam se má předat řízení kódu. Také komponentní technologie COM má tento mechanismus zasílání zpráv objektu nějakým podobným způsobem zaveden - přes tabulku ukazatelů na metody. Poznámka: Přímo v technologii COM existuje ještě i druhý způsob zasílání zpráv a vyvolání metod v objektu a to v navazující technologii Automation (použití COM přes IDispatch interface). Technologie COM se v tomto případě stává pouze prostředníkem pro jiný způsob vyvolání metody přes tabulku zpráva-metoda (viz například kniha Základy komponentní technologie COM).
3.6.4 Zapouzdření je opravdu postulátem OOP, další pojmy jsou důležité, ale odvozené Možnost spolupráce s objektem pouze přes zasílání zpráv je opravdu postulátem OOP. Další dvě uváděné vlastnosti - polymorfismus a dědění, jsou pojmy sice velmi důležité (jejich využití je velmi výhodné), jsou tedy pro OOP charakteristické, avšak jsou to z hlediska „teorie OOP“ pojmy odvozené. Lze je pochopit na základě postulátů. Také my si je takto srozumitelně vysvětlíme.
3.6.5 Jiný pohled na aplikaci - objekt není skalár, ale je to zajímavá „samostatná“ struktura Jedním z důsledků zavedení objektů do aplikace je i jiný pohled na aplikaci, než byl až do použití objektů. V teorii datových modelů (resp. teorii databází) se zavádí velmi důležitý pojem skalár. Pro lepší pochopení problematiky si tento pojem vysvětlíme: Skalár se chápe jako atomická a dále nedělitelná informaci v systému.
- 27 -
Příklad: Proměnná typu String, Long, apod. ve VB je skalárem. Proměnná typu „record“ nebo vlastního typu není skalárem. V teorii databází se tento pojem zavádí z prostého důvodu - je požadováno, aby sloupec tabulky byl skalárem. Pokud není sloupec tabulky zaveden jako skalár, potom se vlastně nejedná o to, co si pod sloupcem máme správně představit a vytváří se místo „správného sloupce“ skupina dále dělitelných informací. V tom případě se hovoří o první nenormalizované struktuře, kdy nějaká informace - sloupec - obsahuje jako své části další jiné informace. Nelze například navrhnout jeden záznam tabulky skládající se ze sloupců tak, že jeden z těchto sloupců zavedeme jako další celý záznam tabulky. Tato situace obsažení jedné informace v druhé se namísto vnoření řeší odkazem přes vnucení cizího klíče do jiné tabulky a nikoliv vnořením tabulek do sebe! Teorie databází se zásadně vyhýbá vnořování tabulek do sebe. Oproti tomu objektové struktury jsou zásadně „skládající se“ již z principu. Odkaz na jiný objekt se chápe jako zvláštní případ vnoření - v objektové struktuře má smysl hovořit o vzájemném vnoření objektů do sebe, což u tabulek nemá smysl. V tabulkách řešíme odkaz z jedné tabulky do druhé nikoliv vnořením, ale pomocí nějakého sloupce, který se stává vazebním klíčem mezi tabulkami. Představme si, že opravdu můžeme tabulky skládat jako do sebe nořící se struktury. Můžeme namalovat takovou „tabulku“, kde jeden sloupec je vlastně řádkem další tabulky. Vznikne tak příklad popisu následující entity (pozor - toto není normalizovaná struktura!): A = [ a1, a2, a3, [ b1, b2] ]= [a1, a2, a3, B ] kde B = [ b1, b2 ] Tuto „vnořenou“ konstrukci samozřejmě teorie databází nedovoluje. Pokud bychom chtěli obdobu této konstrukce napsat v databázové teorii, potom bychom napsali něco v tomto smyslu: A = [ a1, a2, a3] B = [ b1, b2, a1 je cizí klíč ] Nebo A = [ a1, a2, a3, b1, b2 ] apod. (záleží na návrhu datového modelu) Prvky a1, a2, a3, b1, b2 považujeme za dále nedělitelné informace, tedy skaláry. Naopak v objektové teorii je vnoření objektů a tedy „neskalárnost“ při skládání základní vlastností. Zápis ve tvaru: A = [ a1, a2, a3, [ b1, b2] ] = [a1, a2, a3, B ] Můžeme v dalším vývoji měnit podle požadavků analýzy, například: A =[ a1, a2, a3, [ b1, b2] ] = [a1, a2, a3, B ] = [ C, a3, B ] kde C = [a1, a2]. Jednotlivé návrhy entit, tj. který z těchto skládajících zápisů bude vlastně tím pravým, jsou dílem analýzy a tvorby objektového modelu. Optimální je ten návrh, který vede k maximálnímu znovupoužití pojmů a minimalizaci kódu. Tuto optimalizaci zavedeme s pojmem třída.
- 28 -
Příklad 4 Objekt Osoba má Rodné číslo, Jméno, Příjmení, Ulici, Město a PSČ. Zvolme zkratku pro písmeno m jako atribut a písmeno o jako zkratku pro objekt. Jeden z možných návrhů objektu je: Osoba = [m Rodne cislo, m Jmeno, m Prijmeni, m Ulice, m Mesto, m PSC] Jiný návrh může být: Osoba = [m Rodne cislo, m Jmeno, m Prijmeni, o Adresa] kde Adresa = [m Ulice, m Mesto, m PSC] Vnořili jsme do sebe dva objekty - do Osoby jsem vložili Adresu. Je dobré si uvědomit, že vnoření objektů dovoluje i vazbu 1 : N pomocí objektů realizujících tento vztah (kolekce, dictionary apod.) tj. vnoření N prvků zapsané takto: A = [ a1, a2, a3, N * [ b1, b2] ] = [a1, a2, a3, N * B ] Ke skládání - vnořování - se vrátíme v jedné z kapitol o chybách začátečníků, protože tam se vyskytuje jedna z nejzávažnějších chyb při zvládání OOP. Dopředu podotkněme, že vnořování objektů jako jejich základní vlastnost implicitně určuje to, že se nikdo nemusí v programu starat o vytváření vazeb mezi objekty ve smyslu zavádění klíčů v objektových strukturách, což bývá nejčastější chybou začínajících programátorů!
3.6.6 Polymorfismus Na uvedených postulátech (stejně jako na všech postulátech) je výhodné to, že z nich lze odvodit další vlastnosti objektů. Podobně je tomu u polymorfismu. Setkáváme se s mnohými způsoby vysvětlení polymorfismu - některé velmi nepřesné a velmi složité. Přitom vysvětlení polymorfismu je jednoduché. Představme si tu situaci, kdy dva různé objekty mají ve svém protokolu stejnou zprávu, ale každý z nich na ni reaguje jinou metodou. Znamená to, že oba objekty mají ve svém protokolu zpráv tutéž metodu, ale každý z nich má k nim přiřazenu jinou metodu. Pokud oběma objektům pošleme tutéž zprávu, každý z nich vyvolá jinou metodu. Tuto situaci různého chování objektů na stejnou zprávu nazýváme polymorfismus. Uvědomme si, že polymorfismus je v „normálním“ životě natolik běžný, že si jej ani neuvědomujeme. Například představme si N jedinců, kteří rozumí určité zprávě, kterou jim předáme, ale každý na ni reaguje jinou metodou. Takto se přece chová valná většina z nás! Podle základů OOP je dostačující, aby daný objekt rozuměl určité zprávě (měl ji v protokolu zpráv)
Například dva objekty Text a Obrázek mohou skládat Stránku a mají tutéž zprávu Vytiskni se. Každý z nich tak činí jinak, jinou metodou, jedna je metodou pro tisk textu, druhá je metodou pro tisk bitové mapy. Celá Stránka, což je objekt – „kontejner“, který obsahuje několik Textů a několik Obrázků. Protože obsluha může poskládat obsah Stránky libovolně, není dopředu jasné, jak bude Stránka složena, tj. z kolika objektů Obrázek a objektů Text. - 29 -
Pokud chceme stránku vytisknout, nabízí se nám pomocí polymorfismu elegantní a jednoduché řešení: Každému objektu na Stránce se pošle zpráva Vytiskni se. V teorii OOP je polymorfismus zaveden jako důsledek existence protokolu zpráv a má jednoduché vyjádření: „Různé chování různých objektů na tutéž zprávu“. V knihách o OOP naleznete ještě několik dalších příkladů na polymorfismus. Princip je však vždy stejný. Připomeňme jenom, že polymorfismus vyplynul sám od sebe od konstrukce objektu: Objekt může přijmout zprávu a na základě ní vyvolat metodu.
3.6.7 Třída V postulátech obecné teorie OOP se hovoří o vlastnostech objektu jako takového a není v nich žádná zmínka o nějaké třídě. Znamená to, že podle teorie OOP mohou existovat objekty bez zavedení třídy! Důležité je vědět, že v teorii OOP lze hovořit o objektu bez třídy, tj. lze deklarovat a zavést jeden objekt „přímou definicí“. Stačí definovat jeho vlastnosti, tj. jaké má nový objekt atributy, jaké má metody, jaký má protokol zpráv a z jakých objektů je složen. Tento způsob tvorby objektů „deklaruj jeden objekt po druhém“ je podle teorie OOP možný, má však jednu nevýhodu: Pokud budeme deklarovat „úplně stejný objekt“ lišící se pouze názvem, ale jinak má nový objekt stejné vlastnosti jako již hotový objekt, potom se v definici budeme opakovat. Z toho důvodu, aby se definice nemusela opakovat, se zavádí nový objekt Třída. Je to takový objekt, který napomáhá vzniknout jako kopyto, jako forma novým objektům stejných vlastností. Pokud tedy definujeme nový objekt, stačí v této definici uvést, z jaké je Třídy. Další je již dáno vztahem mezi objekty. Stačí tedy definovat jednou kopyto pro budoucí objekty a můžeme jich poté definovat kolik chceme a nebudeme se v definici opakovat, pouze se odkážeme, že objekt je z této třídy, čímž je dáno, jak je definován. Znamená to, že pojem třída je pouze něčím, co nám napomáhá definovat nové objekty jako jejich forma, jejich kopyto, jejich šablona. Jenom pomocí třídy nic „nenaprogramujete“, stejně jako jenom pomocí šablony na boty (kopyta) nikoho neobujete. Musíte pomocí šablony objekt nechat zrodit (create, Set New ... apod.). Některé jazyky jako Visual Basic, Visual C++, Delphi (Object Pascal) nemají třídu zavedenu jako objekt pomáhající tvorbě nových objektů, ale z historických důvodů mají pojem třída zaveden nějak jinak. Smysl „kopyto pro objekty“ je však stejný! V těchto jazycích je třída zavedena jako obdoba typu proměnné. Znamená to, že základní funkce třídy je tímto zachována: Jedná se také o „kopyto, formu“ pro budoucí objekty dané třídy, tzv. instance třídy. I kdybychom v systému vytvořili pouze jeden objekt z dané třídy, musíme tuto třídu v těchto jazycích vždy zavést. Postup je takový, že nejprve musíme deklarovat třídu (např. class module, form module, apod. v Basicu) a teprve potom můžeme vytvářet instance z těchto tříd. Důležité pro pochopení třídy (kromě toho, že se jedná o kopyto pro budoucí objekty) je to, že pomocná třídy začíná v OOP vznikat nový druh abstrakce. Pokud zavedete třídu pro budoucí instance třídy, tak vlastně definujete vlastnosti pro každou instanci, což je již samo o sobě abstrakce. Pokud například napíšete pro třídu osob Cosoba, že objekt osoba z této třídy bude mít jméno a příjmení, tak jste vlastně řekli „obecně osoba má jméno příjmení“, což je abstraktní věta.
- 30 -
3.6.8 Dědění Zavedení pojmu třída napomohlo definici nových objektů proto, aby se nemusel opakovat kód. Podobně dědění napomáhá ušetřit kód tehdy, pokud se nalézají ve třídách společné prvky. V tom případě se tyto prvky stávají zobecněním pro obě třídy a vzniká tak vztah dědění z jedné třídy do druhé. Pokud budeme zavádět dvě třídy pro tvorbu budoucích objektů a zjistíme přitom, že jedna třída deklaruje všechny vlastnosti objektů stejné jako druhá třída a navíc zavádí nové vlastnosti, tzv. vztah generalizace a specializace mezi třídami, je možné použít dědění jako vztah mezi třídami, pokud daný jazyk podporuje tento vztah. Dědění je vztahem mezi třídami a odstraňuje duplicitu při definici tříd, pokud mají třídy něco společného. Některé jazyky dědění přímo nepodporují a nahrazuje se různými postupy. Bližší podrobnosti těchto postupů naleznete v uvedené knize. Důležité je, že dědění je vlastností nikoliv podstatnou pro OOP, že se jedná o vlastnost odvozenou, a že dědění je jedním z řešení, jak odstraňovat duplicity kódu. Závěr Význam objektového programování je značný. Je to specifický pohled na základní strukturální prvky a jejich použití pro výstavbu funkcionality software a na techniky (zpracování objektů) přitom používané. Na základě této metody dochází k rozvoji ještě flexibilnějších a inženýrskému stylu tvorby software bližších metod a technik (objektové modely v systému spolupráce klient-server, komponentové programování, internetové služby). Ačkoliv vznikl v procesu programování software a snah najít vhodné strukturální prvky s možným opětovným použitím (reusing) , byly jeho myšlenky povýšeny i na problematiku modelování reality (podnik, škola, …) a v základu použity k tvorbě business software informačních systémů. Objektový přístup k modelování a realizaci informačních systémů používá objektové programování a systémy umožňující ho realizovat, za základ objektové implementace.
3.7 Událostní a skriptové programování Tyto dvě metody - myšlenkové postupy jsou nerozlučně spjaty s webovou platformou pro tvorbu tzv. webových aplikací (tedy Web – based Applications). Webová platforma je abstraktní označení pro souhrn vlastností a možností webových ICT (značkovací jazyky, např. HTML/DHTML, technologie komunikace tenký klient-server založená na distribuci informace, webové služby, …).
Událostní programování Začátky událostního programování spojujeme s možností přidělením specifické množiny událostí každému objektu podle jeho charakteru (textové políčko, seznam, formulář, …). Myšlenka potom spočívá v možnosti událost vyvolat-spustit a zachytit a reagovat na ni. Realizace těchto požadavků potom umožnila převést statické HTML stránky na tzv. dynamické DHTML stránky. Jestliže je pro daný objekt událost zachycena, systém zachycení umožní předat řízení na reakční proceduru. V proceduře je možno nejen měnit kvalitu daného objektu, ale nastavovat i jiné aktivity v rozsahu dané stránky HTML. - 31 -
Definice Událostní programování je metoda umožňující reagovat na události objektů a realizovat od událostí odvozené aktivity se stanoveným rozsahem platnosti.
Příklad 5 Následující DHTML stránka ukazuje využití událostního programování k zabezpečení různých dynamických aktivit objektů na stránce. Mnohé DHTML editory (např. FrontPage, …) pro tvorbu webových stránek takové dynamické efekty mohou pro vybrané typy objektů organizovat. Typické je využití událostí „click“ a „double click“. Pochopitelně, zdrojový kód je automaticky generován.
- 32 -
Skriptové programování Poněkud odlišná je metoda skriptového programování. Na stránky HTML na straně klienta se mohou umístit kusy programového kódu identifikované dohodnutými značkami. Mohou zde být reakční procedury na události asociované s objekty stránky, ale rovněž kód s událostmi nesouvisící. Potom většina těchto skriptů patří do prezenční vrstvy HTML stránek webové aplikace. Kusy kódu – skripty můžeme umístit rovněž do webové stránky na straně serveru. Význam těchto skriptů je ale poněkud jiný než význam skriptů na straně klienta (tenký klient reprezentovaný pouze samotným prohlížečem – Browser). Různé pohledy a role na skripty na straně klienta a serveru jsou zabudovány ve filosofii www funkce pro stránky HTML. Velmi často se serverové skripty podílí na realizaci logiky datové vrstvy (logika zpracování dat), na přípravu komunikace s datovou vrstvou a na korespondenci objektů a dat mezi tenkým klientem a serverem (např. pomocí formulářů). Značná část skriptů na straně serveru je věnována komputerizací procesů daného fyzického systému a patří tedy do aplikační vrstvy třívrstvé webové aplikace. Pochopitelně, poloha skriptů jasně člení skripty na klientské a skripty serverové. Neméně je závažná i druhá skutečnost spojená s existencí skriptů: 1. DHTML stránky a webové serverové stránky se v důsledku metody událostního a skriptového programování stávají jednoduchými webovými aplikacemi (Webbased Simple Applications), 2. je přesně stanovena filosofie manipulace se skripty na straně klienta a serveru. Některé technologie odlišují serverové a klientské webové stránky dvěma odlišnými příponami (např.: .htm a .asp nebo .aspx). Hezky tuto situaci ilustruje následující vrstvové strukturální schéma jednoduché webové aplikace. Definice Skriptové programování je metoda-technika umožňující umísťovat skripty – kusy kódu na DHTML stránky tenkého klienta a serveru a tak realizovat aktivity náležící zejména do prezenční a aplikační (business) vrstvy webových aplikací. Filosofie Internetu pro práci s klientskými a serverovými stránkami webovými stránkami se sice vyvíjela několik let, ale teď je již více méně ustálená. Diskuse. Filosofie Internetu pro práci s klientskými a serverovými webovými stránkami. Účel použití skriptů na straně klienta a serveru.
Následující obrázek ilustruje třívrstvou webovou aplikaci a obsah jednotlivých vrstev v souvislosti s ICT firmy Microsoft.
- 33 -
Prvky GUI datové asociace datové asociace 2. vrstva APLIKAČNÍ – business kód Logika zprac.dat kód - skripty
Prvky pro správu dat
kód
asociace na základě událostí
APLIKAČNÍ
procedury
kód - skripty
události
Reakční procedury 1. vrstva PREZENČNÍ
Poskytovatel
BD 3. vrstva DATOVÁ
U této třívrstvé webové aplikace (druhé generace1) je známo, že: • • •
1. a 2. vrstva je uložena na provozním serveru, 1. vrstva se projeví vizuálně zejména na straně tenkého klienta, 2. vrstva je již kombinací aplikačních procedur a kódu logiky zpracování dat.
Příklad 6 Tento příklad je pouze ukázkou použití skriptů v jednoduché webové aplikaci pro komplexní zpracování průzkum prostřednictvím dotazníku. Konstrukce webových stránek aplikace je provedena v editoru FrontPage. Následující formulář-dotazník Používáte_výpočetní_techniku. htm obsahuje část osobních údajů klientů a část o zájmech klientů v oblasti výpočetní techniky. Vyhodnocení správnosti odeslaných dat provedeme na straně serveru ve stránce Vyhod_Zprac_Potvr.asp a bude se týkat jak osobních údajů, tak i zájmu o výpočetní techniku. Správné údaje potvrdíme a uložíme do báze dat zájmy.mdb O nesprávných datech budeme indikovat chyby. První závažnou chybou uživatele – tenkého klienta je neúplnost dat ve formuláři. Musí být uvedeny všechny osobní údaje. Dále je na syntax hlídáno PSČ ( 5 číslic ) a telefon (jen číslice). Pro zpracování formuláře vytvoříme jednoduchou aplikaci PRŮZKUM, která zabezpečí následující funkcionalitu.
1
webové vícevrstvé aplikace a založené na komponentním programování s webovými službami považujeme za webové aplikace 3. generace
- 34 -
SYSTÉMOVÉ FUNKCE : A)
Sledování průzkumu uživatelů různých typů počítačů ( stolní, notebook, kapesní ) a software ( hry, programovací systémy, kreslící programy). Každý z klientů zapíše při prvním přístupu
k dotazníku své osobní údaje a zaškrtne jistá políčka formuláře pro záznam jeho zájmů. Jestliže jde o druhý a další přístup, potom se osobní údaje zadávají znovu (opravený výsledek zájmu). Každý klient je uložen spolu s jeho zájmy do malé báze dat zájmy.mdb o dvou tabulkách Klient a Zájem. Tyto tabulky jsou spojeny vazbou 1: N podle atributu IDklienta. Zájem
Datum testování
Klient
ID klienta ID klienta Jméno Ulice Město PSČ Telefon ….
Stolní počítač 1
N
Notebook Kapesní počítač Microsoft Office Hry Kreslící programy Programovací systémy ….
Pro BD bude použit systém Access 2000. B) Vyhodnocení průzkumu vede na nakreslení dvou grafů. V prvním z nich jsou zachyceny vztahy mezi počty počítačů a v druhém vztahy mezi počty software pro daný vzorek klientů. (neřešeno).
C) Administraci pro BD provádí jedině administrátor, který má právo provádět některé operace s BD, jako "Vyčištění BD pro nový průzkum", "Redukce jen na záznam zájmů z posledního přístupu klienta", "Spuštění vyhodnocení průzkumu" ( neřešeno ). ROZHRANÍ Aplikace má pouze dvě rozhraní. Jedno pro klienta, které je tvořeno dotazníkem a druhé pro administrátora BD, které je umístěné na stránce řízení aplikace.
Rozhraní klienta – dotazník na stránce Pouziváte_vypocetni_techniku.asp je předané prohlížeči a má tvar:
- 35 -
STRUKTURA APLIKACE A JEJÍ WEBOVÉ SÍDLO Webové sídlo aplikace PRŮZKUM má následující složení : • Default. htm ........................................... Domovská stránka, která je rozdělena do tří rámců. V levém z nich bude řízení, které je dáno stránkou Řízení_aplikace. htm
• Pouzivate_vypocetni_techniku. htm ........... Stránka pro vlastní dotazník. • Vyhod_Zprac_Potvr. asp .......................... Stránka pro komplexní zpracování formuláře. • Řízení_aplikace. htm................................ Jednoduchá stránka pro řízení aplikace (možnost spouštění funkcionalit skupin A, B, C). Je zde tedy možné spustit rozhraní administrátora a přechod na rozhraní klienta ( dotazník ). • Statistika_průzkumu. asp.............................. Stránka pro vyhodnocení průzkumu a nakreslení dvou výsledných grafů (dotazovaní ? počítače, dotazovaní ? aplikace). Návrh dotazníku na stránce Pouzivate_vypocetni_techniku. htm ( sestrojeno pomocí FrontPage ):
- 36 -
tabulky formuláře pro data, nakreslené pomocí FrontPage
1
2
Aplikace PRŮZKUM má webové sídlo pro domovskou stránku s URL adresou http://K303-mis/DotaznikVT/ kde K303-mis je osobní server IIS.
Vše, co se s daty dotazníku děje, je ve skriptech stránek Vyhod_Zprac_Potvr.asp a Statistika_pruzkumu. asp . První z nich dává, spolu s náčrtem kódu dotazníku, ucelenou představu o vyhodnocení-prověření, převzetí-potvrzení a zpracování dat dotazníku. Domovskou stránku default.htm a stránku Řízení_aplikace.asp čtenář snadno navrhne sám.
Náčrt struktury a kódu pro stránku Pouzivate_vypocetni_techniku . htm
- 37 -
Náčrt struktury pro stránku Vyhod_Zprac_Potvr.asp
…… je to serverová stránka
<% Dim Jmeno1, Ulice1, Mesto1, PSC1,Telefon1,P Dim Stolni1, Notebook1, Kapesni Dim Office1, Hry1, Kresleni1, Programovani1, ErrPSC Dim ZAV_TEXT, FormularOK, Co_chybi FormularOK=true 'PŘEDPOKLAD.. DATA JSOU ÚPLNÁ A SPRÁVNÁ ErrPSC=" Žádné chyby v PSČ" Co_chybi="" 'NÁSLEDUJE PŘEVZETÍ ÚDAJŮ Jmeno1=Request.Form("Jmeno") Ulice1=Request.Form("Ulice") Mesto1=Request.Form("Mesto") PSC1=Request.Form("PSC") Telefon1=Request.Form("Telefon") Stolni1=Request.Form("Stolni") Notebook1=Request.Form("Notebook") Kapesni1=Request.Form("Kapesni") Office1=Request.Form("Office") Hry1=Request.Form("Hry") Kresleni1=Request.Form("Kresleni") Programovani1=Request.Form("Programovani") 'NÁSLEDUJE TESTOVÁNÍ ÚDAJŮ Test Jmeno1,"Jméno" Test Ulice1,"Ulice" Test Mesto1,"Město" Test PSC1,"PSČ" Test Telefon1,"Telefon" Test1 Stolni1 Test1 Notebook1 Test1 Kapesni1 Test1 Office1 Test1 Hry1 Test1 Kresleni1 Test1 Programovani1 'NÁSLEDUJE TESTOVÁNÍ PSČ If Not IsNumeric(PSC1) Then ErrPSC="PSČ není číslo" FormularOK=false Else If Len(Trim(PSC1))<>5 Then ErrPSC="Špatný počet cifer v PSČ" FormularOK=False End If End If
- 38 -
POZNÁMKY: Jsou nadeklarovány proměnné Jmeno1,….,Programovani1 pro převzetí dat dotazníku. ErrPSC zachycuje chybu, která se vyskytne v údaji PSČ dotazníku. Je-li cokoliv v datech špatného ( neúplnost dat nebo chxba v PSČ ), potom se proměnná FormularOK nastaví na False. Od hodnoty proměnné FormularOK záleží, jaké jsou výstupní texty v proměnné ZAV_TEXT a jestli bude zpracování dat dotazníku ( uložení do báze dat ). Převzetí dat z dotazníku je provedeno přes objekt Request technologie ASP. Technologii ASP jsme museli použít, když jsme chtěli převzít data z dotazníku. Ačkoliv zde v příkladě uvedeme její použití , bude to ale průzračné a pochopitelné. Základy samotné technologie uvedeme až v kapitole 7. Testování dat formuláře na absenci a evidence těch dat, která chybí.
Testování je-li PSČ číslo a má-li předepsaných 5 číslic
'NÁSLEDUJE PROCEDURA Test ( Q, S ) 'PRO TESTOVÁNÍ OSOBNÍCH ÚDAJŮ
Procedura Test dostává při vyvolání v
Sub Test(Q,S) parametru korespondujícím s Q hodnotu If Len(Q)=0 Then údaje a v druhém parametru S název údaje. Co_chybi=Co_chybi + S + "---" Jestli je údaj neuveden, potom se jeho jméno Q="neuvedeno" přidá do proměnné Co_chybi. FormularOK=False End If End Sub 'NÁSLEDUJE PROCEDURA Test1 ( Q ) ' PRO TESTOVÁNÍ odpovědí Procedura Test1 je jednoparametrová. Sub Test1(Q) Parametr Q předává ANO nebo NE podle toho, je-li údaj dotazníku If Len(Q)=0 Then zaškrtnut nebo ne. Q="NE" Else Q="ANO" End If End Sub 'ÚDAJŮ O TECHNICE A APLIKACÍCH ' POUŽITÍ celostránkové PROMĚNNÉ FormularOK If FormularOK=False Then Proměnná FormularOK rozhoduje o výpisu textů v proměnných ZAV_TEXT="DATA NEJSOU V POŘÁDKU, vyvolejte znovu formulář" ZAV_TEXT a Co_chybi. Else ZAV_TEXT="DATA JSOU V POŘÁDKU, děkujeme za jejich odeslání" Co_chybi="Všechny položky jsou uvedeny" End If %> …………………………. potvrzovací tabulka dat z formuláře …………………………… <% Dim Zaznam_je, ID, strDotaz, MaxID Dim objSpojeni, objPrikaz, RsZaznamy If FormularOK=True Then 'Když FormularOK=False nic nedělej
Deklarace proměnných, jejich názvy ukazují na jejich použití.
SET objSpojeni=Server.CreateObject("ADODB.Connection") objSpojeni.Open ("Dotaznik") Set objPrikaz = Server.CreateObject("ADODB.Command") objPrikaz.ActiveConnection = objSpojeni objPrikaz.CommandText= "Select * From Klient" Set RsZaznamy = objPrikaz.Execute
Tvorba objektu objSpojení a jeho otevření pro DSN Dotazník. Tvorba objektu objPrikaz a jeho svázání s objektem objSpojeni. Nastavení vlastnosti CommandText na SQL příkaz a jeho provedení. Tím se získává Recordset uložený v objektu RsZáznamy.
'Hledání klienta v tabulce Klient, podle Jmena a hledání max IDklienta Zaznam_je="ne" MaxID=0 Tato část vyšetřuje, zda se v Recordsetu nachází právě přihlášený klient s jménem v proměnné Jmeno1. Projdou se všechny záznamy a současně se najde i maximální hodnota pole Idklienta
Do While Not RsZaznamy.EOF If Trim(RsZaznamy("Jmeno"))= Trim(Jmeno1) Then Zaznam_je="ano" ID=RsZaznamy("IDklienta") End If If MaxID < RsZaznamy("IDklienta") Then MaxID = RsZaznamy("IDklienta") End If RsZaznamy.MoveNext Loop
Zde se reaguje na hodnotu proměnné Zaznam_je (ano, ne). Je-li hodnotou ano, tak se zapisuje vazební záznam jen do tabulky Zajem. Jinak se zapisují záznamy do obou tabulek.
MaxID=MaxID+1 Testovani1= Now() 'Zápis nového klienta a jeho zájmů nebo 'klient již je zapsán a proto zápis jen jeho zájmů If Zaznam_je = "ano" Then 'Klient je, zápis bude jen do tabulky Zajem strDotaz="INSERT INTO Zajem(Stolni_pocitac,Notebook,Kapesni_pocitac,Microsoft_Office," _ & "Hry,Kreslici_programy,Programovaci_systemy,IDklienta, Datum_testovani)" _ & " VALUES('" & Stolni1 & "', '" & Notebook1 & "', '" & Kapesni1 & "', '" & Office1 & "', '" & Hry1 & "', '" _ & Kresleni1 & "', '" & Programovani1 & "', " & ID & ", '" & Testovani1 & "')"
- 39 -
objPrikaz.CommandText = strDotaz Set RsZaznamy = objPrikaz.Execute Else 'Klient není a tedy zápis do obou tabulek Klient a Zajem strDotaz="INSERT INTO Klient(IDklienta,Jmeno,Ulice,Mesto," _ & "PSC,Telefon)" _ & " VALUES(" & MaxID & ", '" & Jmeno1 & "', '" & Ulice1 & "', '" & Mesto1 & "', '" & PSC1 & "', '" _ & Telefon1 & "')" objPrikaz.CommandText = strDotaz Set RsZaznamy = objPrikaz.Execute 'Response.write "
" strDotaz="INSERT INTO Zajem(Stolni_pocitac,Notebook,Kapesni_pocitac, Microsoft_Office," _ & "Hry,Kreslici_programy,Programovaci_systemy,IDklienta, Datum_testovani)" _ & " VALUES('" & Stolni1 & "', '" & Notebook1 & "', '" & Kapesni1 & "', '" & Office1 & "', '" & Hry1 & "', '" _ & Kresleni1 _ & "', '" & Programovani1 & "', " & MaxID & ", '" & Testovani1 & "')" objPrikaz.CommandText = strDotaz Set RsZaznamy = objPrikaz.Execute End If Set RsZaznamy = Nothing objSpojeni.Close Set objSpojeni = Nothing Set objPrikaz = Nothing End If %>
Toto je tvar potvrzovací tabulky pro převzatá data z dotazníku, sestrojené pomocí FrontPage. Do jednotlivých prázdných buněk se umístí skripty ( např. do prázdné buňky vedle buňky Jméno se vloží skript <% =Jmeno1 %> ) pro zveřejnění jednotlivých převzatých hodnot.
Báze dat má obě tabulky Klient a Zajem svázané vazbou 1 : N. To znamená, že jeden klient může mít více přístupů k dotazníku. Když se bude dotazník vyhodnocovat, tak za výsledné se vezme poslední vyplnění dotazníku. Redukce jen na poslední přístupy se může spustit administrátorskou funkcí již před zpracováním dotazníku.
Následující obrázek ukazuje možný obsah obou tabulek. Jedna z vazeb je podtržená. - 40 -
Poznámky : 1. Tučné příkazy v prvním skriptu způsobí převzetí dat z formuláře-dotazníku ( tedy ze stránky Pouzivate_vypocetni_techniku . htm ) do ASP stránky Vyhod_Zprac_Potvr.asp . Je to provedeno pomocí objektu Request, jednoho z pěti objektů technologie ASP. 2. Tučné příkazy se žlutým pozadím ve druhém skriptu umožnují využívat technologie ADO pro práci s bází dat. Jsou použity tři objekty z ADO, Connection, Command a Recordset. Objekt RecordSet je ale vytvořen implicitně a zásadní orientace byla na objekt Command a příkazy SQL Select a Insert Into. 3. Druhý skript zveřejníme ještě ve variantě s orientací na objekt RecordSet a metody AddNew a Update. <% Dim Zaznam_je,ID,strDotaz,sBasePath Dim objSpojeni,rsZaznamy,MaxID Sub PridatZajem rsZaznamy.AddNew rsZaznamy("Stolni_pocitac")=Stolni1 rsZaznamy("Notebook")=Notebook1 rsZaznamy("Kapesni_pocitac")=Kapesni1 rsZaznamy("Microsoft_Office")=Office1 rsZaznamy("Hry")=Hry1 rsZaznamy("Kreslici_programy")=Kresleni1 rsZaznamy("Programovaci_systemy")=Programovani1 rsZaznamy("IDklienta")=ID rsZaznamy("Datum_testovani")= Now() rsZaznamy.Update End Sub Sub PridatKlienta rsZaznamy.AddNew rsZaznamy("IDklienta")=MaxID rsZaznamy("Jmeno")=Jmeno1 rsZaznamy("Ulice")=Ulice1 rsZaznamy("Mesto")=Mesto1 rsZaznamy("PSC")=PSC1 rsZaznamy("Telefon")=Telefon1 rsZaznamy.Update End Sub 'Když FormularOK=False If FormularOK = True Then
nic nedělej
- 41 -
SET objSpojeni=Server.CreateObject("ADODB.Connection") objSpojeni.Open "Dotaznik" strDotaz="Select * From Klient" Set rsZaznamy = objSpojeni.Execute(strDotaz) 'Hledání klienta v tabulce Klient, podle Jmena Zaznam_je = "ne" MaxID=0 Do While Not RsZaznamy.EOF If Trim(RsZaznamy("Jmeno"))= Trim(Jmeno1) Then Zaznam_je="ano" ID=RsZaznamy("IDklienta") End If If MaxID < RsZaznamy("IDklienta") Then MaxID = RsZaznamy("IDklienta") End If RsZaznamy.MoveNext Loop MaxID=MaxID+1 objSpojeni.Close 'Zápis nového klienta a záznamu do Zajem NEBO 'klient již je a proto zápis jen do Zajem sBasePath="C:/inetpub/wwwroot/Dotaznik/fpdb/zájmy.mdb" If Zaznam_je = "ano" Then 'Klient je, zápis bude jen do tabulky Zajem strDotaz="Select * From Zajem" Set objSpojeni=Server.CreateObject ("ADODB.Connection") Set rsZaznamy = Server.CreateObject("ADODB.Recordset") ' "PROVIDER=Microsoft.Jet.OLEDB.4.0; Data Source=" & sBasePath objSpojeni.Open "PROVIDER=Microsoft.Jet.OLEDB.4.0;Data" _ & "Source=C:/Inetpub/wwwroot/DotaznikVT/fpdb/zájmy.mdb" rsZaznamy.Open strDotaz, objSpojeni, ,2 PridatZajem Else 'Klient není, tedy zápis do obou tabulek Klient a Zajem strDotaz="Select * From Klient" Set objSpojeni=Server.CreateObject ("ADODB.Connection") Set rsZaznamy = Server.CreateObject("ADODB.Recordset") objSpojeni.Open "PROVIDER=Microsoft.Jet.OLEDB.4.0; Data Source=" & sBasePath rsZaznamy.Open strDotaz, objSpojeni, ,2 PridatKlienta rsZaznamy.Close strDotaz="Select * From Zajem" rsZaznamy.Open strDotaz, objSpojeni, ,2 PridatZajem End If Set rsZaznamy=Nothing Set objSpojeni=Nothing End If %>
- 42 -
3.8 Abstraktní datové typy Datové struktury se staly nedílnou součástí každého programu. Jejich zápis v programovacích jazycích bude velmi blízký zápisu, který se používá v disciplině z níž datová struktura pochází. Vidíme to nejen na číslech ale i na proměnných, maticích, tabulkách a dalších datových strukturách. Programovací jazyk dokáže některé datové struktury zpracovávat přirozeně ( je s nimi v programovacím jazyku počítáno ), jiné musí zpracovávat prostřednictvím některých jednodušších. Např. nedovedeme si představit programovací jazyk, který by přirozeně nezpracovával konstanty různých datových typů ( čísla, texty, logické hodnoty, datumy, čas, … ), proměnné, vektory, matice, záznamy a soubory. Často právě šíře přirozeně zpracovávaných datových struktur bývá jedním z kritérií kvality programovacího jazyka. Zpracování datové struktury S v algoritmu A je vlastně posloupností operací, provedených nad touto datovou strukturou. Každá taková operace bere v úvahu vztahy mezi jednotlivými položkami datové struktury. Porušení těchto vztahů ( budou přeorganizovány ) provádí jen některé algoritmy. Často se stává, že porušení relací mezi položkami p1, p2, …, pn-1, pn datové struktury S, může vést ke zcela nové struktuře S'. Abychom mohli popsat vnitřní řád datové struktury a operace nad ní, které vedou k zásadním změnám relací γ1, γ2, γ3… mezi položkami, zavedeme formální definici datové struktury (není pro BD). Na jejím základě vyšetříme vlastnost obecné datové struktury. Definice Formální datová struktura S je uspořádaná trojice S = [ P, Ω, σ0 ] , kde P.................je konečná množina položek p1, p2, …, pn-1, pn Ω ................je konečná množina operací ω1, ω2, …, ωm-1, ωm nad datovou strukturou a σ0................je počáteční stav, v němž se datová struktura nachází hned po svém zřízení.
Provedeme-li nad datovou strukturou námi navržené operace, dojde k tomu, že se velmi často mění právě hodnoty položek datové struktury. Datová struktura se poté nachází v nové situaci - tedy stavu. Novou situaci může ale vyvolat i změna relací mezi položkami datové struktury. Vlivem mnoha operací tak přechází datová struktura ze stavu do stavu. Stav datové struktury bude tedy reprezentován : • •
hodnotami položek, relacemi mezi položkami.
Množina relací mezi položkami je konečná množina. Na druhé straně, hodnoty položek datové struktury mohou být z nekonečných množin. Může tedy datová struktura nabýt teoreticky nekonečného množství stavů označovaných symbolem σ. To je velmi nepříjemné a proto se zavádí pojem relevantní stav. Relevantní stav Σ je množina vybraných stavů a takových množin je konečný počet. Existuje tedy definované zobrazení Z ( σ ) → { Σ1, Σ2, …, Σk }, kde Σi je relevantní stav které každý běžný stav datové struktury dokáže reprezentovat stavem relevantním. Uveďme jednoduchý příklad. Příklad 5 Uvažujme jako datovou strukturu celočíselnou matici A3,3 = ( ai,j ). Položkami této struktury jsou prvky ai,j , proto P = { ai,j }. Datová struktura má jedinou polohovou relaci Pos( i,j ) mezi svými položkami. Stavů struktury je nekonečně mnoho. Za relevantní stavy ale můžeme např. navrhnout :
- 43 -
• • • •
stav, kdy jsou všechny prvky matice nulové, tzv. nulová matice, stav, kdy jsou prvky po hlavní diagonále jedničkové a ostatní nulové, tzv. jednotková matice, stav, kdy ∀i,j platí, že ai,j = aj,i , tzv. symetrická matice, ostatní stavy matice reprezentované tzv. běžným stavem.
Může tedy existovat mnoho matic, které jsou symetrické. Definice Stavem datové struktury S nazveme uspořádanou trojici [ Q, Γ, h ], kde Q .............. je množina hodnotově obsazených položek, Q ⊆ P, Γ.............. je množina { γi } relací mezi položkami a h .............. je zobrazení, které každé položce pi ∈ Q přiřazuje jedinou hodnotu z definiční domény hodnot. Každá datová struktura musí být před provedením první operace v počátečním stavu. Jestliže to není respektováno, může dojít k různým anomáliím při jejím zpracovaní. Jako příklad anomálie můžeme uvést případ prvního referenčního použití proměnné x, aniž by tomu předcházelo zadání inicializační hodnoty. Takové situace jsou pochopitelně při provádění programu obvykle zachyceny a programátorovi je zveřejněno patřičné upozornění. Mnoho programovacích jazyků se řídí strategií "Maximálně zabezpeč provedení programu" a proto s ohledem na datový typ nastavují každé proměnné inicializační hodnotou. Pro číselné proměnné je to 0, pro textové proměnné je to prázdný řetězec. Obecně můžeme mezi operacemi nad datovou strukturou rozeznávat ty, které vedou na změnu stavu a ty které změnu nezpůsobí. Pochopitelně, v relevantním stavu může datová struktura setrvávat poměrně dlouho. Operace z množiny Ω můžeme podle toho, jestli mění nebo nemění stav datové struktury, rozdělit do tří podmnožin : • • •
konstruktory, selektory a predikáty.
Konstruktory, na základě parametrů Xi,k , mění stav datové struktury tím, že mění obsah jedné z jeho tří komponent. Nejčastějším případem konstruktorů je změna hodnot všech nebo jen vybraných položek datové struktury. Případy změny relací mezi položkami nejsou tak časté. Posloupnosti změn stavů datové struktury náleží i posloupnost provedených konstruktorů. Na rozdíl od konstruktorů, selektory na základě parametrů Xi,s nemění stav datové struktury, ale poskytují přístup k hodnotě jedné nebo hodnotám více položek. Rozdíl predikátů od dvou předchozích typů operací je značný. Predikáty nastavují na pravdu nebo lež výsledek výroku o datové struktuře. Jde o výroky týkající se hodnot nebo relací mezi položkami. Podejme teď formální definice jednotlivých typů operací. konstruktor….ω ωk ∈ Ω k je definován vztahem ωk : Σ x Xi,k → Σ , kde Xi,k je množina parametrů konstruktoru , selektor……….ω ωs ∈ Ω s
je definován vztahem ωs : Σ x Xi,s → Q , kde Xi,s je množina parametrů selektoru,
predikát……..ω ωp ∈ Ω p
je definován zobrazením ωp : Σ x Xip → { True, False } , kde Xip je množina parametrů predikátu.
- 44 -
Život datové struktury obvykle začíná počátečním stavem a končí koncovým stavem. Za počáteční můžeme považovat stav, který vznikne po operaci zřízení datové struktury. Koncový stav je obvykle stav, kdy datová struktura již ukončila svůj život. To bývá např. s ukončením programu. Jaká je realizace některých operací nad datovou strukturou ? Stačí uvést jednoduchý příklad pro matice. Příklad 6 Před zřízením matice A5,5 = ( ai,j ) celočíselného datového typu s indexy 1…5, 1…5, musí být ve VB nastavena báze počáteční hodnoty deklaračním příkazem Option Base 1 Příkaz Dim A(5,5) As Integer v jazyku Visual Basic potom zmíněnou čtvercovou celočíselnou matici A5,5 zřizuje. Matice je ve stavu, kdy nejsou definovány počáteční hodnoty, ale je zřízena fyzická struktura uložení. Příkazy
For i = 1 To 5 Step 1 For j = 1 To 5 Step 1 A( i, j ) = 0 Next j Next i
používají konstruktor A( i, j ) = 0 Tento konstruktor mění hodnoty vybraných položek a tedy mění stav matice. Samotný zápis A( i, j ) je ale selektor, který zpřístupňuje prvek ai,j . Napíšeme-li příkaz If A( 5,5 ) = 0 Then y=1 End If
potom jde o predikát zjišťující, je-li prvek a5,5 = 0. Uvedený aparát formální prezentace datových struktur není dostatečný pro nejvyšší typ datové struktury – báze dat ( BD ). Rozšíření provedl americký informatik E. F. Codd. Softwarové inženýrství používá pro směr "Datové struktury" více teoretických aparátů. Často mezi ně patří relace, formální algebry ( jako algebry čísel, množinové algebry, … ) a grafy. Obvykle se základ těchto aparátů podává v běžném kurzu matematiky. Použití algebry ukážeme na příkladu algebry řetězců a použití relací na podání základů současně nejvyšší datové struktury nazývané "báze dat".
- 45 -
4 Literatura Richta, Sochor: Softwarové inženýrství I., skripta ČVUT-FEL, Praha 1996, dotisk 1998. (Toto je zcela základní skriptum pro tento předmět !!! Každý student by ho měl mít. Dává docela dobrý a relativní široký přehled celé problematiky. POZOR: neobsahuje UML a formální specifikace. Richta, Sochor: Projektování programových systémů., skripta ČVUT-FEL, Praha 1994. (Toto je starší varianta výše uvedeného skripta. POZOR: na rozdíl od něho neobsahuje objektově orientované metodiky! Ale pro studium klasických neobjektových metodologií lze bez problému použít.)
- 46 -
