2 SWI JAKO DISCIPLINA TVORBY PROGRAMŮ

Transkript

1 2 SWI JAKO DISCIPLINA TVORBY PROGRAMŮ Na základě analýzy softwarové krize, byly nalezeny její příčiny a důsledky a proto bylo SWI postupně obohacováno vším co krizi vylučuje. Obecným závěrem analýzy bylo i heslo pro další vývoj software: Co nejrychleji (agilní vývoj), pod striktním řízením na základě reálných plánů, uplatněním metod a technik vedoucích k přehlednému, snadno modifikovatelnému a spolehlivému software. Heslo bylo uplatňováno více pro SPS než pro jednoduché programy. Zde dochází k jistému rozdílu mezi informatiky v šířce chápání discipliny SWI. Někteří nerozlišují dvě discipliny, SWI a II Informační inženýrství a vše dávají dohromady pod SWI. To je tzv. široké chápání SWI (patří mezi ně i V. Kadlec). Jiní informatici (patřil mezi ně J.Martin a E. Yourdon) striktně chápou orientaci SWI jen na tvorbu programů. Podle nich různé typy analýz (např. ve strukturovaném přístupu: datová analýza, procesní analýza, funkční a transakční analýza, interakční analýza) patří do II a předchází tvorbě software. Tento přístup potom zavádí metodiky vlastního vývoje IS a metodologii, která se metodikami zabývá. Např. strukturované metodiky jsou založeny obvykle na tzv. fázích (ÚVODNÍ STUDIE, ANALÝZA, HRUBÝ A DETAILNÍ NÁVRH, IMPLEMENTACE, ZAVEDENÍ DO PRAXE, VALIDACE A CERTIFIKACE PRAXÍ). Role SWI je potom orientována jen na fázi IMPLEMENTACE. Toto pojetí jaksi zadává pomyslnou hranici mezi SWI a II. Oba dva přístupy informatiků k SWI jsou vzájemně se překrývající a mohou být zdánlivě konfliktní v chápání některých pojmů. Např. Životní cyklus: Jde o pojem souvisící jen s vývojem programu, nebo o pojem souvisící s metodikou vývoje IS? My se budeme držet užšího pojetí SWI, a neustále budeme poukazovat na širší souvislosti. Jinými slovy, budeme-li orientováni na školní tvorbu jednoduchých programů, tak to bude sice využitelné i pro tvorbu SPS, ale navíc bude mnoho souvislostí s komputerizací velkých fyzických systémů. Na druhé straně, tvorba SPS je natolik komplexní, že vyžaduje týmovou práci řízenou podle zavedeného softwarového projektu. je užitečné, když takový způsob tvorby software již je obohacen o pojetí životního cyklu. Pochopitelně, ačkoliv představy o životním cyklu tvorby SPS (to je software) a IS (to je složitý abstraktní systém na zpracování informace s mnoha komponentami) mohou být diametrálně odlišné, přesto mohou být obecné metody nebo filosofie podobné. Informatici ovšem pojetí životního cyklu orientují jen na jednu komponentu IS a to na jeho aplikační software, což je vlastně SPS. Nemůžeme programovat dříve, než najdeme to co máme programovat (procesy/transakce všech možných typů). A to jsou nejen algoritmy procesů a jejich transakcí, ale i složitá data a informační vztahy mezi nimi. Podrobně o rozdílu mezi jednoduchým programem a SPS pohovoříme později. Je pochopitelné, že metody, techniky, nástroje a jejich počítačová podpora jsou pro jednoduché programy a složité programové systémy (sem patří také aplikační software IS) velmi často značně odlišné. - 1

2 Orientace produkce software je dnes jednoznačně zaměřena na aplikace (aplikace se často chápou jako jednoduchá varianta SPS) a složité programové systémy a my to budeme také respektovat. 2.1 Klasifikace jednoduchých programů a složitých programových systémů Věnujme se teď pojetí jednoduchého programu, aplikace a složitého programového systému a ukažme historii jejich vývoje. Chceme-li vyjádřit podstatu jednoduchých programů, budeme muset spojit dohromady zkušenosti z jejich tvorby s transparentním formálním aparátem. Tento aparát potom posílí chápání podstaty tvorby jednoduchých programů. Historický vývoj chápání programů spěl rychle k vydělování tzv. jednoduchých programů a složitých programových systémů. Je však velmi obtížné běžným slovem charakterizovat jejich odlišnosti. Pokusíme se proto pomocí jednoduchých formálních aparátů postihnout nejtypičtější kvality obou skupin. Definice 1 a 2 podávají jednoduchý program jako uspořádanou šestici komponent a SPS jako systém relativně nezávislých programů/aplikací. Definice později podrobíme revizi pod zorným úhlem role objektového programování (instance tříd-objekty-nové dat. struktury, událostireakce-nový způsob řízení-nové řídící struktury). V každém případě je program chápán jako jeden z modelů realizace algoritmu A, tady realizace počítačem. X Program P=P(A ) Y Všechna přípustná vstupní data X a všechna přípustná výstupní data Y (zpracovávaná ve formě datové struktury) jsou svázány zobrazením A (X) Y. Analýza vlastností dat X a Y bude provedena v kapitole popisující datové struktury. Množina X může být např. množinou individuálních proměnných, souhrnů proměnných, vektorů, matic, tabulek, souborů,... Definice 1 Jednoduchý program P je uspořádaná šestice komponent ve tvaru P = ( T, D, R, Ω, S st, S d ), kde T je text programu složený z příkazů nad jazykem J, píšeme T=T(J), D je konečná množina datových struktur v programu, R je konečná množina řídících struktur v programu, Ω je konečná množina operací nad datovými strukturami v programu, S st je statická struktura programu předepsaná překladačem jazyka J, S d je dynamická struktura programu, která je dána přechody mezi příkazy na základě řídících struktur z množiny R. - 2

3 V tomto okamžiku je sice nepříjemné to, že ještě neznáme pohledy SWI na datové a řídící struktury. Pojetí dynamické a statické struktury programu již intuitivně chápeme v důsledku znalosti programovacího systému jazyka Pascal (jazyk a jeho překladač). Logika programu je dána kartézským součinem L=D x Ω x R. Tento vztah spojuje ty komponenty programu, které jsou pro aktivitu programu určující. Je pochopitelné, že vlastní porozumění tomuto zápisu je podmíněno potřebnými znalostmi abstraktních datových struktur a jejich formálních zápisů, významných operací nad datovými strukturami a pojetím řídících struktur v programu. Jejich pojetí bylo významně rozšířeno zavedením objektového a událostního programování (objekty disponují vlastnostmi, událostmi a metodami). Je na nás, abychom zmíněné znalosti postupně získali. Příklad 1: Následující příkaz v jazyku Pascal dostatečně dokumentuje definici logiky programu. Odlišnými barvami jsou označeny řídící struktury, operace a datové struktury. if a > b then y := a b else y := b a ; - řídící struktura (větvení) - operace - datové struktury Řídící struktury, jimiž jsou větvení, cyklus a sekvence jednoznačně určují potenciální přechody mezi příkazy. Potenciální přechody, na nichž je dynamika založena, se dají reprezentovat tzv. orientovaným grafem G řízení programu P s notací G = G(P), nad kterým lze provádět řadu užitečných úloh (uzly jsou příkazy programu, hrany mezi uzly jsou potenciální přechody mezi příkazy). Charakteristické vlastnosti tohoto grafu jsou plně dány dynamickou strukturou programu. Tento graf řízení programu přesně ilustruje jeho D s prostřednictvím individuálních potenciálních přechodů mezi příkazy. Jednoduchý program je charakterizován velmi často např. těmito typickými vlastnostmi : neveliký rozsah textu (1 až 2 str. A4), kompaktní celek, nedělitelný na další programy, omezený rozsah použitých forem datových a řídících struktur, vně programu nepřenositelné fyzické formy datových struktur a logika jejich zpracování (výjimkou jsou soubory). V současné době jsou tyto historicky typické vlastnosti rozšiřovány. Do množiny J se přidávají příkazy umožňující zpracovat i složitější datové struktury, např. prvky GUI (okna - 3

4 parametrů, menu, dialogy), objekty, entity (z náležících zdrojových bází dat). Často se také mění pohled na řídící struktury. Běžně jsou již používány řídící struktury založené na událostech. I přes tato vylepšování dochází k tvorbě jednoduchých programů převážně v rámci výuky programování, resp. při tvorbě prostého firmware. Jednoduchým programům se ovšem neodpírá jejich možná dělitelnost na samostatné procedury z nichž je vystavěna jejich celková aktivita. Následující obrázek zase dokumentuje význam komponenty S st pro pascalovské programy. Příklad 2: Jak se dají interpretovat komponenty S st a S d? Zkuste zjistit jejich interpretaci pro známé programovací jazyky Algol, Pascal, Visual Basic, resp. další jazyky (nevyjímaje značkovací jazyky, skriptovací jazyky, ). Např. S st pro pascalovský program je interpretací následujícího schématu statické struktury programu. Definice 2 Složitý programový systém P = {P 1, P 2,, P n=1, P n } je tvořen skupinou vzájemně svázaných, relativně nebo úplně samostatných programů pracující navenek jako jeden celek mající atributy obecného systému. - 4

5 Tato definice umožňuje sice postavit jistou hranici mezi jednoduchými programy a složitými programovými systémy, ale např. pro modulární programy není jasné do které skupiny patří. Definice je ale východiskem pro rozvedení vlastností obecného systému : nejvyššími strukturálními prvky jsou programy P 1, P 2,, P n mezi nimiž jsou vazby V = {v i,j P i x P j }. Tyto vazby mohou mít různorodý charakter : 1. řídících vazeb pro potencionální přechody mezi programy, 2. datových vazeb pro předávání a zpřístupnění dat, 3. kauzálních vazeb ( příčina, následek ), 4. synchronizačních vazeb pro přechody mezi programy v paralelním programovém systému, 5. koordinačních síťových vazeb (řízení distribuce), když je složitý programový systém rozložen na počítačové síti, 6. vazba předávání zpráv mezi objekty, 7. vazba přechod na událost a další. složitý programový systém má okolí O s prvky A 1, A 2,,A m píšeme O = ( A 1, A 2,, A m ) s možnými vazbami programů na prvky okolí což zapíšeme ve tvaru V = { v i,j P i x A j }. Tyto vazby mohou mít opět různorodý charakter : 1. datových vazeb pro přístup k vnějším zdrojům dat, 2. řídících vazeb pro tzv. vnější řízení, 3. zásahů pro restrukturalizaci vazeb. Programový systém je uzavřený, je-li V prázdnou množinou. zápis složitého programového systému může být také ve tvaru S = ( P, V, V ), stavem Σ = ( x 1, x 2,,x t ) rozumíme souhrn přesně definovaných situací, podmínek, vlastností-stavových veličin x 1, x 2,,x t v nichž se může systém nacházet. Systém je obvykle v počátečním stavu σ 0 a přechází ze stavu do stavu na základě své činnosti, množinu programů P 1, P 2,, P n lze sémanticky sdružovat do disjunktních podmnožin S 1, S 2, které nazýváme podsystémy. Tím dojde také k přeskupení vazeb, protože některé z vazeb mezi programy se stanou vazbami mezi podsystémy a jiné vazbami podsystémů na okolí. Další možností je seskupení programů do speciálních celků - modulů s interpretací všech možných vazeb mezi moduly a systémem řízení (potenciální přechody mezi moduly). Seskupování může být provedeno na základě specifických kritérií (např. modul pro správu dokumentů klienta, modul komunikace s klientem, ). Modulem může být např. podsystém - 5

6 SPS je charakterizován velmi často např. těmito typickými vlastnostmi : velký rozsah textu, jehož části mohou být v odlišných programovacích jazycích, členění systému na podsystémy v souladu s analýzou informačního problému, členění systému na moduly, vazby na okolí jsou realizovány v tzv. GUI (Graphical User Interface), je použito všech dostupných řídících a datových struktur, jednotná logická datová struktura daná bází dat (relační/objektovou), tvorba je řízena pomocí projektu se zvoleným životním cyklem, tvorba je převážně týmovou prací, členění na tři nebo více vrstev (prezentační, aplikační a datová), pro SPS na bázi Internetu: členění na části klient/server, možnost zavedení distribuovaných programů, Nižší formou SPS jsou tzv. aplikace. Vyznačují se tím, že programů není příliš mnoho (neurčité), ale je velké množství pomocných souborů různých formátů a významu. Příklady složitých programových systémů : operační systémy, aplikace různých druhů ( textové a tabulkové procesory, ), software všech klasických variant IS ( transakční, expertní, taktické, strategické ), software všech variant IS na bázi Internetu. - 6

7 2.2 Ukázky různých typů aplikací Prof. RNDr. Milan Mišovič, CSc Klasické souborové: 1. Jednovrstvé aplikace zpracovávající klasické soubory. Data a kód jsou v jedné vrstvě. Soubory mají vlastní strukturu a nepředpokládá se jejich zpracování v jiné aplikaci. Používá se tedy jen jeden počítač, síť se nepředpokládá. počítač kód aplikace soubory aplikace Z A S T A R A L É Obrázek 1: Jednovrstvá aplikace zpracovávající klasické soubory. 2. Dvouvrstvé aplikace zpracovávající klasické soubory. První vrstva je kód, druhou vrstvou jsou data ve formě souborů. Používá se tedy více počítačů. Uživatelé, tj. aplikace Klienti souborů sdílí soubory a jejich strukturu. Jsou to aplikace technologie tlustý klient server. Jde o souborový server. aplikace 1 aplikace n počítač 1 počítač n síťová komunikace Souborový server Obrázek 2: Dvouvrstvá aplikace zpracovávající klasické soubory. - 7

8 Klasické, neobjektové zpracovávající BD: 3. jednovrstvé a dvouvrstvé aplikace zpracovávající BD pro jeden počítač. Kód aplikace a BD mohou být v různých vrstvách. Síť se nepředpokládá. Klasická aplikace počítač M O D E R N Ě J Š Í komunikace Obrázek 3: Dvouvrstvá a jednovrstvá aplikace, obě zpracovávající BD. Např. pro dvouvrstvou aplikaci konstruovanou ve Visual Basic to znamená, že kód a formuláře jsou v první vrstvě, zatímco BD je ve vrstvě druhé. VB dokáže zřídit komunikaci s různými BD ( ACCESS, FOX PRO, ORACLE, ) pomocí speciálních poskytovatelů 1. Z hlediska možností VB je to aplikace, které se často hanlivě říká klikačka, protože u ní je podstatné právě klikání myší na volbách v menu, na ovládacích prvcích, na formulářích, na dialogových oknech, BD Prvky GUI 1. vrstva kód DAO, RDO, ADO Prvky pro správu dat asociace Aktivitní procedury události kód události kód Reakční procedury Poskytovatel BD 2. vrstva data Obrázek 4: Dvouvrstvá struktura klasické klikačky (přechod na třívrstvou aplikaci již není problémem, když GUI nějak vydělíme). 1 Poskytovatel je naprogramovaný databázový stroj poskytující aplikaci přístup k bázi dat podobně jako v DBS - 8

9 Klikačka na jednom počítači je nejčastějším případem školních aplikací ve VB. Ovládací prvky z VB působí jak v roli Prvky pro správu dat tak i v roli Prvky GUI. Vizualizace dat hraje v klasické klikačce rozhodující roli. 4. dvouvrstvé aplikace zpracovávající BD pro více počítačů. Jedna vrstva je kód aplikace a formuláře, druhá vrstva je BD. Aplikace, tj. Klienti báze dat, sdílí společnou BD s kterou mají relativně samostatnou komunikaci. Klienti mají ovšem veškeré zpracování importovaných dat z BD na své straně a jsou tedy typu tlustý klient. Zabezpečení importu dat z BD má na starosti databázový server. aplikace 1 aplikace n počítač 1 počítač n síťová komunikace Databázový server BD Obrázek 5: Klasické multi-klientské zpracování téže BD. Od uvedených architektur aplikací se značně liší architektury založené na OOP, které zpracovávají objektovou BD. Myslíme tím tyto aplikace: 5. dvouvrstvé objektové aplikace, 6. třívrstvé (vícevrstvové) objektové aplikace, 7. jednovrstvé databázové aplikace, 8. internetové (webové) a intranetové aplikace. Prozatím vynecháme povídání o objektových aplikacích, včetně zkoumání počtu jejich vrstev. Problematika je poněkud složitá a nemáme zatím vysvětlenou logiku objektového programu, objektové aplikace a objektového SPS. Jednovrstvé databázové aplikace. Jsou to jednovrstvé aplikace plně konstruovány pomocí vývojového prostředí zvoleného databázového stroje (Systém řízení báze dat). Databázový stroj má speciální vývojové prostředí, ve kterém je možno konstruovat všechny významné části aplikace zpracovávající BD. Aplikace může být na tomto stroji silně závislá, totiž může probíhat jen v jeho péči (není přenositelnost Portability). Je ovšem i druhá možnost, že databázový stroj je schopen generovat aplikaci ve tvaru (run-time mode), kdy je aplikace přenositelná na jiný počítač, který nemá nainstalovaný vývojový databázový stroj, v kterém byla aplikace původně vyvinuta. - 9

10 Význam těchto aplikací jaksi pohasl s nástupem internetu a vzniku tzv. webových aplikací (Web-based applications). Důvod byl v zavedení vícevrstvosti webových aplikací a databázovému stroji byla svěřena role správy BD v samostatné vrstvě. Databázová aplikace BD Databázový stroj (SŘBD) Počítač s instalovaným Databázovým strojem Obrázek 6: Jednovrstvá databázová aplikace. Internetové webové aplikace Jsou to v současné době nejčastěji tvořené aplikace. Mohou být postaveny na klasickém strukturovaném programování, nebo moderněji na objektovém programování. Jejich základem je tvorba webového sídla s mnoha klientskými DHTML stránkami a serverovými stránkami. Nejčastějším případem jsou třívrstvé webové aplikace, viz obrázek 7. Předpokládá se technologie tenký klient. První vrstva Gui je na straně tenkého klienta, druhá vrstva aplikační procedury (business vrstva) jsou na serveru. Třetí vrstvu tvoří databázový stroj s BD. Prvky GUI datové asociace datové asociace kód 2. vrstva Logika zprac.dat kód - skripty Prvky pro správu dat APLIKAČNÍ procedury události asociace na základě událostí kód - skripty Reakční procedury Poskytovatel BD 3. vrstva 1. vrstva Obrázek 7: Klasická třívrstvá webová aplikace. - 10

11 2.3 Význačné směry ve vývoji SWI V této části budou stručně charakterizovány vybrané (ne tedy všechny existující) směry poznatků v SWI. Mnohé z nich budou ještě detailně rozebrány v samostatných kapitolách /podkapitolách. Ke klasickým směrům budou přidány i v současné době vévodící směry poznatků. Mnohé ze směrů se budou zdát historické a překonané. Je to sice pravda, ale zdravá a ověřená klasika v SWI má platnost dodnes. Jelikož se nenašel zatím žádný lepší způsob komputerizace algoritmů než pomocí programů, je proto SWI postaveno právě na tvorbě programů a na zkoumání jejich tvorby ze všech možných stran. Technologie tvorby jednoduchého programu. Základem technologie je produkce podle tzv. Životního cyklu programu ( Program Life Cycle ). Životní cyklus jednoduchého programu zahrnuje fáze ZADÁNÍ PROBLÉMU, ANALÝZU, NÁVRH PROGRAMU a KÓDOVÁNÍ - zápis v příkazech programovacího jazyka, LADĚNÍ PROGRAMU. Často se celý životní cyklus jednoduchého programu chápe jako širší pojetí slova ALGORITMIZACE. Analýza se orientuje na nalezení algoritmu řešení problému a jeho zápis ve vývojovém diagramu (technika). V analýze bylo možné použít řadu metod přístupu jako postup SHORA-DOLŮ nebo ZDOLA-NAHORU, strukturální rozklady, abstrakce. Dále šlo o nalezení a definování přípustných dat (pomocí množinového určení), stanovení typů zpracovávaných datových struktur (proměnné, matice, vektory, tabulky, soubory, ) a ilustraci postupu v jejich zpracování. V návrhu programu šlo o vyjádření architektury programu a zvolení nejjednodušší metody postupu jeho tvorby. Jde o takové metody programování jako : Strukturované programování, Normované programování, Procedurové programování, Logické programování, Paralelní programování, Abstrakce dat Každé z těchto typů "programování" má svoji základní jednotku. Např. základní jednotkou Procedurového programování je Procedura - stavební kámen. Pak je podstata tohoto programování vyjádřena takto : Rozděl aktivity programu do procedur. Posloupností vyvolání procedur realizuj globální aktivitu programu. Později se začalo pro rozsáhlejší programy používat Modulární programování (stavební jednotkou je Modul) a pro výstižný a ekonomický popis a zpracování datových struktur tzv. Objektové programování (jednotkou je Objekt a jeho informační podstata a operace). Často se mezi metody zahrnuje i tzv. Událostní programování a skriptové programování. Ve vlastním kódování pak šlo o použití vhodného programovacího jazyka, později o použití vývojového prostředí (jehož součástí je také jazyk a jeho překladač) v souladu se zvolenou metodou programování. Řada informatiků se orientovala na konkrétní naplnění životního cyklu ( tj. obsahu jednotlivých fází a tak vznikly ucelené přístupy k tvorbě programu, jako : Jacksonova metoda návrhu programu Mayersův návrh modulárních programů, V Ladění programu šlo o odstranění jednak syntaxních a potom logických chyb v programu tak, aby na přípustná vstupní data X program dával přípustná výstupní data Y. - 11

12 V tomto směru dochází k uplatnění výsledků jiných směrů (datové typy a jejich zpracování, programovací jazyky, vývojová prostředí, verifikace programů, automatizace projektování, metrologie software, psychologie programování ). Datové abstraktní struktury, datové typy a jejich zpracování *. Tento směr se zabývá typy datových struktur a jejich zpracováním na logické a fyzické úrovni. Pečlivě se rozebírají významné operace (třídění, vyhledávání, ) pro jednotlivé typy datových struktur. Mnoho pozornosti je věnováno abstrakci dat, dynamickým typům dat a rekurzi v datech. Z hlediska datových struktur je pak posuzována kvalita programovacích jazyků. Vrcholem datových struktur jsou databázové struktury a báze dat v relační nebo objektové podobě. Jejich zavedení a zpracování v databázových systémech je podepřeno speciální Coddovou relační algebrou a formální objektovou algebrou. Problematika datových typů úzce souvisí s formálními aparáty pro popis podstaty datových struktur (Data Structures) a s disciplinou Abstraktní datové modely. Programovací jazyky *. Programovací jazyk (Programming Language) je souhrn elementárních prostředků pro vyjádření aktivit nad datovými strukturami a postupu jejich provádění. Je základním prostředkem pro realizaci kódování a tím i tvorbu programu. Program je komputerizací 2 jistého algoritmu. Směr rozebírá pod zorným úhlem mnoha kritérií každý programovací jazyk, čímž se získává posouzení celkové kvality jazyka. Posuzuje se kvalita řídících struktur, orientace programovacího jazyka na vybrané datové struktury, algoritmy a metody programování. Navrhují se doplňkové knihovny silnějších prostředků - prostředků 3GL, než jsou elementární příkazy. Tyto prostředky umožní programátorovi realizovat interaktivním přístupem velmi silné prvky programu jako řídící menu, dialogová okna, zpracování databázových struktur, dotazy do bází dat, tvorbu grafů, tabulek, spolupráci s INTERNETEM,... Za vrchol se považují speciální programovací jazyky založené na objektovém programování a doplněné událostním a skriptovým programováním, jimiž se zvládne i kódování složitých programových systémů ( např. objektový Pascal v systému DELPHI, Visual Basic, Visual C ++ v systému VISUAL STUDIO, objektové PHP, Java, Perl, ). Výzkum tvorby překladačů programovacích jazyků přinesl velmi produktivní technologie jejichž vrcholem jsou generátory překladačů specifických jazyků. Problematika překladačů navazuje na problematiku práce s datovými typy na obou úrovních, logické a fyzické. Problematika programovacích jazyků úzce souvisí s matematickou teorií formálních jazyků a lingvistikou. Vývojová prostředí *. Vývojové prostředí je souhrn prostředků, které zabezpečují počítačovou podporu pro jednotlivé fáze životního cyklu jednoduchých programů (Program Integrated Development Environment) a složitých programových systémů (System Integrated Development Environment). Složení vývojového prostředí je výrazně poplatné jeho orientaci na počítačovou podporu fáze resp. fází životního cyklu tvorby software. Pokud se týká orientace na jednoduché programy bývá počítačová podpora věnována výrazně jen fázi KÓDOVÁNÍ a navazujícím aktivitám (uložení programu, tisk textu programu, ). Takové prostředí pak obsahuje : 2 komputerizace je realizace algoritmů prostřednictvím počítačových programů - 12

13 Programovací jazyk a jeho překladač Knihovny prostředků 3GL, generátory procedur Péče o prostředí a práce se soubory Řízení prostředí (menu a panely) Textový editor pro zápis programů Ladící a trasovací prostředky Obrázek 8 : Vývojové prostředí s klasickým programovacím jazykem v období 80-tých let. Pochopitelně, daleko členitější jsou vývojová prostředí pro SPS (aplikace, software expertních a informačních systémů,...), povídání o nich bude později. Verifikace programů *. Tento směr se zabývá prověřováním korektnosti programů. Korektnost je laicky definována následující větou : "Program je korektní jestliže za všech okolností dělá jen to co bylo programátorem zamýšleno" Podstatou problematiky jsou teoretické a praktické algoritmy pro prověrku korektnostispolehlivosti programu. Jde nejen o dokazování absolutní resp. parciální korektnosti ale i o použití metod, které korektnost nemohou dokázat. Sem patří i testování jednoduchých programů a složitých programových systémů. SWI nabízí širokou paletu testovacích postupů pro jednoduché programy (testování na symbolických a reálných datech, trasování cest, přechodů mezi procedurami, hodnot proměnných,...). Významné je hledání algoritmů pro produkci tzv. úplné množiny testovacích dat pro cesty v programu, nad kterou provede programátor testování programu. Do tohoto směru patří i zkoumání a navrhování verifikačních a diagnostických překladačů zabezpečujících přijatelnou verifikaci, diagnostiku a automatickou korekci programu. Je zde řada problémů, které teoretická a praktická informatika ještě nedokázaly vyřešit. Problematika absolutního dokazování korektnosti programů patří do teoretické informatiky (Matematická informatika, Teorie programování). Literatura. IEEE, (1990a), IEEE Std Standard for Software Productivity Metrics, New York, N.Y. IEEE, (1990b), IEEE Std Standard for Software Quality Metrics Methodology, New York, N.Y. Norma ISO 9126 Jones, I, Capers, G.: Applied Software Measurement. McGraw-Hill, New York, N.Y, 1991 Kan, S.H.: Metrics and Models in Software Quality Engineering, Adisson Wesley, Reading Mass. Král, J., Demner J.: Softwarové inženýrství, Academia Praha,CZ, 1991 Sommerville, I.: Software Engineering ( 4 th ed. ), Addison Wesley, Reading, Mass

14 Norma NATO AQPA 150 Prof. RNDr. Milan Mišovič, CSc Psychologie programování. V tomto směru se zkoumá mnoho faktorů majících vliv na "psychologii" programátorské práce. Prvním z faktorů je znalost a uplatnění empirických zákonitostí vývoje software (tzv. softwarová fyzika). Tyto zákonitosti byly potvrzeny podrobným sledováním specifik programátorské práce a bylo zjištěno, že produktivita práce programátora silně závisí od jeho psychiky. Zákonitosti byly vyjádřeny v tzv. softwarových rovnicích vyjadřujících vztahy mezi mnoha charakteristickými veličinami v programátorské práci (velikost, doba realizace, kvalita, počet programátorů, lexikální atomy díla, produktivita práce, ). Dalším faktorem je docenění empirické hypotézy o existenci chyby v každém programu. Důležitým faktorem je uplatnění zákonitostí týmové práce (psychologické problémy, složení týmu, vedení týmu, role stěžejních členů týmu, sociální role členů týmu, sociální normy, vztahy, ponorkové klíma,...). Značnou roli ve výskytu chyb hraje faktor subjektivních chyb v myšlení bez ohledu na to čím byly vyvolány. Do práce programátora, resp. čistého analytika se jistě promítají psychologické problémy komunikace člověk-počítač. Důležitým faktorem úspěchu ve vývoji software je výběr vhodné technologie vývoje. Jde o to, zda tato technologie umožňuje provádět vývojové práce (zápis programu, překlad, ladění, opravy chyb, automatizace některých aktivit v programu a v jeho životním cyklu, ) "přijatelně". Průběžně se tento směr doplňoval zkušenostmi jenž se získaly z použití CASE prostředků při vývoji IS. Literatura. Král, J., Demner J.: Softwarové inženýrství, Academia Praha,CZ, 1991 Metrologie software *. Jednoduché programy a složité programové systémy (spolu software) jsou zbožím jehož atributy je nutné měřit. Vyprodukovaný software má obvykle alespoň tři základní charakteristiky : rozměrnost, pracnost technologie výroby, časové nároky, kvalita ( korektnost ), Atributy software se přesně měřit nedají, ale praxe to nutí provádět. Nejrozvinutější jsou metriky pro rozměrnost a pracnost. Na druhé straně je i kvalita software měřitelná, ale jde spíše o měření její vnější stránky (např. metrikou "střední doba mezi výskytem chyb"). Vlastnosti kvalitního software popisuje i norma ISO Využití metrik je obvykle záležitostí výrobce software. Metriky jsou převážně konstruovány tak, že nezávisí na vývojovém prostředí v němž se software vyvíjí, odlišnosti jsou ale v orientaci metrik na klasický a objektově orientovaný software. Metriky můžeme považovat za paměť pro tvorbu software (není dobré zapomínat jak probíhala předchozí tvorba software). Uveďme některé příklady metrik: Délka programu, jde o velikostní metriku vyjádřenou počtem řádků, procedur, Pracnost, jako spotřeba normojednotek času na vývoj software, Produktivita, jako počet jednotek délky na jednotku času, Selhání, počet selhání software v čase t, Oprava, jako počet míst v software, které bylo nutno předělat po odstranění zjištěných selhání,. - 14

15 Literatura. IEEE, (1990a), IEEE Std Standard for Software Productivity Metrics, New York, N.Y. IEEE, (1990b), IEEE Std Standard for Software Quality Metrics Methodology, New York, N.Y. Norma ISO 9126 Jones, I, Capers, G.: Applied Software Measurement. McGraw-Hill, New York, N.Y, 1991 Kan, S.H.: Metrics and Models in Software Quality Engineering, Adisson Wesley, Reading Mass. Král, J., Demner J.: Softwarové inženýrství, Academia Praha,CZ, 1991 Sommerville, I.: Software Engineering ( 4 th ed. ), Addison Wesley, Reading, Mass Norma NATO AQPA 150 Učeň, P. a kol.: Metriky v informatice. jak objektivně zjistit přínosy informačního systému. GRADA Praha, Automatizace tvorby programů. Je to směr v němž se zkoumají ty nejefektivnější způsoby omezení absolutní role programátora v procesu kódování resp. se nacházejí možnosti počítačové podpory pro tvorbu jednoduchých programů a složitých programových systémů. Vrcholem automatizace je generování kódu pro velmi často používané aktivity (vstupy, výstupy, dialogová okna, menu, spojení s BD, přenos informace mezi programem a BD, ) spolu s vizualizací zadávaných parametrů automatizovaných aktivit. S počítačovou podporou se setkáme nejen ve vývojových prostředích pro jednoduché programy ale zejména ve složitých vývojových prostředí jako jsou DBS systémy a CASE prostředky. Myslíme tím počítačovou podporu pro všechny, resp. vybrané fáze životního cyklu tvorby software. Velmi častým případem je obrovská výpomoc interpretačních překladačů při psaní vlastního textu programu. Např. při objektovém programování dostane programátor automatickou vizuální informaci o kvalitách aktivního objektu (vlastnosti, události, metody, závislosti, takže může velmi rychle sestavit poměrně složitě kvantifikovaný příkaz pro přístup k jisté vlastnosti/události/metodě daného objektu. Příklad: Formulář frmseznam (ve vývojovém prostředí pro Visual Basic) obsahuje objekt Tlačítko jména cmdadd (vestavěný objekt) chceme nastavit vlastnost Caption na hodnotu Add. To můžeme provést manuálně v okně Properties-cmdAdd nebo příkazem frmseznam. cmdadd. Caption = "Add" - 15

16 Metodiky tvorby programů. Jde o ucelené návody postupu tvorby složitých programových systémů. Metodiky samy o sobě popisují - stanovují aktivity výrobního vývojového procesu software, protože říkají přesně CO dělat, JAK to dělat, KDY to dělat a KDE to dělat (jsou metodickou technologií). Mimo jiné odkazují tvůrce na potřebnou teoretickou podporu v době vývoje software. Vývojový proces software je členěn na fáze. Metodika do každé fáze promítá parciální obsah pojmů CO, JAK, KDY a KDE. Jestliže výrobní proces software proběhl všemi fázemi úspěšně, prošlo software svým nutným vývojovým cyklem. Něco jiného je tzv. životní cyklus software, který říká jakou filosofií se projdou nebo prochází všechny fáze vývojového cyklu. Jsou tedy pojmy výrobní proces, vývojový proces a životní cyklus velmi příbuzné, jsou téměř synonymické. Metodiku budeme ale od těchto tří pojmů mírně odlišovat. V životním cyklu může dojít k různým způsobům implementace metodiky. CO, JAK, KDY A KDE se může během vývoje implementovat na celý cílový software nebo na jeho část nebo postupně přírůstkově, Je tedy životní cyklus realizován na základě jistého modelu stylu životního cyklu. Závěrem musíme říci, že studium je potřebné věnovat jednak metodice a potom stylu životního cyklu. Metodiky a styly životních cyklů je jeden z nejdůležitějších směrů softwarového inženýrství. Prošly velmi rychlým vývojem, mnohé již jsou zastaralé, jiné jsou momentélně v kurzu. V každém případě metodiky odrážejí náhledy na vývoj software dané doby. Např. rozlišujeme metodiky po softwarové krizi a soudobé agilní metodiky. - 16

17 2.4 Technologie tvorby aplikačního-business vybavení informačních systémů (jen seznámení) Tento problematika svým rozsahem patří do II Informačního inženýrství. II předkládá četné metodiky, metody, techniky a prostředky pro vývoj IS, spolu s jistými teoretickými základy. IS je chápán jako komplex komponent (hardware, software - základní a aplikační, lidé, fyzická zařízení, legislativní předpisy, ) a proto jeho vývoj má mnohem více úkolů než jen vyvinout aplikační software, které je typu SPS. Celý vývoj probíhá podle stanoveného projektu, na základě tzv. životního cyklu IS, s členěním na fáze, což je závislé na použitém přístupu k vývoji IS (strukturovaný/objektový přístup). Např. životní cyklus vývoje IS pro strukturovaný přístup je členěn na následující fáze: ÚVODNÍ STUDIE ANALÝZA HRUBÝ NÁVRH IS DETAILNÍ NÁVRH IS IMPLEMENTACE ZAVÁDĚNÍ DO PRAXE Způsob provádění jednotlivých fází (pořadí, úkoly) je tzv. styl životního cyklu vývoje IS (např. vodopádové/spirálové/ provádění jednotlivých fází). Celý vývoj IS je řízen obsahem projektu postaveného pro tento účel. SPS je v tomto případě právě aplikačním software informačního systému, které se získá naprogramováním procesů a jejich transakcí. A to je vlastně komputerizace procesů fyzického systému (podniku, školy, ), pro který má být IS vytvořen. Vedle některých poznatků využitelných při tvorbě složitých programových systémů (modulární programy, aplikace vytvořené v prostředích DBS, ) se setkáme s novými metodami, technikami a prostředky využitelnými jen pro tvorbu IS. IS představují komputerizaci celých organizací, firem, podniků (fyzické systémy). V užším pojetí je Softwarové inženýrství využíváno jen v jedné z fází životního cyklu IS, přesněji ve fázi IMPLEMENTACE. Pro ostatní fáze se využívá poznatků dalších disciplin jako jsou II -Informační inženýrství (Information Engineering IE) a OI - Organizační inženýrství (Organization Engineering OE). Pro tvorbu software typu SPS IS mnozí z informatiků vidí v SWI uplatnění některých velmi užitečných a charakteristických principů (typických pro tzv. strukturovaný přístup), např. princip modelování struktury informace, vztahů mezi informacemi, toků informace, aktivit a přechodů mezi nimi, vztahů informace a aktivit ( k tomu slouží takové nástroje jako vývojové diagramy programů, diagramy modulárních programů, diagramy struktury složitých programových systémů, kontextové diagramy, diagramy toků dat, datové diagramy, diagramy života datových struktur, procesní diagramy,.) princip prototypování ( nebo iterace ) vychází z toho, že se postupně v iteračních krocích vytvořeným software blížíme k jeho požadované podobě princip uplatnění strukturovaných rozkladů umožní k informačnímu problému přistupovat v různých úrovních, počínaje nejvyšší abstrakcí a konče reálnými detaily princip řízení procesu tvorby software ( jeho členění do fází, se stanovením náplně jednotlivých fází, s metodami, prostředky a - 17

18 Kontrolováno až sem nástroji které se dají v jednotlivých fázích využít ) vyjádřený tzv. životním cyklem princip vícenásobného využití již vytvořených částí software, princip počítačové podpory nejen pro metody, techniky a prostředky používané v životním cyklu ale i pro řízení všech vývojových prací ( je to pestrá paleta generátorů, editorů diagramů, ). - 18

19 INFORMAČNÍ SYSTÉMY IS je potřeba chápat poněkud strukturovaněji, tj. alespoň v následujících komponentách: Hardwarové prostředky. Všeobecné softwarové prostředky (základní software). Výkonné software IS, tj. aplikační software. Lidé, prostory, zařízení. Legislativní a fyzické předpisy. Vývoj IS a rovněž jeho aplikačního software mé svá přísná pravidla. Klasické strukturované pojetí projektování a vývoje IS čerpá ze tří význačných zdrojů: Softwarové inženýrství, Informační inženýrství, Organizační inženýrství. Rozvoj těchto zdrojů byl a je nerovnoměrný. Historicky nejdelší rozvoj má Softwarové inženýrství ( začátky 60. let ). Informační inženýrství se objevuje až koncem 70. let a je spojeno s tvorbou informačních systémů. Ačkoliv byly poznatky organizačního inženýrství známé desítky let, první poznámky k jeho koncepci a využití při tvorbě IS se objevují až koncem 60. let. Disciplina o IS je ve své podstatě velmi problematická alespoň ve třech směrech : 1. interdisciplinárního charakteru ( podíl více disciplin na jejím formování ), 2. pragmatického vývoje ( poznatky jsou obvykle evokovány až uplatněním nových možností ICT ), 3. absence všeobecně přijatelné teoretické základny. Jsou názory, že disciplina o IS je průnikem poznatků z následujících věd nebo disciplin : počítačová věda ( Computer Science ), věda o řízení ( Management Science ) a rozhodování, věda o organizacích ( Organization Science ), ekonomika, věda o chování ( Behavioral Science ) a pracovní psychologie, vybrané části z filosofie a sociologie, matematika Průnik poznatků ze zmíněných věd nebo disciplin je ilustrován následujícím obrázkem. - 19

20 věda o řízení věda o organizacích ekonomika IS matematika věda o chování vybrané části z filosofie a sociologie počítačová věda Obrázek 9: Interdisciplinární pojetí IS Jsou názory informatiků, že rozvoj poznatků v disciplině IS je založen jen na bázi praxe. Většina výzkumných projektů se zabývá převážně problematikou co nejlepší aplikace nových ICT a dlouhodobé teoretické výzkumy se téměř nevyskytují. Disciplina IS nemá ucelenou teoretickou základnu. Na potvrzení praktických poznatků jsou používány dílčí teorie. Příznačné je to zejména ve dvou zdrojích poznatků : Softwarové inženýrství a Informační inženýrství. S některými teoretickými úlohami se informatici setkali zejména v Softwarovém inženýrství ( datové struktury, teorie jazyků a překladačů, verifikace programů, úplné množina testovacích dat, ) a s dalšími z informačního inženýrství se informatici jistě setkají v nejbližší budoucnosti. Obecná problematika projektování IS, projekt Procesu výstavby IS (tj. všech komponent) se obvykle účastní : zadavatel...organizace, která objednává a financuje výstavbu IS, řešitel...disponuje řešitelským týmem, je obvykle i dodavatelem IS, uživatel...ten IS využívá, často je to současně zadavatel, dodává základní informaci pro řešitelský tým. Pro vlastní řízení procesu tvorby IS se obvykle zřizuje řídící komise v níž hlavní roli hraje zadavatel. Aby se zabezpečila úspěšná tvorba resp. renovace IS zavádí se posloupnost složitých operací s aplikací formalizovaných metod řízení a plánování, často nazývaná projekt. Vedoucí projektu pak zodpovídá za vyhotovení a kontrolu realizace přijaté informační strategie. Prostřednictvím řídící komise komunikuje vedoucí projektu s vedením uživatele, vedením řešitele a jeho řešitelskými týmy. Projekt jako takový pokrývá především ostatní fáze ŽC mimo ÚVODNÍ STUDIE. Základním posláním projektu je zabezpečit ve stanoveném čase, se stanovenými subjekty ( zadavatel, řešitel a jeho týmy ) naplnění úkolů jednotlivých fází ŽC a k tomu potřebuje velmi kvalitní např. produktově orientované řízení. - 20