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

Předmět Vývoj informačních systémů

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

doc. Ing. Alena Buchalcevová, Ph.D doc. Ing. Alena Buchalcevová, Ph.D

Studijní zátěž Prezenční studium

Semestr Týden

Počet kreditů

Počet výukových hodin podle počtu kreditů

7 -

252 7

Počet výukových kontaktních hodin 36 2+1

Počet výukových hodin samostudia 216 18

Počet časových hodin samostudia 162 13,5

Kombinované studium Počet kreditů

Semestr Výuka v blocích tři bloky za semestr

7 -

Počet výukových hodin podle počtu kreditů 252 24

Počet výukových kontaktních hodin 24 3x4

Počet výukových hodin samostudia 228

Počet časových hodin samostudia

171

©Alena Buchalcevová Vývoj informačních systémů

Obsah Úvod ........................................................................................................... 3 1.

Disciplína Softwarové inženýrství ........................................................... 5

2.

Strukturovaný přístup k vývoji ............................................................... 7 2.1. 2.2.

3.

Objektový přístup k vývoji .................................................................... 14 3.1. 3.2. 3.3. 3.4.

4.

Strukturované programování .............................................................. 7 Strukturovaná analýza a návrh............................................................ 8 Objektově orientované programování .............................................. 15 Objektově orientovaná analýza a návrh ............................................ 17 Komponentový vývoj ....................................................................... 17 Vývoj orientovaný na služby ............................................................ 24

Fáze vývoje informačního systému ....................................................... 25 4.1. Příprava plánu projektu..................................................................... 26 4.2. Specifikace požadavků ..................................................................... 26 4.3. Analýza ............................................................................................. 27 Podrobný popis případů užití ................................................................ 27 Návrh tříd a jejich odpovědností ........................................................... 27 Vytvoření analytického diagramu tříd ................................................. 28 Vytvoření sekvenčních diagramů pro vybrané případy užití ............. 30 Definování testů ...................................................................................... 30 4.4. Návrh ................................................................................................ 30 Systémový návrh ..................................................................................... 30 Objektový návrh ..................................................................................... 30 4.5. Implementace .................................................................................... 32

5.

Testování programového systému ......................................................... 35 Postup procesu testování ........................................................................ 37

6.

Metodiky budování IS/ICT .................................................................... 39 6.1.

Agilní metodiky ................................................................................ 41

-2-


Úvod Úvod Předmět Vývoj informačních systémů je zařazen jako povinný předmět v 6. semestru bakalářského studia oboru Informační technologie. Úvod do předmětu Vývoj informačních systémů Cílem předmětu Vývoj informačních systémů 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, 2012. 357 s. ISBN 978-80-2474153-6. 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. 2009. ISBN 978-80-245-1540-3 Tuto knihu lze získat přes e-shop nakladatelství Oeconomica http://www.eshopoeconomica.cz/ BUCHALCEVOVÁ, Alena, STANOVSKÁ, Iva. Příklady modelů analýzy a návrhu aplikace v UML. Praha Oeconomica. 2013 Tuto knihu lze získat přes e-shop nakladatelství Oeconomica http://www.eshopoeconomica.cz/ 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. -3-

©Alena Buchalcevová Vývoj informačních systémů 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-


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

Bruckner a kol

Vzdavatel a rok Strany vydání doporuče ného textu Tvorba informačních Praha:Grada 78-80 systémů Publishing, 2012

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í 1994 -2004. Ú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ů.

-5-


Obrázek 1: Výsledek projektů v letech 1994-2004 (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-


C L

2.Strukturovaný přístup k vývoji

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 Doporučená literatura: Autor Název

Bruckner a kol Řepa Václav

Tvorba informačních systémů Analýza a návrh informačních systémů

Vzdavatel a rok vydání

Praha:Grada Publishing, 2012 Praha: Ekopress, 1999

Strany doporuče ného textu 268- 273

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.

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

©Alena Buchalcevová Vývoj informačních systémů 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.

2.2. 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 I M P L E M E N T A C E

LOGICKÁ ÚROVEŇ

T1

SELECT P.A, P.B FROM P WHERE P.C > 2000.

Obrázek 2: Funkční a datový pohled

-8-

a d c

rc

g

FYZICKÁ ÚROVEŇ

©Alena Buchalcevová Vývoj informačních systémů 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-

©Alena Buchalcevová Vývoj informačních systémů 

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

- 10 -


EOD

DATUMCASTKA FAKTUR -ZA-DOD

DOD-CIS

Tvorba faktury CASTKA -ZA-DOD DOD-CIS

DATUMFAKTUR

DOD-CIS

Doplnění údajů o dodávce

CH-DOD

CH-DOD

DOD-CIS

Přiřazení čísla faktury

TYPZAKAZ

OBJ-CIS

NOVE-C -FAKT

CASTKA -ZA-DOD

NOTFOUND

Zápis nové faktury do DB

DATUM FAKTURACE

Výpočet částky slevy pro typ zákazníka

Zjištění typu zákazníka NOTFOUND

EOD Čtení a ověření nevyfakturované dodávky s objednávkou

Čti systémové datum

SLEVA

SLEVA Zjištění částky za položky dodávky

DOD-CIS

DATUMFAKTUR

CASTKA -ZA-DOD

Tisk faktury

TYPZAKAZ

CASTKA -ZA-DOD

DATUMDNES

NOVE-C -FAKT

DOD-CIS EOD

DOD-CIS

SLEVA Zjištění slevy z ceny

Zjištění údajů pro fakturu

DATA-FAKTURY

CASTKA -PO-SLEVE

DOD-CIS

ZAK-CIS

POLDODAV

Vypsání chyby do chybového protokolu

TYPZAKAZ

NOVE-C -FAKT

Procenta slev

Čtení typu zákazníka

ZAK-CIS

OBJ-CIS

DPH

MAX Č-FAKT PROCENTO -SLEVY

ZAK-CIS Čtení čísla zákazníka

DATUMFAKTUR

Položka dodávky

TYPZAKAZ Zákazník

DOD-CIS Faktura Objednávka

Dodávka NOTFOUND

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í).

- 11 -

©Alena Buchalcevová Vývoj informačních systémů ČTI ÚDAJE O ZÁKAZNÍKOVI Jméno zákazníka Číslo účtu neexistuje

Číslo účtu zákazníka

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. VOLAJÍCÍ MODUL P3

P1

P2

ABC

Doplňující prvky

- 12 -

©Alena Buchalcevová Vývoj informačních systémů MODUL (volající)

Modul (opakovaně volá) Opakování

Modul

Modul

Databázová tabulka (soubor)

Obrazovka

MODUL (volaný)

MODUL data

Modul

(podmíněně volá)

Podmíněné volání

řídící parametr 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

- 13 -

©Alena Buchalcevová Vývoj informačních systémů 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ě programování a objektově orientované analýzy a návrhu

- 14 -

orientovaného


L

3. Objektový přístup k vývoji

Doporučená literatura: Autor Název

Bruckner a kol BUCHALCEVOVÁ, Alena, STANOVSKÁ, Iva

Vzdavatel a rok Strany vydání doporuče ného textu Tvorba informačních Praha:Grada 238-253 systémů Publishing, 2012 Příklady modelů Praha analýzy a návrhu Oeconomica. 2013 aplikace v UML

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.

3.1. 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 ) - 15 -

©Alena Buchalcevová Vývoj informačních systémů  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.

- 16 -


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 1995. 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ů.

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

- 17 -

©Alena Buchalcevová Vývoj informačních systémů 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

- 18 -

©Alena Buchalcevová Vývoj informačních systémů 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é - 19 -

©Alena Buchalcevová Vývoj informačních systémů 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

Proces B

Klient

Proxy rozhraní komunika ční kanál - 20 -

Proces C

Server komponenta

Klient

Proxy

Server komponenta


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

- 21 -

©Alena Buchalcevová Vývoj informačních systémů 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 2000. 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ů, email, 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

- 22 -

©Alena Buchalcevová Vývoj informačních systémů 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 - 23 -

©Alena Buchalcevová Vývoj informačních systémů 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.

3.4. 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 - 24 -


<č.>.

vytvářejí nově, ale celá řada existujících komponent se upravuje a doplňuje o rozhraní XML/SOAP. Význam webových služeb spočívá v tom, že tento standard byl velmi rychle (během 1 roku) přijat a je implementován na různých technologických platformách. Jejich přednost spočívá v tom, že jde o jednoduché standardy, nikoli API rozhraní, které je složité a závislé na prodejci.

S

Shrnutí V současnosti převažujícím způsobem vývoje IS je objektově orientovaný vývoj a jeho další vývojové stupně – komponentový vývoj a vývoj orientovaný na služby.

Kontrolní otázky a náměty: 1. Vysvětlete pojmy a jejich souvislosti: objekt, třída, komponenta, služba 2. Co to objektově-orientovaný a komponentový přístup k vývoji SW?

C L

4. Fáze vývoje informačního systému Cíle kapitoly: vysvětlit postup vývoje informačního systému na zobecněném příkladě fází a ukázat, jaké hlavní činnosti je třeba v jednotlivých fázích realizovat Doporučená literatura: Autor Název


Tvorba informačních systémů Příklady modelů analýzy a návrhu aplikace v UML


Praha:Grada Publishing, 2012 Praha Oeconomica. 2013


V této kapitole je uveden zobecněný postup vývoje programového systému menšího rozsahu objektově orientovaným způsobem. Postup můžeme rozložit do následujících fází:  Příprava plánu projektu  Specifikace požadavků  Analýza  Návrh  Implementace  Testování  Nasazení - 25 -

©Alena Buchalcevová Vývoj informačních systémů 

Údržba

4.1. Příprava plánu projektu V této fázi je třeba připravit plán, podle kterého bude projekt probíhat. Problematika řízení projektů je zpracována v řadě publikací. Pro naše účely postačí, když si uvědomíme nutnost této fáze a základní činnosti, které je třeba v této fázi provést:  určit vedoucího projektu,  určit členy týmu,  definovat termíny dokončení jednotlivých fází a výstupy z těchto fází, Přechody z jedné fáze do druhé jsou charakterizovány tzv. milníky (milestone), které specifikují podmínky, za kterých lze fázi ukončit.  definovat metriky kvality,  definovat ekonomické charakteristiky projektu (náklady, přínosy). Závěrem této fáze je rozhodnutí, zda je projekt za daných požadavků, dostupných technologií, zdrojů a rozpočtu možné realizovat.

4.2. Specifikace požadavků Dříve než zahájíme analýzu, návrh a kódování, je třeba identifikovat požadavky, které má software splňovat. Musíme zjistit, jaké funkce bude zákazník s programem realizovat, za jakých podmínek, v jakém prostředí. Základní kategorií požadavků jsou funkční požadavky, které určují funkcionalitu budoucí aplikace. Je ale třeba zjišťovat i tzv. nefunkční požadavky jako jsou například požadavky na bezpečnost, dostupnost apod. Pokusme se nejprve vymezit pojem požadavek. Požadavek je schopnost nebo vlastnost, kterou uživatel potřebuje k vyřešení problému a dosažení cíle. Správa požadavků je systematický přístup k identifikaci, organizaci, komunikaci a řízení měnících se požadavků na softwarovou aplikaci. Primárním cílem správy požadavků je specifikace požadavků, která definuje a dokumentuje chování budovaného systému. Chyby v požadavcích mají velké dopady. Náklady na opravy chyb v požadavcích jsou více než 10 krát větší než náklady na opravu jiných chyb. Přitom chyby v požadavcích představují více než 40% všech chyb softwarového projektu. Podle [Frankl,2005] jsou chyby v požadavcích hlavním důvodem neúspěchu softwarových projektů. Proto je správě požadavků věnována značná pozornost v tradičních metodikách vývoje softwaru a jsou pro ni definovány standardizované procesy. Požadavky mají stanoveny formální a věcné náležitosti, které musí splňovat. Například metodika Rational Unified Proces doporučuje následující postup. Příchozí požadavky jsou předepsaným způsobem zaznamenány. Obvykle se eviduje jejich stručný popis spolu se souvisejícími atributy, které jsou nezbytné pro posouzení požadavku u dodavatele. Po zadání požadavku probíhají kontrolní procesy, které zkoumají, zda má požadavek všechny formální i věcné náležitosti. Požadavky jsou pak seskupeny podle souvislostí, odstraňují se duplicitní požadavky a doplňuje se podrobná specifikace. Dodavatel pak posuzuje realizaci každého požadavku, dopad na stávající systémy a odhaduje termín realizace a potřebné zdroje. Po posouzení požadavků dodavatelem a odsouhlasení jejich realizace následuje vytvoření vize budoucího softwaru. Vize shrnuje klíčové potřeby zadavatele a popisuje požadované funkční i

- 26 -

©Alena Buchalcevová Vývoj informačních systémů systémové vlastnosti softwaru. V průběhu správy požadavků se vytváří společný slovník, který má za úkol sjednotit používanou terminologii a pomoci odstranit možné duplicity způsobené rozdílnou formulací téhož problému. V této fázi vzniká úvodní model případů užití, který obsahuje klíčové funkce systému. Model případů užití je dále zpřesňován tak aby byly identifikováni všichni aktéři a všechny případy užití. Pak se určí priority případů užití a rizika. Softwarový architekt vyhledá klíčové případy užití pro definování architektury systému a vytvoří její první nástin (obsahující pouze pohled případů užití). Priority případů užití se poté zanesou do vize. Analytik případů užití detailně popíše jednotlivé případy užití (vstupní i výstupní podmínky, postupy v rámci případu užití a výsledkem je detailní specifikace případů užití. Požadavky nestačí jen specifikovat, ale je třeba je řídit v rámci celého životního cyklu požadavků včetně řízení změn požadavků. Kvalitní správa požadavků je velice složitým procesem, při němž se doporučuje využívat softwarových nástrojů, které umožňují efektivně organizovat procesy a přispívají k flexibilní komunikaci mezi všemi účastníky.

4.3. Analýza Abychom mohli navrhnout programový systém, je třeba pochopit danou problémovou oblast. To je cílem fáze analýzy, které se aktivně účastní také uživatelé systému. Fáze analýzy zahrnuje zejména následující kroky:  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ů.

Podrobný popis případů užití Základem objektově orientované analýzy je modelování případů užití, které je podrobně popsáno v Bruckner a kol., 2012,

Návrh tříd a jejich odpovědností Jsou-li podrobně popsány případy užití, je třeba identifikovat objekty a třídy a určit, jaké atributy a metody mají mít. Identifikace tříd, jejich atributů a metod je iterativní proces, při kterém je třeba mít znalosti modelování tříd, rozumět aplikační doméně, mít zkušenosti s analýzou podobných problémových oblastí. Pro identifikaci tříd se doporučuje například přístup přes podstatná jména, který probíhá následovně: Analytik pročítá specifikaci požadavků a vyhledává podstatná jména. Každé podstatné jméno je kandidátem na třídu. Kandidátské třídy se seskupí do kategorií:  relevantní třídy,  neurčité třídy,  irrelevantní (jsou mimo problémovou doménu, nelze formulovat jejich účel). Jinou možností, jak identifikovat třídy a jejich odpovědnosti, je CRC modelování. CRC je zkratkou Class-Responsibility-Collaborator Card. CRC modelování je jednoduchá, ale silná objektově orientovaná modelovací technika. CRC tým tvoří uživatelé, analytici a vývojáři. CRC model je množinou CRC karet. CRC karta, která je znázorněna na obrázku 3.1, se vytváří pro každou třídu. V záhlaví karty je uvedeno jméno třídy, v levé části - 27 -

©Alena Buchalcevová Vývoj informačních systémů jsou uvedeny odpovědnosti třídy a v pravé spolupracující třídy. Na zadní straně karty je pak podrobnější popis třídy.

Obrázek 6. CRC karta

Odpovědnost třídy je něco, co třída „zná“ nebo „dělá“. Například třída Osoba má odpovědnost za své jméno, adresu, rodné číslo, třída Auto má odpovědnost za velikost, počet dveří, schopnost jet či zastavit. Spolupracovník třídy je jiná třída, kterou třída využívá při realizaci své odpovědnosti. Na spolupracující třídu se obrátí třída, pokud potřebuje informace, které sama nemá a nebo potřebuje změnit informace, které nemá. Při CRC modelování se nejprve na základě požadavku respektive scénáře případu užití vytvoří prvotní návrh CRC karet. Karty se umístí na tabuli a to tak, aby třídy, které spolupracují byly umístěny blízko sebe. Potom se prvotní návrh prověřuje a zpřesňuje na základě simulace používání systému. Prochází se scénář případu užití a zjišťuje se, která třída zpracuje požadavek, jaké další třídy při zpracování požadavku využije, jaké odpovědnosti musí mít třídy atd. Obrázek 3.2 ukazuje, jaký je vztah mezi modely při objektově orientované analýze a návrhu a kdy je vhodné CRC model vytvářet.

Obrázek 7 Místo CRC modelu

Vytvoření analytického diagramu tříd Třídy, které jsme identifikovali při CRC modelování pak zakreslíme v UML modelu tříd. V této fázi jde o analytický (konceptuální, doménový) model tříd. Nalezení správných tříd, určení relevantních atributů a metod, definování vztahů mezi třídami, to vše je náročný proces, který je do značné míry ovlivněn

- 28 -

©Alena Buchalcevová Vývoj informačních systémů zkušenostmi analytika. Přesné postupy, které by vedly k vytvoření rozumné struktury tříd, metodiky většinou neuvádějí, ale poskytují jen návody či doporučení. Většinou se doporučuje postupovat iterativně, to znamená nejprve načrtnout základní strukturu tříd a dále ji zpřesňovat a rozvíjet. Vhodné je pracovat týmově a společně analyzovat danou oblast a navrhovat třídy. Strukturu tříd je třeba zdokumentovat, nejlépe pomocí CASE nástroje, který podporuje UML. Použití CASE nástroje nám umožní snadno upravovat model:  v jednotlivých iteracích fáze analýzy a návrhu,  při přechodu ke kódování, kdy přistupuje řada implementačních charakteristik,  po nasazení systému při jeho údržbě a rozvoji. Při vytváření analytického modelu tříd je třeba prvotní návrh prověřovat v následujících směrech:  prověření, zda nemá být atribut třídou Volba, zda má být určitý prvek třídou, a nebo atributem, může být někdy obtížná a nemusí být konečná. Prvek navrhneme například jako atribut, ale můžeme z něj později udělat třídu. Příkladem může být třeba rodné číslo. Pokud budeme chtít provádět speciální kontroly rodného čísla, poskytovat jej v různých formátech (s lomítkem, bez lomítka apod.), vypočítávat věk, bude možná vhodnější udělat pro něj třídu a do objektu třídy Osoba vložit instanci této třídy.  dvě třídy nebo dvě instance téže třídy Je třeba rozlišit, kdy dva prvky představují jen dvě instance téže třídy a kdy je třeba skutečně vytvořit dvě třídy. Můžeme si to ukázat na následujícím příkladě U třídy Osoba chceme evidovat adresu trvalého bydliště a adresu přechodného bydliště. Po hlubší analýze dojdeme k závěru, že pro udržování údajů o adrese bude vhodné vytvořit třídu Adresa. Tato třída bude mít několik atributů (ulice, číslo, město, psč, stát). Všechny tyto atributy jsou jak u trvalého bydliště, tak u přechodného bydliště. Také metody, které třída Adresa bude poskytovat, se nijak neliší pro adresu trvalého a adresu přechodného bydliště. Proto vytvoříme třídu jednu. Do třídy Osoba potom vložíme dvě instance třídy Adresa, jednu pro trvalé bydliště a druhou pro přechodné bydliště.  kandidáti na vztah generalizace-specializace Pokud se ve více třídách opakují tytéž informace, můžeme uvažovat o vytvoření obecné třídy. Tuto třídu vybavíme atributy a metodami, které jsou společné a od ní odvodíme speciální třídy.  spolupráce tříd Zajímáme se o interakci s ostatními třídami. Pokud dvě třídy příliš mnoho spolupracují, bude možná vhodnější vytvořit z nich jedinou třídu. Navržená struktura tříd musí být porovnána s případy užití. Klademe si otázky typu:  Pokryjí navržené třídy všechny definované případy užití?  Poskytuje navržená struktura tříd prostor pro další rozšíření a přidávání funkcí? Při návrhu tříd se snažíme o jednoduchost. Přínos objektově orientovaného přístupu spočívá v možnosti rozdělit problém na malé části, které mohou stát samostatně a přitom reprezentují ucelenou funkčnost. Je lepší navrhnout více malých objektů, které reprezentují jasně a dobře jednu věc, než jeden velký nepochopitelný a složitý objekt. Navíc malé, jasné objekty, lze snadno znovupoužít. - 29 -


Vytvoření sekvenčních diagramů pro vybrané případy užití Model tříd představuje statický pohled na problémovou oblast, a proto bývá doplňován scénáři pro jednotlivé případy užití, které se vyjadřují pomocí sekvenčních diagramů, které jsme vysvětlili v podkapitole 2.8.

Definování testů Již ve fázi analýzy je třeba se zabývat testováním a navrhnout testy. Návrh testů v raných fázích vývoje demonstruje snahu vyvinout kvalitní software a podporuje vytváření spustitelné verze na konci každé iterace. Testy mají prověřit jak vlastní funkčnost aplikace, tak i uživatelské rozhraní. Včasným testováním uživatelského rozhraní samotnými uživateli, lze předejít mnohým zklamáním na konci projektu.

4.4. Návrh Fáze návrhu bývá rozdělována na dvě fáze: systémový návrh a objektový návrh.

Systémový návrh V rámci systémového návrhu je třeba zvolit implementační prostředí a definovat:  platformu - operační systém,  rozhodnout o technologické architektuře aplikace: o jednouživatelská (desktop) aplikace, o aplikace typu klient/server s tlustým klientem (např. pod Windows), o internetová aplikace, o vícevrstvá aplikace snadno přenositelná z tlustého na tenkého klienta o vybrat programovací jazyk a vývojové prostředí, o vytvořit a nebo použít aplikační rámec (application framework). V závislosti na technologické architektuře aplikace se definuje uživatelské rozhraní: klasické aplikace - textové UI, grafické UI rozhraní akceptované prohlížečem. Při vytváření uživatelského rozhraní aplikace se zpravidla využívá celá řada již hotových objektů, jak jednotlivých prvků jako jsou tlačítka, editační pole apod., tak i formulářů či celých šablon aplikací. Tyto prvky tvoří tzv. aplikační rámec. Pokud jsme vybrali programovací jazyk a vývojové prostředí, které již tyto objekty má vytvořeny, stačí je jen použít. Pokud ne, je třeba tyto prvky nejdříve naprogramovat. Takovým aplikačním rámcem je třeba knihovna Swing pro Javu, ActiveX prvky , CSS pro WWW stránky.

Objektový návrh Ve fázi objektového návrhu vytváříme designový model tříd, definujeme spolupráci objektů pomocí sekvenčních diagramů, definuje algoritmy metod a navrhujeme uživatelské rozhraní. V této fázi pracujeme s modely vytvořenými ve fázi analýzy a dále je doplňujeme o prvky, které jsou již implementačně závislé. Ve fázi návrhu přecházíme z aplikační oblasti do počítačové oblasti. Objekty identifikované při analýze tvoří kostru návrhu, ale návrhář musí volit

- 30 -

©Alena Buchalcevová Vývoj informačních systémů mezi různými způsoby implementace a zohledňovat přitom čas provádění operací, nároky na paměť a další faktory. Operace identifikované při analýze je třeba vyjádřit ve formě algoritmů. Složité operace musí být dekomponovány na jednodušší. Je třeba zavést nové objekty pro uchování mezivýsledků. Činnosti prováděné ve fázi objektového návrhu můžeme rozdělit do těchto kroků:  Práce s různými typy diagramů, kontroly konzistence a převod do algoritmů Navzájem porovnáváme jednotlivé diagramy a snažíme se nalézt rozpory.  Návrh algoritmů pro implementaci operací Každá operace musí být formulována jako algoritmus. Je třeba: o vybrat nejvýhodnější algoritmus, o zvolit pro daný algoritmus vyhovující datové struktury, o definovat nové interní třídy a operace, je-li třeba, o přiřadit odpovědnost za operace jednotlivým třídám.  Řešení přístupu k datům Je třeba vyřešit uložení dat. Zvolit buď uložení v souborech a nebo použít databázi. V tom případě je třeba vytvořit datový model, definovat strukturu databáze a vytvořit vrstvu mapující data objektů do databáze.  Použití návrhových vzorů Při řešení obvyklých problémů návrhu použijte návrhové vzory.  Implementace řízení interakce s jinými objekty Vztahy mezi třídami, které byly v konceptuálním modelu tříd znázorněny jako asociace, je třeba implementovat. Každé asociaci odpovídá metoda a je třeba rozhodnout v kompetenci které třídy bude. Objekt, se kterým se komunikuje, musí být předán jako parametr dané metodě.  Prověření struktury objektů pro zavedení dědičnosti  Přeskupení tříd V některých případech je stejná operace definována v různých třídách, které jsou potomky obecnější třídy. Je proto třeba prověřit, zda je možné operaci přesunout do třídy předka a využít ji v potomcích bez předefinování a nebo ji v potomcích překrýt.  Abstraktní třídy Je třeba projít třídy a hledat případné abstraktní třídy, které budou implementovat společnou základní funkčnost.  Rozhraní Pokud programovací jazyk podporuje rozhraní, je třeba prověřit společné operace a vyčlenit je do rozhraní.  Využití delegace pro sdílení implementace Dědičnost je vhodným způsobem implementace vztahu generalizace – specializace, pokud chování nadtřídy sdílí všechny podtřídy. Dědičnost můžeme použít v těch případech kdy podtřída je specializací nadtřídy i v analytickém smyslu. Platí tedy tvrzení podtřída je nebo je jako nadtřída. Někdy ovšem programátoři používají dědičnost jako implementační techniku bez záměru garantovat stejné chování tříd v dědické hierarchii. Tak se stává, že nová třída dědí z třídy předka určité chování, ale jinak jsou třídy úplně rozdílné. To může vést k problémům v jiných operacích dané třídy, které mohou působit nechtěné chování. V případech, kdy chceme použít dědičnost jako implementační techniku, dosáhneme stejného cíle bezpečnějším způsobem pomocí vloženého objektu.

- 31 -

©Alena Buchalcevová Vývoj informačních systémů Tento způsob se nazývá delegace, neboť objekt pro určitou činnost vyvolá metodu jiného objektu, který je jeho součástí a nebo s kterým je spojen.  Návrh asociací Asociace jsou konceptuální entity ve fázi analýzy. Při návrhu je třeba určit strategii, jak je implementovat. Tato strategie může být buď univerzální, použitá pro všechny asociace v modelu, a nebo se pro různé asociace použijí různé techniky. V analytické fázi většinou předpokládáme, že asociace jsou obousměrné. Při rozhodování o směru asociace je třeba si uvědomit, že implementace jednosměrné asociace je jednodušší. Je ale třeba zvážit, zda nebude třeba přidat do třídy nějakou novou operaci, která bude vyžadovat obousměrnou asociaci. Jednosměrné asociace mohou být implementovány jako atribut, který obsahuje referenci na objekt. Pokud je násobnost asociace 1, jde o jednoduchý ukazatel (obrázek 3.5). Je-li násobnost N, jde o množinu ukazatelů. Jsou-li objekty v asociaci uspořádané, je lepší použít seznam.  Rozhodnutí o reprezentaci objektů Implementace objektů je někdy jasná, ale někdy je třeba se rozhodnout pro některou z alternativ. Atribut můžeme reprezentovat různými datovými typy (například číslo pracovníka jako integer nebo string). Pro určitý atribut můžeme definovat také samostatnou třídu. Na obrázku 3.8 je znázorněna třída Usecka definovaná 4 souřadnicemi. Jinou možností určení úsečky je definovat třídu Bod a úsečku potom složit ze dvou instancí třídy Bod tak, jak ukazuje obrázek 3.9  Doplnění vrstvy uživatelského rozhraní Diagramy vytvořené ve fázi analýzy je třeba doplnit o objekty uživatelského rozhraní, zejména o třídy formulářů.  Seskupení tříd do modulů Ve fázi návrhu bychom měli rozhodnout o rozdělení aplikace do komponent a vytvořit diagram komponent.

4.5. Implementace Na začátku implementace je třeba určit pořadí implementace jednotlivých tříd. Probíhá-li fáze implementace v iteracích, je třeba určit, které třídy implementovat v jednotlivých iteracích. K tomu přistupuje ještě problém týmové práce. Jak rozdělit třídy mezi jednotlivé členy týmu? Jak se vypořádat se vzájemnými závislostmi tříd? Jak zajistit, že každá iterace reprezentuje verzi programu, kterou lze testovat. Doporučení pro programování Každý lyžař, šachista nebo kuchař ví, že existuje velký rozdíl mezi tím, kdo něco zná, a tím, kdo to umí. S psaním objektově orientovaných programů je to podobné. Nestačí znát pouze principy, ale je třeba umět navrhnout třídy, jejich vazby a spojit je do programu, který dělá to, co po něm požadujeme. Zkušený programátor dodržuje principy, které umožňují psát čitelné a rozšiřitelné programy. Dobrý programovací styl je důležitý ve všech metodách programování, ale v objektově orientovaném návrhu nabývá na větší důležitosti, protože cílem objektově orientovaného přístupu je produkovat znovupoužitelné a rozšiřitelné programy. V objektově orientovaném programování platí obecné programovací zásady a doporučení, ale přidávají se i nové zásady, které jsou spojeny s novými rysy OOP jako je dědičnost apod. - 32 -

©Alena Buchalcevová Vývoj informačních systémů V následujících odstavcích jsou uvedeny nejdůležitější zásady pro znovupoužitelnost, rozšiřitelnost a robustnost programů Pravidla pro zajištění znovupoužitelnosti  Realizujte koherentní metody, tj. metody, které provádějí jednu funkci a nebo skupinu těsně svázaných funkcí.  Realizujte malé metody. Je-li metoda velká, rozdělte ji na menší, které budou lépe znovupoužitelné.  Realizujte konzistentní metody, to znamená, že stejné metody by měly mít stejná jména, podmínky, pořadí argumentů, návratové hodnoty, chybové stavy.  Oddělte řídící a implementační metody. Řídící metody přijímají rozhodnutí, drží celkový kontext, volají implementační metody, kontrolují stav včetně chybového. Implementační metody provádějí specifické operace bez rozhodování proč. Provádějí výpočet pro plně definované parametry.  Realizujte metody plně pokrývající danou oblast. Pokud se vstupní podmínky mohou vyskytovat v různých kombinacích, obslužte všechny možnosti.  Snažte se zobecnit parametry, vstupní podmínky, omezení, předpoklady, za jakých metoda pracuje, a kontext, v jakém pracuje.  Realizujte smysluplné akce pro nulové a extrémní hodnoty. Často je možné udělat obecnější metodu jen s malým navýšením kódu.  Vyhněte se globálním informacím. Minimalizujte vnější vazby, místo toho použijte parametry.  Vyhněte se módům. Funkce, jejichž chování velmi závisí na kontextu, jsou těžko znovupoužitelné.  Zvažujte dobře použití dědičnosti a více využívejte delegace.  Pravidla pro zajištění rozšiřitelnosti  Dodržujte zapouzdření tříd.  Ukrývejte atributy.  Rozlišujte public a private operace.  Pravidla pro zajištění robustnosti  Program se musí bránit chybám - kontrolujte vstupy.  Optimalizujte program až po té, co běhá - optimalizujte jen často volané funkce.  Kontrolujte parametry metod.  Pokud je to možné, používejte pro uchování dat dynamické proměnné, které nevyžadují předem definované meze.  Vybavte program proměnnými pro ladění a monitorování běhu. Pravidla při programování na velkých projektech  Nepředbíhejte s programováním - nejprve je třeba kompletně dokončit návrh.  Realizujte pochopitelné metody.  Realizujte čitelné metody.  Používejte stejná jména v kódu jako v objektovém modelu.  Volte správná jména - ujistěte se, že přesně vyjadřují operace, třídy, atributy, používejte dané konvence.  Seskupte třídy do modulů.  Dokumentujte třídy a metody. - 33 -

©Alena Buchalcevová Vývoj informačních systémů Závěrečné testování I když testy provádíme po každé iteraci ve fázi implementace, je třeba provést i závěrečné testování, které má odhalit chyby před nasazením systému.

S

Shrnutí V této kapitole jsme si ukázali, co vše je třeba v jednotlivých fázích vývoje IS objektově orientovaným způsobem realizovat

Kontrolní otázky a náměty: 1. Co je předmětem fáze analýzy požadavků na informační systém? 2. Jaké dokumenty jsou vstupem a výstupem fáze návrhu informačního systému?

- 34 -


C L

5. Testování programového systému >

5. Testování programového systému Cíle kapitoly: ukázat význam testování při vývoji IS a představit jednotlivé techniky testování Doporučená literatura: Autor Název


Tvorba informačních systémů Příklady modelů analýzy a návrhu aplikace v UML


Praha:Grada Publishing, 2012 Praha Oeconomica. 2013


Testování je jedním z nejčastěji používaných způsobů ověřování správnosti programového systému či jednotlivého programu. Verifikace a „validace“ Obecně testování patří do procesu „V&V“ (Verification and Validation), který musí probíhat v průběhu celého životního cyklu vývoje programového systému. Cílem procesu „V&V“ je neustálé prověřování, že vyvíjený SW splňuje požadavky a že tyto požadavky odpovídají potřebám zadavatele. Tedy. v průběhu procesu jde o:  objevování defektů/chyb v systému,  prověřování, zda systém je, či není použitelný v provozu. Boehm již v r. 79 definoval rozdíl mezi validací a verifikací takto: Validation: Vytváříme správný produkt? Jedná se o proces ověřování softwarového produktu. Jeho cílem je zjistit, zda tento produkt tak, jak je implementován, splňuje požadavky a očekávání zadavatele. I když lze pro ověření požadavků použít například techniky prototypování, chyby a problémy v SW a často i nedostatky v požadavcích lze zjistit, až když je systém implementován. Proto je úplná validace možná většinou až na konci procesu vývoje SW. Verification: Vytváříme produkt správně? Jedná se o permanentní proces probíhající v průběhu celého životního cyklu vývoje SW produktu, při kterém se ověřuje, zda produkty (výstupy) jednotlivých fází (resp. činností) splňují požadavky stanovené na začátku dané či na závěr předchozí fáze (činnosti), neboli zda tyto produkty odpovídají jejich specifikaci. Produktem v tomto případě může být nejen hotový program, ale i například dokument, model programového systému, popis struktury jednoho programu apod. Pro verifikaci i validaci se požívají statické a dynamické techniky. Statické techniky jsou zaměřeny na analýzu vyjádření systému, jako je například

- 35 -

©Alena Buchalcevová Vývoj informačních systémů prověřování modelu struktury navrhovaného programového systému, simulace modelu jednoho programu vyjádřeného strukturním diagramem, či prověřování výpisu programu. Provádějí se v průběhu celého životního cyklu systému pomocí strukturovaného procházení systému (modelů). Pomocí statických technik lze zjistit, zda systém či program odpovídá zadání, ale nelze jimi demonstrovat, že je tento systém i provozuschopný

Statická verifikace

Specifikace požadavků ("zadání")

Globální návrh

Programový systém (resp. program)

Detailní návrh

Prototyp

Dynamická validace

Obrázek 8: Statická a dynamická verifikace a validace

Dynamické techniky (testování) jsou zaměřeny na prověřování implementace. Jedná se o ověřování funkce programu na datech (zkušebních, které ale odpovídají datům reálným). Na chyby a nedostatky programu se usuzuje z chybných výstupů. Testování chyb (vad, defektů) je zaměřeno na odhalení existence chyb v programech a v celém programovém systému. Zahrnuje testování funkční tzv.“black box“ testování, kdy není nutná znalost kódu programu, a testování strukturální - tzv. „white-box“ testování. Testování defektů je věnována jedna z následujících kapitol. Je na místě zdůraznit, že testováním programů lze pouze odhalit, že v programu jsou chyby. Nelze jím demonstrovat stoprocentní bezchybnost programu. Ať je program podroben sebedokonalejším testům, stále se v něm mohou vyskytovat neodhalené chyby. Na základě tohoto poznání již v roce 1979 definoval Meyers jako úspěšný takový test, který ukáže, že v testovaném SW chyby jsou. Často je totiž za úspěšný považován takový test, který ve výstupech neprokáže žádné anomálie. I v tomto případě to však neznamená, že by v programu chyby nebyly, ale pouze to, že zvolená sada testů je neodhalila. Debugging Testování a debugging jsou někdy směšovány jako jeden proces. Ve skutečnosti však jde o dva rozdílné procesy. Testování odhaluje existenci chyb, debugging je zaměřen na lokalizaci místa v programu, kde příslušné chyby nastaly a na jejich odstranění.

Lokalizace chyby

Návrh způsobu opravy chyby

Obrázek 9: Fáze procesu odstraňování chyb (debugging)

- 36 -

Oprava chyby

Opětovné otestování programu

©Alena Buchalcevová Vývoj informačních systémů Nejdříve je třeba, aby pracovník, který je pověřen odstraněním chyb, lokalizoval, ve které části programu mohla chyba nastat. Usuzuje na základě chybného výsledku programu a na základě znalosti kódu či z jeho dokumentace. Také využívá svoji zkušenost a znalost nejčetnějších programátorských chyb. Lokalizovat přesné místo chyby vyžaduje buď procházení případně simulaci „podezřelé“ části kódu, nebo může vyžadovat sestavení dalších specifických testů. Pokud se místo v programu způsobující chybu podaří lokalizovat, je nutné navrhnout, jak provést opravu. Často je třeba upravit původní návrh programu, z něhož mohou vyplynout i požadavky na změnu návrhu systému (hlavně pokud se chyba týká rozhraní mezi částmi systému). Poté je nutné opravený systém znovu otestovat. Tento proces je většinou poměrně nákladný. Proto se stále více dostávají do popředí statické techniky ověření správnosti systému.

Postup procesu testování Velké systémy nelze testovat jako jeden monolitický celek. Takové systémy jsou tvořeny subsystémy, které jsou vybudovány z modulů, ty se skládají z procedur a funkcí, nebo ze vzájemně komunikujících objektů. Proto by měl být proces testování rozdělen do fází a měl by probíhat ve shodě s postupem implementace. Obvykle se jedná o 5 fází testování většího sytému: Testování programových jednotek (Unit testing). Předmětem testování je správné fungování samostatných programových jednotek (např. funkcí či procedur programů, či metod objektů) bez vztahu na ostatní části programu. Testování modulů (Module testing). Správně navržený modul/objekt zapouzdřuje své prvky (funkce, procedury, v případě objektů metody a data). V tomto případě se tedy testují jednotlivé programové moduly (resp. objekty) včetně vztahů uvnitř modulu/objektu, ale bez vztahu na ostatní moduly/objekty programového systému. Testování subsystémů (Subsystem testing). Předmětem testování je skupina modulů/objektů integrovaných do subsystému. Subsystémem se zde rozumí část systému, která je samostatně vyvíjena a implementována (v „modernějších“ metodikách je samostatně implementovatelná část systému často označována jako přírůstek). Proces je zaměřen hlavně na chyby v rozhraní mezi moduly/objektu v rámci subsystému/přírůstku. Testování systému (System testing) Předmětem zájmu je integrace subsystémů do jednoho celku. Testování je zaměřeno na hledání chyb vyplývajících z nepředpokládané interakce mezi subsystémy a mezi jejich částmi. Zaměřuje se také na ověření, zda systém splňuje funkční i nefunkční požadavky. Akceptační testování (Acceptance testing) Účelem je ukázat, zda systém splňuje provozní a funkční požadavky na něj kladené tak, aby mohl být přijat zadavatelem. Jedná se o poslední fázi testování systému před tím, než je tento schválen pro použití v provozu. Představuje testování systému na datech dodaných zadavatelem (tj. defacto reálných datech, což je mnohem vhodnější než použití simulovaných dat, speciálně navržených pouze pro testování). V rámci těchto testů se často přichází na chyby a nedostatky ve specifikaci požadavků na systém i na chyby v analýze a návrhu (i když by tomu tak mělo být co nejméně, pokud v průběhu vývoje byly

- 37 -

©Alena Buchalcevová Vývoj informačních systémů používány statické verifikační techniky). Schvalovací testování se někdy označuje jako alfa testování. Provádějí jej nejčastěji k tomu předem vybraní uživatelé se znalostí věcné oblasti, která je systémem podporována. U individuálního SW (tj. programové vybavení budované pro jednoho konkrétního zákazníka) probíhají alfa testy tak dlouho, dokud se zadavatel s řešitelem neshodnou na tom, že systém přijatelně realizuje uživatelské požadavky na něj kladené, neboli že systém odpovídá zadání. V případě, že se vyvíjí SW produkt určený pro trh (tj. například nějaký typový aplikační SW), navazuje na alfa testování proces označovaný jako beta testování. Systém je v tomto případě zdarma dodán vybraným potenciálním zákazníkům ke zkušebnímu použití. Ti užíváním přicházejí na problémy, které sdělují vývojářům systému. Tak se zajišťuje vystavení produktu reálným podmínkám použití, při kterém lze odhalit chyby, které se nepodařilo zjistit v předchozích testech jeho tvůrcům. Po odstranění zjištěných nedostatků je systém předložen k dalšímu kolu beta testů, nebo je uvolněn do prodeje. Testování je iterativní proces. Chyby a nedostatky mohou být zjištěny v kterékoliv fázi. Při jejich korekci může vzniknout potřeba vrátit se k některé z předchozích fází. Například chyba v programovém modulu může být odhalena až při testování systému (modul má chybné rozhraní k modulům z jiného subsystému). Opravy v programech mohou způsobit jiné chyby, proto po provedení každé opravy je třeba testy opakovat. Tento postup se někdy označuje jako regresní testování. Ale protože opakování každého testu po každé opravě by bylo velmi nákladné, lze tento postup zjednodušit. Plán testování by měl obsahovat popis vzájemných závislostí mezi částmi systému. Pokud se opravuje část systému, závislá na jiných částech, lze potom pro uskutečnění příslušných testů použít pouze podmnožinu testovacích dat, pomocí které lze ověřit, že oprava ostatní části neponičila.

S

Shrnutí Testování je důležitou součástí vývoje IS, která nesmí být podcenována

Kontrolní otázky a náměty: 1. Vysvětlete rozdíl mezi testováním, validací a verifikací

- 38 -


C L

6. Metodiky budování IS/ICT

6. Metodiky budování IS/ICT Cíle kapitoly: představit metodické nástroje pro podporu vývoje IS Doporučená literatura: Autor Název

Bruckner a kol Buchalcevová BUCHALCEVOVÁ, Alena, STANOVSKÁ, Iva

Tvorba informačních systémů Metodiky budování informačních systémů Příklady modelů analýzy a návrhu aplikace v UML


Praha:Grada Publishing, 2012 Praha: Oeconomica, 2009 Praha Oeconomica. 2013


Metodika představuje v obecném smyslu souhrn metod a postupů pro realizaci určitého úkolu. V oblasti vývoje informačních systémů jsou metodiky často označovány jako metodiky vývoje softwaru, anglicky Software Development Methodologies. Protože v dnešní době není vývoj nového řešení tak častý a spíše se nasazují hotová řešení a rozšiřují a integrují stávající řešení, používáme pojem metodiky budování IS/ICT. „Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení.“ tvorby IS/ICT [BUCHALCEVOVÁ, 2005]. Tato definice reprezentuje „maximalistický obsah metodik“ a odpovídá spíše tradičním a těžkým metodikám. Agilní metodiky, které jsou dále charakterizovány, definují jen principy a praktiky. Kategorizace metodik budování IS/ICT Metodik budování IS/ICT je velké množství, což je dáno jednak historicky, kdy postupně vznikaly, ale zejména tím, že akcentují různá paradigmata jako strukturovaný, objektový, komponentový vývoj, různé přístupy k řešení, různé problémové oblasti, do kterých vyvíjený software patří, stejně jako různou míru kritičnosti vytvářeného softwaru, různou velikost týmu a další hlediska. Při posuzování určité metodiky je účelné uvažovat následující kritéria kategorizace metodik, která byla definována v [BUCHALCEVOVÁ, 2009]: 1. Zaměření metodiky Toto kritérium zohledňuje skutečnost, zda je metodika zaměřena na budování IS/ICT celé organizace, anebo jen na jednotlivý projekt. Podle něj lze rozlišovat globální metodiky, které se týkají celé organizace a projektové metodiky, které popisují činnosti jen v rámci jednoho projektu. Většina publikovaných metodik patří do kategorie projektových metodik. Jsou to metodiky, které se zaměřují na vývoj, rozvoj či zavedení softwaru v rámci jednoho projektu, pro určitý subsystém. Patří sem i metodika Rational Unified Process (RUP) a všechny agilní metodiky (viz dále). Rostoucí význam

- 39 -

©Alena Buchalcevová Vývoj informačních systémů integrace aplikací a podnikové architektury (Enterprise Architecture) zvyšuje význam globálních metodik. Do kategorie globálních metodik můžeme zařadit metodiku MMDIS, která je popsána v následujících kapitolách. 2. Rozsah metodiky Rozsahem metodiky se zpravidla chápe počet fází životního cyklu informačního systému, které metodika pokrývá. My chápeme rozsah metodiky jako průnik tří hledisek, kterými jsou: fáze životního cyklu, role a dimenze [BUCHALCEVOVÁ, 2009]. Na základě tohoto kritéria se rozlišují metodiky pokrývající celý životní cyklus tvorby a dílčí metodiky, které se zabývají jen částí životního cyklu IS. 3. Váha metodiky Váhu metodiky vymezil A. Cockburn [COCKBURN, 1998], když zavedl charakteristiky metodiky, které označil zkratkou PARTS – precision (podrobnost), accuracy (přesnost), relevance (relevance), tolerance (tolerance), scale (měřítko). Od těchto charakteristik potom odvodil pojmy velikost, hustota a váha metodiky. Velikost metodiky (methodology size) vyjadřuje počet kontrolních prvků obsažených v metodice. Hustota metodiky (methodology specific density) vyjadřuje míru podrobnosti a těsnost tolerance metodiky, požadovanou podrobnost a konzistenci prvků. Váha metodiky (methodology weight) je potom součin velikosti metodiky a hustoty metodiky [COCKBURN, 1998]. V rámci tohoto kritéria, rozlišujeme těžké (rigorózní )metodiky, které jsou zpravidla založeny na vodopádovém životním cyklu a jsou velmi podrobné a lehké metodiky, které jsou označovány jako minimálně dostatečná metodika. 4. Typ řešení Informační systém se dnes zpravidla nevytváří na zelené louce, ale často se rozšiřuje stávající řešení, anebo se provádí integrace řešení. Některé části IS/ICT si mohou organizace zajišťovat také formou Application Service Provision či jiné formy outsourcingu. Další alternativou je implementace typového aplikačního softwaru. Je zřejmé, že metodika implementace typového aplikačního softwaru se liší od metodiky vývoje softwaru. V rámci tohoto kritéria se rozlišuje vývoj nového řešení, integrace řešení, rozvoj a rozšíření řešení (upgrade), customizace a implementace typového řešení a užití řešení. 5. Doména Kritérium Doména má smysl uplatnit v rámci projektových metodik. Metodika pro vytvoření datového skladu je jiná než vybudování workflow či vývoj klasické aplikace. Doména představuje určitou předmětnou oblast, pro kterou je informační systém vytvářen. Kritérium rozlišuje tyto domény: Business Intelligence, Customer Relationship Management, obecný software, Content Management, Enterprise Application Integration, e-commerce, Enterprise Resource Planning. 6. Přístup k řešení Toto kritérium zohledňuje základní paradigma, na kterém je metodika založena. Rozlišují se metodiky pro strukturovaný vývoj, rychlý vývoj aplikací (RAD), objektový vývoj, komponentový vývoj či vývoj orientovaný na služby. V praxi se setkáme s kategoriemi metodik, které jsou kombinací více kritérií. Tradiční (rigorózní ) metodiky jsou „těžké“ metodiky ve smyslu kritéria Váha metodiky. To znamená, že jsou velmi podrobné a formální. Vycházejí z přesvědčení, že procesy při budování IS/ICT lze popsat, plánovat, řídit a měřit, a proto podrobně a přesně definují jednotlivé procesy, činnosti a vytvářené

- 40 -

©Alena Buchalcevová Vývoj informačních systémů produkty. Tradiční metodiky jsou zpravidla založeny na vodopádovém modelu životního cyklu a jsou pro ně typické problémy, které byly uvedeny u tohoto modelu. Mezi tyto metodiky patří například Structured Systems Analysis and Design Method (SSADM) [SSADM, 2000], která byla velmi rozšířena v osmdesátých a devadesátých letech minulého století. Další kategorií metodik jsou těžké metodiky, které jsou ale postaveny na iterativním modelu životního cyklu. Sem můžeme zařadit metodiku Rational Unified Process (RUP), která je téměř standardem mezi těžkými metodikami. Dále bychom do této kategorie mohli zařadit metodiku Microsoft Solutions Framework (MSF). Kategorizace obou těchto metodik, které jsou v dnešní době dost používané, je obtížná. Obě metodiky se postupně doplňovaly o agilní principy a praktiky a dnes je můžeme označit spíše za metodické rámce (frameworks), v jejichž rámci lze vytvořit různé metodiky pro různé typy projektů od těžkých, formálních až po agilní.

6.1. Agilní metodiky Zastánci agilních přístupů jsou přesvědčeni, že software je tak specifický, že proces jeho vývoje nelze předem plně popsat, ale je nutné jej průběžně monitorovat a přizpůsobovat změnám. Proto agilní přístupy nepopisují procesy při vývoji softwaru, ale definují jen principy a praktiky. Každá z agilních metodik je svým způsobem specifická, ale všechny jsou postaveny na stejných principech a hodnotách, které byly v roce 2001 definovány v Manifestu agilního vývoje softwaru [MANIFESTO, 2011] a potom podrobněji rozpracovány do následujících dvanácti principů [MANIFESTO, 2011]: 1. Nejvyšší prioritou je uspokojovat zákazníky včasnou a kontinuální dodávkou softwaru, který jim přináší hodnotu. 2. Změny požadavků jsou vítány i v pozdějších fázích vývoje, neboť změna může poskytnout zákazníkovi konkurenční výhodu. 3. Fungující software je třeba dodávat často (od několika týdnů do několika měsíců) a preferovat kratší dobu. 4. Lidé z byznysu a vývojáři mají denně spolupracovat na projektu. 5. Klíčovým faktorem úspěchu projektu jsou motivovaní jedinci, kteří mají vytvořeny podmínky pro práci a mají podporu vedení. 6. Nejefektivnějším způsobem přenosu informací v týmu je osobní komunikace. 7. Primární mírou úspěchu je fungující software. 8. Agilní procesy podporují udržitelný vývoj. Sponzoři, vývojáři a uživatelé by měli být schopni dodržovat pevnou pracovní dobu. 9. Neustále je třeba se zaměřovat na perfektní technické řešení a návrh, které posilují agilitu. 10. Základním principem je jednoduchost, tj. umění maximalizovat množství neudělané práce. 11. Nejlepší architektury, požadavky a návrhy vznikají ze samoorganizujících se týmů. 12. V pravidelných intervalech se tým zabývá tím, jak pracovat efektivněji a podle toho upravuje své chování. Mezi agilní metodiky byly od počátku řazeny následující metodiky a přístupy:  Dynamic Systems Development Method (DSDM), - 41 -

©Alena Buchalcevová Vývoj informačních systémů  Adaptive Software Development (ASD),  Feature Driven Development (FDD),  Extrémní programování (Extreme Programming, XP),  Lean Development,  Scrum,  Crystal metodiky,  Agilní modelování (Agile Modeling). Tyto metodiky za více než deset let své existence prošly vývojem a změnami a vznikly také nové agilní metodiky. Příkladem je třeba výše zmíněná metodika MSF for Agile Software Development, anebo metodika OpenUP. Metodika OpenUP byla vydána v roce 2007 a je dostupná pod Eclipse Public License.

S

Shrnutí Podrobnější popis jednotlivých metodik budování IS/ICT je v knize [BUCHALCEVOVÁ, 2009], kde také lze nalézt popis systému METES, který umožňuje hodnocení metodik a výběr vhodné metodiky pro určitý typ projektu. Systém METES definuje 26 kritérií hodnocení, podle nichž jsou v knize zhodnoceny nejvýznamnější současné metodiky: Rational Unified Process (RUP), OpenUP, Feature Driven Development (FDD), Scrum, Extrémní programování (XP) a Microsoft Solutions Framework (MSF) for CMMI.

Kontrolní otázky a náměty: 1. Kategorizujte metodiky budování IS a uvedte příklady 2. Jaké jsou základní principy agilních metodik

- 42 -

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

Recommend Documents