Vývoj informačních systémů

Transkript

1 Předmět Garant: Autor: doc. Ing. Alena Buchalcevová, Ph.D doc. Ing. Alena Buchalcevová, Ph.D Studijní zátěž Prezenční studium Počet kreditů Počet výukových hodin podle počtu kreditů Počet výukových kontaktních hodin Počet výukových hodin samostudia Počet časových hodin samostudia Semestr Týden ,5 Kombinované studium Počet kreditů Počet výukových hodin podle počtu kreditů Počet výukových kontaktních hodin Počet výukových hodin samostudia Počet časových hodin samostudia Semestr Výuka v blocích tři x 4 bloky za semestr

2 Obsah Úvod Disciplína Softwarové inženýrství Strukturovaný přístup k vývoji Strukturované programování Strukturovaná analýza a návrh Objektový přístup k vývoji Objektově orientované programování Objektově orientovaná analýza a návrh Komponentový vývoj Vývoj orientovaný na služby Fáze vývoje informačního systému Příprava plánu projektu Specifikace požadavků Analýza Podrobný popis případů užití Návrh tříd a jejich odpovědností Vytvoření analytického diagramu tříd Vytvoření sekvenčních diagramů pro vybrané případy užití Definování testů Návrh Systémový návrh Objektový návrh Implementace Testování programového systému Postup procesu testování Metodiky budování IS/ICT Agilní metodiky

3 Úvod Úvod Předmět je zařazen jako povinný předmět v 6. semestru bakalářského studia oboru Informační technologie. Úvod do předmětu Cílem předmětu je získat přehled o procesu vývoje informačního systému, seznámit posluchače s postupy a metodami potřebnými pro všechny pracovníky, kteří se podílejí na výběru, vývoji či provozu informačních systémů. Po absolvování předmětu posluchači získají potřebný nadhled a zkušenosti, které mohou uplatnit jako manažer, systémový analytik, návrhář či správce informačních systémů, s důrazem na objektový design. Z předmětu se získává zápočet a zkouška. Zápočet student získá za zpracování a obhájení semestrální práce na zadané téma. Zkouška je písemná s ústní obhajobou. Práce s doporučenou literaturou Pro studium předmětu je doporučena následující literatura. Základní knihou je monografie: BRUCKNER, Tomáš, VOŘÍŠEK, Jiří, BUCHALCEVOVÁ, Alena, STANOVSKÁ, Iva, CHLAPEK, Dušan, ŘEPA, Václav. Tvorba informačních systémů. 1. vyd. Praha : Grada Publishing, s. ISBN Knihu je možné půjčit v knihovně BIVŠ nebo koupit v knihkupectvích. Další užitečnou knihou je: BUCHALCEVOVÁ, Alena. Metodiky budování informačních systémů. Oeconomica ISBN Tuto knihu lze získat přes e-shop nakladatelství Oeconomica BUCHALCEVOVÁ, Alena, STANOVSKÁ, Iva. Příklady modelů analýzy a návrhu aplikace v UML. Praha Oeconomica Tuto knihu lze získat přes e-shop nakladatelství Oeconomica Jak pracovat s touto publikací Studijní opora slouží především pro potřeby samostudia v kombinovaném studiu. Předmět je v kombinovaném studiu obvykle rozdělen do třech přednáškových bloků, z nichž každý je dále rozdělen do třech částí oddělených dvěma krátkými přestávkami. Každé této části zhruba odpovídá kapitola tohoto materiálu. V úvodu každé kapitoly je student seznámen s důležitostí problematiky dané kapitoly a to nejen v návaznosti na studium na Bankovním Institutu Vysoké Škole. Jsou mu předloženy cíle, kterých by měl student při studiu kapitoly dosáhnout. Každá kapitola se snaží představit praktické využití probírané látky. Závěrem každé kapitoly je její shrnutí a kontrolní a testové otázky, jejichž odpovědi jsou uvedené v dodatku

4 Tato studijní opora je formátována tak, aby měl student možnost si do ní vpisovat stručné poznámky. Pro lepší orientaci jsou opakující se a důležité pasáže kapitol označeny následujícími piktogramy: - 4 -

5 C L 1. Disciplína Softwarové inženýrství Cíle kapitoly: vymezit disciplínu Softwarové inženýrství, ukázat současný stav v této oblasti Doporučená literatura: Autor Název Vzdavatel a rok vydání Bruckner a kol Tvorba informačních systémů Praha:Grada Publishing, 2012 Strany doporuče ného textu Softwarové inženýrství disciplína počítačové vědy zaměřená na vývoj velkých softwarových systémů zahrnuje o technologické aspekty vytváření SW systémů (modelování, implementace, testování) o aspekty řízení ( vedení týmů, plánování ) představuje používání systematického, kvantifikovatelného přístupu k vývoji, provozování a údržbě softwaru Úspěšnost projektů vývoje informačních systémů není uspokojivá. Společnost Standish Group realizuje již od roku 1985 v rámci projektu CHAOS průzkumy zaměřené na zjištění příčin úspěchu či neúspěchu softwarových projektů. Souhrnné výsledky za období 12 let jsou prezentovány a analyzovány v [JOHNSON, 2006]. Graf na obrázku 6-1 ukazuje úspěšnost softwarových projektů v období Úspěšnost projektu je definována jako splnění 3 kritérií projekt dokončen včas, dle rozpočtu a se všemi specifikovanými funkcemi. Z grafu je patrné, že úspěšnost softwarových projektů se ve srovnání s rokem 1994 zvyšuje, přesto v roce 2004 bylo plně úspěšných jen 29 % softwarových projektů

6 Obrázek 1: Výsledek projektů v letech (zdroj: [JOHNSON, 2006]) Společnost Standish Group definovala na základě výsledků průzkumů projektu CHAOS deset kritických faktorů úspěchu projektu. Hlavní příčinou neúspěchu projektů je podle respondentů nedostatečné zapojení uživatelů do projektu. Hned na dalších místech je podpora vedení a jasné byznys cíle. V posledních letech se objevuje mezi kritickými faktory úspěchu optimalizace rozsahu projektu, která je základem agilních metod a explicitně jsou jmenovány i agilní procesy. Na dalších místech jsou zkušenosti s řízením projektu, dostupnost kvalifikovaných pracovníků, formální metodika a nástroje [JOHNSON, 2006]. Vývoj disciplíny softwarové inženýrství koncem 60.let - strukturovaný přístup počátek SW inženýrství objektově orientovaný přístup - nastupují novou éru softwarového inženýrství komponentový vývoj vývoj orientovaný na služby, SOA - 6 -

7 2.Strukturovaný přístup k vývoji C 2. Strukturovaný přístup k vývoji Cíle kapitoly: pochopit základní principy strukturovaného programování a strukturované analýzy a návrhu, naučit se používat techniky strukturované analýzy a návrhu, zejména DFD L Doporučená literatura: Autor Název Vzdavatel a rok vydání Bruckner a kol Řepa Václav Tvorba informačních systémů Analýza a návrh informačních systémů Praha:Grada Publishing, 2012 Praha: Ekopress, 1999 Strany doporuče ného textu Paradigma strukturovaného přístupu vzniklo nejprve v oblasti programování. Později se tento myšlenkový přístup rozšířil i do oblasti analýzy a návrhu systému Strukturované programování Strukturované programování je definováno jako technika organizace a kódování počítačových programů, jež využívá hierarchii modulů, kde každý modul má jediný vstupní a výstupní bod a ve kterých je kód postupně vykonáván (bez nepodmíněných odboček do vyšších úrovní hierarchie kódu). Strukturované programování používá tři typy kontroly průběhu kódu: sekvenci, podmínku a iteraci. Výraznými prvky strukturovaně orientovaných programovacích jazyků jsou podprogramy, uživatelsky definované typy, statické a dynamické, globální a lokální proměnné. Jedním z konkrétních přístupů k aplikaci zásad strukturovaného programování je metodika navrhování programů nazvaná po svém tvůrci Jacksonovo strukturované programování (JSP). Přínosem M. Jacksona je kromě návrhu nového znázornění struktury programu (strukturní diagramy) i vytvoření poměrně uceleného návodu, jak z dané specifikace programu odvodit programovou strukturu. Strukturované programování je založeno na třech základních zásadách: Zásada postupu shora dolů (Top - Down, hierarchický rozklad) Spočívá v tom, že každý proces (úloha) se rozkládá od nejvyšší úrovně (tj. úrovně celé úlohy) postupně na struktury podřízené úrovně, z níž každý prvek může být dále rozkládán do struktury další podřízené úrovně atd. Rozklad probíhá do té doby, než dosáhneme přiměřené složitosti úloh. Výsledkem je hierarchická struktura. Všechny prvky na téže úrovni jsou vzájemně nezávislé, vztahy mezi nimi jsou dány typem nadřízené struktury. Zásada používání tří základních řídících struktur - 7 -

8 T1 a d c rc g Alena Buchalcevová Při aplikaci této zásady se vychází ze skutečnosti, že řešení každého problému lze zapsat pomocí tří základních řídících struktur: o sekvence - posloupnost prvků řídící struktury, o selekce - výběr jednoho z prvků řídící struktury, o iterace - opakování prvku řídící struktury, Úloha, jejíž struktura je vyjádřená základními řídícími strukturami, je jednoduchá a má přehlednou stavbu. Zásada závislosti struktury procesu na struktuře dat Tato zásada je formulací zásadního axiomu, že struktura úlohy vyplývá ze srovnání struktur vstupních a výstupních dat, tedy ze srovnání požadavků na výstup s možnostmi vstupu Strukturovaná analýza a návrh Strukturovaný přístup se z programování rozšířil i do oblasti analýzy systému. Moderní strukturovaná analýza (Modern Structured Analysis) Edwarda Yourdona publikovaná v roce 1989 je jednou z prvních ucelených metodik analýzy systému, jejímž základem jsou modely znázorněné pomocí diagramů datových toků (data flow diagrams), které postihují podstatné procesy v systému spolu se vstupy, výstupy a datovými úložišti. Ve fázi návrhu pak mluvíme o strukturovaném návrhu (Yourdon a Constantine), jehož výsledkem je návrh modulární struktury programového systému. Pro návrh programových systémů vznikla celá řada metod, které, stejně jako ostatní metody tvorby IS, zahrnují doporučený postup, činnosti a kroky postupu, doporučené techniky a nástroje. Většina metod definuje i vlastnosti dobrého programového systému a dává návod, jak z konceptuální, implementačně i technologicky nezávislé funkční specifikace systému odvodit strukturu programového systému. Podstanou vlastností strukturovaných přístupů je oddělení pohledu na funkce systému a na data systému. Většina strukturovaných metod se snaží tento problém řešit definicí různě složitých pravidel pro zajištění konzistence obou pohledů. Funkční modelování Datové modelování KONCEPTUÁLNÍ ÚROVEŇ D E S I G N LOGICKÁ ÚROVEŇ I M P L E M E N T A C E SELECT P.A, P.B FROM P WHERE P.C > FYZICKÁ ÚROVEŇ Obrázek 2: Funkční a datový pohled - 8 -

9 Dále jsou uvedeny základní pojmy a přístupy strukturovaného návrhu programového systému. V současnosti objektového a komponentového vývoje, je následující text popisem nedávné historie, aby byl čtenář schopen rozumět třeba dokumentaci starších systémů. Některé z uvedených principů (hlavně vlastnosti dobrého návrhu) však mají dlouhodobou platnost, nezávisle na právě platném paradigmatu. Bližší popis naleznete v [Repa, 1999]. Vstupy do návrhu SW systému (výsledky analýzy a konceptuálního návrhu IS) Diagramy datových toků Uživateské postupy Specifikace uživatelského rozhraní Návrh databáze Slovník dat Strukturovaný návrh programového systému Výstupy z nárhu SW systému (a zároveň vstupy do implementace) Aktualizovaný slovník dat Logický model dat Specifikace programového systému Modulární struktura (Structured chart) Specifikace modulů (PDL) Popis programových běhů Strategie kódování a testování Obrázek 3: Strukturovaný návrh PS Strukturovaný návrh programového systému lze charakterizovat obrázkem 3. Vstupem do návrhu programového systému je funkční specifikace systému, představovaná například diagramy datových toků odpovídající části systému, popis procedur a ručně řízených postupů, specifikace uživatelského rozhraní, konceptuálním návrhem databáze a specifikací základního SW a HW. Výsledkem je jednak návrh automatizované části informačního systému, který slouží jako zadání pro programování a jednak plán kódování a testování. Kromě návrhu programového systému je nutné souběžně navrhovat logickou strukturu databáze, uživatelské rozhraní systému a řadu dalších záležitostí. Základní prvky a výrazové prostředky strukturovaného návrhu Modul a jeho vlastnosti Modulem se rozumí softwarová jednotka, tedy určitý počet příkazů či instrukcí, jejichž spuštění zajistí provedení určité činnosti - funkčnosti aplikace. Je to relativně samostatná část programového systému, které lze předat řízení a která má tyto vlastnosti: název: jednoznačné pojmenování modulu v rámci programu; vstup: množina údajů (datových a řídících položek), které modul dostává při vyvolání (spuštění), výstup: množina údajů, které modul vrací jako výsledek své činnosti volajícímu modulu, funkci: činnost, která popisuje, co modul provádí, aby zabezpečil transformaci vstupu na výstup, zpracování: vnitřní logika modulu - programový kód, posloupnost příkazů, pomocí které se provádí funkce modulu; zpracování popisuje, jak je prováděna transformace vstupu na výstup, jak jsou zpracovávána data z databáze atd., - 9 -

10 interní data: vlastní pracovní oblasti modulu, jako jsou například pracovní proměnné pro řízení počtu opakování v cyklu apod., na které se neodvolává žádná jiná část programu resp. programového systému, a další vlastnosti, které jsou důležité pro dokumentaci modulu, jako jsou autor modulu, datum vytvoření, datum a autor poslední úpravy, podřízené (volané) moduly. Vstupy, výstupy a funkce představují vnější pohled na modul, zpracování a lokální data představují vnitřní pohled na modul. Externí pohled na modul je předmětem pozornosti právě v etapě návrhu programového systému. Zabývají se jím návrháři (designéři) programových systémů, jejichž hlavní odpovědností je navrhnout, co má programový systém dělat a jaká je jeho optimální struktura. Zatímco vnitřní pohled na modul je spíše záležitostí implementace (vlastního programování, kódování programů) a odpovídají za něj programátoři, kteří na základě popisu funkce programu, potřebných vstupů a výstupů rozhodují o tom, jak modul realizovat. Základní pravidlo modulárního návrhu je: každý modul má pouze jeden vstupní a jeden výstupní bod. To znamená, že modul bude vždy stejným způsobem spuštěn, vždy provede stejné příkazy a vždy má stejné typy vstupů a výstupů. Diagram modulární struktury Nástrojem používaným pro zobrazení modulární struktury programového systému, který je navrhován s využitím strukturovaných metod a technik, byl často diagram modulární struktury tzv. structure chart. Graficky zobrazuje: moduly, hierarchii a organizaci komunikace mezi moduly (jejich vzájemné volání), data a řídící parametry, která si moduly předávají (rozhraní volání). Nezobrazuje vnitřní logiku modulů ani pořadí a počet opakování vzájemného volání

11 DOD-CIS Zjištění údajů pro fakturu EOD CASTKA -ZA-DOD DATUM- FAKTUR CASTKA -ZA-DOD DOD-CIS Tvorba faktury CASTKA -PO-SLEVE SLEVA Zjištění slevy z ceny NOVE-C -FAKT DATUM- FAKTUR SLEVA Přiřazení čísla faktury CASTKA -ZA-DOD NOVE-C -FAKT DATA-FAKTURY Zápis nové faktury do DB Tisk faktury DATUM- DNES DOD-CIS Doplnění údajů o dodávce Čti systémové datum DATUM- FAKTUR DOD-CIS EOD CASTKA -ZA-DOD CH-DOD EOD Čtení a ověření nevyfakturované dodávky s objednávkou DOD-CIS Zjištění částky za položky dodávky CH-DOD DOD-CIS Vypsání chyby do chybového protokolu NOT- FOUND POL- DODAV DOD-CIS DOD-CIS Zjištění typu zákazníka Čtení čísla zákazníka TYP- ZAKAZ ZAK-CIS SLEVA ZAK-CIS TYP- ZAKAZ TYP- ZAKAZ Čtení typu zákazníka CASTKA -ZA-DOD Výpočet částky slevy pro typ zákazníka Procenta slev DATUM FAKTURACE MAX Č-FAKT PROCENTO -SLEVY DATUM- FAKTUR DPH NOVE-C -FAKT OBJ-CIS NOT- FOUND OBJ-CIS Položka dodávky ZAK-CIS Zákazník TYP- ZAKAZ DOD-CIS Faktura Objednávka Dodávka NOT- FOUND Obrázek 4: Structure chart - příklad Spojení (volání) modulů A B Moduly jsou uspořádány do struktury, která vyjadřuje vzájemnou spolupráci a komunikaci, volání modulů resp. předávání řízení. modul A (volající) volá modul B (volaný), modul B po vykonání své funkce vrací řízení modulu A. Neříká se, kolikrát se volání provádí, ani jaká je vnitřní struktura modulu A či modulu B. Komunikace mezi moduly Vyjadřuje předávaná data a řídící informace (signály) předávané mezi moduly (parametry volání)

12 ČTI ÚDAJE O ZÁKAZNÍKOVI Číslo účtu zákazníka Jméno zákazníka Číslo účtu neexistuje NAJDI JMÉNO ZÁKAZNÍKA Při návrhu modulární struktury se popisuje rozhraní modulů, ne počet ani pořadí volání modulů. Grafická podoba programového systému se doplňuje o popis vnitřní logiky jednotlivých modulů specifikaci modulů a popisem všech používaných dat ve slovníku dat. Volání modulu v rámci modulu VOLAJICIHO bude zápis volání modulu ABC, vstupní parametry a výstupní parametry jsou odděleny středníkem, v případě neexistence vstupních parametrů seznam středníkem začíná: CALL ABC (P1 P2, P3) ABC (P1 P2, P3) BEGIN Deklarace modulu ABC (P1 P2, P3) BEGIN (příkazy) END ABC Přístup k databázi FILE - deklaruje data READ, WRITE, DELETE, ADD, UPDATE apod. pro práci s daty Zpracování např. A = A + 1 nebo SET A to 0 apod. V O L A J Í C Í M O D U L P1 P3 P2 A B C Doplňující prvky

13 MODUL (volající) Opakování Modul (opakovaně volá) Databázová tabulka (soubor) Modul Modul Obrazovka MODUL (volaný) MODUL Modul (podmíněně volá) data řídící parametr Podmíněné volání MODUL Modul Modul (podmíněně vyvolaný) V některých notacích se do pro zvýšení názornosti tohoto diagramu přidávaly další prvky, například o symboly vyjadřující opakování, podmíněné volání (podmínka pro volání je ovšem jasná až ze specifikace modulu), databázové tabulky (soubory) a případně i obrazovky (viz obrázek vlevo). Structure chart spolu se specifikací modulů je zadáním pro programátory. Před předáním návrhu k implementaci a programování je třeba ověřit kvalitu a vlastnosti návrhu. Doporučení a kritéria pro hodnocení kvality rozdělení programového systému do jednotek Obecně nelze jednoznačně definovat, co se rozumí dobrým návrhem programového systému, či dobrým programovým systémem. Tato skutečnost závisí na požadavcích, které jsou na aplikaci kladené. Dobrý programový systém může být v jednom případě výsledkem návrhu, kdy je hlavním kritériem úspornost kódu, v jiném případě se může jednat o návrh, který vyžaduje minimum implementace, jindy jím může být co nejvíce udržovatelný systém. U programových systémů s dlouhodobější životností, u kterých se předpokládá, že je bude třeba přizpůsobovat měnícím se podmínkám reality, je poslední zmíněné kritérium pro dobrý návrh jedním z nejdůležitějších. Požadavek na udržovatelnost systému vyplývá z rozložení nákladů na tvorbu a provoz aplikačních systémů. Uvádí se, že 60-80% celkových nákladů na aplikační systémy tvoří právě náklady na jejich údržbu a rozvoj. Programový systém by měl být vybudován tak, aby každá změna byla co nejvíce ohraničená, lokální. Čím jednodušší, průhlednější a pochopitelnější je celková architektura, struktura a stavba systému, tím lépe lze odhadnout dopad případných změn provedených v některé části systému na jiné části systému. Každá programová jednotka, která je součástí systému, by měla být co nejvíce soudržná, což znamená, že všechny její interní součásti by měly mít mezi sebou velmi těsné logické vazby. Zároveň by programové jednotky měly být co nejméně provázané mezi sebou. Spřaženost je mírou nezávislosti programových jednotek. Čím méně jsou jednotky vzájemně spřažené, tím jednodušeji se systém přizpůsobuje a udržuje. Soudržnost (cohesion) a spřaženost (coupling) je tedy možné považovat za základní měřítka dobrého návrhu programového systému, pokud je cílem vytvořit udržovatelný systém. Obě tyto charakteristiky jsou aplikovatelné jak v případě strukturovaného, tak v případě objektového přístupu k návrhu programového systému. Na první pohled by se mohlo zdát, že u objektového

14 přístupu ztrácí toto téma smysl, jelikož při objektovém návrhu je jaksi přirozené, že se systém vzhledem k zapouzdření funkcí a dat bude dobře udržovat. Nicméně v objektově orientovaném systému může být kvalita návrhu značně ovlivněna uplatněním dědičnosti. Soudržnost Soudržnost programové jednotky (modulu, objektu, komponenty) je mírou těsnosti funkčních vztahů mezi prvky v rámci této jednotky. Prvky se zde rozumí příkazy, skupiny příkazů, deklarace dat nebo předání řízení jiné programové jednotce, tedy jakákoliv část programové jednotky, která provádí nějakou činnost nebo definuje data. Programová jednotka by měla realizovat jednu logickou funkci systému. Všechny prvky programové jednotky by se měly podílet na této realizaci a na ničem jiném. Pokud programová jednotka obsahuje i prvky, které se nepodílejí na realizaci příslušné funkce (například se tyto prvky podílejí na funkcích, které se pouze náhodou provádějí ve stejnou dobu, ale jinak s realizovanou funkcí nijak nesouvisejí), jedná se o malou míru soudržnosti. Spřaženost Spřaženost indikuje sílu či těsnost závislosti mezi programovými jednotkami navzájem. Je to míra možnosti, že se chyba v jedné programové jednotce projeví jako chyba v jiné programové jednotce, nebo že se změna v jedné programové jednotce projeví jako chyba v jiné programové jednotce nebo že vyvolá nutnost změny v jiné jednotce. Cílem návrhu programového systému by mělo být vytvořit takový systém, jehož programové jednotky na sobě nezávisí či téměř nezávisí. Jako základní pravidlo platí, že moduly jsou spřaženy těsně tehdy, pokud sdílejí stejné proměnné nebo pokud si předávají řídící informace (jedna jednotka řídí činnost druhé). Slabá spřaženost je taková, kdy je reprezentace dat spravována uvnitř programové jednotky a datové rozhraní této jednotky s ostatními jednotkami je zajišťováno výlučně prostřednictvím předáváním parametrů. V případě, že je nutné některá data sdílet, protože implementační prostředí to jinak neumožňuje, je nutné toto sdílení přísně řídit. S Shrnutí Strukturovaný přístup k vývoji IS je již historií, ale mnohé principy a postupy se uplatnují i v současnosti. Kontrolní otázky a náměty: 1. Charakterizujte principy strukturovaného programování 2. Jaký je účel techniky Diagram datových toků C 3. Objektový přístup k vývoji Cíle kapitoly: pochopit základní principy objektově orientovaného programování a objektově orientované analýzy a návrhu

15 3. Objektový přístup k vývoji L Doporučená literatura: Autor Název Vzdavatel a rok vydání Bruckner a kol BUCHALCEVOVÁ, Alena, STANOVSKÁ, Iva Tvorba informačních systémů Příklady modelů analýzy a návrhu aplikace v UML Praha:Grada Publishing, 2012 Praha Oeconomica Strany doporuče ného textu Od začátku 90 let se stále více hovoří o objektově orientovaném programování, objektovém přístupu, objektech a komponentách. V čem je podstata objektového přístupu a proč vůbec vznikl? Vývoj SW strukturovaným způsobem byl nesporným přínosem. Přesto se začaly projevovat nedostatky tohoto paradigmatu, zejména oddělení dat a funkcí v systému. Data a funkce jsou v programech odděleny na rozdíl od objektů v reálném světě. Proto je třeba i při tvorbě software neoddělovat data od funkcí, které s nimi pracují. A to je základní myšlenkou objektově orientovaného přístupu. Tento přístup vznikl nejprve v programování, ale postupně se rozšířil i do analýzy a návrhu systému, kde v dnešní době převažuje Objektově orientované programování Základní myšlenky objektově orientovaného programování (OOP) byly použity již v jazyce SIMULA 67, masového rozšíření se však dočkaly až v 80. letech, zejména díky Turbo Pascalu verze 5.5. a verze 6.0 s aplikační knihovnou Turbo Vision. Pascal je příkladem hybridního objektového jazyka, do kterého byly objektové rysy přidány až následně. Příkladem čistého objektového jazyka je Smalltalk. V roce 1986 vzniká hybridní objektový jazyk C++. V roce 1995 přišla firma Borland s novým vizuálním vývojovým prostředím Delphi, které si u vývojářů získalo velkou oblibu. Toto vývojové prostředí je založeno na jazyce Object Pascal, který vychází z Borland Pascalu 7.0 a obsahuje některá objektová rozšíření. V roce 1996 vzniká nový čistě objektový jazyk Java, jehož význam roste zejména při tvorbě internetových aplikací. OOP představuje nový logický přístup k vytváření programu. Základem tohoto přístupu je snaha o abstrakci problému a znovupoužitelnost kódu. Objekt si můžeme představit jako černou skříňku. Objekty navzájem komunikují, posílají si zprávy. Každý objekt má přípustné pouze určité zprávy, které jsou definovány v rozhraní objektu. Rozhraní určuje, jaké požadavky může daný objekt uspokojit. Aby bylo možné požadavek uspokojit, musí existovat programový kód (metoda), který danou činnost vykoná. Tento kód včetně ukrytých dat tvoří implementaci. Každý objekt má svou identitu a objekty jsou navzájem rozlišitelné. Každý objekt má určité vlastnosti, které nazýváme atributy, určité chování, které je reprezentováno metodami objektu, a má určité vztahy s jinými objekty. Objektově orientované programování je charakterizováno těmito základními vlastnostmi: existence objektů a tříd objektů zapouzdření ( encapsulation )

16 dědičnost ( inheritance ) polymorfismus ( polymorphism ) Abychom nemuseli při analýze a návrhu modelovat každý objekt zvlášť a při implementaci jej znovu programovat, je zaveden pojem třída objektů. Třída objektů (class) je abstrakcí objektů se stejnými vlastnostmi, stejným chováním a stejnými vztahy k ostatním objektům. Objekty téže třídy mají vždy stejné atributy, ale většinou se liší hodnotami těchto atributů. Objekty téže třídy mají mít stejný sémantický význam. Každý objekt zná svou třídu. Řada objektově orientovaných jazyků umí určit třídu za běhu programu. Seskupení objektů do tříd představuje velmi účelnou abstrakci problému, která nám umožňuje modelovat třídy a tím určovat atributy a chování všech objektů těchto tříd. Třída je jakási forma (šablona), podle které se vytvářejí objekty. Pokud vytváříme nový objekt, stačí uvést, do jaké třídy patří, a tím jsou určeny jeho vlastnosti i chování. Zapouzdření (encapsulation) je technika softwarového návrhu, při které jsou data a funkce s nimi pracující spojeny do jediné entity. Data objektu jsou skryta před ostatními objekty a lze k nim přistupovat pouze pomocí metod objektu. To má několik podstatných výhod: data jsou chráněna před narušením zvenku, ostatní objekty nemusí znát vnitřní strukturu dat, realizace změny v datech je mnohem jednodušší, protože se projeví jen v jedné třídě. Zapouzdření je nejdůležitějším principem objektového přístupu. Některé objektově orientované jazyky (například Object Pascal) zavádějí do své syntaxe vlastnosti (property). Vlastnosti představují zapouzdření atributů objektů. Jedná se o soukromé proměnné, které ve své definici mají přímo definovány metody pro nastavení a čtení hodnot z těchto proměnných. Dědičnost představuje znovupoužitelnost na úrovni deklarace třídy. Pokud chceme vytvořit novou třídu, která má podobné vlastnosti jako existující třída, můžeme využít mechanismu dědičnosti a tuto třídu odvodit z existující třídy. Třída, od které odvozujeme, se nazývá bázová, rodičovská, nadtřída, třída předka. Třída odvozená se nazývá podtřída, dceřinná třída, třída potomka. Třída rodičovská obsahuje definici všech charakteristických vlastností a chování, které jsou sdíleny všemi odvozenými třídami. Odvozená třída obsahuje všechny datové položky třídy předka (přestože soukromé položky jsou ukryty a jsou nedostupné), a kopíruje rozhraní třídy předka. To znamená, že zprávy, které můžeme posílat objektům třídy předka, můžeme posílat i objektům potomka. Vzhledem k tomu, že typ třídy rozeznáváme podle zpráv, které jí můžeme posílat, je odvozená třída stejného typu jako výchozí třída. Objekty odvozené třídy dědí i chování třídy výchozí. Chceme-li, aby nová třída měla jiné chování, máme dvě možnosti: přidat nové metody, změnit metody oproti rodičovské třídě (překrytí, předefinování metody, overriding). Polymorfismus představuje určitý druh abstrakce, kdy abstrahujeme od implementačních rozdílů a zaměřujeme se na stejný způsob používání objektů. Jedná se o zjednodušení zejména pro uživatele objektů, kteří s nimi mohou zacházet stejným způsobem. Objekty různých tříd mají metodu se stejným jménem, přičemž její implementace se v jednotlivých třídách může lišit

17 3.2. Objektově orientovaná analýza a návrh S nástupem objektové orientace vznikly různé metodiky objektové analýzy a návrhu systému (Coad-Yourdon, OMT - Rumbaugh, Booch, OOSE- Jacobson, OOMT). Tyto metodiky používaly různou notaci pro vyjádření prvků návrhu. Pro výrobce CASE nástrojů bylo problematické zvolit notaci, kterou budou podporovat. Proto firma Rational Software Corporation povolala 3 nejvýznamnější představitele objektově orientovaných metodik (Grady Booch, Jim Rumbaugh, Ivar Jacobson), kteří se spojili a společně vypracovali jednotnou notaci nazvanou UML (Unified Modelling Language), která byla poprvé publikována v roce Popis UML naleznete v [Bruckner a kol., 2012]. Cílem objektově orientované analýzy je zkoumat existující objekty, zda mohou být znovupoužity a nebo přizpůsobeny novému použití, a definovat objekty nové. Jde o objekty věcné oblasti, které se nazývají entitní objekty (entity object). V rámci objektově orientovaného návrhu pokračujeme v zpřesňování návrhu entitních objektů a definujeme nové objekty, které slouží realizaci systému. Jedná se jednak o objekty rozhraní (interface object), jejichž prostřednictvím bude uživatel komunikovat se systémem a také řídící objekty (control object), které drží aplikační logiku. Toto rozdělení objektů v systému definoval Ivar Jacobson a je obdobné mechanismu používanému ve Smalltalku, který je nazýván Model-view-controller (MVC). Výše uvedený mechanismus MVC byl prvním návrhovým vzorem pro objektově orientovaný návrh. Co je podstatou návrhových vzorů? Programátoři často vytvářejí části programů napodobováním jiných programů zkušenějších programátorů. Toto napodobování vyžaduje pochopit vzor kódu a použít jej v programu. Na návrhové vzory je možné pohlížet jako na abstrakci tohoto napodobování. Jinými slovy řečeno návrhové vzory definují množinu pravidel popisujících, jak provést určité úlohy při vývoji SW. Podobně knihy o algoritmech popisují různé vzory algoritmů, které jsou efektivní a prověřené (například různé třídící algoritmy). Návrhové vzory se prosazují s objektovým přístupem, který díky svým vlastnostem jako zapouzdření, dědičnost a polymorfismus umožňuje snadné využívání a modifikaci vzorů Komponentový vývoj Komponentový vývoj (Component based development CBD) je přístup k tvorbě softwaru založený na vytváření softwaru složeného z komponent. Z důvodu určitých specifik komponentového vývoje nejde pouze o druh technologie pro podporu implementace aplikací, ale spíše o celkový přístup k návrhu, implementaci, údržbě aplikace a samozřejmě i řízení projektu. Vzhledem ke znovupoužitelnosti komponent se jedná o koncept, který se týká návrhu a tvorby softwaru v celé firmě a v dlouhodobém horizontu. Stěžejní fází komponentového vývoje je správné rozdělení vytvářeného systému na části (komponenty), které mohou být vytvářeny samostatně. Proces vývoje je potom rozdělen na dvě oblasti úloh. První oblast představuje vývoj klíčových komponent, které lze využít v mnoha aplikacích. Druhou oblastí je tvorba specifických řešení integrací služeb poskytovaných navrženými komponentami

18 Pojem komponenta Pro pojem komponenta neexistuje zatím jediná všeobecně přijímaná definice. Uvedeme některé používané definice: Komponenta IS je typový aplikační software s alespoň elementární funkcionalitou, který je podmnožinou otevřeného IS. Ideální komponenta je komponenta IS, která nemá chyb, nemá analytická či technická omezení, a jejíž pracnost integrace do IS je nákladově zanedbatelná. Petr Maňas, LCS International, a.s. Komponenta je softwarový modul, který v sobě zapouzdřuje určité typické funkční prvky aplikace, jako jsou uživatelské rozhraní, aplikační logika a přístup k datům. Aby byl softwarový modul považován za komponentu, musí splňovat alespoň požadavek zapouzdření a jednoúrovňové dědičnosti, musí obsahovat nějakou smysluplnou funkčnost a musí být schopen určitým definovaným způsobem tuto funkčnost dát k dispozici, tedy musí být schopen komunikovat s jinými komponentami. Petr Karlach, Progress Software, s.r.o. Komponenta je část softwaru, která byla navržena a vytvořena tak, aby ji bylo možné znovupoužít. (RUP) Komponenta je spustitelný kód ve formě *.exe, *.dll, který obsahuje určitou definovanou funkčnost, která je dostupná prostřednictvím definovaného rozhraní. (Microsoft) Komponenta je soudržný SW balík, který může být vyvíjen a dodáván samostatně a obsahuje definovaná rozhraní, prostřednictvím kterých komponenta může poskytovat služby jiným komponentám. Požadavky na komponentu Z výše uvedených definic můžeme odvodit požadavky, které musí komponenta splňovat: Zapouzdření Komponenta zapouzdřuje data a funkčnost, za kterou je zodpovědná. Znovupoužitelnost Znovupoužitelností se myslí opakované použití již napsaného kódu. Je nutné, aby komponenta byla co nejméně závislá na ostatních komponentách. Pro znovupoužitelnost komponent je charakteristický black-box přístup (na rozdíl od tříd). Chci-li použít komponentu, nezajímá mě její vnitřní struktura, ale její rozhraní, které musí být dobře zdokumentováno. Dokumentace Každá komponenta musí být zdokumentována, aby ji bylo možné správně a efektivně používat (klíčová je dokumentace externích rozhraní komponenty). Dokumentace vnitřní struktury je potřeba pro podporu a další vývoj komponenty, nikoli pro znovupoužitelnost. Dokumentaci komponenty je třeba udržovat, aby byla aktuální i při změnách komponenty. Žádoucí je udržovat dokumentaci pro jednotlivé verze komponenty. Parametrizovatelnost Je třeba vytvářet komponenty značně flexibilní, aby jejich chování bylo možné do značné míry parametrizovat. Zde jsou kladeny velké nároky na popis různých (typických) konfigurací komponenty. Standardní rozhraní Chceme-li zajistit jednotnou komunikaci mezi různými komponentami, musí vytvářené komponenty splňovat určitá pravidla. Z výše uvedeného pravidla zapouzdření vyplývá, že funkčnost komponenty je dostupná výhradně prostřednictvím definovaných rozhraní. K zajištění komunikace komponent

19 mezi sebou prostřednictvím jednotné komunikační infrastruktury je nutné zajistit kompatibilitu rozhraní. Binární kompatibilitu rozhraní komponent definují jednotlivé komponentové architektury. Nezávislá testovatelnost Každá komponenta musí být samostatně testovatelná. Použití otestovaných komponent při tvorbě software významně zvyšuje kvalitu a snižuje chybovost software. Některé metodiky požadují, aby součástí komponenty byly i její testovací skripty. Nezávislost na programovacím jazyce Tento požadavek lze realizovat implementací komponenty pro některý z komponentových standardů (COM+, CORBA, EJB) Často je diskutován rozdíl mezi třídou a komponentou. Komponentu i třídu lze znovupoužít. Třída je však většinou značně spjata s implementačním prostředím. Komponenta je zcela zapouzdřená funkčnost, která je zpřístupněna prostřednictvím rozhraní. Komponenta je zpravidla spojena s požadavkem na nezávislost na programovacím jazyce. Přínosy komponentového vývoje Flexibilita a škálovatelnost Software vytvořený z malých částí je snáze modifikovatelný než velké monolitické aplikace. Požadavek na změnu nebo rozšíření funkčnosti lze zrealizovat relativně snadno úpravou jedné nebo několika málo komponent. Zmodifikované komponenty lze vyměnit, aniž bychom museli zasahovat do ostatních částí systému, čímž snížíme riziko zanesení chyb. Využití existujících komponent Máme-li software rozdělen na řadu relativně jednoduchých částí, můžeme se rozhodnout, které komponenty bude firma vyrábět znovu, které si nechá vyrobit jinou firmou a které může znovupoužít, protože byly již vyvinuty na jiném projektu. Využívání již existujících komponent (znovupoužitelných) je nejvýznamnějším aspektem komponentového vývoje. Zvýšení kvality Při tvorbě aplikace jsou používány již samostatně otestované komponenty, což zvyšuje kvalitu výsledného software. Testování jednoduchých komponent je výrazně snazší než testování složité monolitické aplikace. Testování aplikace složené z malých komponent se zužuje především na integrační testy ověřující správnou integraci komponent, případně na testování uživatelského rozhraní. Organizace práce na projektu Rozdělení vytvářeného software na malé části umožňuje snáze rozdělit práci mezi členy týmu, případně mezi více týmů a především přesně definovat zodpovědnost za jednotlivé komponenty a jejich implementaci a testování. Technologický základ komponentového vývoje Mluvíme-li o komponentovém vývoji, můžeme na něj pohlížet ze dvou pohledů: z hlediska technologického se jedná o specifické technologie jako COM, CORBA, J2EE a.net z věcného hlediska jde o vytváření SW v rodinách produktů tvořených z komponent. Technologie, které jsou základem pro komponentový vývoj, se označují jako standardní komponentové architektury a definují způsob komunikace mezi komponentami a pravidla pro implementaci komponent. Komponentová architektura dále definuje infrastrukturu pro řadu služeb, které vytvářené

20 komponenty mohou využívat. Zajišťuje nejen základní služby jako je vytvoření a zrušení instance komponenty, její zpřístupnění v rámci procesu, případně aplikacím v jiném procesu nebo na jiném počítači, ale i řadu dalších služeb. Tvůrce komponenty se pak nemusí starat o implementaci těchto služeb, protože může využívat služeb komponentové infrastruktury, pokud dodrží definovaná pravidla. Jde například o tyto služby: Transparence fyzického umístění komponenty Aplikace vytvořené z komponent jsou často vícevrstvé a pracují buď v různých oddílech paměti (adresních prostorech) na stejném počítači, nebo jsou rozloženy na více počítačů. Klient se serverem komunikují nikoliv přímo, nýbrž pomocí zástupného rozhraní (na obrázku 5 označené jako proxy rozhraní), které poskytují klientovi zdání, že se komponenta nachází na stejném počítači a dokonce v adresním prostoru stejného procesu, zatímco ve skutečnosti může běžet v jiném procesu nebo dokonce na jiném počítači. Proxy objekty obstarávají zabalení parametrů volání instance komponenty (tento proces se nazývá marshalling) a jejich rozbalení na straně serveru a provedení samotného volání služby komponenty. Pokud se instance komponenty nachází v prostoru stejného procesu jako klientský program, je možné využít a také je využit přímý přístup k rozhraní komponenty, jak je naznačeno v pravé části obrázku. Takováto komunikace je mnohem efektivnější díky eliminaci operací marshallingu a unmarshallingu. Pooling instancí komponenty a kontejnery V případě, že ke službám serveru přistupuje více klientů, je vhodné mít možnost obsloužit je současně. Ke splnění tohoto cíle vedou dvě cesty použití více vláken (threadů) v rámci běhu jedné instance komponenty nebo vytvoření více instancí. Vzhledem k tomu, že multithreadový kód musí obsahovat synchronizační prvky, které musí implementovat programátor, je obvykle jednodušší druhé řešení. To spočívá ve vytvoření určitého počtu instancí komponent (eventuelně jejich vytváření podle požadavků až do daného limitu) v životním prostoru kontejneru. Kontejner pak obsluhuje a uchovává jejich stav a přiděluje jejich služby jednotlivým volajícími klientům. Samozřejmě může také nastat situace, kdy počet klientů bude větší než počet komponent a klienti budou své požadavky na obsloužení vznášet víceméně náhodně s poměrně dlouhými prodlevami. V takovém případě je velmi užitečný mechanismus, který uloží stav komponenty vybrané podle určitého algoritmu (může to být např. nejdéle nečinná nebo poslední činná) do operační paměti či na disk a poté nahraje stav jiného klienta a začne jej obsluhovat. Až původně odložený klient obnoví svou činnost, je jeho stav obnoven a k jeho obsluze je přiřazena komponenta, která je v danou chvíli volná. Proces A Klient Proxy - rozhraní Proces B Server - komponenta Proxy Proces C Klient Server - komponenta komunika ční kanál

21 Obrázek 5: Volání služby komponenty klientem Transakční služby Pracuje-li komponenta s daty uloženými v databázi a provádí nad nimi jiné, než pouze triviální čtecí operace, je vhodné, aby komponentová infrastruktura poskytovala služby pro řízení transakcí. Obzvláště důležité je to pro případy, kdy komponenta pracuje nad distribuovanou databází. Scénář práce nad distribuovanou databází je u dnešních velkých systémů poměrně běžný, proto je velmi vhodné, aby jako jedna ze služeb infrastruktury byl také DTC koordinátor distribuovaných transakcí. V praxi je také běžné, že transakci neprovádí pouze jeden objekt (instance komponenty), ale část úkolu práce s databází vykonají asociované objekty. V tom případě je vhodné mít možnost nastavit na úrovni komponent, zda daná komponenta po svém spuštění poběží v nové transakci nebo přebere kontext té, ve které byla vytvořena atd. Zasílání zpráv Server, na kterém komponenty běží nemusí být v každém okamžiku k dispozici z důvodu např. výpadku sítě, havárie, problémů s HW nebo z prostého důvodu nemožnosti stabilního připojení klienta. V takovém případě je nezbytná asynchronní komunikace. Persistence Persistencí rozumíme možnost převést stav komponenty do datového proudu a eventuelně jej uložit na nějaké médium. Persistence komponent je důležitá např. při běhu určitého počtu instancí komponent v poolu. Jestliže zde běží např. komponenta typu nákupní košík, která obsluhuje požadavky klienta v internetovém obchodě, může být prodleva mezi okamžiky, kdy pracuje, dosti dlouhá. Z tohoto důvodu je vhodné mít k dispozici možnost uložit stav komponenty, přidělit její zdroje jinému zájemci o službu a stav nákupního koše původně obsluhovaného klienta při jeho dalším požadavku obnovit z úložiště a jeho obsluhu přidělit právě volné instanci komponenty. Jiným důvodem pro podporu persistence je uložení stavu komponenty pro případ havárie systému. Tento problém se týká pouze stavových komponent, tj. takových, které ve svých atributech uchovávají svůj stav a ten ovlivňuje průběh algoritmu zpracování zadávaných úkolů a na základě výsledku zpracování je opět upravován. Bezpečnost Otázka bezpečnosti je v současné době, kdy jsou ceněny zejména informace a dostupnost služeb, naprosto klíčová. Proto by komponentová infrastruktura měla mít schopnost řídit spouštění a běh instancí komponent na základě přidělených práv, pro volání komponent umístěných na vzdálených strojích použít kryptování komunikace. V otázce bezpečnosti rozlišujeme tři problematické oblasti, které vyžadují ošetření: Enkrypce zakódování komunikace tak, aby nebylo možné zjistit její obsah Autentikace ověření identity klienta, který vyžaduje služby komponenty. Autorizace ověření oprávnění klienta k různým úkonům (na základě znalosti jeho identity z autentikačního procesu)

22 Identita, pod kterou komponenta běží na základě své identity může být komponentě povolen nebo odepřen přístup k různým systémovým či datovým zdrojům, případně ke službám jiných komponent COM+ COM je technologie firmy Microsoft, která vznikla ze standardu OLE (standard sloužící pro předávání grafů a tabulek mezi aplikacemi a dokumenty). COM+ definuje binární standard pro rozhraní komponent. Komponentou se rozumí modul *.dll, *.exe, *.ocx, jehož funkčnost je přístupná výhradně prostřednictvím rozhraní splňujících specifikovaný standard. Vlastní funkčnost může být implementována pomocí tříd v libovolném programovací jazyce. Třídy a rozhraní jsou identifikovány pomocí CLSID (třída) a UUID (rozhraní), která jsou generována na základě speciálního algoritmu, který zajišťuje unikátnost identifikátoru na celém světě po několik tisíc let. Pro snadnější použití používají programátoři pro třídy alternativní identifikátor PROGID (Programmatic Identification), např. Word.Application. Na rozdíl od předchozího standardu COM, COM+ integruje služby pro vyvažování zátěže, řízení bezpečnosti, transakcí, sdílení objektů a asynchronní volání. COM+ je integrováno v Component services ve Windows Technologie COM+ je podporována různé míře většinou dnes dostupných vývojových nástrojů. CORBA CORBA představuje standard umožňující komunikaci komponent bez ohledu na platformu, autora a programovací jazyk, počítač či síťovou infrastrukturu. To umožňuje definice rozhraní pomocí IDL (Interface Definition Language), který definuje metody, výjimky a datové typy. Jádrem standardu CORBA je objektová sběrnice (ORB Object Request Broker), která umožňuje objektům přijímat a předávat zprávy v distribuovaném a heterogenním prostředí. ORB dále zajišťuje jmenné, vyhledávací a volací služby (včetně předávání proměnných mezi vlákny). CORBAservices jsou služby zajišťující vytváření instancí a přístup k nim prostřednictvím rozhraní. CORBAfacilities je množina objektů poskytujících řadu aplikačních služeb (tisk, správa dokumentů, , přístup k datům). Enterprise Java Beans Enterprise Java Beans (EJB) je průmyslový standard vyvíjený firmou Sun ve spolupráci s klíčovými partnery. Standard definuje rozmístění, vzájemné propojení a model, jak vytvářet znovupoužitelné komponenty v Javě umístěné na aplikačním serveru. Součástí standardu EJB je též komunikace EJB komponent s komponentami v jiných prostředích než v Javě. EJB komponenty pracují na aplikačních serverech, které podporují služby EJB. Server poskytuje EJB kontejner, který je zodpovědný za registraci objektů, zakládání a rušení jeho instancí, kontrolu bezpečnosti, řízení transakcí včetně distribuovaných atd. EJB tedy umožňuje vytvářet v Javě serverové komponenty, které podporují celou řadu služeb definovaných infrastrukturou EJB, a jsou znovupoužitelné na různých aplikačních serverech. Každá komponenta (Java bean) musí implementovat specifická rozhraní. Rozlišují se základní typy komponent Entity beans (reprezentují persistentní data v databázi) a Session beans (existuje v rámci jedné realace mezi klientem a serverem). Postup při komponentovém vývoji Při komponentovém vývoji je třeba kromě kvalitní analýzy klást důraz především na správné rozdělení systému na komponenty v době návrhu. Potom

23 je možné, aby na projektu paralelně pracovalo více implementačních týmů, a vytvořené komponenty je možné znovupoužít na dalších projektech nebo je prodat na trhu komponent. S otázkou rozdělení systému na komponenty v době návrhu souvisí také otázka granularity komponent. Komponentu jako prvek znovupoužitelnosti je třeba vytvořit s jistou mírou obecnosti. Jestliže je komponenta navržena příliš obecně, vede to k nutnosti uvažování mnoha alternativ, možných stavů a funkcí, které sice musí být ošetřeny, ale nakonec často vůbec nemusí být využity. Implementace velmi obecné komponenty je zdlouhavá a obtížná a samotný její kód je díky mnoha větvím algoritmu těžkopádný a nevýkonný. Další otázkou, kterou je zapotřebí řešit při vývoji komponentových aplikací, je volba komponentové architektury Komponentový vývoj má 2 roviny - návrh a implementace komponent a skládání aplikací z komponent. Návrh i implementace komponenty jsou obdobné návrhu a implementaci třídy v objektově orientovaném programování. Spočívá v definici rozhraní, návrhu a implementaci funkcionality komponenty a následné kompilaci všech těchto součástí. Velmi důležitým faktem při implementaci komponenty je nutnost vytvoření přiměřeně obecného, dostatečně parametrizovatelného a v důsledku toho znovupoužitelného kódu. To vede k nutnosti zařadit do kódu daleko větší množství podmínek a kontrol než jak by tomu bylo v případě programování kódu pouze pro jednu aplikaci a jeden účel. Obecně lze při implementaci komponenty samotné také zahrnout již existující komponentu. Pro tyto účely jsou používány techniky Containment a Aggregation. Skládáme-li aplikaci z komponent, je důležité znát rozhraní a funkcionalitu komponent. Popis rozhraní a funkcionality by v sobě měl zahrnovat tzv. kontrakt komponenty. Kontrakt si můžeme představit jako smlouvu mezi klientem a komponentou o tom, jaké služby jsou komponentou poskytovány a jakým způsobem o ně musí být žádáno, resp. jaké podmínky musí být splněny před tím, než je služba využita. Kontrakt by měl zahrnovat: vstupní podmínky pro každou funkci zpřístupněnou rozhraním, výstupní podmínky, tj. formální zápis výsledku práce funkcí, přípustné stavy komponenty a volání, která k přechodům mezi jednotlivými stavy vedou. Další možností, jak zjistit funkcionalitu komponenty je studium dokumentace. Poslední otázkou, kterou je zapotřebí při skládání aplikace z komponent vzít v úvahu, je možnost využít nákupu komponent. Z dlouhodobého hlediska se komponenty vyvíjejí je přidávána nová funkcionalita a v důsledku toho může docházet ke změnám. Tyto změny mohou být různých typů: pouze ve výkonových charakteristikách komponenty (např. vyšší kvalita animace u grafické komponenty, ovšem za cenu snížení výkonu), ve funkcionalitě beze změn rozhraní při současném zachování výkonu, ve funkcionalitě beze změn rozhraní při současné změně výkonu, ve funkcionalitě při současných změnách rozhraní, rozhraní beze změn ve funkcionalitě. Pravděpodobně nejnepříjemnější je varianta změny funkcionality beze změn v rozhraní. V takovém případě se mění sémantika komponenty, tj. výsledky volání jednotlivých metod nebo může dojít ke změnám v pořadí volání metod

24 komponenty. Jde o velmi nepříjemné vlastnosti, které způsobí při přeinstalování novou verzí značné problémy. Existují v podstatě tři možnosti řešení uvedených druhů změn komponenty: Distribuce nové verze komponenty pod novým jménem, samostatně. Toto řešení má výhodu zachování služeb poskytovaných starou verzí komponenty, přičemž klienti, kteří tuto starou verzi používají mohou být výhledově změněni. Je vhodné zejména v případě, kdy je komponenta velice rozšířena, nebo jsou implementované změny příliš zásadní (na úrovní hlavního čísla verze). Nevýhodou je nutnost přeprogramovat nejen ty části klienta, které využívají funkcionalitu komponenty, ale také ty části, které verifikují, zda je klient připojen ke správné komponentě. Zahrnutí funkcionality staré verze komponenty do nové verze a zpřístupnění jejího rozhraní jednou z technik containment nebo aggregation vedle rozhraní nové verze ev. zdědění nebo zkopírování definice rozhraní a přidání nových metod do staré verze rozhraní. Dědění rozhraní ovšem není ve všech komponentových technologiích podporováno. Použití výše uvedeného přístupu vidím zejména v situaci, kdy nová verze komponenty staví na funkcionalitě staré verze, resp. je zapotřebí nasadit novou verzi komponenty, přičemž stávající musí být možno dále používat, např. v případě velkého množství geograficky velmi různorodě rozmístěných klientů a centrály, která potřebuje novou funkcionalitu. Přepis staré verze komponenty novou verzí bez zahrnutí či zachování staré verze. Takový scénář je možný pouze tehdy, je-li stará verze nevyhovující a/nebo je-li využívána malým počtem klientů, kteří mohou být snadno nahrazeni novou verzí. V praxi je problematika verzování řešena každou komponentovou technologií jinak některé technologie používají jedinečný identifikátor, jiné ponechávají řešení problému verzování na straně vývojáře Vývoj orientovaný na služby Webové služby Webové služby (Web Services) je nový termín, který v posledním roce ovládl oblast IT. Jedná se o novou technologii, která se pokouší reagovat na změny v byznysu, ke kterým dochází zhruba v posledních 5 letech. Termín webové služby je používán ve více významech. Uveďme podstatné rysy webových služeb: představují standardní způsob propojení vzdálených komponent, používají XML pro předávání zpráv mezi komponentami, mohou být vytvořeny jakoukoli technologií, která vytváří definované spojení. Webová služba je libovolná služba prováděná prostřednictvím rozhraní WSDL (Web Service Definition Language) přes síť, typicky používající protokol SOAP přenášející XML data. Pro svou existenci potřebují webové služby protokol SOAP a adresářové služby UDDI a řadu dalších služeb middleware. Jádrem většiny webových služeb jsou komponenty. Abychom mohli mluvit o webových službách, musí být tyto komponenty dostupné přes XML/SOAP/UDDI. XML/SOAP/UDDI je nový typ middleware, který se používá pro usnadnění komunikace komponentových aplikací v prostředí Internetu. Některé z těchto komponent se