Trocha historie - 3. Ÿ st
V posledn¡m d¡lu pov¡d n¡ o programov n¡ a o vØcech, kter‚ s n¡m souvis¡, se zamØý¡me na Ÿ¡m d l t¡m vìznamnØjç¡ £lohu vìvojov‚ho prostýed¡.

Týet¡ vrstva abstrakce

V souŸasn‚ dobØ se zd , §e samotn‚ programovac¡ jazyky nebo nov‚ metodiky n vrhu u§ nemohou d le zjednoduçit a zrychlit vìvoj aplikac¡. Tuto roli nyn¡ pýeb¡raj¡ podp…rn‚ n stroje, kter‚ umo§åuj¡ automatick‚ generov n¡ k¢du, a vìvojov  prostýed¡ (IDE), v nich§ jsou tyto n stroje Ÿasto integrov ny.

Basic
Program toýi se mohli s vìvojovìm prostýed¡m poprv‚ setkat u§ pýed v¡ce ne§ 30 lety, neboœ prvn¡ takov‚ prostýed¡ s sebou vlastnØ pýinesl Basic. Tento jazyk byl toti§ navr§en jako interpreter, kterì umo§åoval spouçtØt Ÿ sti programu a hned vidØt jejich vìsledky. D¡ky tomu mohli program toýi pracovat interaktivnØ, a tedy daleko efektivnØji, ne§ bylo obvykl‚.
Pýipomeåme si, §e v t‚ dobØ bylo pravidlem d vkov‚ zpracov n¡ program…: program tor dodal oper tor…m zdrojovì text programu na dØrnìch çt¡tc¡ch (nebo týeba na magnetick‚ p sce), vypsal pr…vodku a po nØjak‚m Ÿase si pýiçel pro vytiçtØn‚ vìsledky. Interaktivn¡ Basic tedy pýedstavoval z sadn¡ pr…lom, ovçem k tomu vy§adoval technick‚ z zem¡ - termin l, kterì by interaktivn¡ pr ci umo§åoval. Vìhody Basicu tedy zaŸaly bìt zýejm‚ a§ ve chv¡li, kdy se interaktivn¡ termin ly staly bاnou souŸ st¡ vìpoŸetn¡ch stýedisek, a pozdØji, kdy se implementace Basicu staly standardn¡ souŸ st¡ vybaven¡ mikropoŸ¡taŸ…. (Nen¡ bez zaj¡mavosti, §e na mnohìch poŸ¡taŸ¡ch Basic dokonce nahrazoval operaŸn¡ syst‚m.)
Je ovçem tak‚ pravda, §e Basic byl jazyk, kterì se ke skuteŸnìm vìpoŸt…m pý¡liç nehodil. (S dneçn¡m Visual Basicem nem  kromØ n zvu a nØkolika kl¡Ÿovìch slov mnoho spoleŸn‚ho.)

Smalltalk
Vìvojov‚ prostýed¡ bylo rovnا ned¡lnou souŸ st¡ jazyka Smalltalk. Obsahovalo nejen n stroje pro vytvoýen¡ programu, ale i n stroje pro jeho ladØn¡; vìvojov‚ prostýed¡ bylo dokonale integrov no s jazykem, tj. skl dalo se z objekt…, kter‚ mohl program tor pou§¡t i v programu. Podobnìm zp…sobem byla vytvoýena integrovan  prostýed¡ i nØkterìch jinìch ŸistØ objektovìch jazyk….

Vìvojov  prostýed¡ na PC
V naçem pov¡d n¡ nelze opominout vìvojov  prostýed¡ nejbاnØjç¡ch pýekladaŸ… na PC - u§ vzhledem k jejich masov‚mu rozç¡ýen¡. M m t¡m na mysli napý. prostýed¡ Turbo Pascal, Microsoft C a dalç¡ n stroje.
Ve srovn n¡ s prostýed¡m Smalltalku (nebo i s dneçn¡mi podobami çpiŸkovìch vìvoj ýskìch n stroj…) byla prvn¡ integrovan  vìvojov  prostýed¡ (IDE) znaŸnØ jednoduch  a nevìkonn , ale i pýesto nab¡zela mnohem v¡ce ne§ tradiŸn¡ pý¡kazov  ý dka. ZpoŸ tku tato IDE obsahovala vlastnØ jen textovì editor, pýekladaŸ, n stroje pro nastavov n¡ voleb a n stroje pro pr ci s projekty a se soubory. K nim pozdØji pýibyly prostýedky pro symbolick‚ ladØn¡, pro vytv ýen¡ pomocnìch datovìch soubor… (prostýedky - resources - ve Windows) aj.

æamani
Pýi programov n¡ aplikac¡ pro Windows (ale i jinìch) se uk zalo, §e velk  vØtçina program… dodr§uje jedno z kladn¡ sch‚ma. V "oknech" je to napý. funkce WinMain, obsahuj¡c¡ popis a registraci tý¡dy okna, vytvoýen¡, zobrazen¡ a pýekreslen¡ okna a cyklus vìbØru zpr v z fronty. Tak‚ "okenn¡" procedura je vlastnØ povinnou souŸ st¡ programu a m  sv‚ ust len‚ sch‚ma - jeden pý¡kaz, kterì podle druhu doçl‚ zpr vy urŸuje, co se m  st t. PodobnØ existuj¡ ust len  sch‚mata i pýi vytv ýen¡ distribuovanìch aplikac¡.
Velice brzy proto zaŸala IDE nab¡zet slu§by r…znìch n stroj…, kter‚ se podle okolnost¡ nazìvaj¡ Wizard, Expert, SmartGuide atd. Dovol¡m si o nich nad le hovoýit jako o "çamanech". Po vyvol n¡ çamana se vØtçinou objev¡ dotazn¡k v podobØ nØkolika dialogovìch oken, kter  zjist¡, co si vlastnØ pýejeme. Podle toho pak IDE vytvoý¡ kostru aplikace, v n¡§ koment ýem oznaŸ¡ m¡sta, na kter  m  u§ivatel doplnit sv…j zdrojovì k¢d.
æamani mohou podstatnìm zp…sobem zrychlit programov n¡. Nejen proto, §e za n s nap¡ç¡ týeba i stovky ý dk… zdrojov‚ho textu, ale hlavnØ proto, §e je nap¡ç¡ syntakticky i s‚manticky spr vnØ (samozýejmØ pokud zad me spr vn‚ £daje). Na druh‚ stranØ ovçem mohou bìt ponØkud svazuj¡c¡ - napý. u§ivatel‚ MS Visual C++ 5.0 si jistØ vzpomenou, §e aplikace vytvoýen  AppWizardem vyu§¡vaj¡c¡m knihovnu MFC musela vych zet z architektury dokument/pohled, a pokud jsme chtØli nØco jin‚ho, museli jsme "ruŸnØ" Ÿ st vytvoýen‚ho k¢du zmØnit.
VØtçina çaman… vyu§¡v  speci ln¡ (nestandardn¡) knihovny dod van‚ s pýekladaŸem - IOC (IBM), MFC (Microsoft a dnes i jin‚ pýekladaŸe), OWL (Borland), VCL (Borland) atd. To ale znamen , §e u§ivatel mus¡ vedle standardu pou§it‚ho programovac¡ho jazyka zn t nejen danou knihovnu, ale i strukturu aplikace, kterou danì n stroj vytvoý¡.

Vizu ln¡ programov n¡
V devades tìch letech se zaŸal pýi programov n¡ uplatåovat novì postup - vizu ln¡ programov n¡. Za prvn¡ n znak bychom mohli pova§ovat n stroje na vytv ýen¡ prostýedk… (resources) urŸenìch pro programy pro Windows, jako byl napý. Resource Workshop, kter‚ umo§åovaly vytvoýit nØkter‚ souŸ sti programu vizu lnØ pomoc¡ myçi na z kladØ pýeddefinovanìch souŸ st¡.
Poprv‚ jsme se s vizu ln¡m programov n¡m mohli ve vìznamn‚ m¡ýe setkat v prvn¡ch verz¡ch Visual Basicu a pozdØji ve vylepçen‚ podobØ v n stroj¡ch, jako je Delphi, C++ Builder, JBuilder, Power++, PowerJ, VisualAge apod. Princip je dnes u§ dobýe zn mì: nejŸastØji pou§¡van‚ slo§ky aplikac¡ jsou zapouzdýeny do komponent, obvykle implementovanìch jako objektov‚ typy. IDE je zpravidla nab¡z¡ na "palet ch", kde je reprezentuj¡ ikony. 
Z kladn¡ postup pýi vizu ln¡m programov n¡ lze shrnout asi takto: Po vytvoýen¡ nov‚ho projektu (nebo na naçi § dost) otevýe IDE pr zdn‚ okno aplikace a vytvoý¡ k nØmu odpov¡daj¡c¡ zdrojovì k¢d. Do nab¡dnut‚ho okna m…§eme pomoc¡ myçi vkl dat komponenty, kter‚ si vybereme z palet. Pýitom prostýed¡ generuje odpov¡daj¡c¡ zdrojovì k¢d.
VØtçinu vlastnost¡ komponent m…§eme nastavit ve speci ln¡m oknØ ji§ v dobØ n vrhu. IDE pýitom obvykle ihned zmØn¡ odpov¡daj¡c¡m zp…sobem zdrojovì k¢d programu a vizu ln¡ n vrh programu. U§ivatel pak mus¡ definovat odezvy programu na ud losti, kter‚ mohou nastat - nejŸastØjç¡ ud lost¡ je "stisknut¡ tlaŸ¡tka" v u§ivatelsk‚m rozhran¡. I tady n m m…§e IDE vìraznØ pomoci; m…§e napý. nab¡zet ýadu pýeddefinovanìch procedur typickìch pro urŸit‚ komponenty nebo pro vztahy mezi nimi (uzavý¡t okno po stisknut¡ tlaŸ¡tka apod.).
Tak‚ zde jsou vìhody zýejm‚ - Ÿ¡m v¡ce k¢du generuje IDE automaticky, t¡m rychleji program tor vytvoý¡ aplikaci a t¡m m‚nØ m  pý¡le§itost¡ k chyb m. Pýitom m…§e ve skuteŸnosti umØt m‚nØ, ne§ kdyby programoval "klasicky"; napý. v Delphi m…§ete napsat jednoduch‚ datab zov‚ aplikace a zn t pýitom jen z kladn¡ vlastnosti nØjakìch tý¡ datab zovìch komponent.
Zd  se tedy, §e programov n¡ zalo§en‚ na komponent ch nab¡z¡ ýeçen¡ softwarov‚ krize. Ovçem, jako obvykle, nen¡ to zadarmo. Programov n¡ zalo§en‚ na komponent ch lze velice dobýe pýirovnat ke stavbØ z panel…. Je rychl‚ a snadno zvl dnuteln‚, ale drah‚ - vy§aduje speci ln¡ n stroje a vìkonnì poŸ¡taŸ. Vytvoýen‚ programy jsou toti§ zpravidla podstatnØ rozs hlejç¡ ne§ podobn‚ programy zalo§en‚ na "obyŸejn‚m" pýekladaŸi a aplikaŸn¡m rozhran¡ operaŸn¡ho syst‚mu. Dosa§en  ýeçen¡ tak‚ nemus¡ bìt v§dy tak kvalitn¡, jak bychom si pý li, neboœ obŸas je týeba pýizp…sobit se mo§nostem prefabrikovanìch d¡l… (komponent).

CASE
Zejm‚na pýi programov n¡ datab zovìch aplikac¡ zalo§enìch na relaŸn¡ch datab z¡ch se setk me s dalç¡ variantou vìvojovìch prostýed¡. Zde u§ je postup vìvoje v¡cem‚nØ standardizov n: Prvn¡m krokem je vytvoýen¡ konceptu ln¡ho datov‚ho modelu, ve kter‚m se pop¡ç¡ jednotliv‚ entity, relace mezi nimi atd. Druhìm krokem je vytvoýen¡ fyzick‚ho datov‚ho modelu, v nØm§ ji§ vezmeme v £vahu vlastnosti pou§it‚ho datab zov‚ho serveru. Zde na z kladØ konceptu ln¡ho modelu pop¡çeme jednotliv‚ datab zov‚ tabulky, indexy, dotazy atd., kter‚ chceme ve sv‚ aplikaci pou§¡t. Ve týet¡m kroku se pak pomoc¡ fyzick‚ho datov‚ho modelu vytvoý¡ datab zov‚ skripty pro vytvoýen¡ datab z¡, tabulek a index…, d le dotazy v jazyce SQL atd.
Konceptu ln¡ datovì model se obvykle popisuje graficky pomoc¡ tzv. entitnØ-relaŸn¡ch diagram…; potýebn‚ n stroje jsou dnes obvyklou souŸ st¡ prostýed¡ pro vìvoj datab zovìch aplikac¡. Na nØ pak obvykle navazuj¡ n stroje pro pýevod konceptu ln¡ho datov‚ho modelu na datovì model fyzickì. Vytvoýenì fyzickì datovì model lze samozýejmØ jeçtØ upravit a na jeho z kladØ pak automaticky generovat program. (Takovì n stroj nab¡z¡ napý. Oracle Developer 2000.) Podobnìm zp…sobem lze dnes navrhovat i v¡cevrstv‚ aplikace - zn mì je napý. produkt Rational Rose.
JeçtØ v ned vn‚ dobØ byly n stroje tohoto druhu nesm¡rnØ drah‚, tak§e si je mohly dovolit pouze velk‚ firmy. Dnes se zvolna zaŸ¡naj¡ st vat souŸ st¡ bاnìch vìvojovìch prostýed¡, i kdy§ zpravidla ve znaŸnØ omezen‚ podobØ. Napý. souŸ st¡ Visual C++ 6.0 Enterprise je Visual Modeller, kterì pýedstavuje omezenou verzi Rational Rose.

LadØn¡
Ruku v ruce s programov n¡m jde v§dy nezbytn‚ ladØn¡. Hled n¡ logickìch chyb v programech bylo a je jednou z nejobt¡§nØjç¡ch, nejprotivnØjç¡ch a nejzdlouhavØjç¡ch f z¡ vìvoje programu.
V prvn¡ch dob ch byly z kladn¡m n strojem ladic¡ tisky a analìza zdrojov‚ho textu. NØkter‚ pýekladaŸe k tomu nab¡zely mo§nost vìpisu ký¡§ovìch referenc¡, tj. vìpisu identifik tor… a m¡st jejich pou§it¡. OperaŸn¡ syst‚my tak‚ zpravidla poskytovaly v pý¡padØ chyby vìpis operaŸn¡ pamØti v osmiŸkov‚ nebo v çestn ctkov‚ soustavØ.
Mo§nosti, kter‚ z hlediska ladØn¡ pýedstavuj¡ vìvojov  prostýed¡, naznaŸil v polovinØ 60. let Basic. Vedle samostatn‚ho spouçtØn¡ a testov n¡ jednotlivìch Ÿ st¡ programu nab¡zely nØkter‚ implementace i mo§nost "animace", tedy bØhu programu s pýest vkou po jednotlivìch pý¡kazech.
SkuteŸnì rozvoj ladic¡ch n stroj… pýinesly ale a§ osobn¡ poŸ¡taŸe, neboœ vzhledem k velikosti trhu mohly bìt podp…rn‚ programy snadno dostupn‚. Prvn¡ ladic¡ programy byly samostatn‚, nebyly integrov ny do vìvojov‚ho prostýed¡ a umo§åovaly krokovat program (prov dØt oddØlenØ jednotliv‚ pý¡kazy), vkl dat do nØj zar §ky a sledovat pýitom hodnoty vybranìch promØnnìch, pý¡padnØ vìraz…. Princip ladic¡ho programu je ve skuteŸnosti jednoduchì: Ladic¡ program nahrad¡ instrukci ladØn‚ho programu, pýed kterou se m  program zastavit, instrukc¡, kter  vyvol  pýeruçen¡, a p…vodn¡ instrukci si uschov . Jakmile ladØnì program na toto m¡sto dobØhne, dojde k pýeruçen¡ a ladic¡ program pýevezme ý¡zen¡. Nahrad¡ instrukci pýeruçen¡ p…vodn¡ instrukc¡ a Ÿek  na pokyny u§ivatele.
S rostouc¡mi n roky na programy rostly ovçem tak‚ n roky na ladic¡ n stroje. Ke standardn¡mu (dnes vlastnØ u§ asi minim ln¡mu) vybaven¡ ladic¡ch program… patý¡ mj. n sleduj¡c¡ mo§nosti:
 Krokov n¡ program… se vstupem do podprogram… nebo bez nØj, a to na £rovni zdrojov‚ho textu nebo disasemblovan‚ho pýelo§en‚ho programu.
 Pou§¡v n¡ zar §ek v zanìch na m¡sto, na poŸet pr…chod…, na splnØn¡ dan‚ podm¡nky, na zmØnu hodnoty jist‚ promØnn‚ atd.
 Pr…bاn‚ sledov n¡ hodnot vìraz…, lok ln¡ch promØnnìch, vìsledk… funkc¡ apod.
 Prohl¡dka operaŸn¡ pamØti, stavu registr…, z sobn¡ku, posloupnosti vol n¡ podprogram… apod. za bØhu programu.
 Mo§nost mØnit obsah promØnnìch za bØhu programu.
 LadØn¡ procesu bا¡c¡ho na jin‚m poŸ¡taŸi, schopnost ladic¡ho programu pýipojit se k bا¡c¡mu procesu.
 Poskytov n¡ informac¡ o jednotlivìch vl knech (threadech) bا¡c¡ aplikace.
Vedle toho se dnes zvolna st v  samozýejmost¡ mo§nost editovat zdrojovì text v pr…bØhu ladØn¡ s t¡m, §e se zmØny ihned prom¡tnou do chov n¡ programu (alespoå v omezen‚ m¡ýe). LadØn¡ distribuovanìch aplikac¡ vy§aduje tak‚ mo§nost pýech zet pr…bاnØ mezi jednotlivìmi bا¡c¡mi programy (i na r…znìch poŸ¡taŸ¡ch), popý¡padØ i mezi r…znìmi programovac¡mi jazyky.

Týet¡ vrstva
Dnes je ji§ zýejm‚, §e integrovan  vìvojov  prostýed¡ zaŸ¡naj¡ hr t roli týet¡ vrstvy abstrakce mezi program torem a hardwarem poŸ¡taŸe. Jak v¡me, prvn¡ vrstvou byl asembler, kterì zbavil program tora nutnosti starat se o konkr‚tn¡ adresy v programu. Druhou vrstvu pak pýedstavuj¡ vyçç¡ programovac¡ jazyky, kter‚ nab¡dly vyjadýov n¡ v jazyce podstatnØ bli§ç¡m ŸlovØku - nebo sp¡çe ýeçen‚mu probl‚mu - ne§ stroji. Program zpravidla alespoå vzd lenØ pýipom¡n  anglick‚ vØty, matematick‚ z pisy apod.
Týet¡ vrstva pak zbavuje program tora z vislosti na programovac¡m jazyku alespoå v prvn¡ch f z¡ch vìvoje programu. Umo§åuje mu vyjadýovat sv‚ pýedstavy o funkci programu pomoc¡ sch‚mat a diagram…, sestavovat u§ivatelsk‚ rozhran¡ i nØkter‚ funkŸn¡ bloky aplikace z prefabrikovanìch celk… nebo specifikovat sv‚ pýedstavy o funkci budouc¡ho programu vyplnØn¡m dotazn¡ku apod.
V souŸasn‚ dobØ vçak nem…§eme hovoýit o skuteŸn‚ nez vislosti program tora na programovac¡m jazyku. I kdy§ ve vØtçinØ prostýed¡ m…§eme dnes nejjednoduçç¡ aplikace vytvoýit, ani§ bychom napsali jedinou ý dku k¢du, pro naprogramov n¡ Ÿehokoli pou§iteln‚ho mus¡ program tor umØt jazyk, kterì stoj¡ v pozad¡, a v nØm napsat tØla ýady procedur. IDE za nØj ovçem nap¡çe znaŸnou Ÿ st k¢du a v mnoha pý¡padech ho zbav¡ potýeby detailnØ rozumØt struktuýe aplikace v dan‚m prostýed¡ (napý¡klad v Delphi lze napsat plnohodnotnou aplikaci, ani§ bychom nØco vØdØli o fungov n¡ cyklu zpr v ve Windows, o zp…sobu pýekreslov n¡ oken, apod.). Nav¡c polotovary vytvoýen‚ v prvn¡ f zi n vrhu (u§ivatelsk‚ rozhran¡ programu, konceptu ln¡ datovì model apod.) mohou bìt pýenositeln‚ mezi r…znìmi vìvojovìmi n stroji, v souŸasn‚ dobØ alespoå v r mci produkt… jedn‚ firmy.
Týet¡ vrstva tedy jeçtØ nen¡ £pln , druhou vrstvu - programovac¡ jazyk - je pod n¡ st le jeçtØ velmi silnØ zn t, ale pýesto se dalç¡ stupeå abstrakce zaŸ¡n  vìraznØ uplatåovat.
Na druh‚ stranØ ovçem vstupuj¡ do hry i dalç¡ vrstvy, a to na £rovni procesoru. Z kdysi pomØrnØ jednoduch‚ho zaý¡zen¡ se st v  n stroj, kterì se star  o ochranu pamØti, o pr ci s virtu ln¡ pamØt¡, o vìbØr a pýeuspoý d v n¡ instrukc¡ tak, aby se daly prov dØt paralelnØ, a pýitom z…stal p…vodn¡ vìznam programu zachov n. A objevuj¡ se u§ dokonce i £vahy o hardwarov‚ implementaci garbage collectoru.

Co dodat
Naçe tý¡d¡ln‚ pov¡d n¡ o programov n¡ se toŸilo kolem programovac¡ch jazyk…, styl… programov n¡ a vìvojovìch prostýed¡. To samozýejmØ nejsou vçechny faktory, kter‚ zp…sob pr ce program tora ovlivåuj¡. Nav¡c jsme se mnoha d…le§itìch vØc¡ jen dotkli, dalç¡ podstatn‚ jsme vynechali. M…j dojem je, §e v souŸasn‚ dobØ ustupuje vìznam programovac¡ch jazyk… do pozad¡ a vl dy se uj¡maj¡ n stroje pro vizu ln¡ programov n¡.
Mo§n  z toho bude m¡t ýada lid¡ dojem, §e program toýi - ta znaŸnØ nepohodln  sorta lid¡, kterìm je týeba dobýe platit, a kteý¡ se pýitom jen zý¡dka chovaj¡ tak, jak by si jejich ç‚fov‚ pý li - u§ koneŸnØ zmiz¡ v propadliçti dØjin. Jen§e programov n¡ nen¡ vlastnØ z le§itost programovac¡ho jazyka nebo ER diagram…; programov n¡ vy§aduje porozumØn¡ probl‚mu na jedn‚ stranØ a mo§nostem poŸ¡taŸ… na stranØ druh‚, a pýitom nen¡ pý¡liç podstatn‚, ve kter‚m jazyce se vyjadýujeme; zda p¡çeme pý¡kazy ve Fortranu, nebo zda kresl¡me nØjak‚ diagramy. Mo§n  za nØkolik let postaŸ¡, kdy§ si s poŸ¡taŸem prostØ popov¡d me - ale bude z le§et na tom, co a jak mu to ýekneme. Probl‚m je v tom, §e s rostouc¡m vìkonem a klesaj¡c¡ cenou poŸ¡taŸ… sice na jedn‚ stranØ z vratnØ rostou mo§nosti, kter‚ vìvojov‚ n stroje poskytuj¡, ale na druh‚ stranØ jeçtØ rychleji rostou po§adavky na software.

Je tاk‚ bìt prorokem
PoŸ¡taŸe a vçe, co s nimi souvis¡, proçly vìvojem, pro jeho§ rychlost snad neexistuje v dØjin ch techniky analogie. Proto je tاk‚ cokoli pýedv¡dat. Velice pØknØ to ukazuje vìrok, kterì otiskl Ÿasopis Popular Mechanics v r. 1949, tedy v dobØ, kterou mnoz¡ jeçtØ pamatuj¡: "V budoucnosti mo§n  nebudou poŸ¡taŸe tØ§ç¡ ne§ p…ldruh‚ tuny..."
Miroslav Virius