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