2 SWI JAKO DISCIPLINA TVORBY PROGRAMŮ

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I

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


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 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, Ω , Sst, Sd ), 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, Sst je statická struktura programu předepsaná překladačem jazyka J, Sd 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

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I 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 Ds 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

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I 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 Sst pro pascalovské programy.

Příklad 2: Jak se dají interpretovat komponenty Sst a Sd ? Zkuste zjistit jejich interpretaci pro známé programovací jazyky Algol, Pascal, Visual Basic, resp. další jazyky (nevyjímaje značkovací jazyky, skriptovací jazyky, …). Např. Sst pro pascalovský program je interpretací následujícího schématu statické struktury programu.

Definice 2 Složitý programový systém P = {P1, P 2, …, Pn=1, Pn} 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

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I 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 P1, P2,…, Pn mezi nimiž jsou vazby V = {vi,j | Pi x Pj }. Tyto vazby mohou mít různorodý charakter : řídících vazeb pro potencionální přechody mezi programy, datových vazeb pro předávání a zpřístupnění dat, kauzálních vazeb ( příčina, následek ), 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ší. 1. 2. 3. 4.

•

složitý programový systém má okolí O s prvky A1, A2,…,Am píšeme O = ( A1, A2,…, Am ) s možnými vazbami programů na prvky okolí což zapíšeme ve tvaru V = { vi,j | Pi x Aj }. 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 Σ = ( x1, x2, …,xt ) rozumíme souhrn přesně definovaných situací, podmínek, vlastností-stavových veličin x1, x2, …,xt 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ů P1, P2,…, Pn lze sémanticky sdružovat do disjunktních podmnožin S1, S2,… 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

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I 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


2.2 Ukázky různých typů aplikací 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č

soubory

aplikace

Obrázek 1: Jednovrstvá aplikace zpracovávající klasické soubory.

Z

A S

T

A R

A

L É

kód aplikace

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.

aplikacen

aplikace1

počítač1

počítačn síťová komunikace

Souborový server

Obrázek 2: Dvouvrstvá aplikace zpracovávající klasické soubory.

-7

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I 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č

N Ě J

Š Í

komunikace

E R

BD

M

O

D

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, …

Prvky GUI asociace

1. vrstva kód události

kód

Aktivitní procedury kód

DAO, RDO, ADO

Prvky pro správu dat

Poskytovatel

události

Reakční procedury

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

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I „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.

aplikacen

aplikace1

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. 6. 7. 8.

dvouvrstvé objektové aplikace, třívrstvé (vícevrstvové) objektové aplikace, jednovrstvé databázové aplikace, 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

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I 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

asociace na základě událostí

APLIKAČNÍ 2. vrstva

procedury

Logika zprac.dat kód - skripty

kód - skripty

události

Reakční procedury

Prvky pro správu dat

1. vrstva Poskytovatel

BD 3. vrstva

Obrázek 7: Klasická třívrstvá webová aplikace. - 10


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

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I 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


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.-1045-1990. Standard for Software Productivity Metrics, New York, N.Y. IEEE, (1990b), IEEE Std.-1061-1990. 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 ( 4th ed. ), Addison Wesley, Reading, Mass. 1991

- 13

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I Norma NATO AQPA 150

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 9000-3. 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

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I Literatura. IEEE, (1990a), IEEE Std.-1045-1990. Standard for Software Productivity Metrics, New York, N.Y. IEEE, (1990b), IEEE Std.-1061-1990. 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 ( 4th ed. ), Addison Wesley, Reading, Mass. 1991 Norma NATO AQPA 150 Učeň, P. a kol.: Metriky v informatice. jak objektivně zjistit přínosy informačního systému. GRADA Praha, 2002.

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


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


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 IMPLEMENTACE ZAVÁDĚNÍ DO PRAXE

DETAILNÍ NÁVRH IS

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


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


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


věda o řízení věda o organizacích

ekonomika matematika

IS

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


Plánování práce

P R O J E K T

SYSTÉM ŘÍZENÍ

Definování výsledných produktů

Výběr metod a činností vedoucích k vytvoření specifikovaných produktů Usměrňování tvorby výsledného produktu jímž je IS

Rozdělování práce a zdrojů

Sledování postupu a měření kvantity a kvality produktů jednotlivých fází

Obrázek 10: Komponenty systému řízení Za základní principy metod řízení projektu můžeme považovat : • • • •

orientovanost metody ( např.produktová orientovanost, …), členění na předepsané skupiny činností a předepsané činnosti ve skupinách, specifičnost organizace projektu ( vedení, komise, týmy, dokumentování,…), algoritmy odhadů a kontrol ( kontrola postupu v etapě, kontrola kvality produktů, revize celého postupu v etapě,…).

Jako příklad můžeme uvést „seznam standardních řídících činností“ metody LBMS Project Management. Problematika projektu je dost rozsáhlá a zaslouží si samostatnou publikaci. Zde se dotkneme jen problematiky měření prací a měření kvality výsledných produktů. K tomu jen poznamenejme, že řízení projektu vždy důsledně zachycuje začátek a konec každého kroku ve fázi ( např. specifikace programu, tvorba programu, testování programu, nebo sestavení podsystému programů, testování podsystému, instalace podsystému,… ) a potom konec celé fáze. Uvědomme si, že plánování by mělo přesně specifikovat nejen úhrn prací za krok, fázi ale i definovat plánované vlastnosti výsledných produktů kroků nebo fází ( specifikace za fázi ANALÝZA, model návrhu za fázi NÁVRH, celý implementovaný IS za fázi IMPLEMENTACE ). Metrologie vývojových prací Jestliže ÚVODNÍ STUDIE dokládá výhodnost výstavby resp. renovace IS, potom se zavádí projekt. Předmětem projektu jsou především zbývající fáze vybraného životního cyklu, klasifikace provedených prací ( síť činností ), jejich množství, kvalita, doba, spotřeba práce, nároky na zdroje a kritické cesty ve vývoji produktů. To vše musí být provedeno v souladu s kvalifikovanými odhady, které jsou založeny na již známých metrikách. Činnostní metriky jsou jakési vztahy, založené na různých parametrech ukazující vliv zvoleného prostředí na dobu trvání jistého kroku.

- 21

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I Některé metriky jsou definovány slovně, jiné s použitím formálního aparátu. Metriky se buď čerpají z jiných projektů anebo se při tvorbě IS vytvářejí. Jednotkou pro tyto metriky jsou obvykle člověkohodiny spotřebované průměrným pracovníkem na vytvoření daného produktu v požadované kvalitě. Např. již víme, že softwarové inženýrství nám poskytuje dost metrik na měření tvorby programů ( může být orientováno na různá vývojová prostředí ). Pomocí metriky se s ohledem na kvalitu parametrů ( máme-li jen průměrné vývojáře resp.podstatně kvalitnější ) dokáže odhadnout kolik by daný krok nebo úkon měl trvat. Metriky jimiž se měří kvalita produktů jsou založeny na rčení „produkt je kvalitní, vyhovuje-li stanoveným požadavkům“. Požadavky se prověřují na základě speciálních metod. Kvalita dílčích produktů a výsledného IS musí být plánována, sledována a zaznamenávána.V souladu s touto myšlenkou byla v SE definována i kvalita-korektnost programu ( program je kvalitní-korektní, splňuje-li to co bylo zamýšleno ). Samozřejmě program není jediným typem produktu. Metrika na obecný produkt může zahrnovat např. • náklady, • použitý materiál ( zdroje ), • soulad se zavedenými standardy, • spolehlivost, • a další… INFORMAČNÍ INŽENÝRSTVÍ Informační inženýrství ( Information Engineering IE ) je pojem který vznikl asi na začátku 80. let. Často se otcovství přisuzuje informatikovi James Martinovi viz [MA89]. Informační inženýrství je J. Martinem definováno jako : Aplikace vnitřně uzavřené množiny formálních strukturovaných postupů-metod, technik a prostředků pro informační plánování, analýzu, návrh a konstrukci IS na široké podnikové bázi, nebo pro hlavní sektory podniku. Jinými slovy se tyto postupy, techniky a prostředky používají pro naplnění úkolů informačního plánování, analýzy a konstrukce IS. Aplikují se na podnik jako celek resp. na jeho hlavní části-zájmové oblasti ( Business Area ). Cílem informačního inženýrství ( dále jen IE ) je vytvořit pomocí těchto nástrojů informační model podniku. To je obvykle skupina modelů, přičemž každý z nich je tvořen podle předem navržených pravidel. Jednotlivé modely mohou být strukturovány-fragmentovány např. podle zájmových oblastí, do jednodušších a přehlednějších fragmentů : • • • • • • •

model důležitých míst podniku a datových vazeb mezi nimi, model stěžejných dat a vazeb mezi nimi, model zájmových oblastí a datových vazeb mezi nimi, detailní model dat za každou zájmovou oblast detailní model zpracování a toků dat v každé zájmové oblasti, model programového vybavení IS, model struktury IS a rozmístění jeho částí,… - 22

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I Fragmentace má převažující výhody zejména v přehlednosti, čitelnosti modelů a snadné postupové orientaci. Pochopitelně, rozklady SHORA-DOLŮ prvků jednotlivých modelů do nižších úrovní jsou rovněž svázány s existujícími formálními pravidly. Tato budou uváděna u jednotlivých modelů. V IE se výrazně projevuje několik myšlenkových směrů. Jeden ze směrů v IE považuje data za „srdce“ IS (informatik J. Martin ). Z toho se pak vyvozuje, že IS musí především zabezpečit zásadní povinnosti vůči datům, tj. jejich vytváření, bezpečné udržování, manipulování s nimi a bezrizikovou distribuci. Tato myšlenka je doprovázena hypotézou, že data jsou nejstabilnější složkou IS, tedy IS je datově orientovaný ( Data driven - datově poháněný ). Metoda přístupu, jak víme je označována jako MIE- Martin Information Engineering. Druhý směr považuje za hlavní právě aktivity podniku ( často se mluví o procesech nebo nejnižších funkcích ) a provádí jejich důslednou strukturalizaci na oblasti aktivit, na skupiny aktivit a na samotné aktivity ( informatik E. Yourdon ). Pomocí tohoto přístupu se IS modeluje jako seskupení vzájemně souvisících procesů a funkcí propojených datovými toky. IS je orientován procesně ( Process Oriented ). Tato metoda je označována jako SA- Structured Analysis. Často se k tomuto přístupu přidává událostní řízení. Podstatou je to, že každá aktivita IS je vyvolána tzv. událostí ( vnitřní, vnější ). Systém musí tedy na každou událost reagovat svojí aktivitou. Proto se v diagramu aktivit označují ty procesy nebo funkce, ( tzv. událostní vstupy ), kde reakce na události začínají. Takové IS jsou orientovány událostně ( Event driven ). Třetí směr se snaží komplexně využít výhod obou předešlých směrů a takové IS mají vyváženou orientaci ( Balance Orientation ). Tomuto pojetí vyhovuje Yourdonem upravená metoda SA s plně uplatněným konceptem událostního modelování, označovaná později jako MSA- Modern Structured Method. Z uvedeného je zřejmé, že IE je pružná disciplina reagující na skutečnou povahu podniku. DATA

Funkční pohled

FUNKCE

podnik

Obrázek 11: Vztah funkcí, dat a událostí Událostní řízení

Datový pohled UDÁLOSTI

Jelikož podnik je velmi složitá realita, nutno předpokládat, že metody, techniky a prostředky IE, používané v informačním plánování, analýze a konstrukci IS jsou náročné pro provádění s tužkou v ruce a bez jejich realizaci na automatizačních prostředcích neefektivnímusí tedy být „komputerizovatelné“. Informatici postupně „sprogramovali“ jednotlivé techniky a prostředky, sestavili je do integrovaného celku CASE ( Computer Aided Software Engineering ), který se stal hlavním pomocníkem pro SE a IE při výstavbě IS. V průběhu informačního a procesního zkoumání vybraného podniku buduje IE vědomostní bázi ( repository-encyclopedia ) o zmíněném podniku. Do této báze se ukládají veškeré poznatky k nimž se zkoumáním podniku dospělo. Často se o této bázi mluví jako o metasystému, tj. systému jenž obsahuje popis jiného systému.

- 23

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I Zkoumání podniku je v IE vtěsnáno do předepsaného rámce, který je nazýván životním cyklem IS. Životní cyklus je členěn na fáze z nichž každá má své specifické poslání. Jejich celkovým cílem je ukázat jak může komputerizace podnikových aktivit se zpracováním dat pomoct dosažení strategických cílů podniku. Dále můžeme říct, že IE nejen umožňuje aby IS byl budován progresivně s maximálním využitím možností informačních a komunikačních technologií ale také formuje obsah všech složek celkové architektury IS. Na základě životního cyklu, k němuž se přidá filosofická báze, může být vypracován přesný předpis-metodika. Tento předpis pak říká PROČ se ta nebo ona aktivita v IE nebo SE má dělat ( filosofie ), CO ( metoda ) se má dělat a KDY ( časový harmonogram ) se to má dělat a JAK ( technika ) a ČÍM ( nástroj ) se to má dělat. Metodika je tedy návod plně pokrývající celou tvorbu IS a je pak hlavním vodítkem pro tvůrce IS. V metodikách dochází k použití řady manipulačních a myšlenkových prvků- metod, technik a nástrojů. Všechny tyto prvky jsou "komputerizovány" v CASE, který je buď s metodologií silně svázán ( podporuje jen to co je v metodologii ) anebo je obecný a vhodný pro podporu více metodologií. Teď si stručně vysvětlíme význam důležitých pojmů : metoda........................je myšlenkový postup, odpovídající na otázku CO je potřeba udělat v dané fázi vývoje IS. Metoda může být zatížena přístupem, který se v IE používá. Metoda Michael A. Jacksona, označovaná jako „Jackson Systém Programming- JSP“ byla používána v SE k návrhu programu z hlediska zpracování dat. Metoda téhož autora „Jackson Systém Development-JSD“ je již používána k vývoji programových systémů. Metoda „Yourdon Structured Analysis-SA“ se používá v IE a je základem druhého myšlenkového směru. Metoda „Martin Information Engineering-MIE“ je základem prvního myšlenkového směru v IE. technika......................je tvořena předepsanými kroky odpovídající otázce JAK docílit požadovaný výsledek. Např. pro datové modelování se používá technika tvorby Entity Relationship Diagram-ERD zavedená informatikem Chenem. Podobně je známá technika procesního modelování vedoucí k Data Flow Diagram-DFD. Technika normalizace datového modelu pomocí sémantické algebry nad atributy entit je používána k snížení redundance a zabezpečení přijatelně rychle probíhající aktualizace dat. nástroj ........................je prostředek ukazující ČÍM a který budeme používat k zápisuvyjádření aktivity jisté techniky. Nástroj dokonce umožňuje danou techniku vůbec použít. Příkladem nástrojů jsou prvky a celé diagramy ERD, DFD, Structure Diagram-SD, State DiagramSTD,....Elementární nástroje jsou obvykle dále nedělitelná primitiva. metoda 1 technika 1

technika n

nástroj

nástroj

metoda m

metodologie

- 24

Obrázek 10: Vztah metodologie, metody, techniky a nástroje


MODELY "KOMPUTERIZACE" PODNIKU Každý podnik u něhož je zpracování informace náročné na čas a zkušenosti zaměstnanců musí přikročit k využití jedné z vhodných informačních a komunikačních technologií. ICT pomůže podniku získat přehled ve zpracování informace a provádět operace nad daty a distribuci dat v přijatelné době. Poněvadž je tato skutečnost téměř nutnou podmínkou dosažení strategických cílů středních a větších podniků, je vždy zavedení ICT věnována značná pozornost. Zaváděním ICT do podniku se obvykle zabývají specializované firmy. Zavedení v sobě zahrnuje : • odprodej ICT podniku, • instalaci ICT, • zaškolení zaměstnanců ve využití ICT. Je naprosto zřejmé, že tvůrci informačních a komunikačních technologií a prodejci by měli být dostatečně obeznámeni s problematikou podniků řešenou v organizačním inženýrství. Jistě jsou rovněž obeznámeni s problematikou modelů komputerizace podniků tj.s uplatňováním ICT za účelem podpory pro dosažení jejich strategických cílů, aby mohli managerům podniku doporučit tu nejvhodnější ICT. Na druhé straně je pro podnik výhodné jestliže management podniku je s těmito modely obeznámen také. Jelikož jsou ICT klasického podniku prezentovány v jeho informačním systému, jsou modely komputerizace vlastně vývojovými modely IS. Je pochopitelné, že softwarová firma používá jinou ICT než klasický podnik. Její strategický cíl je specifický-tvorba informačních technologií a k tomu potřebuje i specifickou vývojovou ICT ( databázovou technologii s distribucí dat, technologii prostředků CASE,…). Modely komputerizace podniků začaly vznikat v průběhu 70-tých let. Vývoj modelů vždy reagoval na převratné změny v informačních technologiích. První takovou změnou bylo opuštění technologie zpracování izolovaných souborů a přechod na databázovou technologii zpracování dat. Druhou takovou změnou byla integrace databázové technologie s komunikační technologií s vytvořením lokálních a globálních počítačových sítí. Proto se za nejvyšší stupeň komputerizace podniku považuje distribuovaná integrace. V informatice se nejvíce uznávají tři modely komputerizace podniku : • model, který zavedl R. L. Nolan v roce 1979, reaguje na zavedení databázové technologie zpracování dat, • model autorů J. L. Mac Kenney, F.W. Mc Farlan, se zabývá vnořením nových IT do stávajícího IS, • model navržený kolektivem v jehož čele stál S. L. Huff . Cílem všech těchto modelů je dát návod pro zavádění IT a zjištění konečného efektu zavedení IT z hlediska strategických cílů podniku. Každý model člení komputerizaci podniku do fází, přičemž fáze obsahuje CO se má udělat, JAK se to má udělat a KRITÉRIÁ jimiž se ověřuje naplnění obsahu fáze. Všechny poznatky o komputerizaci podniku poukazují na zásadní roli jeho managementu. Ten musí zvážit jak nejrychleji dostat podnik na nejvyšší úroveň DISTRIBUOVANÉ INTEGRACE , co to bude stát a kdy se náklady vrátí. Klasický, strukturovaný přístup k modelování reality chápe obě stránky objektu reality „relativně“ samostatně. To spočívá v tom, že informační podstata je vyjmuta z objektu - 25

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I a dostává pojmenování entita, pracuje se sní samostatně a místo o objektech se mluví jen o entitách. Pokud se chce mluvit o entitách v podobném smyslu jako kategorie objektů používá se termín entita-typ ( nebo typová entita ) Entita -typ má vlastně výskyty-instance. Podobně se vyjímají procedury a pojmenovávají se jako obecné procesy nebo nižší funkce. Toto rozdělení ale neznamená, že se nehledí na neustálou bezespornost ( konzistenci ) mezi entitami a procesy / transakcemi nad nimi, které mění hodnoty jejich atributů. Laicky řečeno, jestliže máme celkem 20 různých entit v informačních vztazích, potom by procesy/funkce měli zpracovávat právě je a ne jiné entity. Často probíhá zkoumání entit a procesů paralelně. Na rozdíl od strukturované analýzy chápe se objekt v objektovém přístupu jako celistvý, nedělitelný prvek reality. Je to odlišný pohled, proto i způsob modelování aktivit objektů a jejich informačních vztahů je jiný než v strukturované analýze. Souhrnem tedy můžeme říci, že entity reprezentují celková data v podniku a procesy a transakce zase celkové aktivity. Rozmanitost dat a aktivit vyžaduje uplatnění strukturálního pohledu již na nejvyšší úrovni modelování podniku. Myslí se tím kontextový rozklad podniku na jednotlivé dílčí celky ( Business area ), které vystupují ve vzájemných souvislostech. Každý takový celek je množinou těsně souvisících procesů a dat, které se analyzují vždy dohromady. Tato kontextová analýza začíná u stanovení dílčích zájmových oblastí – subjektů zájmu a specifikací jejich osobitých dat a aktivit. Vznik zájmových oblastí-subjektů může být evokován buď strukturální výstavbou podniku, nebo členěním jeho oblastí aktivit. Zájmová oblast obvykle přebírá název velké skupiny aktivit jaksi k sobě náležících např. tím, že zpracovávají pouze uzavřenou množinu entit. Příkladem takových zájmových oblastí-subjektů u ekonomických systémů může být např. „personalistika, finance a účtování, skladová evidence, reklama, konstrukce, výroba“, ...... Vojenské systémy zpracování informace mají obvykle specifické zájmové oblasti, např. „ logistika, výcvik, řízení a velení,.....Dílčí subjekty zájmu umožní později dočasně omezit šíři prováděné datové a funkční analýzy. Na druhé straně se jistě nezapomene na to, že mohou existovat informační vztahy mezi dvěma entitami z různých zájmových oblastí a že podobně mohou na sebe navazovat i procesy. Vedle toho může nastat ještě složitější situace, když analýza další zájmové oblasti vyvolá značné změny ve výsledcích analýzy jedné nebo více předchozích zájmových oblastí.

- 26


Konstrukce

Účetnictví Data a aktivity

vazby

Data a aktivity

Data a aktivity

Personalistika Data a aktivity Data a aktivity Řízení výroby Řízení skladů

Obrázek 12: Typické zájmové oblasti v kontextové analýze podniku

Následující obrázek ilustruje jednu z nejznámějších strukturovaných metodik SSADM.

- 27


Popis podniku

ÚVODNÍ STUDIE

ANALÝZA

HRUBÝ a DETAILNÍ

IMPLEMENTACE

NÁVRH Provozní dokumentace

Specifikace Datová analýza Procesní analýza Analýza aktivit Funkční a transakční analýza Interakční analýza

….. přechod mezi fázemi a přenos výsledků ….. přechod mezi komponentami fáze .…. detailizace přenosu výsledků

Obrázek 13: Struktura metodiky SSADM.

Následující obrázek je kontextovým diagramem vesnické knihovny.

- 28


Čtenář Čtenář

Obj ed. l ís te Ob k , st j orno M ed. lí s e tek lís zik tek n .o /st bj o rn ed Objednání knihy o .

Katalogový / předmětový lístek

Mezik. objednávky

Ob je d . lís /+ tek sto +an r no o Ob jed . lí s te k

Výdej knih

Požadavek +Zařazení

Knihovní sklad

Kata

líste

Vrácení knihy

Př e d

obj ed. Pe Leg lístek na i /p liz tim r od Evidence čtenářů . l ace lou íst Zá žen p. Pla ek í lís tba Me t zik ek Pr n. od v ob lo u rá jed ce že . lí ní ní ste an ka o/ Čtenář no sto Čtenář Stav knih /sto r no rno

Penalizace

Nákup a zařazení knih

m. Př ed

Katalogy Katalogy

Zápůjční lístek

k

k líste log .

Ob je dn ávk a kn Dod ih ací l is t, fakt u ra nab íd ky

Jiná Jiná knihovna knihovna

Vydavatelství Vydavatelství

Obrázek 14: Kontextový diagram knihovny beletrie.

ZÁKLADY VYVÁŽENÉ ORIENTACE NA DATA A AKTIVITY Filosofie přístupu. Přístup k modelované realitě se realizuje ve třech rovinách-přiblížení : • • •

kontextové konceptuální technologické

používá se ve fázi ÚVODNÍ STUDIE, ANALÝZA, NÁVRH, IMPLEMENTACE.

Každá z uvedených rovin-přiblížení má za úkol převést odpovídající modelování reality do specifického modelu : • kontextová do kontextového diagramu, • konceptuální esenciálního - logického modelu ( často se přidává i kontextový diagram ),

•

technologická

technologického modelu.

Kontextová rovina. V této rovině se zavádí nejvyšší abstrakce reality ( viz 2.5.3 ) a realita se považuje za jeden celek ke kterému se definují následující základní atributy : • členění na dílčí subjekty3 a jejich účel zavedení, • členění dílčích subjektů na místa zpracování informace a tok informace mezi nimi. 3

dílčí celky na které je realita členěna ( podle organizační struktury, nebo podle oblastí aktivit )

- 29

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I Konceptuální rovina. Úkolem je podat podstatu-esenci-logiku zpracování informace bez implementačních detailů ( realizace BD, procesů, funkcí, reakcí na události, koncepce počítačového prostředí, rozmístění techniky, lidí,…), která je poměrně trvalá. Tato rovina je nejvhodnější pro interview s uživatelem. ESENCIÁLNÍ MODEL

IS

Model prostředí

Model chování

Kontextový diagram

ERD diagram a konceptuální model dat

Seznam událostí

DFD, diagramy transakcí, životní cykly entit

STD diagramy ( pro systémy závislé na čase )

Stručný popis účelu modelovaného IS

Slovník dat ( Data Dictionary, DD )

Obrázek 15: Struktura esenciálního modelu IS. Ačkoliv každý z dílčích modelů vznikne na základě odlišného pohledu na modelovanou realitu, jsou mezi nimi silné souvislosti. Existuje vážné nebezpečí existence mnohých rozporů, z nichž některé mohou znehodnocovat dosažené výsledky v modelování. Jestliže je ale celý proces modelování podepřen použitím prostředku CASE, pak on je obvykle schopen automaticky mnoho nekonzistencí mezi modely indikovat. Vzájemné souvislosti modelů dostatečně vystihuje následující obrázek. ERD

DD

Typické souvislosti :

DFD

Diagramy transakcí, ELH

STD

DFD

DD

DFD

Transakce, ELH

Transakce, ELH

DFD

DD

Transakce, ELH

DFD

ERD ERD DFD

DD

DFD DFD

Transakce, ELH STD

Obrázek 16: Vzájemné souvislosti modelů. Technologická rovina. Cílem roviny je z logického modelu vytvořit technologický model, implementačně závislý na prostředí do něhož bude IS zasazen. Patří sem i převod esenciálního pojetí do relačně-síťového prostředí. Toto uplatnění se v široké míře dotýká ERD modelu, který se upravuje do nejvhodnější normální formy databázových struktur4 a to vyvolá i dodatečné 4

databázová struktura ( teoretický pojem ) je prvek množiny nad níž je postavena Coddova algebra

- 30

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I úpravy DFD diagramu. Základem úprav jsou výsledky sémantické analýzy vzájemných vztahů mezi všemi atributy téže entity. Některé závislosti mezi atributy vyžadují provést rozklad entity na dvě resp. více entit, pro které musíme hledat nové informační vazby na okolí ( úprava ERD ) a způsoby zpracování ( úprava DFD ). Za základní prvky v diskutovaném vyváženém přístupu se považují : • • • •

zvolená metoda, techniky, nástroje-prostředky a produkty.

Za zvolenou metodu vybereme upravený „základ metody MSA“ s uplatněním metody událostí. Metoda událostí umožní přijatelně fragmentovat jinak rozsáhlý a po subjektech členěný DFD. Ve vývoji informačního systému, který může probíhat podle zevšeobecněného ŽC, se v rámci plnění úkolů jednotlivých fází používají zejména tyto osvědčené techniky : • • • • •

technika tvorby kontextového diagramu, technika tvorby ERD….. koncipovaná informatikem Chenem, technika tvorby DFD…..zavedená informatikem De Marco a postupně upravená v 80. létech, technika normalizace ERD podle sémantické algebry do požadovaných normálních forem…..vynucená praxí fyzické reprezentace bází dat, technika tvorby ELH ( Entity Life History-životní cyklus entity )…..vynucená praxí v interakční analýze jako odstraňování možné nekonzistentnosti mezi ERD a DFD. Za produkty se považují :

kontextový diagram, seznamy oblastí aktivit, dílčích aktivit, událostí, ERD, DFD, popis účelu IS, specifikace transakcí, ELH diagramy, STD diagramy, slovník dat , … jako výsledky stanovených aktivit jednotlivých fází, které jsou prováděny vybranou metodou a za použití předepsaných technik a nástrojů. Metoda musí obsahovat vzorové popisy všech produktů. Produkty jsou obvykle vytvářeny pomocí nástrojů počítačové podpory ( CASE, DBS, programovací systémy ).

Přístup vyvážené orientace klade hlavní důraz na pokud možno souběžný postup v datové analýze ( viz kap.3 ) a analýze aktivit ( viz kap.4 ), přičemž by obě analýzy měly být konfrontovány prostřednictvím třetí, tzv. interakční analýzy.

Závěr. Text uvádí přehled základních poznatků z informatiky, softwarového a informačního inženýrství, týkajících se projektování a vývoje IS ( složitý programový systém, směry v SE, projektování a vývoj, interdisciplinární pojetí vývoje, … ). TEXT se nezabývá organizačním inženýrstvím. Pro pochopení současné orientace SE jsou uvedeny definice a vlastnosti jednoduchého programu a složitého programového systému. Diskuse informačního inženýrství je orientována na roli dat a aktivit v zájmové oblasti a filosofii modelování jejich samostatné nebo koexistenční role. Pro strukturovaný přístup byla použita jako vzor filosofie metody MSA ( Yourdonova bible pro strukturovaný přístup ).

- 31


2.5 Styly životních cyklů vývoje software a dalších komponent pro IS Životní cyklus IS (Life Cycle) je prostředkem II pro řízení vývojových prací. Jde tedy o širší chápání vývoje než jen vývoje software IS, přesněji aplikačního software. Životní cyklus software je obvykle členěn na fáze v nichž se provádí přesně vymezené činnosti, stanovené metodikou, pomocí různých metod, technik a nástrojů. Obsah jednotlivých fází je tedy řízen metodikou, která dává odpověď na dotazy CO, KDE, KDY a JAK. Při řízení fází obvykle výsledky předchozí fáze vstupují do fáze následující a také se ukládají do vědomostní báze. Styl životního cyklu je buď těsně svázán s jistým myšlenkovým směrem v Informačním inženýrství anebo je obecný a nezávislý. Jiný životní cyklus navrhuje E. Yourdon a jiný J. Martin, představitelé dvou známých směrů v Informačním inženýrství. Následující přehled uvádí často používané styly životních cyklů: I. II. III. IV. V.

vodopádový, fontánový, spirálovitý, síťový a prototypový

Obecně můžeme styly životních cyklů charakterizovat podle toho, jakým způsobem umožňují vývoj aplikačního software IS. Vodopádový ŽC Typické ŽC jsou tzv. „vodopádové-kaskádovité“, které předpokládají, že další fáze je zahájena jen tehdy až je předchozí plně ukončena a její výsledky schváleny uživatelem. Často se nárůst poznatků od fáze předchozí k fázi následující zobrazuje „pyramidálně“ s postupem shora dolů. POPIS STÁVAJÍCÍHO SYSTÉMU ZPRACOVÁNÍ INFORMACE

úvodní studie-předprojektová příprava plánování

analýza

analýza

návrh návrh

im plem entace

implementace a testování zavedení

d ata

a k tiv

ity

Obrázek 17 : Vodopádový životní cyklus a pyramidální uspořádání fází životního cyklu.

Fontánový životní cyklus Je to cyklus, který přímo předepisuje povinný návrat z dořešené fáze do fáze předchozí s opravou a upřesněním poznatků v ní.

- 32

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I zavádění implementace návrh analýza

popis

Obrázek 18 : Fontánový životní cyklus Přírůstkový ŽC Dalším typem jsou tzv. přírůstkové ŽC, které umožní tvorbu aplikačního software IS po částech. To ale obvykle znamená, že fázemi můžeme projít několikrát Opětovným průchodem libovolnou fází vzniká nárůst nových poznatků. Průchod je často organizován spirálovitě. Jde tedy o postupné vylepšování získaného řešení. U spirálovitého životního cyklu je názorně využit jeden z principů SE „iterativní přístup“ k tvorbě programů resp. složitých programových systémů. analýza posouzení verze IS uživatelem

návrh

získané verze IS implementace

praktický provoz dané verze testování

Obrázek 19 : Spirálovitý životní cyklus

Síťový životní cyklus Je navržen informatikem E. Yourdonem v knize [YO88]. Tento životní cyklus předpokládá možnost paralelního provádění některých fází, případně dílčích kroků některých fází. Je tvořen z 9 činností a 3 koncových prvků jimiž jsou : I. II. III.

uživatel, řídící orgán, obsluha

Uživatel: např. zákazník, klient, prostě osoba, která platí za systém. Rozhodující vlastnost: jen on může systém po dokončení přijmout. Jen on může rozhodnout, zda je systém vhodný a zda bude zahrnut do existujících obchodních operací. Na to mají významný vliv testy přijatelnosti. - 33

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I Existují 3 druhy uživatelů, kteří přicházejí do styku se systémem během jeho plánování, vývoje a aktivního provozování. Je užitečné si určit tři odlišné třídy uživatelů, kteří se setkají s projekčním týmem budujícím systém: Strategický uživatel: zajímá ho především zisk a dlouhodobá návratnost investic. Je to obvykle vedoucí provozního oddělení, např. ekonomický náměstek nebo viceprezident, a ovlivňuje tvorbu zejména úvodní studie (činnost 1.) a prvních částí systémové analýzy (činnost 2.). Taktický uživatel: osoba, která dohlíží na provádění každodenních operací v určité části organizace a řídí se rozpočtem. Tato osoba má obvykle velmi dobrý přehled o každodenní práce ve své části organizace, přesto by neměla být důvěrně seznámena s prováděcími podrobnostmi na nižší úrovni. Taktický uživatel obvykle dohlíží na nejméně jednoho úředníka a zabývá se tím, aby vývoj nového systému neměl vliv na práci jeho podřízených. Proto bude systémový analytik často slyšet výkřik taktického uživatele: “Nehovořte s mými lidmi, jsou velmi zaneprázdněni! Já vám řeknu vše, co potřebujete vědět o jejich práci!”. Provozní uživatel: úředník či administrativní osoba, která se stále častěji objevuje v moderních organizacích. Tato osoba bude se systémem v největším kontaktu, jakmile bude systém v provozu. V systémech on-line jsou pro tuto osobu nejdůležitější dialogy člověka s počítačem a chybové zprávy. Řídící orgán: stejně jako pro termín uživatel může být i zde široké spektrum významů. V některých případech je uživatel a řídicí orgán jedno a totéž. Stejně tak dobře se může ukázat, že je to strategický uživatel. V některých případech může tento termín znamenat vyšší autoritu výkonný výbor, řídící výbor nebo dokonce správní radu složenou z ředitelů. V kontextu této knihy [YO88] se jedná o osobu (nebo skupinu osob), která schvaluje financování projektu a dává organizační omezení. Obsluha (operátoři) termín může mít opět řadu významů. V případě malého samostatného minipočítačového nebo mikropočítačového systému může být uživatel také operátorem. Ve většině případů je užitečné obsluhu a uživatele odlišovat, pak je obsluhou osoba nebo skupina osob zodpovědná za každodenní práci HW a SW při provozování systému. Ve velké většině ekonomických projektů bude nový systém pracovat, společně s desítkami dalších systémů, na počítači řízeném centralizovanou skupinou (ačkoli počítač sám může být decentralizován). Proto náš postup pro tvorbu systémů by měl zobrazovat toto vzájemné působení a projekční tým by měl být na to připraven. Tyto tři prvky- uživatelé, řídicí orgán a obsluha - vzájemně působí přes 9 činností.

- 34

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I procedure description

user manual

7 users

system requirements

operations

8

operational restriction

user policy

design specification

survey

1

converted database

installation

design

3

project character

tentative cost / benefit report

database conversion

existing database

design specification

9

analysis complements

2

structured specification

implementation

management

4 cost / benefit report

accepted system

integrated system

acceptance test generation 5

installed system quality assurance test set

quality assurance

6

Obrázek 20 : Strukturovaný síťový životní cyklus E. Yourdona

Povězme si to nejnutnější o jednotlivých fázích.

Úvodní studie ( survey ) . tato činnost je také známá pod názvem úvodní projekt nebo projektový úkol. Typicky začíná, když uživatel požaduje aby jedna nebo více činností v jeho organizaci byla automatizována. Hlavním účelem průzkumu je určení aktuálních nedostatků ve stávajícím systému, stanovení nových cílů, rozhodnutí, zda je automatizace proveditelná a pokud ano, pak navrhnout několik přijatelných variant. A konečně - připravit projektový úkol, který bude použitý jako průvodce v ostatních činnostech projektu. Analýza ( analysis ). Hlavním účelem analýzy je převedení jejich dvou hlavních vstupů - uživatelských zásad a projektového úkolu na strukturovanou specifikaci. Analýza obsahuje modelování uživatelského prostředí pomocí diagramů datových toků DFD, datového modelu ERD, stavového diagramu STD. Návrh ( design ). Návrh se zabývá rozvržením jednotlivých částí specifikace (známé také pod pojmem “esenciální model”) vhodným zpracovatelům (procesory CPU anebo lidé) a příslušných úloh (nebo prací, nebo sekcí, atd.) ke každému procesoru - zpracovateli. V rámci každé úlohy se činnost při návrhu zabývá vývojem vhodné hierarchie programových modulů a rozhraní mezi těmito moduly tak, aby se implementovala specifikace vytvořená v činnosti 2.-Analýza. Implementace ( implementation ). Tato činnost zahrnuje jak kódování (programování), tak také postupnou integraci modulů do úplné kostry celého systému. Proto se v této činnosti používá jak strukturované programování, tak také implementace metodou shora dolů.

- 35

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I Generování testů přijatelnosti (acceptance test generation). Strukturovaná specifikace by měla obsahovat všechny informace nezbytné pro definování přijatelného systému z hlediska uživatele. Jakmile tedy byla specifikace vytvořena, může být na jejím základě zahájena činnost generování sady testů přijatelnosti. Tato činnost se někdy také nazývá konečné testování nebo testování přijatelnosti. Činnost vyžaduje jako svůj vstup množinu testovacích dat vytvořenou v části 5.-Generování testů přijatelnosti a integrovaný systém vytvořený v části 4.-Implementace. Popis postupu ( procedure description ). Jednou z důležitých činností, která se musí provést, je vytvoření formálního popisu částí nového systému, které se budou provádět manuálně, stejně jako popisu, jak budou uživatelé spolupracovat s automatizovanou částí nového systému. Výsledkem této činnosti je provozní a uživatelská dokumentace. Úprava databáze ( database conversion ). U některých projektů představuje úprava databáze více práce (a více strategického plánování) než vlastní vývoj počítačových programů pro nový systém. V jiných případech není třeba existující databázi vůbec upravovat. Všeobecně řečeno, tato činnost vyžaduje jako svůj vstup aktuálně užívanou uživatelskou databázi a detailní specifikaci návrhu vytvořenou v části 3.-Návrh. Uvedení do provozu ( installation ). Poslední částí je instalace a uvedení do provozu. Vstupy do této části jsou provozní a uživatelská dokumentace vytvořená v části 7., databáze upravená v části 8. a přijatý systém vytvořený v části 6. V některých případech může instalace jednoduše znamenat přechod na nový systém přes noc, bez nějakého vzruchu či oslavných fanfár. V jiných případech může instalace a uvedení do provozu představovat postupný proces, kdy jedna skupina uživatelů (nebo jednotlivá pracovní místa) po druhé dostávají provozní a uživatelskou dokumentaci, výpočetní techniku a absolvují školení ohledně provozu nového systému. Životní cyklus E. Yourdona je speciální diagram datových toků. Jinými slovy, síť datových toků propojujících jednotlivé činnosti znamená, že několik činností může probíhat paralelně. Proto hovoříme raději o činnostech, a nikoli o fázích. Fáze zpravidla označuje v projektu omezený časový úsek, po který ona probíhá. Ještě musíme zvýraznit jednu skutečnost. Diagram datových toků nezobrazuje explicitně zpětnou vazbu, ani řízení. Prakticky každá činnost může poskytovat informace, a obvykle to také dělá, které mohou vhodně měnit jednu nebo více předchozích činností. Proto např. část návrhu může poskytovat informace, které mohou upravit zprávu o nákladech a přínosech, která byla vytvořena v části 2.-Analýza. Skutečně, vědomosti získané v části návrhu mohou dokonce změnit předchozí rozhodnutí z hlediska základní proveditelnosti projektu. V krajních případech mohou určité události v kterékoli části způsobit náhlé ukončení projektu. Vstupní údaje řídicího orgánu jsou zobrazeny pouze pro činnost analýzy, protože jen pro ni jsou určitá data nezbytná. Avšak předpokládá se, že řídicí orgán má vliv nad vykonáváním všech činností. Jinak řečeno, diagram pouze zobrazuje nezbytné vstupy a výstupy pro všechny činnosti. Posloupnost činností může být ovlivněna do určité míry přítomností nebo absencí dat, která umožňují nebo neumožňují zahájení příslušné další činnosti.

Prototypový životní cyklus (Prototyping Life Cycle) vyjadřuje skutečnost, že řešitel a uživatel vyberou počáteční ( nejdůležitější ) přiměřeně náročnou část systému a provedou se na ní všechny fáze konče implementací. Vzniká tak práce schopný model, který simuluje vybrané aktivity systému. Mezitím dochází k vytvoření nového modelu a předešlý se zahazuje. Pochopitelně, takový postup ( s rychlým vývojem modelů ) vyžaduje i schopné vývojové prostředky, jako : • • • •

Generátory obrazovek, Neprocedurální tvůrce výstupních sestav, Neprocedurální SQL, 4GL jazyky,………..

Koncem 80. let mnoho informatiků předpokládalo nástup prototypvání až s příchodem schopných vývojových prostředí. Ne každý požadovaný IS lze výhodně budovat pomocí

- 36

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I prototypování. Vedle toho může použití prototypování „nahrávat“ i situace samotného uživatele. Často se uvádí, že pro uplatnění prototypování je vhodný takový rozsáhlý systém : • jehož uživatel je neschopen nebo neochoten zkoumat takové abstrakce jako je DFD a ERD, nechce čekat na rozsáhlý a časově náročný průzkum všech dat a aktivit systému, ale chce mít „něco „ fungujícího, • jehož uživatel není schopen specifikovat v žádné formě své požadavky na IS, • který nevyžaduje specifikaci velkého množství algoritmů pro dosažení potřebných výstupů informace a je převážně interaktivní.

feasibility

guidelines

Rigorous specification approach

Good candidat

Identify basic needs

preliminary design

Develop working model Clean up prototype And document

Demo in context solicit refinement and extensions

Implement revisions/ enhancements

Impact on prototype

Prototype done

Detail component needed

Rigorous specification components

Obrázek 21 : Prototypový životní cyklus.

Jaké jsou výhody a nevýhody uváděných stylů životních cyklů ? Vodopádový životní cyklus dává dostatečný čas pro důkladné splnění úkolů každé fáze, tj. ke schválení výsledků uživatelem dojde až tenkrát, když odpovídají realitě a jeho požadavkům na cílový-žádaný IS. Tato „důkladnost“ do jisté míry zabezpečuje, že je málo omylů a tedy i málo vynucených návratů z jedné fáze do fáze předchozí. Na druhé straně, vodopádový životní cyklus je zdlouhavý a uživatel-zadavatel nemá dlouhou dobu ani malou fungující část aplikačního software IS.

- 37

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I Přírůstkový životní cyklus může rychle přinést fungující prototyp IS. Prototyp obvykle zahrnuje provedení úkolů jednotlivých fází jen nad vybranou částí podniku nejčastěji klíčovou. Na druhé straně může provedení fází pro další část podniku vyvolat revizi předchozích poznatků. a provedení oprav může být nákladné. Tato rizika rostou s růstem složitosti IS. Síťový životní cyklus dovolí provádět paralelně některé činnosti nebo fáze. Fontánový životní cyklus umožní poopravit předchozí fázi na základě výsledků z fáze předchozí. Prototypový životní cyklus sice velmi rychle přináší fungující část IS, ale další prototyp nemusí z předchozího příliš využívat, což vede ke ztrátám. Poznámka. Každá fáze životního cyklu má pochopitelně ještě jemné členění. Rovněž zde není udržovaná jednotnost. Stačí když např. uvedeme různé typy analýz uváděných ve fázi ANALÝZA : • • • • • •

datová analýza dávající dohromady entity a jejich vztahy, vede na ERD diagram, procesní analýza zkoumající procesy, funkce a vede na jejich zápisy a vyjádření v DFD diagramu funkční analýza vede ke zkoumání funkcí systému, událostí, jejich následnosti a povahy a transakcí, které se v událostech provádí nad entitami, stavová analýza vede ke zkoumání stavů systému a končí STD diagramem, analýza života entit-interakční analýza navazuje na událostní analýzu a ukazuje jakými stavy každá entita prochází při jejím zpracování v událostech a jejich transakcích a končí konstrukcí ELH pro každou entitu, relační-normalizační analýza zkoumá sémantické závislosti mezi atributy téže entity a vede k sestrojení potřebných normálních forem entity ( 3NF resp. 4NF ).

Na základě životního cyklu je konstruována tzv. metodologie pro tvorbu IS. Je-li životní cyklus teoretická záležitost, je metodologie filosoficko-praktickým návodem jak IS sestrojit. Metodologie na rozdíl od životního cyklu vybírá k použití zcela konkrétní metody, techniky a nástroje. Podobně tak činí pro měření a prověřování výsledků jednotlivých fází. Pro vybrané metody, techniky a prostředky metodologie se obvykle konstruuje počítačová podpora, často zabudovaná v přiřazeném CASE prostředku.

2.6 Současné trendy softwarového inženýrství Pochopitelně, rozvoj SWI přinesl mnoho významného do vývojářské práce programátorů. Jsou to trendy, které obsahují:

skvělé postupy propracovaného projektového řízení a organizovanéhoinženýrského vývoje software, tzv. metodiky, mnohé nové nástroje vývojáře komputerízující náročné sestavování kódu, nové způsoby měření vývojářské práce a kvality software, nové komponentové a vrstvové pohledy na architekturu software.

V první řadě musíme říct, že pohledy na jednoduchý program a SPS jsou neměnné, ale hledají se účinnější a rychlejší způsoby jejich vývoje co možná s maximální podporou automatizačních nástrojů.

- 38

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I V současné době vystupují ve vývoji software do popředí následující trendy v moderních metodikách. Jde o novější metodiky vývojové práce na software, vznikající v 90. létech. Tyto metodiky vylepšují nejen strukturovaný přístup, ale silně se dotýkají nově se prosazujícího objektového přístupu. Pokrytí problematiky vývoje software je u těchto metodik poněkud širší. Jde tedy i o problematiku těsně souvisící s psaním kódu. Mezi nejznámější z těchto metodik patří: Rational Unified Process …..objektová metodika firmy Rational Unified Software Development Method Agilní metodiky pro rychlý a flexibilní vývoj aplikací: o Adaptive Software development o Feature-driven Development o Extreme programming o Lean Development o Scrum Development Process o Crystal Methodologies

2.7 ARCHITEKTURA SOFTWARE Prozkoumání pohledů na strukturu software začalo velmi intenzivně začátkem 90. let. Ačkoliv se naznalo, že modulární programování prakticky a formálně dosáhlo značných úspěchů, přesto vznikly nové pohledy, které rozšířily jeho možnosti, jelikož povýšily strukturu na architekturu. Zájmem nových pohledů se staly především SPS. Samotné členění SPS na podsystémy a jejich komponenty bylo doprovázeno silnou formalizací a stanovením pravidel, pomocí kterých se definovala nejenom struktura SPS, komponenty, ale i vlastní spolupráce samotných komponent. Komponentové pojetí bylo doprovázeno snahou o zavedení distribuovanosti (komponenty mohou být lokalizovány na různých zdrojích) a návrhem reálných komponentových architektur. Jak se komponenta vůbec chápala? Definice 3 Softwarová komponenta je softwarový element, který se může s jinými komponentami skládat podle definovaného kompozičního standardu a který může být lokalizován na mnoha serverech a distribuován do cílového místa použití. Komponentová technologie umožní téměř doslova realizovat inženýrský přístup k vývoji software: Skládat software z předpřipravených komponent, znovu používat komponenty bez jakéhokoliv omezení (každé použití je novou instancí dané komponenty), přizpůsobovat komponenty s možností vytvoření komponent s novou funkcionalitou, využívat možností několika rozhraní, které komponenta nabízí (rozhraní je základem využití komponentové technologie). Mezi nejznámější komponentové technologie patří: COM / DCOM /COM+ …společnosti Microsoft CORBA Component Model … společnosti OMG JavaBeans a Enterprise Java Beans ….společnost SUN

- 39

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I o Test-driven Development O všech těchto metodikách pojednává publikace (Kadlec, 2005).

2.8 Metrologie software, normy, metriky a provoz software Definice 3 Metrika ρ je konkrétně stanovená metoda měření vlastností V jisté entity E (vztahu, jevu, procesu, SW aplikace, prostředí, …), se stanoveným rozsahem R výsledků měření. Metoda měření vlastností entity E může být postavena na použití několika ukazatelů kvality a kvantity. Jejich stanovení, verbální nebo numerické, vlastně determinuje měření vlastností entity E. Jelikož se metrika může orientovat na měření kvantity nebo kvality vlastností V entity E, je možné z toho vyvodit jejich první členění. Obecně je snahou formovat kvalitativní a kvantitativní metriky pro tutéž entitu jako konzistentní nástroje. Zavedení metrik je objektivní nutností, protože dávají možnost ohodnocovat vztahy, jevy, procesy, SW aplikace, prostředí, … Metriky Vývojářské metriky (SW metriky): Skupina softwarových metrik definovaných normami ISO 9126-1, 9126-2 a 9126-3 Funkčnost, Přiměřenost, Přesnost, Bezpečnost, Shoda funkčnosti, Bezporuchovost, Použitelnost, Účinnost, Udržovatelnost a Přenositelnost Technické požadavky Softwarové metriky outsourcingu: Dostupnost Doba odezvy Bezpečnost

Zaměření SW – Quality Measurement

SW – Outsourcing Quality Measurement

VÝVOJÁŘSKÉ METRIKY (SW METRIKY) SW metriky jsou dostatečně popsány v normách ISO 9126-1,2,3. Některé z metrik, např. SOFTWAROVÉ METRIKY OUTSOURCINGU Tyto metriky se týkají měření základních vlastností libovolného software, které je provozováno v režimu Application Service Providing, tj. v pronájmu se vzdáleným poskytováním aplikací mimo server zákazníka. Metriky. První dvě metriky, tj. Dostupnost a Doba odezvy software vychází z měření některých vlastností software v režimu outsourcingu. U třetí metriky Bezpečnost a spolehlivost systémových a uživatelských dat v eLearningovém prostředí provedeme obecný rozbor zahrnující i použití outsourcingu.

- 40

Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Softwarové inženýrství I DOSTUPNOST software: Jednou z nejdůležitějších uživatelských metrik je Dostupnost komponent software. Pochopitelně, uživatel žádá, aby mu bylo software maximálně dostupné (např. celých 24 hodin za den). Za předpokladů, že personální počítač je lokálním serverem na kterém je nainstalováno celé software (je zanedbán vliv přenosové cesty), potom můžeme vyslovit pojetí metriky Dostupnost a formálně popsat kvalitativní ukazatel jednoduchou formulí. Formule bude platná i tenkrát, když outsourcingový poskytovatel garantuje rovněž přenosovou cestu (dostupnost se potom měří až u zákazníka). Definice 4 Dostupnost software je doba t, měřená vůči rozsahu T a vyjádřena v procentech, v jejimž průběhu je prostředí uživateli k dispozici. Nejvýkonnější je software pro které je t = T , to ale není z mnoha důvodů možné. Pro t < T je nedostupnost v procentech potom dána vztahem D=

100t T

……………………………..

(1)

a procentová nedostupnost zase vztahem 100-D . Velmi užitečná je následující tabulka hodnot. Nedostupnost v Nedostupnost v % min/den 1 14,4 5 72 10 144

Nedostupnost v hod/týden 1,68 8,4 16,8

Je-li ts doba spotřebovaná přenosovou cestou (když ji outsourcingový poskytovatel negarantuje), potom je pro výpočet použitelná jednoduchá modifikace vztahu (1) ve formě D=

100(t − tS ) . T

Změření času ts je ale problematické, protože je nutné měření jak u zákazníka tak i na provozním serveru. Některé drobné problémy uživatele vyplývají přímo z outsourcingu, když jeho nájemce dává záruku jen za dostupnost provozního serveru a software. Jinými slovy, garanci přenosové cesty dává poskytovatel připojení. Situace je jiná, když tyto dva subjekty (poskytovatel software a poskytovatel přenosové cesty) splynou. DOBA odezvy software: Je to metrika, která měří za jakou časovou dobu t se přihlásí s výsledkem některá z komponent software poté, co ji vyzveme k činnosti, tj. dáme požadavek na její běh a čekáme odpověď. Požadovanou odpověď od provozního serveru dostane tenký klient prostřednictvím lokálního serveru organizace a může ji zobrazit. Souvislosti mezi komponentami a dobou odezvy mů žeme podat pomocí množinových

výrazů. Buď n ∈ ℕ přirozené číslo, ℝ a K jsou množiny reálných čísel a komponent

- 41


elearningového prostředí. K  je počet komponent. Doba odezvy t je definována následujícím předpisem t: K x ℕ → ℝ . Prů měrnou dobu odezvy t můžeme potom zadat vztahem

∑ t (k , n)

, kde k∈ K je komponenta a n počet uživatelů , kteří ji právě používají. K Uveďme teď jiný pohled na dobu t odezvy komponenty software. Uvažujme dvě přenosové cesty a stejné SW u obou serverů - lokálním (v dané organizaci) a provozním (v organizaci poskytující software outsourcingově). Požadavek a odpověď jako takové "letí" po dvou přenosových cestách a tyto doby ts1 a ts2 musíme uvažovat. Vedle toho musíme uvažovat další doby které se podílí na součtu

t=

k ∈K

t = 2(ts1 + ts2) + (tSW1 + tSW2) + tk + tp) , tj.

… (2)

tSW ....... doba za kterou SW serveru pochopí požadavek a vydá pokyn k hledání vstupní stránky komponenty a zpracuje výsledek hledání u sebe, tk ......... doba práce komponenty, tp ......... doba práce prohlížeče, ukončená prezentací odpovědi v HTML/DHTML stránce.

ts2

tp

lokální server

provozní server místo měření

ts1 tk Tenký klient SW serveru

tSW1,2

eLearningové prostředí doba, za kterou se spustí komponenta, je zanedbatelná vzhledem k ts1, 2 a tSW1, 2

Obrázek 22: Outsourcing software se dvěma přenosovými cestami.

Obecně je doba odezvy závislá na několika parametrech: 1. Přenosová rychlost c. Je-li cesta ke komponentám software přes několik serverů , potom je nutno uvažovat vlivy parciálních rychlostí přenosu. Může být ovšem rychlost konstantní a potom tento parametr není potřeba uvažovat. 2. Typ Tv výzvy, která je dána pomocí typu požadaveku. Je pochopitelné, že pomocí požadavku je v té či oné komponentě spuštěna jistá operace. Její nároky na zpracování dat jsou specifické a projeví se přímo v době za kterou je dána odpověď ( to je zabudováno v tSW ). 3. Orientace To komponenty na typ obsluhy výzvy Tv. Komponenta mů že pracovat stylem "co nejkratší reakční doba" pro vybrané uživatele, anebo tento styl není

- 42


uplatňován. 4. Počet n klientů formulujících požadavek na komponentu. Dotazovaná komponenta je na provozním serveru uložena pouze jednou ve více přístupné formě. Pozornost komponenty jednotlivým klientům se střídá a fyzicky není spojitá ani pro jednoho z nich. Pochopitelně, doba odezvy se tím pro jednotlivé uživatele prodlužuje. 5. Výkonnost V týkající se HW a SW provozního serveru a uživatelského počítače. Posouzení HW není obtížné, výkonnost je na komponentách uvedena. SW provozního serveru je obvykle optimalizován pro jistý počet uživatelů (např. databázový stroj, překladače skriptových jazyků , …). Výkonnost je ale pro všechny komponenty konstantní a nemusíme ji uvažovat. Definice 5 Doba odezvy libovolné komponenty software je doba t, měřená od okamžiku podání požadavku do doby získání odpovědi. Tato doba je závislá na mnoha parametrech, proto píšeme t = f(n, Tv, To). Předpokládáme-li dvě přenosové cesty a stejný SW na obou serverech, můžeme uvést pro t následující formuli t = 2(ts1 + ts2) + (tSW1 + tSW2) + tk + tp).

"Obecně zákazníci očekávají, že doba odezvy nebude delší než u stejných aplikací neprovozovaných formou EEP".

Proto je potřebné si na provozním serveru organizace (tedy s jedinou přenosovou cestou ) změřit doby odezev jednotlivých komponent u více typů eLearningového prostředí a průměry použít za metrikové hodnoty pro nově vyvíjené prostředí.

Definice 6 Bezpečnost je metrika založená na následujících kvalitativních požadavcích-ukazatelích, které musí být zabezpečeny: 1. DŮVĚRNOST KOMUNIKACE MEZI SPS A KLIENTEM, 2. INTEGRITA DAT VE SPS, 3. AUTORIZACE A AUTENTIZACE DAT (PRÁVA MANIPULACE S DATY), 4. OCHRANA TOKŮ DAT VE SPS, 5. OCHRANA TOKŮ DAT VNĚ SPS, 6. OCHRANA RELEVANTNÍCH DAT SPS v BD.

2.9 Charakteristické rysy vývojových prostředí 2.10 Teoretické směry softwarového inženýrství

- 43


2.10.1

Teorie programů

2.10.2

Verifikace programů

2.10.3

Teorie formálních jazyků

- 44

2 SWI JAKO DISCIPLINA TVORBY PROGRAMŮ

Recommend Documents