Slezská univerzita v Opavě Filozoficko-přírodovědecká fakulta v Opavě METODIKY VÝVOJE SOFTWARE Studijní opora předmětu „UI/AI050 – Metodiky vývoje software“ Mgr. Jiří Martinů Opava 2017 POKYNY KE STUDIU METODIKY VÝVOJE SOFTWARE Pro studium problematiky metodik vývoje software jste obdrželi studijní balík obsahující: • toto skriptum určené pro distanční (kombinované) i prezenční studium • přístup do e-learningového portálu Moodle • harmonogram průběhu semestru a rozvrh prezenční části Prerekvizity Pro studium tohoto předmětu se nepředpokládají žádné předchozí znalosti. . Cílem předmětu je seznámit studenta s metodikami návrhu a implementací softwarového projektu. Po prostudování modulu by měl student chápat smysl využívání metodik vývoje software a modelování, měl by být schopen orientace v různých metodikách, měl by umět popsat základní vlastnosti probíraných metodik a měl by rozumět rozdílu mezi agilními a rigorózními metodikami. Pro koho je předmět určen Modul je zařazen do bakalářského studia oboru Aplikovaná informatika studijního programu B1802 – Aplikovaná informatika, ale může jej studovat i zájemce z kteréhokoliv jiného oboru. Skriptum se dělí na části, kapitoly, které odpovídají logickému dělení studované látky, ale nejsou stejně obsáhlé. Předpokládaná doba ke studiu kapitoly se může výrazně lišit, proto jsou velké kapitoly děleny dále na číslované podkapitoly a těm odpovídá níže popsaná struktura. Při studiu každé kapitoly doporučujeme následující postup: Čas ke studiu: xx hodin Na úvod kapitoly je uveden čas potřebný k prostudování látky. Čas je orientační a může vám sloužit jako hrubé vodítko pro rozvržení studia celého předmětu či kapitoly. Někomu se čas může zdát příliš dlouhý, někomu naopak. Jsou studenti, kteří se s touto problematikou ještě nikdy nesetkali a naopak takoví, kteří již v tomto oboru mají bohaté zkušenosti. Cíl: Po prostudování tohoto odstavce budete umět Popsat … Definovat … Vyřešit … Následují cíle, kterých máte dosáhnout po prostudování této kapitoly – konkrétní dovednosti, znalosti. Výklad Kapitola pokračuje výkladem studované látky, zavedením nových pojmů, jejich vysvětlením; v případě potřeby je látka doplněna obrázky, tabulkami, odkazy, apod. Shrnutí pojmů Na závěr kapitoly jsou zopakovány hlavní pojmy a části kapitoly, které si v ní máte osvojit. Pokud něčemu ještě nerozumíte, vraťte se k výkladové části kapitoly. Otázky Pro ověření, že jste dobře a úplně látku kapitoly zvládli, máte k dispozici několik teoretických otázek. Úspěšné a příjemné studium s tímto učebním textem Vám přeje autor. Jiří Martinů OBSAH 1 ÚVOD DO PROBLEMATIKY: SPECIFIKACE POJMŮ METODOLOGIE, METODIKA (CÍL METODIK), METODA, ROZDĚLENÍ METODIK PRO VÝVOJ SW. PRIMÁRNÍ DŮVODY MODELOVÁNÍ. ŽIVOTNÍ CYKLY VÝVOJE SW. LEHKÉ A TĚŽKÉ METODIKY......................................................................................................... 10 1.1 Základní terminologie............................................................................................ 10 1.2 Rozdělení metodik pro modelování SW............................................................... 11 1.2.1 Přehled jednotlivých kritérií rozdělení metodik............................................... 11 1.3 Primární důvody modelování................................................................................ 13 1.4 Životní cykly vývoje SW........................................................................................ 14 2 VODOPÁDOVÝ PŘÍSTUP K TVORBĚ SW: PRINCIP MODELU, ŽIVOTNÍ CYKLUS, SPECIFIKACE, PLÁN, FÁZE VÝVOJE, MOŽNOSTI POUŽITÍ, NEVÝHODY........................................................................................................................... 17 2.1 Model vodopád ....................................................................................................... 17 2.2 Výhody a nevýhody vodopádového modelu......................................................... 18 2.3 Model výzkumník................................................................................................... 18 2.4 Model prototyp ....................................................................................................... 19 3 ITERAČNÍ/EVOLUČNÍ PŘÍSTUP K TVORBĚ SW: PRINCIP MODELU, ITERACE, ZPĚTNÁ VAZBA, FÁZE ŽIVOTNÍHO CYKLU. SROVNÁNÍ VODOPÁDOVÉHO A ITERAČNÍHO PŘÍSTUPU........................................................... 22 3.1 Iterace...................................................................................................................... 22 3.2 Spirálový model...................................................................................................... 23 3.3 Srovnání vodopádového a spirálového modelu ................................................... 23 4 METODIKA UP: MODELOVACÍ PROCES UP (UNIFIED PROCESS), STRUKTURA JAZYKA UML (UNIFIED MODELING LANGUAGE), NEJPOUŽÍVANĚJŠÍ DIAGRAMY JAZYKA UML, DALŠÍ PRVKY UML, VZTAH UP A UML..................................................................................................................................... 26 4.1 Metodika UP ........................................................................................................... 26 4.2 Struktura UP .......................................................................................................... 29 4.2.1 Stručné shrnutí k metodice UP........................................................................... 32 4.3 Struktura jazyka UML .......................................................................................... 32 4.3.1 Stavební bloky...................................................................................................... 34 4.3.2 Diagram tříd......................................................................................................... 37 4.3.3 Diagram komponent............................................................................................ 39 4.3.4 Diagram složených struktur ............................................................................... 43 4.3.5 Diagram nasazení ................................................................................................ 44 4.3.6 Diagram balíčků .................................................................................................. 45 4.3.7 Diagram objektů.................................................................................................. 47 4.3.8 Diagram profilu ................................................................................................... 50 4.3.9 Diagram aktivit.................................................................................................... 51 4.3.10 Diagram užití ....................................................................................................... 53 4.3.11 Stavový diagram.................................................................................................. 54 4.3.12 Sekvenční diagram .............................................................................................. 60 4.3.13 Diagram komunikace .......................................................................................... 64 4.3.14 Diagram interakcí................................................................................................ 68 4.3.15 Diagram časování ................................................................................................ 70 4.4 Vztah UP a UML.................................................................................................... 71 5 METODIKA RUP A EUP: RUP (RATIONAL UNIFIED PROCESS) CHARAKTERISTIKA, ZPŮSOB DISTRIBUCE, NOTACE, ZÁKLADNÍ ELEMENTY, POSLOUPNOST AKCÍ. EUP SROVNÁNÍ A SPOLEČNÉ APLIKACE S RUP. .......... 75 5.1 RUP (Rational Unified Process)............................................................................ 75 5.1.1 Charakteristika RUP........................................................................................... 75 5.1.2 Způsob distribuce RUP....................................................................................... 76 5.1.3 Notace RUP.......................................................................................................... 77 5.1.4 Základní elementy RUP...................................................................................... 77 5.1.5 Posloupnost akcí RUP ......................................................................................... 80 5.2 EUP (Enterpsise Unified Process)........................................................................ 80 5.2.1 Charakteristika EUP........................................................................................... 80 5.2.2 Způsob distribuce EUP ....................................................................................... 82 5.2.3 Notace EUP .......................................................................................................... 82 5.2.4 Základní elementy EUP ...................................................................................... 82 5.2.5 Posloupnost akcí EUP ......................................................................................... 82 6 AGILNÍ PŘÍSTUP K TVORBĚ SW: VÝHODY AGILNÍCH METODIK (RYCHLOST, WEBOVÉ TECHNOLOGIE, ITERATIVITA, INKREMENTACE). MANIFEST AGILNÍHO VÝVOJE SW (THE AGILE MANIFESTO)........................... 85 6.1 Agilní metodiky ...................................................................................................... 85 6.2 Manifest agilního vývoje SW................................................................................. 86 6.3 Omezení rizik při agilním přístupu ...................................................................... 87 6.4 Složení týmu agilního vývoje................................................................................. 88 6.4.1 Doplnění týmových rolí u projektů většího rozsahu ........................................ 90 6.5 Koordinace činností................................................................................................ 92 7 METODIKY ADS, DSDM, FDD, XP: ADS (ADAPTIVE SOFTWARE DEVELOPMENT ), DSDM (DYNAMIC SYSTEMS DEVELOPMENT METHOD), FDD (FEATURE-DRIVENDEVELOPMENT), CHARAKTERISTIKY, VÝHODY, PRINCIPY VÝVOJE, SROVNÁNÍ. EXTREME PROGRAMMING (XP), CHARAKTERISTIKA A VÝHODY XP............................................................................. 95 7.1 ASD (Adaptive Software Development) - Adaptivní vývoj SW......................... 95 7.2 FDD (Feature-Driven Development) .................................................................... 96 7.3 XP (Extreme Programming) - Extrémní programování .................................... 97 7.4 DSDM - Dynamic Systems Development Method............................................... 99 7.5 Lean Development................................................................................................ 102 8 METODIKY ADS, DSDM, FDD, XP: ADS (ADAPTIVE SOFTWARE DEVELOPMENT ), DSDM (DYNAMIC SYSTEMS DEVELOPMENT METHOD), FDD (FEATURE-DRIVENDEVELOPMENT), CHARAKTERISTIKY, VÝHODY, PRINCIPY VÝVOJE, SROVNÁNÍ. EXTREME PROGRAMMING (XP), CHARAKTERISTIKA A VÝHODY XP........................................................................... 105 8.1 SCRUM ................................................................................................................. 105 8.1.1 Role v metodice Scrum...................................................................................... 106 8.1.2 Průběh práce v metodice Scrum ...................................................................... 108 8.2 Crystal metodiky .................................................................................................. 111 9 SW NÁSTROJE: CASE NÁSTROJE A JEJICH ROZDĚLENÍ (PRE, UPPER, MIDDLE, LOWER, POST). IDE NÁSTROJE. CASE IDE NÁSTROJE, PŘEHLED VYBRANÝCH NÁSTROJŮ (CASE STUDIO, ORACLE DESIGNER)........................ 118 9.1 Obecná charakteristika CASE nástrojů ............................................................ 118 9.2 Dělení CASE nástrojů.......................................................................................... 119 9.2.1 Dělení podle životního cyklu projektu............................................................. 120 9.2.2 Dělení podle interaktivity.................................................................................. 121 9.2.3 Dělení podle fáze projektu ................................................................................ 121 9.2.4 Dělení podle délky využívání ............................................................................ 121 9.2.5 Dělení podle stupně integrace........................................................................... 121 9.3 Použití CASE nástrojů v průběhu vývoje IS ..................................................... 122 9.4 Příklady nástrojů CASE...................................................................................... 122 9.4.1 Enterprise Architect (Sparx Systems) ............................................................. 122 9.4.2 Case Studio......................................................................................................... 123 9.4.3 Oracle Designer (Oracle) .................................................................................. 124 9.4.4 Další CASE nástroje.......................................................................................... 124 10 TRENDY V OBLASTI MODELOVÁNÍ SW: AKTUALITY, VÝVOJ, VÝZKUM, TECHNICKÉ NOVINKY V OBORU SW INŽENÝRSTVÍ............................................ 126 10.1 Obecné trendy v oboru softwarového inženýrství .......................................... 126 10.2 UML a MDA....................................................................................................... 127 10.2.1 Modelování v MDA a členění modelů.............................................................. 127  10.1.1.1 Notace v BPMN .................................................................................... 128 10.3 Automatizace modelování ................................................................................. 131 1 ÚVOD DO PROBLEMATIKY: SPECIFIKACE POJMŮ METODOLOGIE, METODIKA (CÍL METODIK), METODA, ROZDĚLENÍ METODIK PRO VÝVOJ SW. PRIMÁRNÍ DŮVODY MODELOVÁNÍ. ŽIVOTNÍ CYKLY VÝVOJE SW. LEHKÉ A TĚŽKÉ METODIKY. V této kapitole se seznámíme se základními pojmy oblasti metodik vývoje software a s důvody, proč se metodiky a modelování používají. Dozvíme se rovněž, podle jakých kritérií metodiky dělíme a objasníme pojem životní cyklus vývoje software. Čas ke studiu: 2 hodiny Cíl: Po prostudování této kapitoly budete umět Definovat základní pojmy z oblasti metodik vývoje software a modelování. Objasnit důvody modelování. Objasnit pojem životní cyklus při vývoji software. Rozdělit metodiky vývoje software podle různých kritérií. Objasnit rozdíly mezi tzv. lehkou a těžkou metodikou. Výklad 1.1 Základní terminologie  metoda (z řeckého met-hodos – cesta za něčím) je návod či postup získávání poznatků. Jinými slovy jde o prostředek poznání. Odpovídá na otázku: JAK dosáhnout vytýčeného cíle? Zaměřuje se na určitou etapu vývoje SW.  metodika obecně je nauka o metodě nebo pracovní postup. Jedná se o doporučený souhrn etap, přístupů, zásad, postupů, pravidel, metod, technik, nástrojů, dokumentů, metod řízení, atd. Odpovídá na otázky typu CO, KDY KDO, PROČ. Ve vývoji software představuje metodika souhrn doporučených praktik a postupů, pokrývajících celý životní cyklus vytvářené aplikace. Pro řešení dílčích problémů se v rámci nasazení metodik uplatňují specifické postupy – metody.  metodologie je vědní disciplína, zabývající se metodami, jejich tvorbou a aplikací.  technika – takto nazýváme postupy kroků, jak se dobrat k výsledku, např. normalizace datového modelu, prototypování.  nástroj – prostředek k provedení něčeho, k zobrazení výsledku apod. Jedná se např. o modely systému, CASE nástroje.  projekt – množina souvisejících činností určených pro splnění daného cíle. Projekt musí mít přiděleny zdroje (lidské zdroje, finanční zdroje, čas…) a je nutné zajistit jeho řízení (manažer). Projekt má rovněž svého zadavatele (odběratele). 1.2 Rozdělení metodik pro modelování SW Metodiky je možné klasifikovat podle různých kritérií a přístupů, jako např. podle zaměření, rozsahu metodiky, váhy metodiky, typu řešení, domény, přístupu, atd. Stručný přehled rozdělení metodik je uveden v následující tabulce, v dalším textu je pak uveden jejích bližší popis: Tab. 1.1 – Rozdělení metodik podle různých kritérií Kritérium Kategorie/ vysvětlení zaměření metodiky globální projektové rozsah metodiky fáze – role - dimenze váha metodiky velikost metodiky x hustota metodiky typ řešení vývoj nového řešení, rozšíření stávajícího řešení, integrace řešení, implementace typového řešení, užití řešení například formou ASP doména ERP, CRM, SCM, EAI… přístup k řešení Strukturovaný, objektově orientovaný… 1.2.1 Přehled jednotlivých kritérií rozdělení metodik V této podkapitole uvádíme stručný popis rozdělení metodik podle kritérií uvedených v tabulce 1.  Kritérium zaměření metodiky: Globální - metodiky vývoje SW v rámci celého podniku či organizace. Patří mezi ně tzv. enterprise metodiky, např. MMDIS, Enterprise Unified Process (EUP), atd. Projektové – v rámci vývoje daného SW se zabývají pouze určitou částí SW.  Kritérium rozsahu: Rozeznáváme metodiky, které se zabývají celým životním cyklem vývoje SW (např. MMDIS, atd.) a metodiky, zabývající se jen určitou částí (etapou) vývoje SW. Posledním uvedeným metodikám říkáme dílčí metodiky.  Kritérium váhy (podrobnosti) metodiky: Těžké metodiky – vyžadují podrobný popis a jsou tzv. rigorózní, tzn. přísné, precizní, přesné. Lehké metodiky – jejich vlastností je, že musí být „barely sufficient“ (Cockburn), volně přeloženo jako „sotva (téměř) dostatečné“ anebo „a little less than just enough“ (Highsmith), což je možno volně přeložit jako „trochu méně než dostatečné“. Mezi lehké metodiky patří tzv. agilní metodiky, o kterých bude řeč dále.  Kritérium přístupu k vývoji: Podle kritéria přístupu k vývoji můžeme metodiky rozdělit na: Strukturované metodiky – založené na principech strukturovaného programování RAD (Rapid Application Development) – založený na iterativním přístupu Objektově orientované metodiky – založené na principech objektově orientovaného programování  Kritérium způsobu vývoje: Toto kritérium dělení metodik zahrnuje zejména:  konvenční metodiky s životním cyklem typu vodopád (viz dále)  metodiky přírůstkového a iterativního vývoje  Kritérium domény: Obrázek 1-1Rozdělení metodik vývoje software podle kritéria domény 1.3 Primární důvody modelování Důvodů pro modelování při vývoji SW je celá řada. Modelování slouží k návrhu vztahů mezi dílčími částmi navrhovaného SW systému (např. modulů, objektů), jejich přehlednému zobrazení, návrhu spolupráce a interakce mezi nimi, k návrhu vstupů a výstupů jednotlivých komponent a celkové analýze vyvíjeného SW. Díky vyspělým modelovacím a analytickým nástrojům poskytuje modelování účinný způsob, jak zabránit vzniku a zdlouhavému a neefektivnímu odstraňování chyb vycházejících z „nedomyšlených“ částí kódu. Odhaluje slabá místa navrhovaného systému. Modelování poskytuje rovněž podpůrný prostředek pro tvorbu dokumentace. Usnadňuje spolupráci mezi jednotlivými členy vývojového týmu jasným vymezením úkolů. Modelování vymezuje vznik a životní cykly objektů, procesů a dalších komponent a vede k vytvoření správně navrženého, přehledného, bezpečného a dobře zdokumentovaného SW produktu. 1.4 Životní cykly vývoje SW Pojem životní cyklus je nedílnou součástí každého projektu zaměřeného na vývoj SW: Pod tímto pojmem rozumíme návaznost jednotlivých etap procesu vývoje. Etapy si můžeme představit jako jednotlivé části skládačky (např. kostky, které skládáme do nějakého výsledného tvaru). Každá část skládačky má své definované vlastnosti, jakými jsou např. vstupy a výstupy, data dokončení, atd. Bez hotové části skládačky neleze přidat její další díl, neboli bez ukončené etapy nelze pokračovat v další etapě. Výsledný tvar utvořený z těchto jednotlivých dílů pak tvoří životní cyklus vývoje SW. Existuje celá řada obecně uznávaných etap životního cyklu vývoje SW. Zde uvádíme 2 nejpoužívanější: (Řepa, V. Analýza a návrh informačních systémů. Ekopress, Praha 1999, ISBN 80- 86119-13-0. str. 17-19):  cíl etapy (proč etapa má být provedena a co je jejím výsledkem),  účel a obsah etapy (popis role etapy v celém vývoji systému, shrnutí činností prováděných v etapě),  předpoklady zahájení etapy (kdy je možné začít s pracemi v rámci dané etapy),  kritéria ukončení etapy (kdy je možné prohlásit etapu za ukončenou),  klíčové dokumenty etapy (seznam dokumentů, vyprodukovaných nebo upravených v dané etapě, které musí být schváleny vedením projektu),  kritické faktory etapy (na co je třeba v etapě dávat největší pozor, faktory, které mohou způsobit problémy při vývoji),  činnosti etapy (seznam a popis činností, které se v etapě provádějí),  návaznosti činností v etapě (graficky vyjádřená návaznost a souběžnost provádění jednotlivých činností etapy). (Kendall, K.E. Systém Analysis and Design. Prentice Hall, 1991):  zachycení požadavků na systém (týká se funkčnosti, designu, návaznosti na jiné systémy, integrace s ostatními systémy, reakční doby atd.),  tvorba konceptuálního modelu (zachycení skutečností v rámci modelu),  tvorba implementačního modelu (jedná se již o konkrétní návrh IS),  implementace a zavedení,  testování,  udržování systému a provoz  stažení systému z užívání. Shrnutí pojmů 1.1. V této kapitole jsme se seznámili se základní terminologií z oblasti vývoje software. Objasnili jsme pojmy jako: • metoda • metodika • metodologie • technika • nástroj • projekt Uvedli jsme si rozdělení metodik do kategorií dle následujících kritérií: • zaměření metodiky • rozsah metodiky • váha metodiky • typ řešení • doména • přístup k řešení V další části jsme se naučili rozlišovat pojmy lehká a těžká metodika a seznámili se s pojmem životní cyklus a důvody modelování. Otázky 1.1. 1. Objasněte pojmy metoda, metodika, projekt, technika, nástroj 2. Jaké jsou hlavní vlastnosti projektu, co musí splňovat? 3. Proč provádíme modelování? 4. Co znamená termín „životní cyklus“ vývoj SW? 5. Jaká znáte kritéria rozdělení metodik? 2 VODOPÁDOVÝ PŘÍSTUP K TVORBĚ SW: PRINCIP MODELU, ŽIVOTNÍ CYKLUS, SPECIFIKACE, PLÁN, FÁZE VÝVOJE, MOŽNOSTI POUŽITÍ, NEVÝHODY. V této kapitole se seznámíme s vodopádovým modelem vývoje SW, jeho vlastnostmi, výhodami a nevýhodami. Čas ke studiu: 2 hodiny Cíl: Po prostudování této kapitoly budete umět Definovat pojem vodopádový model. Objasnit hlavní vlastnosti vodopádového modelu. Vyjmenovat fáze vodopádového modelu. Objasnit výhody a nevýhody vodopádového modelu. Výklad 2.1 Model vodopád znázorňuje určitý idealizovaný stav – posloupnost na sebe navazujících etap bez cyklických návratů zpět. V praxi by bylo vhodné jej dodržovat, většinou to však není možné, proto má tento model význam spíše teoretický a slouží jako základní myšlenkový postup pro studium etap životního cyklu. Obrázek 2-1Model vodopád Jak vyplývá z obrázku 1, model vodopád má následující fáze (etapy): • specifikace zadání, stanovení požadavků • analýza a návrh SW • implementace – nasazení SW • verifikace – testování a integrace • provoz a údržba 2.2 Výhody a nevýhody vodopádového modelu Výhody vodopádového modelu • jednoduchý z hlediska řízení • při stálých požadavcích: nejlepší struktura výsledného produktu Nevýhody vodopádového modelu • zákazník není schopen přesně stanovit veškeré požadavky předem • při změnách požadavků má tento model dlouhou dobu realizace • zákazník vidí spustitelnou verzi až v závěrečných fázích projektu, z čehož vyplývá, že např. nedostatky jsou odhaleny příliš pozdě (fáze verifikace) a jejich odstranění vede k navýšení čerpání zdrojů. Dalšími typy modelů vývoje SW jsou modely výzkumník a prototyp. 2.3 Model výzkumník je uváděn spíše jako negativní případ přístupu k vývoji IS. Jeho použití svědčí o tom, že řešitelský tým neovládá dobře danou problematiku, získává postupně zkušenosti v oblasti, pro kterou je IS určen. Za takovýchto okolností je doba etap těžce plánovatelná. U rozsáhlejších IS lze takový přístup použít (bez negativních následků) jen stěží. Obrázek 2-2 Model výzkumník 2.4 Model prototyp jde o aplikaci plánovaného a řízeného inkrementálního přístupu k vývoji IS. Pod pojmem „prototyp“ rozumíme částečnou implementaci produktu (části IS) v logické nebo fyzické formě, která by měla reprezentovat všechna vnější rozhraní systému. Uživatelé IS se s prototypem seznamují a testují jej. Na základě jejich připomínek je upřesňována specifikace požadavků na systém, prototyp je upravován a dále doplňován až do podoby výsledného systému. Na rozdíl od typu „výzkumník“ zde vycházíme z řádné analýzy a návrhu systému, jehož součástí je i rozsah prototypu v jednotlivých stupních vývoje. Stupně vývoje prototypu jsou plánované a jeho vývoj je řízen podle předem stanovených pravidel. Obrázek 2-3 Model prototyp Shrnutí pojmů 2.1. V této kapitole jsme si objasnili pojem vodopádový model. Uvedli jsme jeho hlavní etapy: • specifikace zadání, stanovení požadavků • analýza a návrh SW • implementace – nasazení SW • verifikace – testování a integrace • provoz a údržba Dozvěděli jsme se také, jaké jsou jeho výhody a nevýhody a důvody, proč vodopádový model není v praxi příliš využíván. Otázky 2.1. 1. Kdy se používá model vodopád? 2. Jaké znáte fáze modelu vodopád? 3. Jaké jsou výhody/nevýhody modelu vodopád? 3 ITERAČNÍ/EVOLUČNÍ PŘÍSTUP K TVORBĚ SW: PRINCIP MODELU, ITERACE, ZPĚTNÁ VAZBA, FÁZE ŽIVOTNÍHO CYKLU. SROVNÁNÍ VODOPÁDOVÉHO A ITERAČNÍHO PŘÍSTUPU. V této kapitole se seznámíme s iterativním přístupem k vývoji software a se spirálovým modelem a jeho vlastnostmi. Uvedeme rovněž hlavní etapy spirálového modelu a rozdíly mezi vodopádovým a spirálovým modelem vývoje SW. Čas ke studiu: 2 hodiny Cíl: Po prostudování této kapitoly budete umět Definovat pojem iterace (iterační přístup). Objasnit hlavní vlastnosti spirálového modelu. Vyjmenovat základní etapy spirálového modelu. Uvést hlavní rozdíly vodopádového a spirálového modelu. Výklad 3.1 Iterace Iterace = opakování. Model zahrnuje vývoj SW v iteracích. Tento iterativní přístup má následující vlastnosti: • v průběhu každé iterace je vytvořen reálný výsledek. Zadavatel má po každé iteraci příležitost zhodnotit a zkontrolovat výsledek a srovnat jej se svými požadavky. To má za následek rychlejší a pružnější odhalení chyb ve specifikaci • zadavatel je účastníkem vývoje, členem týmu. Podílí se minimálně na kontrolních bodech, tzv. milestones. • Iterativní přístup klade vyšší nároky na řízení v porovnání např. s vodopádovým (neiterativním) modelem. • Vzhledem k vyšším nárokům na řízení a změny během jednotlivých iterací má iterativní model potenciálně horší výslednou strukturu. Příkladem modelu s iterativním přístupem je spirálový model. 3.2 Spirálový model Spirálový model je odvozen od vodopádového modelu. Zásadním způsobem však mění přístup a oproti vodopádovému modelu má dvě odlišné vlastnosti: • iterativní přístup • podrobná analýza rizik Pokud u spirálového modelu chceme přejít do další fáze (etapy), je nutné provést důslednou analýzu možných problémů a rizik. Analýza rizik je prováděna v každém cyklu a je určujícím faktorem pro další směr projektu. Pod pojmem riziko se rozumí libovolná událost či situace, která by mohla mít dopad na projekt, a která by jej mohla ohrozit. Každému riziku je v průběhu analýzy přiřazena jeho nebezpečnost a pravděpodobnost výskytu. 3.3 Srovnání vodopádového a spirálového modelu Vodopádový model se stal téměř nevyhovujícím v případech, kdy bylo nutné stanovit úplnou a přesnou specifikaci požadavků. Lepším přístupem na počátku je pouze stanovení rámce architektury a funkčnosti navrhovaného systému, což umožňuje např. spirálový model. V průběhu vývoje jsou pak upřesňovány a rozpracovávány jednotlivé detaily. Tento iterativní přístup, který lze chápat jako cyklické opakování, se v době svého vzniku stal přelomovým přístupem v chápání životního cyklu vývoje software. Spirálový model je možné rozdělit na čtyři základní etapy. Pro lepší představu si jednotlivé etapy můžeme znázornit ve formě kvadrantů, obrázek 2: Obrázek 3-1Spirálový model • analýza - v této etapě se stanovují cíle, alternativy a rozsah cyklu (iterace). • vyhodnocení – v této etapě jsou vyhodnoceny alternativy, řešení rizik a jejich identifikace. • vývoj – tato etapa slouží k vývoji produktu a ke kontrole očekávaných výsledků. • plánování – je etapa, ve které se plánuje následující iterace. Na počátku každého cyklu jsou identifikovány subjekty mající vliv na průběh iterace, včetně jejich podmínek ovlivňujících úspěch iterace. Po dokončení cyklu je provedena revize a předání. Při každém průchodu spirálou dochází k rozpracovávání dané problematiky na stále vyšším stupni. Kromě toho základního dělení na 4 etapy se můžeme setkat i s dělením spirály na podrobnější etapy – specifikace, analýza, návrh, implementace, zavádění, analýza rizik. Princip zůstává, samozřejmě, stejný jako u základního spirálového modelu – při každém průchodu etapou dochází k detailnějšímu rozpracování a zjemňování návrhu. Graficky lze tento model znázornit jako na obrázku 3-2. Obrázek 3-2 Jiný typ spirálového modelu Shrnutí pojmů 3.1. V této kapitole jsme si objasnili další z modelů – spirálový model a uvedli si jeho hlavní vlastnosti a výhody v porovnání s vodopádovým modelem. Uvedli jsme si čtyři hlavní etapy spirálového modelu: • analýza • vyhodnocení • vývoj • plánování Otázky 3.1. 1. Co znamená pojem iterativní přístup? 2. Jaké jsou nejdůležitější rozdíly mezi vodopádovým a spirálovým modelem? 3. Uveďte hlavní etapy spirálového modelu a popište, co se během těchto etap provádí. 4 METODIKA UP: MODELOVACÍ PROCES UP (UNIFIED PROCESS), STRUKTURA JAZYKA UML (UNIFIED MODELING LANGUAGE), NEJPOUŽÍVANĚJŠÍ DIAGRAMY JAZYKA UML, DALŠÍ PRVKY UML, VZTAH UP A UML. V této kapitole se seznámíme s modelovacím procesem UP, strukturou a významem jazyka UML, a uvedeme si diagramy jazyka UML využívané k modelování vývoje software. Zvládnutí kapitola bude, vzhledem k počtu diagramů UML a celkovému obsahu, časově náročnější – doporučujeme proto rozdělit si učivo do menších celků, učit se postupně a zkusit si rovněž diagramy prakticky nakreslit. Čas ke studiu: 6 hodin Cíl: Po prostudování této kapitoly budete umět Objasnit principy metodiky UP. Uvést, k čemu se využívá UML. Vyjmenovat základní diagramy UML a objasnit jejich účel. Orientovat se ve vztahu mezi UP a UML. Výklad 4.1 Metodika UP Metodika UP – Unified Process (unifikovaný nebo jednotný proces) vychází z průmyslového standardu SEP – Software Engineering Process. UP je jen zkrácené označení průmyslového standardu USDP – Unified Software Development Process (unifikovaný proces vývoje software). Jednoduše řečeno, jedná se o generický proces pro jazyk UML – Unified Modeling Language (unifikovaný modelovací jazyk). Jde pouze o základní, generickou a otevřenou metodiku, kterou je možné uzpůsobit jakémukoli rozsahu projektu. Metodika UP musí být přizpůsobena cílům a podmínkám daného vývoje, tzn. používaným normám, šablonám, nástrojům, atd. Unifikovaný proces (UP) znamená:  řízení požadavky a případy užití.  řízení rizikem.  základ na architektuře.  iterativní a přírůstkový proces vývoje SW produktu. UP je rozdělen do jednotlivých iterací, z nichž každá prochází pěti základními pracovními procesy:  stanovení požadavků  analýza  návrh  implementace  testování  iterace v UP Iterace je klíčovým prvkem UP. Každou iteraci v UP můžeme chápat jako samostatný dílčí projekt, který má své etapy (jako každý projekt). Etapy iterace v UP jsou tvořeny následujícími činnostmi (aktivitami):  plánování  analýza a návrh  implementace  integrace a testování  interní nebo externí uvedení Jednotlivé iterace mohou probíhat i paralelně. To dovoluje souběžnost a flexibilitu prací u velkých projektů. Obrázek 4-1 Hlavní aktivity iterací v UP Iterace a přírůstky Každá iterace v UP vytváří tzv. baseline, tj. základní linii. Základní linie představuje souhrn schválených a revidovaných prvků. Skýtá určitý základ pro následné přezkoumání a vývoj. Iteraci je možné měnit pouze prostřednictvím formálních metod správy změn a konfigurace. A co jsou přírůstky? Přírůstky jsou rozdílem mezi dvěma následnými základními liniemi. Proto je „metodika iterací a přírůstků“ častým synonymem pro UP. 4.2 Struktura UP Obrázek 4-2 Struktura UP. Zdroj: http://fei.mtrakal.cz/materialy_public/7.semestr/%5B2010- 2011%5DINPSW_Simerda/prednasky/02_UPIntroduction.pdf Každá etapa (fáze) může být tvořena jednou či více iteracemi. Kolik takovýchto iterací bude, se vždy odvíjí od velikosti daného projektu. Každá etapa je ukončena tzv. milníkem (milestone). U každé z etap je nezbytné zvážit:  soustředění se na základ pracovního postupu  cíl(-e) etapy  konečný milník etapy Jak je zřejmé z obrázků 4-2 a4-3, každá aktivita v UP má několik fází:  zahájení  rozpracování  realizace (konstrukce)  zavedení Obrázek 4-3 Etapy (fáze) metodiky UP. Zdroj: http://fei.mtrakal.cz/materialy_public/7.semestr/%5B2010- 2011%5DINPSW_Simerda/prednasky/02_UPIntroduction.pdf Podívejme se nyní na tyto fáze podrobněji. Činnosti fáze zahájení: Požadavky – zvážení důvodů projektu, jeho přínosů a nejdůležitějších požadavků. Analýza – při této činnosti je analyzována a stanovena proveditelnost. Návrh – navrhují se určité technické prototypy. Implementace – určují a vytváří se koncepce technických prototypů. Testování – ve fázi Zahájení se testování neprovádí. Cíle fáze zahájení:  stanovení proveditelnosti projektu, vytvoření koncepcí a technických prototypů  tvorba obchodních případů  určení klíčových požadavků a přínosu systému  určení kritických rizik Milník fáze zahájení:  definovány klíčové požadavky, které musí být odsouhlaseny investorem  definovány systémové vlastnosti  tvorba spustitelného architektonického základu  odhad rizik  obchodní případy  investor souhlasí s cílem projektu Činnosti fáze rozpracování: Požadavky – upřesnění rozsahu systému a požadavků, které na něj jsou a budou kladeny. Analýza – při této činnosti se stanovuje, co budeme vytvářet. Návrh – vytvoření stabilní architektury. Implementace – vytvoření spustitelného architektonického základu. Testování – testování spustitelného architektonického základu. Cíle fáze rozpracování:  vytvoření spustitelného architektonického základu  další upřesnění odhadu rizika a definice požadavků a vlastností kvality  určení klíčových požadavků pro 80% funkčních požadavků  vytvoření přesného plánu konstrukční fáze  formulace nabídky zahrnující všechny zdroje – prostředky, čas, vybavení, personál a náklady Milník fáze rozpracování:  vytvoření robustního spustitelného architektonického základu  je evidován odhad rizik  byl vytvořen plán projektu do takové hloubky, aby umožnil vytvoření nabídky  obchodní případ byl porovnán s plánem  uživatelé odsouhlasili pokračování 4.2.1 Stručné shrnutí k metodice UP UP zahrnuje řízení rizik a případů užití, soustředění se na architekturu, iterace a přírůstky, vytvoření softwarového produktu. UP má 4 etapy (fáze): • zahájení • rozpracování • realizace • zavedení Každá z iterací má 5 procesů: • požadavky • analýza • návrh • implementace • testování 4.3 Struktura jazyka UML Jazyk UML (Unified Modelling Language) je nástrojem sloužícím ke grafickému modelování - dokumentaci, vizualizaci a navrhování softwarových systémů. UML podporuje objektový přístup k návrhu, popisu a analýze. Umožňuje modelovat podnikové procesy a systémové funkce, příkazy programovacího jazyka, opětovně použitelné programové komponenty a schémata databází. V UML zavádíme tzv. metamodel – definuje strukturu, kterou musí všechny UML modely mít. Zajímavostí je, že samotný jazyk UML byl pomocí takového metamodelu navrhnut. Jazyk UML je tvořen následujícími hlavními částmi: • stavební bloky – základní prvky modelu, diagramy, vazby (relace) • společné mechanizmy – obecné způsoby, pomocí nichž je v jazyku UML možno dosáhnout specifických cílů • architektura – vizualizace architektury navrhovaného systému Obecně lze říci, že na UML můžeme pohlížet jako na kolekci nebo sadu spolupracujících objektů. To, s jakými objekty či pohledy pracujeme, závisí na požadované úrovni abstrakce. UML má také čtyři hlavní mechanismy – specifikaci, ozdoby, podskupiny a mechanismy rozšiřitelnosti: • Specifikace – každý modelovaný prvek by měl mít textovou specifikaci popisující sémantiku tohoto prvku, jeho smysl a pravidla. • Ozdoby – doplňující informace, které jsou o modelovaném prvku známé. V některých případech postačí vyjádření prvku jednoduchým geometrickým tvarem, avšak v jiných případech je žádoucí doplnit informace o další podrobnosti – ozdoby. Ve většině případů je na počátku modelování informací méně (a tedy i ozdob) a získáváním dalších informací doplňujeme i ozdoby. Použití ozdob závisí i na úrovni abstrakce (např. u některých diagramů vynecháváme nepodstatné podrobnosti (ozdoby), jinde je uvádíme). 1) podskupiny – určují možný způsob rozdělení jednotlivých prvků. Nejčastěji vytváříme dvě třídy podskupin: 2) klasifikátory a instance 3) rozhraní a implementace • mechanismy rozšiřitelnosti – jazyk UML již obsahuje možnosti rozšiřitelnosti používané při přizpůsobování modelování aktuálním potřebám. Mezi tyto mechanismy patří: 1) omezení – uvádí se ve složených závorkách {}. Jedná se o pravidla či podmínky, které je nutno vždy splnit. 2) stereotypy – pomocí stereotypů je možné ze stávajícího prvku vytvořit prvek jiný. Název stereotypu se uvádí do ostrých závorek <>. Stereotypu je možné přiřadit i symbol, což je využíváno například v diagramu nasazení pro tvorbu symbolů zařízení (serverů, tiskáren, počítačů, notebooků atd.) 3) označené hodnoty – tento mechanismus dovoluje přidávat k prvkům modelu nové vlastnosti. Uvádí se ve složených závorkách ve stylu název a hodnota, např. {barva=červená, verze=1.03}. Podívejme se nyní na hlavní části UML podrobněji. 4.3.1 Stavební bloky Stavební bloky jazyka UML jsou tvořeny třemi typy stavebních bloků: • předměty (things) – samotné prvky modelu • vazby, vztahy (relationships) – vazby, které prvky modelu spojují. Určují, jak spolu dva anebo více prvků modelu významově souvisí. • diagramy (diagrams) – jedná se o pohledy na modely UML. Diagramy zobrazují kolekce prvků modelu a vizuálně zobrazují, co bude systém dělat a jak (jakým způsobem) to bude dělat. Na otázku „co?“ nám odpovídají analytické diagramy a na otázku „jak?“ jsou odpovědí návrhové diagramy. Předměty Předměty, jinak nazývané také jako „věci“ nebo „abstrakce“ jsou v UML vyjadřovány podstatnými jmény. I předměty v UML můžeme dále rozdělit na několik následujících kategorií: • strukturní abstrakce (structural things) – např. třídy, interfejsy, spolupráce, aktivní třída, uzel, komponenta, případ užití, atd. • chování (behavioural things) – slouží jako slovesa jazyka UML, např. interakce, stav, apod. • seskupení (grouping things) – balíčky, do nichž jsou seskupovány významově související prvky modelu do soudržných jednotek. • poznámky (annotational things) – anotace, které je možné k modelu připojit takovým způsobem, aby vynikala. Ekvivalentem z reálného světa je např. podtržení nebo zvýraznění žlutou tužkou, atd. Důležitými pojmy jazyka UML jsou pojmy klasifikátor a instance, které je nutno striktně rozlišovat! Klasifikátor je v UML označení pro třídu, kdežto v případě instance jde o označení objektu neboli instance třídy. Relace Určují nebo zobrazují vazby mezi předměty v modelu. Vztahují se na strukturní abstrakce a seskupování. Relace se řídí přesnou sémantikou typů relací, kterou je nutné ovládat a dodržovat. Následující tabulka uvádí stručný přehled relací a jejich grafického znázornění. Diagramy Diagramy jsou grafickou pomůckou pro vizualizaci modelu. Jsou pouze prostředkem, jakým se zobrazují jednotlivé části modelu. Zde je nutné upozornit na častou záměnu nebo domnělou identitu diagramu a modelu. Model není diagram a diagram není model! Diagram je pouze pohled na model. Z diagramu je možné odstranit např. některé vazby nebo předměty, které však v modelu mohou stále existovat. Proto, využíváme-li diagramy k vizualizaci modelu, věnujeme pozornost tomu, aby diagram skutečně reflektoval skutečný stav a podobu modelu. Pokud provedeme úpravy v modelu, měli bychom tyto modifikace přenést rovněž do diagramu a opačně. V UML se používají následující druhy diagramů: strukturní diagramy: • diagram tříd • diagram komponent • diagram složených struktur • diagram nasazení • diagram balíčků • diagram objektů, též se nazývá diagram instancí • diagram profilů diagramy chování: • diagram aktivit • diagram užití • stavový diagram diagramy interakce: • sekvenční diagram • diagram komunikace • diagram interakcí • diagram časování 4.3.2 Diagram tříd Diagram tříd je základním prvkem objektově orientovaného modelování. Je možné jej použít pro obecné koncepční modelování, detailní modelování, pro převod modelů do programového kódu anebo pro modelování dat. Diagram tříd znázorňuje souvislosti mezi objekty, operace u objektů a datové struktury od konceptuální úrovně až po úroveň implementace. Pokud jde o datové struktury – ty jsou v diagramu tříd zařazeny do tříd, u nichž jsou rovněž zobrazeny jejich vztahy. Mimo datové struktury obsahuje diagram tříd rovněž třídy systému s jejich atributy, operacemi a metodami. Jak z názvu diagramu vyplývá, jeho základním prvkem nebo objektem jsou třídy. Grafické znázornění tříd je v diagramu tříd rozděleno do třech částí: Horní část – obsahuje název třídy (tučným písmem). Podle určitých konvencí, které je na místě dodržovat, začíná název třídy velkým písmenem. V případě víceslovného názvu třídy je vhodné použít tzv. velbloudí styl (CamelCase) – mezi slovy vynecháme mezery a počáteční písmeno každého slova začneme kapitálkou, např.: VíceslovnýNázevTřídy. Střední část – obsahuje atributy třídy, psané s malým počátečním písmenem. V případě víceslovných názvů atributů používáme rovněž CamelCase, ovšem s malým počátečním písmenem, např.: názevVíceslovnéhoAtributu. Z objektově orientovaných přístupů víme, že atributy definují vlastnosti třídy. Např. pro třídu Uživatel bychom mohli definovat atributy jako jméno, příjmení, telefon, role, apod. Spodní část – obsahuje operace a metody, které daná třída provádí. Typografická konvence je shodná s atributy – názvy operací a metod se tedy píší s malým počátečním písmenem a stylem CamelCase. Za názvem metod a operací se píší závorky, aby bylo ihned zřejmé, že se jedná o „funkce“ třídy. Důležitými symboly využívanými u diagramu tříd jsou rovněž znaky, označující viditelnost atributů a metod. Mezi používané symboly patří následující: + označuje viditelnost typu public - označuje viditelnost typu private # označuje viditelnost typu protected / označuje viditelnost typu derived ~ označuje viditelnost typu package Dle výše uvedeného, pohled na třídu v diagramu tříd je znázorněn např. takto: Zakaznik +registrovatZakaznika() +odstranitZakaznika() +archivovatZakaznika() -pracovní zařazení -telefon -adresa Obrázek 4-4 Diagram tříd Vztahy mezi třídami se prostřednictvím diagramů tříd znázorňují pomocí symbolů pro relace (viz předcházející podkapitola 4.3.1). Např. vztah mezi třídou A a B je možné znázornit následovně: A +metody -atributy B +metody -atributy 0 * Obrázek 4-5 Znázornění relace mezi třídami Číslo u symbolu relace udává tzv. mohutnost (multiplicity). Mohutnost určuje, kolik instancí dané třídy může být svázáno s instancí druhé třídy. K pochopení uvedeného nám pomůže následující tabulka a výše uvedený příklad. Podle tabulky je zřejmé, že instance třídy A může být svázána s jednou nebo více instancemi třídy B. 0 0..1 1 0..* 1..* Žádná instance (zcela výjimečně) Žádná nebo právě jedna Právě jedna instance Žádná nebo více instancí Jedna nebo více instancí V diagramu tříd je možné znázornit rovněž asociace, agregace, kompozice, dědičnost, realizace, závislost. K bližšímu nastudování této problematiky odkazujeme na doporučenou literaturu a další zdroje. 4.3.3 Diagram komponent Podle definice komponent v UML se komponentou rozumí část modulárního systému, která zapouzdřuje svůj obsah a jejíž chování či projev lze navenek nahradit. To znamená, že pokud vyjmeme komponentu z funkčního systému a nahradíme ji jinou komponentou, která umožňuje stejné chování a stejné chování požaduje od systému, pak je vše v pořádku. Jako příklad z reálného světa si lze představit např. tranzistor v elektrickém obvodu. Pokud jej vyjmeme a nahradíme jiným typem tranzistoru se shodnými parametry, systém bude nadále funkční. Nemůžeme, ale např. tranzistoru PNP nahradit tranzistorem NPN, byť má podobné pouzdro a rozmístění vývodů. Komponenta (vzhledem k tomu, že se jedná o určitou specializaci třídy) může obsahovat atributy a metody a může se účastnit asociací a generalizací. Může obsahovat vnitřní strukturu a definovat porty. Pro znázornění komponenty používáme opět standardizovaných grafických prvků. Dle specifikace UML 2.0 je pro notaci komponenty použit symbol obdélníku s ikonou dle starší normy umístěné do pravého horního rohu. Obrázek 4-6 Notace komponenty dle starší normy Na obrázku 4-6 je znázorněna ikona komponenty dle starší normy. Uvádíme ji pro úplnost a z toho důvodu, že se s ní stále můžeme setkat u dříve vytvořených modelů. Obrázek 4-7 Současná notace komponenty Komponenta může poskytovat nebo vyžadovat interfejs – rozhraní pro komunikaci s okolím. Podrobná notace komponenty včetně její vnitřní struktury vypadá např. takto: Obrázek 4-8 Podrobná notace komponenty Klíčové slovo <> umístěné nad název komponenty je volitelné, avšak velmi často využívané. Podobně jako u notace třídy v diagramu tříd, i komponenta může obsahovat grafické znázornění vnitřní struktury. Jednotlivé části struktury se zapisují do oddělených prostor obdélníku znázorňujícího komponentu. Tyto části je možné rozdělit na následující prvky“  rozhraní – poskytovaná nebo požadovaná. Označují se klíčovými slovy <> a <>.  realizace – označuje se notací <>  artefakty – označuje se notací <> Rozhraní komponenty je možné znázornit dvěma způsoby. Explicitní reprezentací rozhraní (požadovaných a poskytovaných) s uvedením podrobností anebo jednodušším způsobem s použitím symbolů určených pro znázornění rozhraní. Oba uvedené způsoby jsou uvedeny na následujících obrázcích. Obrázek 4-9 Rozhraní komponenty s uvedením podrobností Obrázek 4-10 Rozhraní komponenty s použitím symbolů V případě, že je nutné komponentu rozdělit na subkomponenty umístěné uvnitř hlavní komponenty. Při tomto pohledu je možné použít znázornění portů a znázornění spojek pro propojení s rozhraními hlavní komponenty. Pro porty a spojky používáme následující grafické znázornění: Obrázek 4-11 Komponenta s portem Obrázek 4-12 Komponenta se složeným (komplexním) portem Obrázek 4-13 Složená spojka Příklad diagramu komponent: Obrázek 4-14 Diagram komponent. Zdroj: http://uml.czweb.org/Diagramy/diagram_komponent.jpg 4.3.4 Diagram složených struktur Diagramy složených struktur zobrazují vnitřní uspořádání klasifikátorů a znázorňují informace, které se obtížně modelují pomocí jiných typů diagramů. Diagramy složených struktur zavádí až UML 2. V předchozích specifikacích UML se tento diagram neobjevuje. Diagramy složených struktur jsou velice silným prostředkem pro znázornění možností klasifikátoru. Připomeňme si, že pojem klasifikátor v UML znamená označení třídy (nikoli tedy její instance – objektu). Diagram složených struktur je tedy prostředkem pro znázornění:  interní struktury klasifikátoru  interakce klasifikátoru s okolím prostřednictvím portů  chování při spolupráci Notace u tohoto typu diagramu je shodná s notací u diagramu tříd. Na obrázku níže je znázorněn příklad diagramu složených struktur. Obrázek 4-15 Diagram složených struktur 4.3.5 Diagram nasazení Diagram nasazení znázorňuje rozmístění HW a dalších zdrojů včetně softwarových komponent, objektů a procesů, které je tvoří. Základním elementem diagramu nasazení jsou uzly (nodes). Uzly jsou vzájemně propojeny komunikačními cestami (communication paths). Uzly mohou v diagramu nasazení zastupovat různé druhy prostředků, např.:  fyzická zařízení – uzel typu <>  typ prostředí zpracování softwaru – např. aplikační server, databázový server, apod. Označuje se jako <>  artefakty – představují fyzické umístění softwaru, většinou soubory, skripty, dokumenty apod. Artefakty často zastupují více komponent (není podmínkou). Příklad diagramu nasazení: Obrázek 4-16 Diagram nasazení, Zdroj: http://uml.czweb.org/Diagramy/diagram%20nasazeni.jpg 4.3.6 Diagram balíčků Jak název napovídá, diagram balíčků je tvořen znázorněním elementů modelů UML zařazených do skupin (typicky např. související třídy, apod.) a případným znázorněním závislostmi mezi těmito skupinami. Balíčky mohou být součástmi jiných balíčků a je možné tak vytvořit hierarchickou strukturu se znázorněním závislostí mezi jednotlivými balíčky. Třídy v jednom balíčku musí mít v rámci tohoto balíčku jednoznačný název. Při tvorbě diagramu balíčků je vhodné dodržovat následující doporučení:  názvy balíčků by měly být jednoduché a popisné  v ostatních diagramech by měly být balíčky použity pouze tehdy, kdy je zpřehlední nebo zjednoduší  v diagramu balíčků by neměly existovat žádné závislosti ve smyčce  diagram balíčků by měl vycházet z diagramu komponent znázorňujícího fyzickou strukturu modelovaného programu. Pomocí diagramu balíčku pak znázorníme logickou strukturu.  do jednoho balíčku by měly být zahrnuty třídy, které jsou na shodné hierarchické úrovni  balíčky jsou na sobě závislé, pokud jsou na sobě jakkoli závislé dva elementy v daných balíčcích. Příklad diagramu balíčků použitého v diagramu užití: Obrázek 4-17 Diagram balíčků. Zdroj: http://uml.czweb.org/Diagramy/diagram_balicku_UC.jpg 4.3.7 Diagram objektů Poznámka: Namísto označení diagram objektů se lze setkat rovněž s názvem diagram instancí. Diagram objektů zobrazuje instance tříd a vztahy mezi těmito instancemi. Jde vlastně o diagram velmi podobný diagramu tříd nebo diagramu komunikace (s vyloučením zpráv). Jak lze předpokládat, diagramy objektů s diagramy tříd úzce souvisí. Stejně, jako je objekt instancí dané třídy, je možné diagram objektů považovat za instancí diagramu tříd. Objekty v diagramu objektů jsou instancemi tříd z diagramu tříd a vazby mezi těmito objekty jsou dány vazbami mezi těmito třídami. Diagramy objektů znázorňují statickou strukturu systému v určitém čase. Využívají se k určování a testování správnosti a přesnosti diagramů tříd, pro znázornění podmínek vzniku událostí a pro pochopení složitých vztahů mezi třídami. Pokud jde o symboliku, je podobná symbolice diagramu tříd s tím rozdílem, že se do hlavní části obdélníku znázorňujícího objekt uvádí obvykle název objektu následovaný dvojtečkou a názvem třídy, jejích je objekt instancí. Takovéto znázornění je nazýváno pojmenovaný objekt. Doplňujícím zobrazením může být o objekt bez názvu – v tom případě se uvádí pouze dvojtečka následovaná názvem třídy, jejíž je daný objekt instancí. Toto znázornění objektu se pak nazývá nepojmenovaný objekt. V případě, že není uvedena třída objektu, dvojtečka se neuvádí. :Třída Název objektu : Třída Název objektu : Třída : Seskupení Obrázek 4-18 Nepojmenovaný objekt Obrázek 4-19 Pojmenovaný objekt Obrázek 4-20 Pojmenovaný objekt s cestou objektu Stejně jako u diagramu tříd, rovněž u diagramu objektů je možné uvést seznam atributů. V tomto případě je však nutno uvést i jejich hodnoty. Název objektu : Třída Atribut typ = 'Hodnota' Atribut typ = 'Hodnota' Atribut typ = 'Hodnota' Atribut typ = 'Hodnota' Atribut typ = 'Hodnota' Atribut typ = 'Hodnota' Obrázek 4-21 Seznam atributů s povinným uvedením hodnot Vzhledem k tomu, že diagram objektů ukazuje stav v daném časovém okamžiku, může být výhodné odlišit objekt, který je právě aktivní. Toto odlišení se provádí zvýrazněním ohraničení symbolu objektu. Objekt je v tomto případě nazýván aktivní objekt. Aktivní objekt řídí tok akcí. Obrázek 4-22 Aktivní objekt Dalším potřebným typem zobrazení v diagramu objektů jsou vícenásobné instance (dané třídy). Značíme takto: Obrázek 4-23 Vícenásobné instance třídy Vazby v diagramu objektů jsou nazývány jako spojení. Reprezentují instance vztahů (vazeb, relací). U spojení (nad jeho symbolem) se uvádí jeho název. Spojení je dynamické, tzn. že nemusí trvat po celou dobu životního cyklu objektu – v čase se může měnit. Podle konvence UML je název spojení podtržený. Název objektu : Třída Speciálním případem spojení je odkazování objektu sama na sebe. Tento druh spojení se užívá v případě, že objekt plní vícero rolí. Název objektu : Třída Obrázek 4-24 Odkazování objektu sama na sebe V případě dynamické změny (změny role objektu a s tím související změny spojení) je pro tuto situace nezbytné vytvořit nový diagram, zachycující novou, aktuální situaci. Obrázek 4-25 Příklad diagramu objektů. Zdroj: https://www.google.cz/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&ved=0ahUKEwj kwuGvj63YAhUM66QKHTxNBTMQjRwIBw&url=http%3A%2F%2Fslideplayer.cz%2Fslide %2F2514668%2F&psig=AOvVaw2uycYnc7xVGKHDsgeYyUVp&ust=1514564706458701 4.3.8 Diagram profilu Diagram profilu slouží ke grafickému znázornění rozšíření pomocí stereotypů. Pracuje na úrovni metamodelu. V UML 1 se tento typ diagramu nevyužíval, zavádí jej až UML 2. Příklad diagramu profilů: Obrázek 4-26 Diagram profilů 4.3.9 Diagram aktivit Diagram aktivit patří mezi diagramy chování. Jeho účelem je zejména modelování procesů a procedurální logiky. Procesy jsou v diagramu aktivit znázorňovány jako posloupnost kroků, jež můžeme v diagramu znázornit jako akce či vnořené aktivity, přičemž  akce jsou kroky, které již dále nedělíme (tzv. atomické kroky). Je to činnost, která se aktivně vykonává uvnitř aktivity. Může se jednat i o vnořenou aktivitu. Obrázek 4-27 Vnořená aktivita. Zdroj: https://cs.wikipedia.org/wiki/Diagram_aktivit#/media/File:AKCE_aktvita_axample.png Akce může být prováděna buďto člověkem s přidělenou rolí anebo systémem. Role a systémy jsou v diagramu aktivit znázorněny jako pole rozdělená čarami. Uvádí se i název aktivity. Každé takové pole obsahuje akce prováděné člověkem nebo systémem. Obrázek 4-28 Znázornění oblastí. Zdroj: https://cs.wikipedia.org/wiki/Diagram_aktivit#/media/File:Swinline.png  vnořené aktivity reprezentují volání dalších procesů (tzn. aktivit). Tyto další aktivity je možné znázornit pomocí dalšího diagramu aktivit. Pořadí jednotlivých kroků v tomto diagramu je určeno řídícím tokem. Na vstupu aktivity je možné předávat aktivitě data nebo objekty ve formě parametrů. Aktivita pak může objekty zase předávat na svém výstupu. Spuštění aktivity je inicializováno po naplnění všech parametrů a přivedení všech řídících toků. Modelovány jsou pouze aktivní akce. Obrázek 4-29 Modelování aktivních akcí. Zdroj: https://cs.wikipedia.org/wiki/Diagram_aktivit#/media/File:Aktivita_example.png 4.3.10 Diagram užití Patří mezi další diagramy znázorňující chování modelu. Diagram užití znázorňuje pohled na modelovaný systém zvenčí. Umožňuje tak pohled na hranice systému. Diagram užití zobrazuje posloupnosti transakcí mezi uživatelem s přidělenou rolí (případně jiným systémem) a systémem, které spolu nějakým způsobem souvisí. Diagram případů užití využívá následující prvky:  případ užití – jedná se o sekvenci akcí mající nějaký vztah s aktéry. Případ užití se značí jako ovál a může zobrazovat i následující vazby: o Include – případ užití zahrnuje nebo obsahuje jiný případ užití, Typickým příkladem může být např. nabídka Soubor -> Otevřít, apod. o Extend – případ užití slouží k rozšíření jiného případu užití. Typickým příkladem je např. Uložit -> Uložit jako, apod. o Generalization – případ užití je určitým případem jiného případu užití.  Účastník (aktér) – popisuje vnější objekty, které vstupují do vztahu s procesy. Může obsahovat následující relace: o Generalization Aktér je značen symbolem postavy (figury). 4.3.11 Stavový diagram Obrázek 4-31 Stavový diagram Obrázek 4-30 Diagram užití. Zdroj: https://en.wikipedia.org/wiki/Use_case_diagram#/media/File:Use_case_ restaurant_model.svg Stavový diagram je další z řady diagramů chování. Jak název napovídá, jedná se o znázornění stavů vývoje systému s konečným počtem stavů. Jinými slovy se dá říci, že se může jednat o konečný stavový automat nebo podobné systémy, které umožňují znázornění stavů objektu a přechody mezi těmito stavy (přechodová funkce). Během průchodu přes určitý stav mohou být vykonávány různé činnosti (aktivity). Podobně jako tomu je u stavových automatů, u stavového diagramu jsou definovány tři základní stavební prvky – přechod, stav a událost. Stavový diagram se vytváří pro prvky, u kterých má toto znázornění (pomocí stavového automatu) nějaký smysl, tzn.: • prvek může reagovat na vnější události. • existenci prvku je možné vyjádřit pomocí množin stavů, událostí a přechodů mezi jeho stavy. • aktuální stav prvku je důsledkem předchozího stavu, neboli prvek se chová způsobem, který je důsledkem předešlého chování. Podívejme se nyní na základní stavební prvky stavového automatu podrobněji: stav – určuje trvání neměnných podmínek v daném systému. Stav vyjadřuje momentální chování prvku (objektu), jeho činnost nebo čekání na událost. Je určen následujícími parametry: • hodnotami atributů objektu • vazbami, které má objekt s ostatními objekty • momentálně vykonávanou činností (aktivitou) Každému stavu je možné přiřadit jakýkoli počet aktivit a akcí, přičemž pod pojmem aktivita (činnost) se rozumí déletrvající proces, který je možno přerušit a pod pojmem akce rychle probíhající nepřerušitelný proces. Všechny akce (každá z nich) jsou přidruženy k vnitřnímu přechodu, který je důsledkem událostí. Vnitřní přechod je významný pro skutečnosti v rámci daného stavu, není však určen k přechodu do jiného stavu. Stav je v diagramu znázorněn obdélníkem s kulatými rohy a názvem nacházejícím se v horní části obdélníka. přechod – je přímým propojením zdrojového a cílového stavu (v uvedeném směru). Jedná se o reakci objektu na určitou událost (její vznik) anebo na dokončení aktivní činnosti. Ke každému přechodu je možné (nikoli však nezbytné) přidat popisek ve tvaru událost[podmínka] /akce. Kterákoli z částí popisku může být vypuštěna. Přechod je tedy definován následujícími vlastnostmi: • událost – spuštění přechodu. Událost může být interní anebo externí. V případě události dokončení aktivity se jedná o tzv. automatický přechod. • podmínka – jedná se o logický výraz (booleovský), který podmiňuje přechod. • akce – činnost vyvolaná při započetí přechodu událost – podle specifikace UML je událost „něco významného, co nastane v určitém čase a prostoru a co nemá trvání“. Událostí může být celá řada, těmi nejdůležitějšími jsou: • událost volání – jedná se o požadavek na vyvolání konkrétní činnosti instance kontextové třídy. Syntaxe události volání by tedy měla být shodná se syntaxí dané činnosti. Zaznamenání tohoto volání objektem pak vyvolává danou činnost a vyvolává událost. V rámci události volání je možné určit posloupnost a pořadí akcí. V tomto případě se jednotlivé akce oddělují středníkem. • událost změny – řadí se do kategorie signálů a jedná se o změnu splnění podmínky z False na True. • časová událost – patří rovněž do kategorie signálů a dochází k ní po uplynutí určité časové periody nebo po splnění časové podmínky. Příkladem může být např. opakování jednou za minutu, jednou za den, pětkrát do měsíce, atd. V souvislosti se stavy je nutné se zmínit rovněž o tzv. pseudostavech. Pseudostavy nejsou stavy v pravém slova smyslu. Prvek (objekt) v pseudostavech nesetrvává, jen jimi prochází. Ve stavovém diagramu se můžeme setkat s několika typy pseudostavů: • počáteční stav – nejedná se o stav, ale o pseudostav. Je výchozím krokem, ze kterého stavový automat přechází do tzv. defaultního stavu. Pro přechod z počátečního stavu není definována žádná událost, s výjimkou události <>, která definována býti může. U přechodu z počátečního stavu k defaultnímu je možno definovat chování. • rozvětvení – přechody vycházejí z jednoho stavu k několika dalším stavům. U těchto přechodů se nedefinují žádné podmínky ani události. Z pseudostavu rozvětvení vedou minimálně dva přechody. • spojení – je opakem rozvětvení. Rovněž se zde nedefinují události ani podmínky. Do pseudostavu spojení vstupují minimálně dva přechody. • rozhodování – jedná se o větvení přechodů na základě podmínek definovaných u výstupních přechodů. Stavový automat vybere ten přechod, jehož podmínka se vyhodnotí jako splněná. Je tedy nezbytné dbát na determinismus. • přechod (přechodový pseudostav) – využívá se k vytvoření složených přechodů (viz dále) mezi stavy. Je obdobou psedostavu rozvětvení a spojení s tím rozdílem, že u výstupních resp. vstupních přechodů jsou definovány podmínky. U těchto přechodů se definují pouze podmínky, nikoli události. • vstupní/výstupní body – zastupují vstupy a výstupy uskutečňující přechody ze složených stavů nebo do nich. • hluboká historie – je pseudostavem zastupujícím poslední nastavení kompozitního stavu po jeho opuštění, včetně vnořených složených stavů. Z tohoto pseudostavu může být vytvořen pouze jediný přechod k některému ze stavů tvořících složený stav, ve kterém se pseudostav hluboké historie nachází. Jde o výchozí přechod, neboť je takto definován stav, ve kterém se systém ocitne tehdy, pokud v hluboké historii není uložena žádná konfigurace stavů (jde o případ, kdy složený stav nebyl ještě aktivní, anebo přešel do koncového stavu). • mělká historie – zastupuje poslední aktivní podstav složeného stavu. Přechod, který vstupuje do prvku mělké historie reprezentuje přechod do posledního aktivního podstavu složeného stavu. Mělká historie může být součástí pouze jednoho prvku složeného stavu. Přechod, jež vystupuje z mělké historie znázorňuje přechod do výchozího stavu v případě, že složený přechod dosud nebyl aktivován a mělká historie je tedy prázdná. Název „mělká“ symbolizuje pouze povrchní paměť konfigurace, neboť si pamatuje jen poslední aktivní stav (poslední aktivní konfiguraci) v rámci podstavu. • ukončení – po dosažení tohoto pseudostavu jsou veškeré činnosti ukončeny. Výjimkou je činnost vykonaná u přechodu do tohoto pseudostavu. • koncový (pseudostav) – ukončení činnosti celého stavového automatu nebo složeného stavu v případě jeho přechodu do koncového stavu. Z tohoto koncového pseudostavu nejsou již definovány žádné další přechody. Tento stav rovněž nemá definovány žádné vnitřní aktivity. Pro znázornění pseudostavů UML využívá následující symboly: Obrázek 4-32 Symboly pseudostavů stavového diagramu. Zdroj: https://upload.wikimedia.org/wikipedia/commons/a/a5/Pseudostavy.PNG?1514543239109 Termínem složený stav označujeme stavy, které obsahují jeden nebo více vnořených stavových automatů. Obrázek 4-33 Složené stavy. Zdroj: https://upload.wikimedia.org/wikipedia/commons/4/4e/Ortogonalni_pseudostavy.PNG?15145 34149436 4.3.12 Sekvenční diagram Účelem sekvenčního diagramu je: • popsat spolupráci mezi objekty, • popsat komunikaci objektů v čase, • identifikovat události (zprávy) vyměňované mezi objekty. Vstupy pro tvorbu sekvenčního diagramu jsou: • slovní scénáře diagramu případů užití, • diagram tříd. Poznámky k tvorbě sekvenčního diagramu: • slouží k popisu interakcí tříd během realizace případu užití, • k popisu vybíráme jen klíčové případy užití, • další přidáváme podle potřeby – iterativní přístup během tvorby. • Sekvenční diagram je dvourozměrným modelem vyvíjeného SW: • na horizontální ose znázorňujeme jednotlivé objekty, • vertikální osa je osou časovou (tzv. životočáry). Příklad sekvenčního diagramu: Obrázek 4-34 Sekvenční diagram Zprávy jsou v sekvenčním diagramu znázorňovány následujícími symboly: Zprávy je také možno větvit: Obrázek 4-35 Sekvenční diagram - příklad větvení Zprávy je možné také předávat opakovaně: Obrázek 4-36 Sekvenční diagram - příklad cyklického opakování V sekvenčním diagramu můžeme využívat i tzv. vnořené bloky. Používáme je zejména pro paralelismus, větvení a cykly: Obrázek 4-37 Použití operátorů větvení a vnořených bloků Obrázek 4-38 Použití operátorů pro smyčky Rozdílem mezi stavovým a sekvenčním diagramem je, že stavový diagram znázorňuje stavy a jejich změny pro každý prvek (objekt) zvlášť, kdežto sekvenční diagram znázorňuje kooperaci vícero objektů v čase. 4.3.13 Diagram komunikace Z názvu diagramu je zřejmé, že znázorňuje určitou formu komunikace, konkrétně toky zpráv, interakce a vzájemné vztahy mezi instancemi tříd. Ve verzích předcházející UML 2 byl tento diagram nazýván diagramem spolupráce. Diagram nezobrazuje pouze objekty, které spolu komunikují, ale objasňuje rovněž, jakým způsobem tato komunikace probíhá. Obrázek 4-39 Ukázka diagramu komunikace mezi mechanikem, skladníkem a přijímacím technikem autoservisu Znázornění změny stavu objektu: Obrázek 4-40 Znázornění změny stavu objektu Další využívaná zobrazení: • vnořování zpráv, • vytvoření objektu, • zrušení objektu. Obrázek 4-41 Tvorba objektu seznam_zakázek Větvení zpráv a cyklus (opakované zasílání zprávy): Obrázek 4-42 Ukázka větvení zpráv Obrázek 4-43 Ukázka opakovaného zasílání zpráv (cyklus) Zaslání zprávy více objektům postupně (sekvenčně):  10: * vyzkoušet() .... defaultně znamená sekvenční zpracování zpráv. Obrázek 4-44 Ukázka sekvenčního zpracování zpráv Zaslání zprávy více objektům najednou (paralelně): • jiný operátor paralelismu zpráv – 10: *// odevzdat úkol(). Obrázek 4-45 Zasílání zpráv více objektům zároveň Vrácení návratové hodnoty: Obrázek 4-46 Vrácení hodnoty "součet" Aktivní objekt: Obrázek 4-47 Ukázka aktivního objektu "Učitel" Synchronizace zpráv: Obrázek 4-48 Znázornění synchronizace zpráv Popis zprávy zahrnuje: • pořadové číslo zprávy, • název zprávy, • případně i parametry v závorkách () • Vztah diagramu komunikace a sekvenčního diagramu: • oba modely - jsou významově ekvivalentní  obsahují stejné informace, jeden je možné převést na druhý, • sekvenční diagram - je organizován v závislosti na čase  zdůrazňuje, co se děje v čase, • diagram spolupráce - popisuje kontext a uspořádání spolupracujících objektů  zdůrazňuje, co se děje v prostoru. Každý z obou diagramů zdůrazňuje svůj úhel pohledu na vyvíjený software. 4.3.14 Diagram interakcí Diagram (přehledu) interakcí je zvláštním případem diagramu aktivit – místo činností zde vystupují interakce. Je kombinací diagramu aktivit a diagramu sekvencí resp. diagramu spolupráce. Zobrazuje řízení toku interakcí během procesu znázorněného diagramem aktivit (např. v průběhu případu užití). Diagram interakcí používáme k modelování obecné cesty (návazností) mezi popisy interakcí, resp. návazností mezi případy užití: Use Case --> Diagram aktivit --> Diagram interakcí (sekvence, spolupráce) --> Diagram přehledu interakcí Pro grafické znázornění využíváme podobného značení jako v diagramech aktivit větvení, souběžnost, cykly: Obrázek 4-49 Diagram interakcí "knihovna". Zdroj: http://orca.xf.cz/ooms/012/012m2_soubory/image001.gif 4.3.15 Diagram časování Diagram časování znázorňuje průchod objektu jednotlivými stavy v čase a interakce objektu s událostmi a s jinými objekty v čase. Pro přechody mezi stavy je určující časový údaj (význam časových oken), tzn., že každá událost musí proběhnout v přesně stanoveném časovém okně. Časový diagram se využívá pro systémy pracující v reálném čase. Notace v jazyku UML: Obrázek 4-50 Diagram časování. Zdroj: http://uml.czweb.org/Diagramy/diagram_casovani1.jpg Poznámka k obrázku: • po rozpracování je návrh smlouvy odeslán k posouzení, • poté je zahájeno posuzování návrhu smlouvy, • po fázi posouzení je návrh smlouvy schválen. Obrázek 4-51 Diagram časování - kompaktní forma 4.4 Vztah UP a UML Jazyk UML není vázán na žádnou konkrétní metodiku anebo životní cyklus. Může být použit v podstatě se všemi existujícími metodikami. Metodika Unified Process využívá jazyk UML jako vlastní syntaxi pro vizuální modelování. Z tohoto pohledu je možné metodiku Unified Process považovat za upřednostňovanou metodiku při používání jazyka UML, protože je pro ni tento jazyk nejlépe přizpůsoben. Jazyk UML však může poskytovat (a také poskytuje) podporu vizuálního modelování i pro jiné metodiky a metody. Záměrem jazyka UML a metodiky UP byla od jejich vzniku podpora nejlepších známých postupů využívaných v softwarovém inženýrství, vycházejících z ověřených zkušeností. K tomuto účelu byly v jazyku UML a metodice UP sjednoceny všechny dřívější pokusy o tvorbu jazyků pro vizuální modelování a proces vývoje softwaru. Modelovací jazyk UML je především souhrnem grafických notací sloužících ke znázornění návrhových a analytických modelů. Jazyk UML umožňuje modelovat jednoduché i složité aplikace pomocí stejné formální syntaxe a proto je možné výsledky práce sdílet s ostatními návrháři v týmu. Vybrané modely slouží samozřejmě i objednateli aplikace, což umožňuje kvalitnější ujasnění požadavků na navrhovaný systém. Žádný z diagramů nezachycuje vytvářený systém jako celek, ale soustřeďuje se vždy na některou jeho část, nebo lépe řečeno – na jeden pohled na daný systém. Různé pohledy pak tvoří přehledný a komplexní celek pro analýzu, programování, tvorbu dokumentace a ujasňování požadavků. Ve světě již existují různé metodické postupy vycházející z technik modelování v UML, které tyto postupy dále rozšiřují o vlastní doporučené postupy, diagramy a techniky. Nejznámější z nich je metodika RUP společnosti Rational, o které bude řeč v následující kapitole. Shrnutí pojmů 4.1. V této obsáhlé kapitole jsme se seznámili se strukturou metodiky UP a uvedli si její hlavní vlastnosti. Naučili jsme se, že metodika UP musí být přizpůsobena cílům a podmínkám daného vývoje, tzn. používaným normám, šablonám, nástrojům, atd. Objasnili jsme pojem unifikovaný proces (UP):  řízení požadavky a případy užití.  řízení rizikem.  základ na architektuře.  iterativní a přírůstkový proces vývoje SW produktu a zjistili jsme, že je rozdělen do jednotlivých iterací, z nichž každá prochází pěti základními pracovními procesy (činnostmi):  stanovení požadavků  analýza  návrh  implementace  testování Každá činnost v UP je dále rozdělena do pěti fází:  zahájení  rozpracování  realizace  zavedení V další části kapitoly jsme probrali jazyk UML (Unified Modelling Language). Jak již z názvu vyplývá, jedná se o nástroj k modelování procesů. UML pracuje i s tzv. metamodelem, který definuje strukturu všechny modelů UML. Víme, že UML je tvořen třemi hlavními prvky:  stavební bloky – základní prvky modelu, diagramy, vazby (relace)  společné mechanizmy – obecné způsoby, pomocí nichž je v jazyku UML možno dosáhnout specifických cílů  architektura – vizualizace architektury navrhovaného systému Modelování v UML (verze 2.0) provádíme prostřednictvím následujících diagramů, které můžeme rozdělit do tří hlavních kategorií – strukturní diagramy, diagramy chování a diagramy interakce: strukturní diagramy:  diagram tříd  diagram komponent  diagram složených struktur  diagram nasazení  diagram balíčků  diagram objektů, též se nazývá diagram instancí  diagram profilů diagramy chování:  diagram aktivit  diagram užití  stavový diagram diagramy interakce:  sekvenční diagram  diagram komunikace  diagram interakcí  diagram časování Otázky 4.1. 1. Charakterizujte metodiku UP – na jakých čtyřech hlavních principech je postavena? 2. Vysvětlete pojmy iterace a přírůstek. 3. Kolika iteracemi může být tvořena každá fáze UP? 4. Co je to milník? 5. K čemu se využívá UML? 6. Čím je UML tvořen? 7. Do jakých třech hlavních kategorií lze rozdělit diagramy v UML? 8. Vyjmenujte všech 14 diagramů a uveďte stručně jejich vlastnosti a k jakému účelu slouží. 5 METODIKA RUP A EUP: RUP (RATIONAL UNIFIED PROCESS) CHARAKTERISTIKA, ZPŮSOB DISTRIBUCE, NOTACE, ZÁKLADNÍ ELEMENTY, POSLOUPNOST AKCÍ. EUP SROVNÁNÍ A SPOLEČNÉ APLIKACE S RUP. V této kapitole se seznámíme s metodikami, které rozšiřují a obohacují metodiku UP. Jedná se o metodiky RUP a EUP. Čas ke studiu: 2 hodiny Cíl: Po prostudování této kapitoly budete umět Objasnit, z čeho vychází metodika RUP. Charakterizovat metodiku RUP. Uvést odlišnosti metodik RUP a UP. Objasnit hlavní principy metodiky RUP. Charakterizovat metodiku EUP. Uvést způsoby distribuce RUP a EUP. Výklad 5.1 RUP (Rational Unified Process) Metodika RUP je komerční verzí UP. RUP obsahuje veškeré normy obsažené v UP. Je dodávána s bohatým uživatelským prostředím. RUP rozšiřuje UP mnoha významnými způsoby. Ačkoli obě metodiky mají mnoho společného, rozdíly jsou spíše v jednotlivých detailech a v úplnosti, než v sémantice. 5.1.1 Charakteristika RUP RUP, v porovnání s UP, zavádí některé syntaktické odlišnosti, uvedené na následujícím obrázku: Obrázek 5-1 Odlišnosti syntaxe RUP a UP. Zdroj: ARLOW, Jim a Ila NEUSTADT. UML 2 a unifikovaný proces vývoje aplikací: objektově orientovaná analýza a návrh prakticky. 2., aktualiz. a dopl. vyd. Brno: Computer Press, 2007. ISBN 978-80-251-1503-9. Metoda RUP využívá během vývoje následující ověřené postupy:  iterativní vývoj (postupné zjemňování, přidávání vlastností)  správa uživatelských požadavků (doplňování, třídění, hodnocení)  použití architektury komponent (využití stávajících vzorů, komponent částečných řešení)  vizuální modelování (vytváření modelů reality)  sledování kvality Podobně jako UP, RUP má 4 etapy vývoje:  zahájení  rozpracování  realizace  zavedení 5.1.2 Způsob distribuce RUP Vzhledem ke skutečnosti, že metodika RUP je komerčním produktem, pro její využití je nezbytné řádně dodržovat distribuční a licenční podmínky vlastníka práv k této metodice, kterým je v současné době (2017) společnost IBM. Distribuce je prováděna na základě zakoupení licence k používání této metodiky od distributorů této společnosti. Ve většině případů je platnost licence roční a po uplynutí její platnosti je nutné ji (zaplacením licenčního poplatku) obnovit. Bližší informace týkající se distribuce RUP je možné získat online, například na stránkách firmy cnet - https://www.cnet.com/products/ibm-rational-unified-process-softwaresubscription-and-support-renewal-1-year-e013bllsb/specs/ nebo přímo u výrobce - https://www.ibm.com. Firma IBM nabízí licenci k využívání RUP rovněž jako součást jiného balíčku s názvem Rational Method Composer. Metodika RUP je distribuována jako sada webových stránek (HTML), které tvoří znalostní bázi. 5.1.3 Notace RUP Díky faktu, že metodika RUP je postavena na základě UP, využívá tedy shodné diagramy a postupy a její notace je v podstatě shodná s notací UP. Drobné syntaktické odchylky mezi metodikami RUP a UP jsou uvedeny v předchozí kapitole 5.1.1 Charakteristika RUP. 5.1.4 Základní elementy RUP Metodika RUP se opírá o čtyři hlavní prvky, na kterých je celý vývoj software v této metodice založen. Jedná se o následující pojmy:  pracovníci (workers)  činnosti (activities)  meziprodukty (artifacts)  pracovní procesy (workflows) Stručně nyní objasníme význam těchto pojmů metodiky RUP. Pracovníci – jedná se o elementy odpovídající na otázku KDO?. Pracovník určuje odpovědnost skupiny nebo jednotlivce a jejich chování. Chování pracovníka se definuje pomocí činností – aktivit. Každý pracovník má tedy vazbu s množinou aktivit. Odpovědnost je zpravidla určena vztahy s meziprodukty – pracovník je generuje, upravuje, kontroluje… Pracovník není většinou konkrétní osoba, pod tímto pojmem se spíše skrývá určitá role, která může být konkrétním osobám přidělována. Pracovník může mít více rolí a role je možné přidělovat pracovníkům dle konkrétních požadavků. Činnosti – jsou odpovědí na otázku JAK? Jedná se v podstatě o jednotku práce vykonávané jednotlivcem nebo skupinou. Výstupem činnosti by měl být výsledek, který je v rámci projektu smysluplný. Činnost má jednoznačně určený záměr, cíl (čeho danou činností dosáhneme?) Tímto záměrem nebo cílem je ve valné většině případů úprava nebo tvorba meziproduktu – třídy, plánu, modelu, atd. Obvykle se činnost vztahuje k jednomu pracovníku a dotýká se jen nevelkého počtu meziproduktů. Do činnosti mohou meziprodukty vstupovat a upravené mohou být zase jejím výstupem. Jako příklad výše uvedeného může posloužit následující: Projektový manažer vytváří plán. Pracovník bude tedy projektový manažer a jeho činností bude vytvoření plánu. Meziproduktem se stane vytvořený plán. Aktivity je možné rozdělit do dalších kroků:  úvahy (Thinking Steps)  provádění (Performing Steps)  přezkoumání (Reviewing Steps) U každé činnosti je nutné stanovit jasný sled kroků vedoucích k jejímu úspěšnému dokončení. Ke každému z kroků činnosti je v RUP vytvořena velmi detailní dokumentace. Využít přitom lze množství návodů, tipů, pomůcek, atd., které metodika RUP poskytuje. Meziprodukty – dávají odpověď na otázku CO? Jde o určitou informaci nebo její část, která je v rámci daného procesu generována, upravována či používána. Meziprodukty jsou reálnými výsledky projektů. Využívány jsou jako vstupy do činností prováděných pracovníky nebo jako jejich výstupy. Určený pracovník má rovněž i odpovědnost za správnost vygenerovaného nebo upraveného meziproduktu. Meziprodukty mohou mít více podob. Patří mezi ně:  model (např. model případů užití, model návrhu, atd.)  element modelu (např. třída, případ užití, podsystém)  dokument (např. část specifikace, plán)  zdrojový kód  spustitelná aplikace Meziprodukty je možné generovat pomocí mnoha různých nástrojů, kupříkladu Rational Rose pro tvorbu modelů, Microsoft Project pro tvorbu projektů, atd. Díky opravdu velkému počtu meziproduktů definovaných v RUP je žádoucí jejich rozdělení do několika skupin:  meziprodukty týkající se požadavků (Requirements Artifact Set)  meziprodukty týkající se analýzy a designu (Analysis & Design Artifact Set)  meziprodukty týkající se implementace (Implementation Artifact Set)  meziprodukty týkající se testování (Test Artifact Set)  meziprodukty týkající se šíření (Deployment Artifact Set)  meziprodukty týkající se konfiguračního a změnového řízení (Configuration & Change Management Artifact Set)  meziprodukty týkající se projektového řízení (Project Management Artifact Set)  meziprodukty týkající se vývojového prostředí (Environment Artifact Set)  meziprodukty týkající se obchodního modelování (Business Modelling Artifact Set) I přes značný počet meziproduktů definovaných v RUP je jejich využití nebo nevyužití dáno konkrétním potřebám projektu. Stejně jako je tomu u pracovníků a činností, zpravidla se využívá jen určitá podmnožina množiny všech meziproduktů (pracovníků, činností…). Pracovní procesy – poskytují odpověď na otázku KDY? Proces není tvořen pouze seznamem činností, pracovníků a meziproduktů. Nezbytné je ještě přidání série aktivit a interakcí mezi pracovníky. Z uvedeného vyplývá, že pod pojmem pracovní proces se rozumí sled činností, které směřují ke splnění vytýčeného cíle. Z kapitoly Chyba! Nenalezen zdroj odkazů.2 Struktura UP víme, že takovouto posloupnost aktivit můžeme modelovat pomocí Diagramu interakcí a Sekvenčního diagramu. Bohužel, ani pomocí těchto sofistikovaných nástrojů není možné většinou obsáhnout úplně všechny závislosti a vazby mezi činnostmi. Intepretaci diagramů nelze tedy provádět čistě mechanicky, je žádoucí se nad různými závislostmi dobře zamyslet. Každý pracovní proces je tvořen řadou aktivit. Obvykle těchto činností bývá nanejvýš deset. Metodika RUP poskytuje devět definovaných hlavních pracovních procesů. Tyto procesy korespondují se skupinami meziproduktů uvedenými v předchozím odstavci. Vzhledem ke skutečnosti, že každý z těchto devíti pracovních procesů zasahuje poměrně velkou oblast, jsou metodikou RUP dále rozděleny do skupiny, které říkáme podrobnosti pracovních procesů. Tyto skupiny sdružují procesy, které spolu úzce souvisí. 5.1.5 Posloupnost akcí RUP Metodika RUP se řadí mezi metodiky, které jsou řízeny případy užití (use-case driven approach). To znamená, že za základní prvek je považován případ užití, který je definován jako sekvence akcí, které provádí systém nebo které jsou prováděny uvnitř systému. Posloupnost akcí v RUP je tedy v daném projektu řízena případem užití. 5.2 EUP (Enterpsise Unified Process) Metodika EUP je další komerční verzí vycházející z RUP. Podobně, jako RUP rozšiřuje a obohacuje UP, stejně tak EUP rozšiřuje a obohacuje procesní Framework RUP. Toto rozšíření se podrobuje normě ISO12207. Metodika EUP má ve své snaze pokrytí celého životního cyklu vývoje software. 5.2.1 Charakteristika EUP Základ EUP rozšiřuje RUP o dvě fáze:  fáze produkční (production)  fáze stažení z provozu (retirement) Součástí metodiky EUP jsou rovněž nově zavedené součásti:  provoz a podpora (Operations and Support)  modelování podnikových procesů (Enterprise Business Modelling)  správa portfolia (Portfolio Management)  podniková architektura (Enterprise Architecture)  strategie znovupoužitelných komponent, postupů a šablon (Strategic Reuse)  zlepšování softwarového procesu (Software Process Improvement) Výhodou EUP je napojení na podnikové procesy a neustálé zlepšování. Obrázek 5-2: Metodika EUP. Zdroj: http://enterpriseunifiedprocess.com/ 5.2.2 Způsob distribuce EUP EUP je intelektuálním vlastnictvím společnosti Ambysoft Inc. Pro informace o získání licence k tomuto produktu je nutné firmu kontaktovat a individuálně dohodnout podmínky jejího udělení. V současné době nemá tato společnost dostupné veřejné informace o způsobu udělování práv k využívání metody EUP a jejich ceně – je nezbytné společnost kontakt, což je možné učinit na webových stránkách http://enterpriseunifiedprocess.com/licensing.html. 5.2.3 Notace EUP Vzhledem ke skutečnosti, že metodika EUP je postavena na základě RUP, využívá tedy shodné diagramy a postupy a její notace je v podstatě shodná s notací RUP a UP. 5.2.4 Základní elementy EUP Jak již bylo zmíněno, metodika EUP je postavena na základech RUP, kterou rozšiřuje a proto využívá stejné základní elementy jako RUP. Odkazujeme proto na kapitolu 5.1.4 Základní elementy RUP. 5.2.5 Posloupnost akcí EUP Metodika EUP se, stejně jako RUP, řadí mezi metodiky, které jsou řízeny případy užití (use-case driven approach). To znamená, že za základní prvek je považován případ užití, který je definován jako sekvence akcí, které provádí systém nebo které jsou prováděny uvnitř systému. Posloupnost akcí v EUP je tedy v daném projektu řízena případem užití. Shrnutí pojmů 5.1. V této kapitole jsme se zabývali komerční verzí metodiky UP – metodikou RUP. Dozvěděli jsme se, že metodika RUP je dodávána s bohatým uživatelským rozhraním a od metodiky UP se odlišuje několika syntaktickými vlastnostmi. RUP využívá následující ověřené postupy:  iterativní vývoj (postupné zjemňování, přidávání vlastností)  správa uživatelských požadavků (doplňování, třídění, hodnocení)  použití architektury komponent (využití stávajících vzorů, komponent částečných řešení)  vizuální modelování (vytváření modelů reality)  sledování kvality  a má 4 etapy vývoje:  zahájení  rozpracování  realizace  zavedení Důležité pro metodiku RPU jsou rovněž čtyři základní prvky, na kterých je vystavěna:  pracovníci (workers)  činnosti (activities)  meziprodukty (artifacts)  pracovní procesy (workflows) Distribuce RUP je prováděna na základě zakoupení licence k používání této metodiky od distributorů společnosti IBM. V další části kapitoly jsme se věnovali metodice EUP, která vychází z metodiky RUP (obohacuje ji o další fáze):  fáze produkční (production)  fáze stažení z provozu (retirement) Nově rovněž zavádí další součásti:  provoz a podpora (Operations and Support)  modelování podnikových procesů (Enterprise Business Modelling)  správa portfolia (Portfolio Management)  podniková architektura (Enterprise Architecture)  strategie znovupoužitelných komponent, postupů a šablon (Strategic Reuse)  zlepšování softwarového procesu (Software Process Improvement) Notace RUP se shoduje s notací RUP a vychází se stejných principů, pokud jde o posloupnost akcí a základní prvky. Distribuce EUP je zajišťována společností Ambysoft Inc. Otázky 5.1. 1. Jaké jsou hlavní postupy metodiky RUP? 2. Jak byste charakterizovali notaci RUP? 3. Z čeho RUP vychází (z jaké metodiky)? 4. Jakým přístupem se řídí metodiky RUP? 5. Popište posloupnost činností metodiky RUP. 6. Uveďte hlavní rozdíly RUP a EUP. 7. Jaká je notace EUP? 8. Je možné RUP resp. EUP volně používat? Pokud ne, uveďte podmínky, za kterých by to bylo možné. 9. Kdo je distributorem RUP a EUP? 6 AGILNÍ PŘÍSTUP K TVORBĚ SW: VÝHODY AGILNÍCH METODIK (RYCHLOST, WEBOVÉ TECHNOLOGIE, ITERATIVITA, INKREMENTACE). MANIFEST AGILNÍHO VÝVOJE SW (THE AGILE MANIFESTO). V této kapitole se seznámíme s dalším typem metodik, které nazýváme agilní metodiky. Uvedeme si, v čem se agilní metodiky liší od rigorózních a jakými třemi základními principy se liší. Naučíme se rovněž, v jakých případech je využití agilních metodik vhodné a uvedeme důvody proč. Čas ke studiu: 2 hodiny Cíl: Po prostudování této kapitoly budete umět Vysvětlit pojem agilní metodika. Objasnit rozdíl mezi agilní a rigorózní metodikou. Uvést hlavní pilíře agilních metodik. Vysvětlit pojem manifest agilního vývoje. Charakterizovat složení týmu agilního vývoje. Výklad 6.1 Agilní metodiky Agilní metodiky se snaží oprostit od náročnějších postupů vývoje v zájmu rychlosti vývoje. Jejich vznik reaguje na potřeby vývoje určitých typů IS (menší systémy, www aplikace apod.), pro které mohou být doporučení stávajících metodik zbytečně složitá a neúměrná vyvíjenému systému. Agilní metodiky vznikly tedy zejména proto, že klasické přístupy jsou někdy administrativně náročné a nepružné, tj. neúměrně vzhledem k rozsahu a typu vyvíjeného IS. Rovněž zadání mnohdy není zcela jasné, často se mění – v těchto případech je agilní přístup téměř nezbytný. Před jejich vznikem se používaly jen těžké, rigorózní metodiky. Ty mají své odpůrce jednak díky vodopádovému modelu a jednak díky tomu, že vedoucí projektu omezuje vývojáře v práci svým blízkým dohledem. Rigorózní metodiky také těžkopádně reagují na jakékoli změny. Díky uvedeným skutečnostem začaly vznikat odlehčené metodiky, které se (podle názoru jejich autorů) vracejí k praktikám využívaných na samotném počátku vývoje software. Agilními metodikami se odlehčené metodiky nazývají od doby vydání Manifestu agilního vývoje SW. Agilní metodiky se řídí třemi základními principy:  přírůstkový (iterativní) vývoj s velmi krátkými iteracemi – nejprve se tvoří nejdůležitější funkce SW, po odzkoušení zákazníkem se přidávají další.  důraz na komunikaci mezi zákazníkem a vývojářem – zástupci zákazníka by měli být členy vývojového týmu a podílet se na návrhu systému. Díky krátkým iteracím sdělují vývojářům své zkušenosti.  přísné automatizované testování – pro daný SW je vytvořena komplexní sada testů. Testy předem sestavené a prověřené pro každou změnu SW. Poté je změněný SW testován. V současné době (2017) existuje řada metodik, využívajících agilní přístup k vývoji SW. Mezi nejznámější z nich patří:  ASD (Adaptive Software Development) - Adaptivní vývoj SW,  FDD (Feature-Driven Development),  XP (Extreme Programming) - Extrémní programování,  Lean Development,  SCRUM,  Crystal metodiky. O vybraných metodikách s adoptovaným agilním přístupem bude řeč v následujících kapitolách. 6.2 Manifest agilního vývoje SW Manifest agilního přístupu byl vytvořen autory: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland a Dave Thomas. Manifest zahrnuje priority a principy agilního vývoje softwaru. Priority agilního programování  Lidé a jejich spolupráce před procesy a nástroji  Fungující software před obsáhlou dokumentací  Spolupráce se zákazníkem před sjednáváním smluv  Reakce na změnu před dodržováním plánu Principy agilního programování V manifestu je obsaženo následujících dvanáct principů: 1. Nejvyšší prioritou je uspokojení zákazníka prostřednictvím rychlého a průběžného dodávání kvalitního software. 2. Změnové požadavky jsou vítány, dokonce i v průběhu vývoje. Agilní procesy je zpracují tak, aby zákazníkovi přinášely konkurenční výhody. 3. Dodávejte fungující software často, v intervalech týdnů až měsíců. Upřednostňujte kratší intervaly dodání. 4. Lidé z businessu a vývojáři musí spolupracovat každý den během celého projektu. 5. Pro práci na projektu vybírejte motivované jedince. Dejte jim prostředí a podporu, kterou potřebují, a důvěřujte jim, že práci dokončí. 6. Nejúčinnější metoda sdílení informací vývojářskému týmu (i uvnitř tohoto týmu) je osobní setkání. 7. Fungující software je hlavním měřítkem postupu vývoje. 8. Agilní procesy podporují udržitelný vývoj. Sponzoři, vývojáři i uživatelé by měli být schopní dodržovat stálý výkon, dokud je třeba. 9. Průběžná pozornost věnovaná technické dokonalosti a dobrému návrhu posiluje agilní přístup. 10. Základem je jednoduchost – umění co nejvíce práce vůbec nedělat. 11. Nejlepší architektury, požadavky a návrhy vznikají v týmech, které se samy organizují. 12. Tým v pravidelných intervalech vyhodnocuje svou práci a upravuje své postupy tak, aby byl co nejefektivnější. 6.3 Omezení rizik při agilním přístupu Agilní metodiky omezují následující rizika:  rizika, která souvisejí s nepřesným zadáním (které často představuje problém) a s komplexností vytvářeného systému  rizika, která souvisejí s nestálostí členů vývojového týmu  rizika spojená s neexistencí dostatečné dokumentace  rizika plynoucí z neplnění termínů a lhůt a z překračování plánovaných rozpočtů Obrázek 6-1 Iterace agilního vývoje 6.4 Složení týmu agilního vývoje Při agilním vývoji je důležité, aby byl tým složen z vývojářů schopných pružné komunikace a spolupráce spíše než ze specialistů, kteří většinou pracují samostatně. Základním konceptem při agilním vývoji je komunikace. Při agilním vývoji v menším týmu se ve složení týmu obvykle využívají role. Pozor, role nejsou pracovní pozice – každý člen týmu může zastávat jednu nebo více rolí a tyto role je možné v průběhu času měnit. Každá role může mít přiřazen nulový nebo vyšší počet osob, ve kterémkoli bodě v průběhu projektu. Obecně se za role při agilním vývoji považují následující:  vedoucí týmu (vedení projektu, týmový kouč) – tato role odpovídá za podporu týmu, získávání prostředků pro tým a ochranu týmu před problémy. Tato role zahrnuje osobní dovednosti s vedením týmu, ale nikoli technické dovednosti jako je plánování a činnosti, které je výhodnější přenechat ostatním členům týmu.  člen týmu – tato role, která je občas také nazývána programátor či vývojář, je odpovědná za tvorbu a dodávku systému. To zahrnuje činnosti jako modelování, programování, testování a uvolnění hotového produktu, atd.  vlastník produktu – tato role zastupuje investory. Tato role nebo osoba (většinou je v týmu pouze jedna) odpovídá za vytvoření seznamu položek prioritních prací, za včasná rozhodnutí a včasná poskytování informací.  investor – je kdokoli, kdo je přímým uživatelem, nepřímým uživatelem, vedoucím uživatelů, senior manažer, člen provozního týmu, tzv. „zlatý majitel“ poskytující prostředky členům týmu podpory, auditorům, manažerům programu/portfolia, vývojářům pracujícím na jiných systémech, kteří integrují aktuálně vyvíjený projekt, atd. Mezi role týmu lze počítat rovněž ty nepřímé, které jsou však rovněž pro agilní vývoj důležité, ačkoli osoby, které je přebírají, většinou nejsou přímými členy týmu. Jedná se o následující role:  techničtí specialisté (experti) – občas členové týmu potřebují pomoc technických odborníků, jako např. databázových specialistů apod. pro činnosti jako je vytvoření a testování databází, vytvoření sestavovacích skriptů apod. Techničtí experti jsou využívání dle potřeby, nepravidelně, aby pomohli týmu překonat složitý problém a přenést jejich znalosti na jednoho nebo více vývojářů v týmu.  doménoví specialisté – jak je patrné z následujícího obrázku, vlastník projektu zastupuje širokou skupinu investorů, nikoli pouze jednoho koncového uživatele a v praxi není rozumné očekávat, že by se jednalo o odborníky v každém směru ve vaší doméně. Vlastník projektu občas využívá služeb doménových specialistů a zajišťuje jejich občasnou spolupráci s týmem. Jedná se například o daňové specialisty, kteří objasní podrobnosti požadavků anebo sponzora, který objasní vize týkající se projektu, atd.  nezávislý tester – efektivní agilní týmy mají obvykle nezávislého testera, který současně s vývojem pracuje na ověřování práce týmu během celého životního cyklu. Tato role je většinou využívána u velmi komplexních projektů. Obrázek 6-2 Tým agilního vývoje Vlastník produktu obvykle reprezentuje více investorů. Obrázek 6-3 Reprezentace více investorů vlastníkem produktu 6.4.1 Doplnění týmových rolí u projektů většího rozsahu V případě větších týmů se role menšího týmu doplňují o následující dvě:  vlastník architektury – tato role je odpovědná za podporu rozhodnutí týkající se architektury u sub-týmu, který je odpovědný za celkový architektonický směr projektu. Vlastník architektury vede svůj sub-team během počátečních představ o jeho podsystémech a bude zapojen do plánování výchozí architektury pro systém jako celek. Vlastníci architektury se od tradičních architektů liší v tom, že nejsou samostatně odpovědní za určení architektonického směru, ale spíše pomáhají při jeho vytváření (určování) a vývoji.  integrátor – sub-týmy jsou obvykle odpovědné za jeden nebo více podsystémů. Čím větší je celý tým obecně, tím větší a komplikovanější je celý vytvářený systém. V těchto situacích může celý tým potřebovat jednoho člověka nebo více lidí v roli integrátora, zodpovědného za vytvoření (složení) celého systému z jednotlivých dílčích podsystémů. Tito lidé často úzce spolupracují s nezávislým testovacím týmem (pokud takový existuje), který bude v průběhu projektu požadovat provedení testování integrace systému. Obrázek 6-4 Týmové role u projektů většího rozsahu 6.5 Koordinace činností Jak obrázek napovídá, u velkých agilních projektů je potřeba koordinovat několik kritických činností: činnosti spojené s řízením projektu – při managementu projektu není dostatečné se u řešení technických aspektů soustřeďovat pouze na samo-organizaci. To může fungovat v jednotlivých sub-týmech, ale z pohledu celého projektu nebo programu se stávají technické aspekty řízení projektu kritickými. Týká se to především řízení závislostí, sledování zdrojů, řízení smluv a řízení prodeje. Tým projektového řízení na obrázku je složen z vedení různých sub-týmů. Jejich cílem je koordinovat aspekty řízení celého týmu. Tým by měl mít každodenní krátké koordinační schůzky. technické/architektonické problémy – tým vlastnictví architektury je složen z vlastníků architektury sub-týmů a je odpovědný za návrh předpokládané architektury v počátcích projektu. Odpovídá za určení počátečního technického směru a poskytuje základ pro organizaci sub-týmů. V prvním týdnu od zahájení projektu (v některých případech, u složitějších projektů se jedná i o několik týdnů) je jejich úkolem návrh podsystémů a jejich rozhraní, zredukování vazeb mezi podsystémy a tím zredukování míry koordinace mezi sub-týmy. Jakmile jsou rozhraní správně definována, mohou se jednotlivé sub-týmy zaměřit na implementaci vnitřních částí těchto podsystémů. Během doby trvání projektu se tento tým účastní pravidelných schůzek za účelem sdílení myšlenek a řešení technických problémů, konkrétně těch, které souvisejí s rozhraními podsystémů. Na začátku projektu jsou obvyklé každodenní schůzky, ale po stabilizaci architektury je běžné pořádat tyto schůzky jedno či dvakrát týdně. problémy související s požadavky a vlastnictvím projektu – tým vlastnictví projektu je tvořen vlastníky produktu všech sub-týmů a je odpovědný za koordinaci požadavků mezi sub-týmy. Tento tým by měl dojednávat požadavky s větší částí investorů, které zastupují a vhodně je rozdělovat mezi sub-týmy. Tým by měl rovněž projednávat nevyhnutelné neshody mezi sub-týmy, týkající se otázek kdo má co dělat a co daný požadavek skutečně znamená. Spravuje rovněž závislosti požadavků mezi sub-týmy a usiluje o minimalizaci překrývajících se činností mezi sub-týmy. Integrace systému – integrace systému je důležitá pro jakoukoli velikost týmu, ale je často opravdu kritická v případě velkých týmů (které obvykle řeší složitější problémy). Složitost větších projektů obvykle vyžaduje zařazení integrátora (či několika integrátorů) systému do týmu. Integrace systému je prováděna v průběhu celého agilního životního cyklu projektu, nejen na konci projektu v průběhu fáze testování. Na začátku vývoje je pro všechny sub-týmy důležité vytvořit jakousi kostru své části systému (podsystému) podle definovaných a dohodnutých rozhraní. Cílem je vytvoření takové kostry celého systému, aby bylo zřejmé, že sub-týmy pracují na stejné technické vizi celého sytému. U velkých projektů je rovněž důležité, aby nezávislý tým určený pro testování často (po dokončení některého z podsystémů) prováděl integrační testy celého systému – což by bylo velmi obtížné pro jednotlivé sub-týmy v jejich vlastním prostředí. Shrnutí pojmů 6.1. Vzhledem k časové náročnosti a administrativní složitosti vývoje software podle těžkých rigorózních metodik je na místě, v případě menších projektů, použít jiný přístup. Tímto přístupem jsou tzv. agilní metodiky. Agilní metodiky se řídí manifestem, obsahujícím principy a priority agilního programování. Alfou a omegou agilního přístupu jsou krátké přírůstkové iterace, participace zákazníka při vývoji a časté konzultace vývojového týmu se zákazníkem. U agilního přístupu je možné pružně reagovat na změny a upřesňování požadavků na systém. Důležitou součástí agilních metodik je rovněž testování hotových částí v průběhu celého projektu, většinou na konci každé iterace. Otázky 6.1. 1. Vyjmenujte výhody agilního přístupu v porovnání s vývojem podle rigorózních metodik. 2. Co definuje manifest agilního vývoje SW? 3. Jaká je role investora projektu? 4. Vyjmenujte složení běžného týmu agilního vývoje 5. Jsou specialisté součástí projektového týmu? Pokud ano, tak za jakých okolností? 6. Jaká rizika agilní přístup eliminuje nebo potlačuje? 7. Proč je u agilního přístupu důležité testování? 8. Kdo provádí testování u menších projektů a kdo u větších? 9. Jaká je úloha integrátora? 7 METODIKY ADS, DSDM, FDD, XP: ADS (ADAPTIVE SOFTWARE DEVELOPMENT ), DSDM (DYNAMIC SYSTEMS DEVELOPMENT METHOD), FDD (FEATURE-DRIVENDEVELOPMENT), CHARAKTERISTIKY, VÝHODY, PRINCIPY VÝVOJE, SROVNÁNÍ. EXTREME PROGRAMMING (XP), CHARAKTERISTIKA A VÝHODY XP. V této kapitole se seznámíme s několika typy agilních metodik. Vysvětlíme si jejich hlavní principy, u některých uvedeme role a další souvislosti, které se těchto konkrétních metodik týkají. Čas ke studiu: 2 hodiny Cíl: Po prostudování této kapitoly budete umět Objasnit hlavní myšlenky metodik ASD, FDD, DSDM, XP a LD. Uvést výhody metodiky XP. Uvést hlavní postupy metodiky XP. Uvést hlavní postupy metodiky DSDM. Výklad 7.1 ASD (Adaptive Software Development) - Adaptivní vývoj SW Metodika ASD nahrazuje klasický postup vývoje IS „Plánování-Návrh-Realizace“ dynamickým cyklem „Spekulace-Spolupráce-Učení“. Cyklus předpokládá neustálé učení poháněné změnami. Odchylky od plánu nejsou chápány jako chyby, ale jako příležitost k učení. Fáze spekulace zahrnuje určení termínu ukončení projektu, určení optimálního počtu iterací, termínů ukončení každé iterace, určení obsahu jednotlivých iterací, přiřazení SW komponent a technologií jednotlivým iteracím. Ve fázi spolupráce je prováděn vývoj SW komponent. Důraz se klade (jak již plyne z principů agilních metodik) na komunikaci a interakci členů vývojového týmu. Fáze učení slouží k hodnocení a zlepšování procesu vývoje na konci každé iterace, tj. k ohodnocení kvality vyvíjeného SW, práce týmu a stavu projektu. Jedná se o nejdynamičtější metodiku ze souboru agilních metodik, u níž však zůstává zachován procesní přístup. Změna a přizpůsobování se změnám je hnacím motorem této metodiky. Na rozdíl od většiny ostatních agilních metodik se tato metodika nesoustřeďuje na předávání funkčního produktu na konci každé iterace (a to i přesto, že iterativní přístup agilních metodik zůstává zachován). Finálním cílem každé iterace je předání takových podkladů zákazníkovi, které umožní jeho ověření, zda je postup vývoje správný. V tomto rámci je možné předávat prototypy a návrhy rozhraní, případně beta-verze produktu. Finální, otestovaný a odladěný systém je zákazníkovi předán až po ukončení celého vývoje. Z výše uvedeného vyplývá, že metodika ASD je vhodná v případech, kdy není z jakýchkoli důvodů možno projekt rozdělovat a dodávat po menších částech. Týká se to např. řídících a kontrolních systémů, bezpečnostních systémů, atd.). Důležitým faktorem metodiky ASD je, že metodika neobsahuje definici konkrétních postupů – detailní obsahy procesu jsou naplňovány z jiných metodik, ať už rigorózních či agilních. Metodika ASD se s úspěchem využívá u menších i rozsáhlých projektů. 7.2 FDD (Feature-Driven Development) Proces vývoje v této metodě je založen na krátkých (asi dvoutýdenních) iteracích řízených vlastnostmi produktu (feature-driven). Vlastností (feature) se zde rozumí dílčí výsledek, užitečný z pohledu zákazníka, měřitelný a realizovatelný v rámci dvoutýdenní iterace. Vlastnosti (features) jsou v metodice FDD přesně definovány. FDD tedy vede vývojáře k vytváření fungujících přírůstků každé dva týdny. FDD doporučuje definovat tzv. „lehké“ procesy, každý proces je stručně popsán ve struktuře:  vstupní kritéria pro proces  úkoly (název, účastníci, povinnosti, popis úkolu)  nástroje verifikace  výstupní podmínky procesu – hmatatelné výstupy Ve všech procesech se zaznamenávají alternativní řešení. Posloupnost procesů je následující:  vypracování celkového modelu vyvíjeného IS  vytvoření detailního seznamu vlastností IS s prioritami jejich řešení  plánování vývoje pro každou vlastnost, každé skupině (třídě) vlastnosti je přiřazen vlastník, datum ukončení  návrh vlastností, tj. kontaktování vývojářů realizujících danou vlastnost SW a zpracování sekvenčního diagramu řešení dané vlastnosti  realizace vlastnosti Mezi agilními metodikami je FDD chápána jako konvenční a konzervativní, protože se více než ostatní agilní metodiky blíží konvenčním přístupům. Důraz je kladen na modelování a definici pojmů. Na rozdíl od jiných agilních metodik FDD určuje přesný termín dokončení vývoje – mezi její činnosti tedy nepatří dynamické a flexibilní plány vývoje (které jsou např. součástí metodiky SCRUM). FDD definuje tzv. vlastnictví tříd, čímž konkrétnímu vývojáři (programátorovi) přiděluje odpovědnost za danou třídu. Díky dynamickému skládání týmů metodika FDD umožňuje využití při velkých projektech, obecně větších než je tomu u ostatních agilních metodik. 7.3 XP (Extreme Programming) - Extrémní programování je metodika vhodná pro malé až středně velké vývojové týmy, které se musí vyrovnat se zadáním, jež se rychle mění nebo není jasné. Metodika XP se opírá o následující principy:  využívá včasnou, konkrétní a nepřetržitou zpětnou vazbu vyplývající z krátkých iteračních cyklů vývoje IS  přírůstkový přístup k plánování počítá s tím, že plán se může v průběhu projektu dále vyvíjet a měnit  využívání automatizovaných testů, na jejichž sestavení se podíleli programátoři i zákazníci  důraz je kladen na verbální komunikaci vývojového týmu se zákazníkem  návrh systému je evolučním procesem probíhajícím neustále po celou dobu existence systému  úzká spolupráce programátorů (programování v párech) Metodika XP je dobře propracovanou metodikou. Je velmi striktní, pokud jde o dodržování pravidel. Při vývoji software by měla být implementována celá, což je v častých případech velmi složité, či téměř nemožné. I přesto je metodika velmi rozšířená, díky čemuž existuje mnoho knižních i webových zdrojů a diskuzních fór, dokonce i v češtině. Metodika XP získala svůj název díky až extrémnímu využívání činností osvědčených i v jiných metodách. Metodika Extreme Programming je postavena na dvanácti postupech, které by měly být přísně dodržovány:  Plánovací hra – tvorba plánu, na které se podílí všichni členové týmu.  Malé verze – co nejčastější uvolňování nových verzí.  Metafora – je náhradou za termín „architektura“. Vývoj je popisován příběhem o tom, jak má konečný systém fungovat.  Jednoduchý návrh – dodržování maximální jednoduchosti systému.  Testování – u metodiky XP se testování provádí velmi často. Testy jsou tvořeny ještě před vlastní implementací funkcí a pro pokračování je nutné, aby testování proběhlo s pozitivním výsledkem.  Refraktorizace – při tomto postupu je zdrojový kód maximálně optimalizován.  Párové programování – veškeré programování je prováděno dvěma programátory na jednom počítači.  Společné vlastnictví – tato metodika se od většiny ostatních liší tím, že změny zdrojového kódu mohou provádět všichni programátoři. U mnoha jiných (objektových) metodik mají třídy své vlastníky, kteří za ně odpovídají.  Nepřetržitá integrace – celý systém se v průběhu dne vícekrát sestavuje a testuje.  40hodinový pracovní týden – zamezuje pracovnímu vyčerpání a přepínání programátorů. Metodika propaguje filozofii, že odpočatý a spokojený programátor podává kvalitnější pracovní výkony a jeho práce je efektivnější.  Zákazník na pracovišti – podobně jako je tomu u jiných agilních metodik, i zde je zákazník součástí týmu. Vzhledem k extrémnímu přístupu metodiky XP se přísně dbá na jeho faktickou přítomnost.  Standardy pro psaní zdrojového kódu – vzhledem k tomu, že se u metodiky XP nevytváří dokumentace, je nezbytné, aby byl zdrojový kód psán podle daných konvencí a dobře okomentovaný. Dodržování tohoto postupu usnadňuje programátorům rychlou orientaci v i kódu, jehož nejsou autory. 7.4 DSDM - Dynamic Systems Development Method Vývojem této metodiky se společně zabývalo šestnáct různých organizací. Kladem této metodiky je i dodávka frameworku – vývojového prostředí. Metodika se vyznačuje vysokou propracovaností; její vývoj usilovně pokračuje již přes dvacet let. Během této doby byly do metodiky neustále přidávány zkušenosti z vývoje a moderní tendence. Součástí metodiky DSDM je i série dobře propracovaných technik, včetně doporučení kdy a za jakých podmínek je používat a k jakému účelu jsou určeny. Stejně jako u ostatních agilních metodik i u DSDM probíhá vývoj na základě iterací, a to nejen z hlediska hlavních fází, ale i uvnitř těchto fází. U hlavních fází platí, že je možné se v nich vracet, což znamená, že vývoj a ostatní činnosti jsou vždy mířeny do (v daném okamžiku) klíčových míst. Jednou z „negativ“ této metodiky je, že pro její legální používání je nezbytné složit šestnáctičlenné organizaci členský poplatek. Na druhou stranu je výhodou již zmíněný podpůrný framework, který je již zahrnut do ceny členského poplatku. Členský poplatek činí částku od pár desítek GBP po tisíce GBP. Částka je rozlišovaná druhem členství, např. akademické, firemní, vládní, atd. Metodika DSDM se soustřeďuje na následujících osm principů (vycházejících z manifestu agilního vývoje):  zaměření na potřeby podniku  včasná dodávka  spolupráce  nikdy neohrožovat kvalitu  stavět přírůstkově na pevných základech  vyvíjet iterativně  komunikovat neustále a jasně  demonstrovat (předvádět) ovládání Jak bylo výše uvedeno, metodika DSDM obsahuje sérii propracovaných technik. Jádro těchto technik představují následující:  timeboxing – je jednou z projektových technik DSDM určenou k podpoře hlavních cílů DSDM. Technika se soustřeďuje na včasnou realizaci vývoje, v rámci daného rozpočtu a v požadované kvalitě. Hlavní myšlenkou timeboxingu je rozdělení projektu do částí, z niivchž každá má stanovený rozpočet a dodací lhůtu. U každé části jsou rovněž stanoveny požadavky, které mají vyšší prioritu – v souladu s principem MoSCoW (viz dále). Vzhledem ke skutečnosti, že čas a rozpočet jsou pevně stanoveny, proměnnou hodnotou jsou pouze požadavky.  MoSCoW – reprezentuje způsob (technika) upřednostnění položek. Jedná se o akronym tvořený následujícími slovy (angličtina): o MUST have - MUSÍ mít o SHOULD have – MĚL BY mít o COULD have – MOHL BY mít o WON¨T have this time – nyní NESMÍ mít.  prototypování – tato technika odkazuje na tvorbu prototypů vyvíjeného systému v prvních fázích projektu. Umožňuje včasné odhalení nedostatků a chyb v systému.  testování – jedním z důležitých aspektů vývoje pomocí metodiky DSDM je tvorba a dodání softwaru v dobré kvalitě. Aby mohlo být tohoto cíle dosaženo, metodika DSDM preferuje testování v průběhu každé iterace. Vzhledem k tomu, že DSDM je metodikou nezávislou na konkrétních nástrojích a technikách, je na rozhodnutí projektového týmu, jaké nástroje a techniky testování zvolí.  workshop – jedná se o techniku metodiky DSDM využívanou pro přizvání různých investorů k diskuzi o požadavcích, funkčnosti a k vzájemné dohodě. Na workshopu se investoři schází a diskutují o projektu.  modelování – tato základní technika se u DSDM, podobně jako v jiných metodikách, využívá k vizualizaci specifických aspektů projektu nebo podnikových oblastí prostřednictvím diagramů. Modelování poskytuje projektovému týmu dokonalejší porozumění jednotlivým částem systému.  správa konfigurace – dobrá implementace techniky správy konfigurace je z hlediska dynamické povahy metodiky DSDM důležitá. Vzhledem ke skutečnosti, že je v průběhu vývoje projektu zpracováváno více úloh současně a produkty jsou dodávány velmi často, musí být tyto produkty (nebo jejich části) velmi často přísně kontrolovány. V prostředí metodiky DSDM jsou rovněž zavedeny role, kterých je celkem patnáct. Podobně, jako je tomu v případě jiných metodik, i zde mají role přiřazeny své odpovědnosti. Před započetím projektu je důležité členům týmu tyto role přiřadit (resp. přiřadit členy týmu do určitých rolí). V DSDM se jedná o následující role (uvedeny jsou ty nejvýznamnější z patnácti celkových):  výkonný ředitel – důležitá role vycházející z organizace zákazníka, která má ve svých kompetencích přidělování zdrojů a kapitálu.  vizionář – odpovědností této role je inicializace projektu po zajištění základních požadavků. Vizionář má nejpřesnější informace o cílech projektu a zákazníka. Dalším úkolem osoby v této roli je dohled nad správností směru vývoje projektu.  zástupce uživatelů – do projektu přináší názory a znalosti komunity uživatelů a zajišťuje, aby vývojáři měli od uživatelů dostatečnou zpětnou vazbu.  rádce – může být jakýkoli uživatel (zástupce uživatelů), který přináší do projektu důležitá stanoviska a zajišťuje komunikaci požadavků a názorů uživatelů členům vývojového týmu. Má dokonalou znalost projektu (včetně každodenních změn) a s projektem seznamuje ostatní uživatele.  projektový manažer – role obecného vedení projektu. Zvláštností u metodiky DSDM je, že tato role může být obsazena jak členem vývojového týmu, tak i osobou ze strany organizace, pro kterou je projekt vytvářen.  technický koordinátor – odpovědný za sestavení architektury systému a řízení technické kvality projektu.  vedoucí týmu – vede tým a stará se o jeho efektivní práci (týmu jako celku).  vývojář řešení – vytváří prototypy a dodávaný programový kód podle požadavků projektu, které interpretuje.  tester řešení – testuje správnost (v technickém rámci) prováděním testování, odhaluje chyby, řeší je a opětovně testuje. Tester komentuje a vytváří část dokumentace.  zapisovatel – odpovědný za získávání a zaznamenávání požadavků, dohod a rozhodnutí přijatých na každém workshopu.  moderátor – stará se o průběh workshopu, pomáhá s přípravami a komunikací  role specialistů – různé speciální role, jako manažer jakosti, systémový integrátor, doménový expert, atd. Podle velikosti projektu se na vývoji podílí jeden tým nebo více týmů. Pokud jde o řízení projektu, nedělá se rozdíl mezi menším a větším projektem – větší projekty je možné rozdělit na několik nezávislých částí, které jsou řešeny jednotlivými týmy samostatně. Týmy jsou tvořeny dvěma až šesti osobami. Minimum dvou osob vychází z předpokladu, že členy týmu jsou minimálně vývojář a uživatel (jedná se o agilní metodiku). Maximální počet šesti členů týmu je dán na základě dlouhodobých zkušeností s používáním metodiky DSDM. 7.5 Lean Development Další agilní metodikou, kterou je na místě zmínit (jedná se rovněž o velmi populární metodiku) je metodika Lean Development, zkráceně LD. Metodika se zaměřuje na vytváření změnám přizpůsobivého SW. Tato metodologie ztělesňuje představu dynamické stability, o které lze smýšlet v podobném duchu jako o Scrumu, který představuje kontrolovaný chaos. 12 principů Lean Developmentu: 1. Uspokojit zákazníka je nejvyšší priorita. 2. Vždy poskytovat nejvyšší kvalitu za peníze. 3. Úspěch závisí na aktivní účasti zákazníka. 4. Každý LD projekt je týmová práce. 5. Všechno se může změnit. 6. Oblastní, ne bodová řešení. 7. Nevytvářet, ale kompletovat. 8. 80 procentní řešení dnes než 100 procentní řešení zítra. 9. Minimalismus je podstatný. 10. Potřeby určují technologii. 11. Růst produktu znamená růst jeho vlastností ne velikosti. Nikdy se nesnažte překročit omezení LD. Shrnutí pojmů 7.1. V této kapitole jsme si objasnili základní vlastnosti metodik ASD, FDD, XP, DSDM a Lean Development. Uvedli jsme si vhodnost použití jednotlivých metodik. U metodiky XP jsme popsali i dvanáct hlavních postupů, které je nezbytné přísně dodržovat:  Plánovací hra  Malé verze – co nejčastější uvolňování nových verzí.  Metafora  Jednoduchý návrh – dodržování maximální jednoduchosti systému.  Testování  Refraktorizace  Párové programování  Společné vlastnictví  Nepřetržitá integrace  40hodinový pracovní týden  Zákazník na pracovišti  Standardy pro psaní zdrojového kódu U metodiky DSDM jsme uvedli osm základních principů:  zaměření na potřeby podniku  včasná dodávka  spolupráce  nikdy neohrožovat kvalitu  stavět přírůstkově na pevných základech  vyvíjet iterativně  komunikovat neustále a jasně  demonstrovat (předvádět) ovládání Objasnili jsme rovněž sérii propracovaných technik metodiky DSDM (timeboxing, MoSCoW, prototypování, testování, atd.) a uvedli si základní role v této metodice. Otázky 7.1. 1. Objasněte hlavní principy metodiky ASD. 2. Jak rozumíte termínu „feature-driven“? 3. Proč je metodika XP nazývána jako extrémní? 4. Objasněte pojem „párové programování“ v metodice XP. 5. Vyjmenujte osm hlavních principů metodiky DSDM. 6. Kdo může být v metodice DSDM v roli rádce? 7. Za co odpovídá osoba v roli rádce v metodice DSDM? 8. Definujte hlavní myšlenky metodiky Lean Development 8 METODIKY ADS, DSDM, FDD, XP: ADS (ADAPTIVE SOFTWARE DEVELOPMENT ), DSDM (DYNAMIC SYSTEMS DEVELOPMENT METHOD), FDD (FEATURE-DRIVENDEVELOPMENT), CHARAKTERISTIKY, VÝHODY, PRINCIPY VÝVOJE, SROVNÁNÍ. EXTREME PROGRAMMING (XP), CHARAKTERISTIKA A VÝHODY XP. V této kapitole se dozvíme podrobnosti o metodikách Scrum a rodině metodik Crystal. Uvedeme hlavní role a postup práce v metodice Scrum a způsob využití metodik Crystal. Čas ke studiu: 2 hodiny Cíl: Po prostudování této kapitoly budete umět Objasnit hlavní myšlenky metodiky Scrum. Uvést role metodiky Scrum a odpovědnosti těchto rolí. Uvést hlavní principy rodiny metodik Crystal. Vyjmenovat jednotlivé metodiky rodiny Crystal. Výklad 8.1 SCRUM Scrum je iterativní inkrementální framework pro řízení komplexních prací (jako je vývoj nového produktu). Je navrhnutý pro týmy o třech až devíti pracovnících, které si rozdělí svou práci do činností, které mohou být dokončeny během cyklů s pevnou dobou trvání (tzv. sprinty). Týmy sledují vývoj a provádějí přizpůsobení plánů na denních 15minutových schůzkách, které se vyznačují tím, že probíhají ve stoje (tzv. stand-up meeting). Funkční části software jsou dodávány na konci každého sprintu. Klíčovým principem metodiky Scrum je dvojí poznání:  zákazníci mění své pohledy na to, co potřebují nebo chtějí  vzniknou nepředvídatelné situace, pro které není vhodný předpokládaný nebo plánovaný přístup. Autoři metodiky Scrum (Hirotaka Takeuchi a Ikujiro Nonaka) představili v roce 1986 tuto metodiku jako „tvorbu organizačních znalostí, která je vhodná především pro přínos inovace nepřetržitě, přírůstkově a spirálově“. Autoři popsali nový přístup k vývoji komerčního produktu, který by měl zvýšit rychlost a flexibilitu. Tento přístup byl vytvořen na základě případových studií z automobilového průmyslu, průmyslu zabývajícího se fotokopiemi a tiskařského průmyslu. Svůj přístup autoři nazývali holistickým nebo ragbyovým přístupem, ve kterém je celý vývoj prováděn jedním multifunkčním týmem v několika překrývajících se fázích; přístup, kde se tým „pokouší dostat dopředu jako celá jednotka, která si předává míč dozadu i dopředu“ (v překladu slovo „scrum“ znamená „mlýn“, používaný termín z ragby). 8.1.1 Role v metodice Scrum Ve frameworku Scrum existují tři hlavní role. Všechny tyto role dohromady tvoří tým Scrum („tým mlýnu“). Názvy rolí (a ostatní termíny spojené s frameworkem Scrum se podle jeho konvence píší kapitálkami na počátku každého podstatného jména. Můžeme se rovněž setkat s tzv. „velbloudím stylem“, viz výše). Jedná se o následující:  Vlastník Produktu (Produkt Owner)  Vývojový Tým (Development team)  Scrum master (v doslovném překladu „Mistr Mlýnu“ nebo Mlynář…v češtině však tento překlad v souvislosti s metodikami nevyznívá příliš dobře, budeme se proto v dále textu držet původního anglického označení Scrum master). Vlastník produktu – reprezentuje investory a hlas zákazníka. Odpovídá za to, aby tým do obchodu přinášel hodnotu. Vlastník produktu definuje produkt v termínech vlastních zákazníkovi (typicky se jedná o uživatelské příběhy – vyjádření požadavků a vlastností či funkcí systému v přirozeném jazyce), přidává je do tzv. backlogu (seřazený seznam požadavků. Tvoří jej vlastnosti, opravy chyb, jiné než funkční požadavky, atd.) a přiřazuje jim prioritu, na základě důležitosti a závislostí. V týmu Scrum v roli vlastníka produktu měla být jedna osoba, která by neměla být kombinována s rolí mistra. Role vlastníka produktu je ekvivalentem role zástupce zákazníka známé z metodiky XP. Vlastník produktu má v popisu svých úkolů následující komunikační záležitosti:  předvádí řešení klíčovým investorům, kteří nebyli přítomni na hodnocení sprintu.  definuje a oznamuje uvolnění funkčních verzí  informuje o stavu týmu  organizuje revize při dosažení milníků  zaškoluje investory v procesu vývoje  dojednává priority, rozsahy, časové plány, finanční fondy  zajišťuje, že je backlog produktu dostupný, transparentní a jasný Klíčovým povahovým rysem vlastníka produktu je empatie. Musí umět porozumět různým osobám v rolích investorů, které mají různé cíle, zkušenosti, pracovní role… Vlastník projektu se musí být schopen dívat z těchto různých úhlů pohledu. Musí být schopen rovněž „filtrovat“ informace, které předává, podle aktuálního stavu projektu, osoby se kterou komunikuje, atd. Příliš více informací, než je nutné, může v některých případech vést např. ke ztrátě investora. Schopnost vlastníka produktu komunikovat efektivně je rozšířena také jeho znalostmi v oblastech umožňujících identifikovat potřeby investora, vyjednat priority mezi zájmy investora a spolupracovat s vývojáři, aby byla zajištěna efektivní implementace požadavků. Vývojový tým – úkolem vývojového týmu je dodávat tzv. PSI – Potentially Shippable Products (potenciálně použitelný přírůstků) produktu v závěru každého sprintu. Jedná se vlastně o cíl sprintu. Team je tvořen třemi až devíti členy, kteří plní aktuální úkoly – design, vývoj, analýza, testování, dokumentace, technická dokumentace, atd. Vývojové týmy mají více funkcí, mají veškeré dovednosti, aby mohly vytvořit produktový přírůstek. Vývojový tým je sebeorganizační, avšak určité formy projektového managementu se mohou využívat i zde. Scrum master – nejedná se o klasického vedoucího nebo manažera týmu, ale spíše o prostředníka mezi týmem a možnými negativními okolnostmi či vlivy. Stará se o dodržování dohodnutých procesů a plánované dodržování procesu scrum. Mimo jiné, odpovědnost Scrum mastera zahrnuje zejména:  pomoc vlastníkovi produktu udržovat backlog produktu způsobem, umožňujícím správné pochopení požadovaným úkolům tak, aby tým mohl při vývoji neustále postupovat vpřed  pomoc týmu určovat definici hotových částí produktu, se vstupem klíčových investorů  koučing týmu v rámci principů metodiky Scrum s cílem dodat vlastnosti produktu ve vysoké kvalitě  podporu samoorganizace v rámci týmu  pomoc týmu vyhnout se nebo odstranit překážky bránící v postupu  usnadnění týmových schůzek pro zajištění pravidelného postupu  školení klíčových investorů v záležitostech týkajících se produktu – podle zásad Scrum. Rozdíl mezi projektovým manažerem a Scrum master je ten, že projektový manažer může mít odpovědnost také za lidské zdroje. 8.1.2 Průběh práce v metodice Scrum Sprint – je v metodice Scrum název iterace. Je základní jednotkou vývoje. Podléhá časovému omezení, které je předem pro každý sprint pevně stanoveno; obvykle se jedná o jeden týden až jeden měsíc. Nejobvyklejší jsou dva týdny. Každý sprint začíná plánovací schůzkou s cílem určit backlog sprintu, práci v daném sprintu a předběžný plán sprintu. Každý sprint končí revizí a retrospektivou sprintu, ve kterých probíhá hodnocení pokroku, které bude předloženo investorům a návrh zlepšení pro následující sprinty. V případě vývoje SW se na konci sprintu předpokládá funkční, integrovaný, otestovaný a zdokumentovaný produkt, který je možno dodat. Plánování sprintu – na začátku sprintu team uspořádá plánovací schůzku určenou k:  vzájemnému prodiskutování a odsouhlasení rozsahu prací pro daný sprint  výběru položek backlogu produktu, které budou dokončeny v jednom sprintu  přípravě backlogu sprintu obsahujícího práci, kterou je nutno vykonat pro dokončení vybraných položek backlogu produktu  doporučené trvání je čtyři hodiny pro dvoutýdenní sprint o během první poloviny celý tým scrum (vývojový tým, scrum master, vlastník produktu) vybere položky produktového backlogu, u kterých předpokládají, že budou dokončeny během daného sprintu o během druhé poloviny urči tým podrobné úkoly, které je nezbytné splnit pro dokončení těchto položek backlogu produktu – je vytvořen schválený backlog sprintu.  během plnění vytýčených úkolů mohou být některé položky backlogu rozděleny nebo vráceny zpět do produktového backlogu, pokud tým nepředpokládá jejich dokončení v průběhu daného (jednoho) sprintu  jakmile tým připravil backlog sprintu, může předběžně určit (většinou na základě hlasování), které úkoly budou během daného sprintu dodány Denní scrum – každý den během sprintu tým uspořádá denní scrum, tj. denní rychlý meeting, probíhající většinou ve stoje, dle následujících pravidel:  všichni členové vývojového týmu přijdou připraveni. Denní scrum: o začíná přesně v určeném čase a to i v případě nepřítomnosti některých členů týmu o každý den by měl probíhat ve stejném čase a na stejném místě o je časově omezen na patnáct minut  vítán je kdokoli, avšak přispívat mohou pouze členové vývojového týmu  během denního scrumu obvykle každý člen týmu odpovídá na tři otázky: 1. Jaký úkol, který může přispět týmu ke splnění cíle sprintu, jsem včera dokončil? 2. Jaký úkol, který může přispět týmu ke splnění cíle sprintu, plánuji dokončit dnes? 3. Vím o nějakých překážkách, které by mohly mně osobně anebo týmu zabránit ve splnění cílů sprintu? Jakákoli překážka (riziko, problém, opožděná závislost, atd.) identifikovaná na denním scrumu by měla být zaznamenána scrum masterem a vyvěšena (zobrazena) na týmové scrum tabuli nebo na tabuli sdílených rizik. Zároveň by měla být určena osoba pracující na vyřešení (odstranění) překážky (mimo denní scrum). Během denního scrumu by neměly probíhat žádné diskuze o podrobnostech. Revize a retrospektiva sprintu – na konci sprintu tým uspořádá dvě schůzky – revizi sprintu a retrospektivu sprintu. Na revizi sprintu tým:  reviduje dokončenou práci a plánovanou práci, která nebyla dokončena  prezentuje dokončenou práci investorům  tým a investoři spolupracují na dalším postupu (co se bude dělat dále) Revize sprintu se řídí následujícími pravidly:  nekompletní nebo nedokončená práce nemůže být prezentována (demonstrována)  doporučená doba trvání je dvě hodiny v případě dvoutýdenního sprintu Při retrospektivě sprintu tým:  uvažuje o minulém sprintu  určuje, probírá činnosti pro neustálé vylepšování procesu, na kterých se dohodne Retrospektiva sprintu se řídí následujícími pravidly:  jsou položeny dvě zásadní otázky: 1. Co šlo během sprintu dobře? 2. Co by mohlo být během příštího sprintu vylepšeno?  doporučená doba trvání schůzky je hodina a půl u dvoutýdenního sprintu  na schůzce je nápomocen scrum master Rozšíření činností – následující činnosti se obecně provádějí, ačkoli nejsou považovány za hlavní části metodiky Scrum: Upřesňování backlogu – je trvalým procesem revidování položek produktového backlogu společně s kontrolou, zda jsou tyto položky vhodně připraveny a zda je jim přiřazena správná priorita, a to takovým způsobem, aby byly pro týmy během vstupu do sprintu jasné a proveditelné (prostřednictvím činnosti plánování sprintu). Položky produktového backlogu mohou být rozděleny do několika menších, musí být ujasněna akceptační kritéria. Rovněž musí být identifikovány závislosti, výzkumné a přípravné práce. I když se nejedná o jednu ze základních praktik metodiky Scrum, upřesňování backlogu bylo přidáno do pravidel (příručky) metodiky Scrum a bylo přijato jako způsob řízení kvality položek produktového backlogu vstupujících do sprintu. Zrušení sprintu – vlastník produktu může v případě potřeby sprint zrušit. Může tak učinit na základě informací od týmu, scrum mastera nebo managementu. Management může požadovat zrušení sprintu například v případě, že vnější okolnosti negují hodnotu cíle sprintu. Je-li sprint abnormálně ukončen, pak dalším krokem je provedení nového plánování sprintu, kde je zrevidován důvod ukončení sprintu. 8.2 Crystal metodiky Myšlenka Crystal metodik vychází z toho, že jedna metodika nemůže vyhovovat všem projektům a vývojovým týmům. Proto Alistair Cockburn definoval techniku vytváření metodiky „just in time“. Vychází přitom z trojrozměrné matice (crystal) charakteristik projektu. Dimenze matice tvoří:  počet lidí zúčastněných na projektu  míra důležitosti vyvíjeného systému pro zákazníka  priority projektu Podle úrovně těchto základních faktů je vybrána metodika, která se dále přizpůsobí a vyladí podle potřeby konkrétního projektu. Metodiky Crystal jsou považovány za tzv. „lehké metodiky“. U Crystal metodik rozlišujeme reprezentace technik, nástrojů, norem a rolí. Metodiky Crystal se zaměřují na:  osoby  interakci  komunitu  zkušenosti  talenty  komunikace Cockburn tvrdí, že na proces, i když je důležitý, bychom se měli zaměřovat až ve druhé fázi. V první fázi bychom se měli zaměřit především na výše uvedené body. Myšlenkou stojící za metodikami Crystal je, že týmy zapojené v procesu vývoje software budou mít různé schopnosti, zkušenosti a budou různě talentované, a proto prvek procesu není hlavním faktorem. Protože týmy mohou řešit podobné úkoly rozdílnými způsoby, je rodina metodik Crystal v tomto ohledu velmi tolerantní, což z ní činí jednu z nejsnadnějších agilních metodik. V průzkumu, který Cockburn provedl (1999) definuje chování lidí v týmech:  „Lidé jsou komunikující bytosti, nejlépe komunikující tváří v tvář, osobně, s otázkami a odpověďmi v reálném čase.“  „Lidé mají problém jednat během času pořád důsledně.“  „Lidé jsou velmi proměnliví, mění se ze dne na den, z místa na místo.“  „Lidé obecně chtějí být dobrými občany, umí převzít iniciativu a udělat vše možné pro úspěšné zvládnutí projektu.“ Výše uvedené body jsou důvodem, proč jsou metodiky Crystal tak flexibilní a proč se vyhýbají striktním a rigidním procesům, které jsou často využívány v jiných metodikách. Cuckburn vyvinul různé metody v rodině metodik Crystal, které jsou vhodné pro týmy různých velikostí, které vyžadují rozdílné strategie k řešení rozličných problémů. Rodina metodik Crystal využívá k označení „váhy“ metodik různé barvy. V případě menších projektů je možné použít metodiky Crystal Clear, Crystal Yellow nebo Crystal Orange. V případě kritických projektů, při kterých může být v ohrožení lidský život, by měly být použity metodiky Crystal Diamond nebo Sapphire. Několik příkladů rozdělení rodiny Crystal podle barev: 1. Crystal Clear 2. Crystal Yellow 3. Crystal Orange 4. Crystal Orange Web 5. Crystal Red 6. Crystal Maroon 7. Crystal Diamond 8. Crystal Sapphire Obrázek 8-1 Projekty rodiny metodiky Crystal. Zdroj: A Practical Guide to Seven Agile Methodologies Part 2, http://www.devx.com/architect/Article/32836/0/page/2 Podle obrázku je patrné, že větší projekty mají tmavší barvu. Mezi všemi metodikami rodiny Crystal je sedm sdílených, obecných a převládajících vlastností. Cockburn zjistil, že čím více těchto vlastností je v projektu, tím větší je pravděpodobnost úspěchu. Vlastnostmi, o kterých je řeč, jsou: 1. Časté dodávky 2. Reflektivní vylepšování 3. Blízká komunikace nebo komunikace „na pozadí“ (osmotic communication) 4. Osobní bezpečnost 5. Zaměření 6. Snadný přístup k expertům 7. Technické prostředí s automatizovanými testy, řízením konfigurace a častou integrací V následujícím textu se podíváme na uvedené body podrobněji. Časté dodávky - znamenají časté uvolňování iterací softwaru. Myšlenka vychází z podstaty agilních metodik. Designéři a vývojáři rozhodují, které části softwaru, jeho vlastností a funkcí uvolní po každé iteraci. V případě metodik Crystal se jedná o iterace v trvání jednoho týdne až jednoho čtvrtletí. Reflektivní vylepšování – obnáší přerušení práce na vývoji a snahu nalézt lepší řešení procesů. Reflektivní vylepšování jsou usnadněna iteracemi – iterace poskytují zpětnou vazbu o tom, zda je daný proces funkční či nikoli. U metodik Crystal je doporučeno pořádání tzv. „reflektivních workshopů“ jednou za několik týdnů. Tyto workshopy pomáhají s nalezením procesů, které nepracují dobře a jsou týmu nápomocny při jejich modifikaci tak, aby mohla být vyvinuta strategie, která pro daný tým dobře funguje. Blízká nebo osmotická komunikace – je využívána v metodice Crystal Clear a dalších „menších“ metodikách rodiny Crystal. Osmotická komunikace znamená, že tým pracuje v jedné místnosti a jeho členové tak mají možnost komunikovat a řešit problémy spontánně, během celého dne, na rozdíl od diskuzí, které se dějí pouze na schůzkách. Tento přístup je velice výhodný, neboť umožňuje rychlé předávání informací mezi členy týmu, rychlé zodpovězení otázek, informovanost členů týmu o tom, co se právě děje a možnost rychle se zbavit mylných představ. Posloucháním komunikace mezi ostatními členy týmu má vývojář povědomí o tom, co ostatní dělají, může takto získávat zkušenosti a rozvíjet nové myšlenky. Osobní bezpečnost - schopnost členů týmu důvěřovat jeden druhému a svobodně vyjadřovat své myšlenky a problémy, kdykoli se vyskytnou. Pokud se člověk necítí v bezpečí např. při hovoru před skupinou lidí, nebo byl-li v minulosti za svůj názor, myšlenku, nápad ve skupině lidí např. zesměšněn, jen stěží se o jejich prezentaci pokusí příště, což je v týmové práci kontraproduktivní. Zaměření – v metodikách Crystal se zaměření týká dvou věcí – za prvé je to zaměření se na jednotlivou úlohu v projektu dostatečně dlouho na to, aby bylo dosaženo požadovaného pokroku, a za druhé jde o směr, kterým se projekt ubírá. U prvního z uvedených zaměření jde o pokrok v souvislosti s problémy, které by jej mohly ovlivnit, jak např. meetingy, dlouhé otázky, telefonní hovor, atd. Tyto činnosti narušují proces vývoje a může nějakou dobu trvat, než je v procesu pokračováno. Tato zdržení zpožďují dokončení aktuální úlohy. Crystal definuje dvě pravidla pro záležitosti, které mohou přerušit zaměření se na daný úkol. Jedním jsou dvouhodinové časové úseky, ve kterých by vývojář neměl práci nijak přerušovat. Druhým pravidlem je přiřazení vývojáře k projektu alespoň dva dny předtím, než je přiřazen k jinému projektu. U druhého významu zaměření jsou diskutovány takové problémy, jako např. definice cílů. Definice by měly být jasné a vývojáři by měli přesně vědět, co cíle projektu zahrnují. Snadný přístup k expertům - tento bod obnáší práci vývojářů se specialistou tak, aby tento specialista mohl odpovídat na otázky, navrhovat řešení problémů, atd. Expert by měl být skutečný uživatel a nikoli pouze tester jako člen vývojového týmu. Technické prostředí s automatizovanými testy, managementem konfigurace a časté integrace – hlavní myšlenkou by měly být neustálá integrace a testování tak, aby mohly být odhaleny chyby, poškození, atd. v případě provedení změny. Protože se uvedené provádí pravidelně, problémy by neměly narůstat, protože mohou být odstraněny/vyřešeny dříve během projektu. Shrnutí pojmů 8.1. V této kapitole jsme se zabývali metodikami SCRUM a rodinou metodik Crystal. Uvedli jsme hlavní role frameworku Scrum:  Vlastník Produktu (Produkt Owner)  Vývojový Tým (Development team)  Scrum master včetně popisu těchto rolí. U metodiky Scrum jsme rovněž popsali průběh práce a pojmy  Sprint  Plánování sprintu  Denní scrum  Revize a retrospektiva sprintu a rozšiřující činnosti:  Upřesňování backlogu  Zrušení sprintu U rodiny metodik Crystal jsme si vysvětlili, z čeho její tvůrce Cockburn vycházel a na co se metodiky Crystal zaměřují. Jde o  osoby  interakci  komunitu  zkušenosti  talenty  komunikace Zmíněny byly i některé z metodik patřících do rodiny Crystal: 1. Crystal Clear 2. Crystal Yellow 3. Crystal Orange 4. Crystal Orange Web 5. Crystal Red 6. Crystal Maroon 7. Crystal Diamond 8. Crystal Sapphire V této souvislosti jsme si uvedli i systém jejich barevného značení a uvedli sedm jejich základních společných vlastností: 1. Časté dodávky 2. Reflektivní vylepšování 3. Blízká komunikace nebo komunikace „na pozadí“ (osmotic communication) 4. Osobní bezpečnost 5. Zaměření 6. Snadný přístup k expertům 7. Technické prostředí s automatizovanými testy, řízením konfigurace a častou integrací Otázky 8.1. 1. Vysvětlete principy metodiky Scrum. 2. Jaké znáte hlavní role metodiky Scrum? 3. Objasněte pojem „sprint“ v metodice Scrum. 4. K čemu slouží tzv. „denní scrum“? 5. Co je hlavním přínosem metodik rodiny Crystal? 6. Objasněte, k čemu slouží „osmotická komunikace“. 7. Čím osmotická komunikace přispívá při vývoji software? 9 SW NÁSTROJE: CASE NÁSTROJE A JEJICH ROZDĚLENÍ (PRE, UPPER, MIDDLE, LOWER, POST). IDE NÁSTROJE. CASE IDE NÁSTROJE, PŘEHLED VYBRANÝCH NÁSTROJŮ (CASE STUDIO, ORACLE DESIGNER). V této kapitole se seznámíme s pojmem CASE nástroje a jejich rozdělením podle různých kritérií. Uvedeme si způsoby jejich využití a konkrétní příklady vybraných CASE nástrojů. Čas ke studiu: 2 hodiny Cíl: Po prostudování této kapitoly budete umět Objasnit co jsou to CASE nástroje a k čemu slouží. Orientovat se v různých typech CASE nástrojů. Uvést příklady CASE nástrojů. Výklad 9.1 Obecná charakteristika CASE nástrojů CASE nástroj:  CASE - Computer Aided System (Software) Engineering  účel - automatizace některých fází vývoje IS  množina integrovaných softwarových nástrojů CASE nástroje pomáhají při tvorbě grafických modelů softwarových systémů. Jedná se o software sloužící k podpoře vývoje dalšího softwaru a vylepšení procesů jeho vývoje. CASE nástroje často obsahují možnosti pro ladění kódu, vytvoření uživatelského rozhraní, nástroje pro hromadnou úpravu kódů, atd. Podpora CASE nástrojů spadá do mnoha činností a oblastí, mezi které se řadí např. podpora při stanovení požadavků, podpora při analýzách, podpora při návrhu a podpora při programování. CASE nástroje umí generovat zdrojový kód, vytvářet datové modely, spravovat konfigurace, provádět refraktoring apod. Pro člověka je často pochopitelnější systém zobrazený např. diagramem (tzn. obrázkem) než složité slovní popisy tohoto systému. CASE nástroje rovněž disponují schopností automatického generování zdrojového kódu z modelů, což je významným usnadněním práce vývojářů. Některé CASE nástroje umožnují rovněž opak – generování diagramů/modelů ze zdrojového kódu (tzv. reverse engineering). V obou případech poskytují rovněž možnosti synchronizace mezi modelem a zdrojovým kódem. Často jsou CASE nástroje využívány při tvorbě dokumentace – z modelu, ze zdrojového kódu. Integrované nástroje:  jsou schopné vzájemně si předávat výsledky  jednotná databáze (repository) CASE nástroje Výhody CASE:  podpora tvorby katalogu požadavků na systém (specifikace systému)  podpora tvorby analytických a návrhových modelů  údržba projektové dokumentace k vyvíjenému IS  automatické generování programového kódu  automatické generování struktury databáze v daném databázovém prostředí  podpora testování systému 9.2 Dělení CASE nástrojů CASE nástroje se dělí podle různých kritérií. Nejčastějším dělením je:  dělení podle životního cyklu projektu (PRE CASE, UPPER CASE, MIDDLE CASE, LOWER CASE, POST CASE)  dělení podle interaktivity  dělení podle fáze projektu  dělení podle délky využívání (jsou využívány během celého životního cyklu SW?)  dělení podle stupně integrace 9.2.1 Dělení podle životního cyklu projektu  pre CASE - jsou využívány při činnostech předcházejícím vývoji SW (globální strategie)  upper CASE - jsou využívané v etapě analýzy systému  middle CASE - jsou používány v etapě návrhu (designu) systému  lower CASE - jsou používány v etapě implementace systému  post CASE - jsou využívány k podpoře fáze uvedení SW do provozu, jeho údržbě a další organizační činnosti Obrázek 9-1 Dělení CASE nástrojů podle životního cyklu projektu 9.2.2 Dělení podle interaktivity Toto dělení koresponduje se svým názvem. CASE nástroje mohou, ale nemusí být interaktivní. Mezi interaktivní patří například nástroje, které podporují návrhové metody a mezi neinteraktivní se řadí například vývojové nástroje a překladače. 9.2.3 Dělení podle fáze projektu V tomto dělení se jedná o tzv. front-endové či back-endové nástroje. Do jaké skupiny CASE nástroj patří, závisí na fázi vývoje software, ve které se využívají.  front-end CASE – využívají se v prvotních fázích projektu, jedná se například o nástroje pro podporu návrhu.  back-end CASE – využívají se v pozdějších fázích projektu. Jedná se například o testovací nástroje, překladače zdrojového kódu apod. 9.2.4 Dělení podle délky využívání Jedná se o dělení na vertikální resp. horizontální CASE nástroje.  vertikální – podporují jen určitou část nebo oblast životního cyklu software, například tvorbu programového kódu, modelování, zjišťování požadavků uživatele, atd.  horizontální – podporují několik částí nebo oblastí životního cyklu software, jedná se například o nástroje určené ke tvorbě dokumentace, řízení konfigurace, apod. 9.2.5 Dělení podle stupně integrace Toto dělení obsahuje následující kategorie CASE nástrojů: CASE Tools – nástroje sloužící k automatizované podpoře jakékoli úlohy v životním cyklu software. CASE Toolkits – jedná se o kolekci integrovaných CASE nástrojů, umožňujících dílčí či komplexní podporu pouze během jedné fáze projektu. CASE Workbenches – poskytují dílčí nebo úplnou podporu v alespoň dvou fázích životního cyklu software. I-CASE – jedná se o nejvyšší stupeň integrace. Propojují několik CASE Tools, Toolkits a Workbenches. 9.3 Použití CASE nástrojů v průběhu vývoje IS Obecně k vlastnostem CASE nástrojů:  účel CASE nástroje o vývoj informačních systémů a software v architektuře klient/server o vývoj aplikací speciálně pro Internet o vývoj aplikací v prostředí datových skladů o modelování a optimalizace podnikových procesů  integrace CASE nástroje s ostatními nástroji o např. tvorba požadavků na systém a testování systému  soulad CASE nástroje s používanou metodikou a metodami projektování IS o objektový a strukturovaný přístup  používaná notace o dnešní standardy - UML, BPMN  sledování požadavků specifikace a jejich řešení  modularita CASE nástroje, jeho otevřenost a modifikovatelnost o customizace – přizpůsobení uživateli  repository CASE nástroje o databáze, soubor, platforma OS, …  sdílení komponent a správa projektu o podpora týmové práce 9.4 Příklady nástrojů CASE 9.4.1 Enterprise Architect (Sparx Systems) Jedná se o velice sofistikovaný CASE nástroj, s použitím během celého životního cyklu software. Modelování během celého životního cyklu zahrnuje použití pro:  podnikové a IT systémy  vývoj systémů a software  vývoj v reálném čase a vývoj pro embedded platformy Enterprise Architekt umožňuje modelování pomocí diagramů (UML), výstupy zdrojových kódů a propojení s řadou programovacích jazyků, sofistikované testování a monitorování. Mezi podporované programovací jazyky patří například:  ActionScript  Ada  C and C++  C#  Java  Delphi  Verilog  PHP  VHDL  Python  System C  VB.Net  Visual Basic  a další… Více informací na stránkách výrobce: https://www.sparxsystems.com.au/products/ea/index.html 9.4.2 Case Studio Tento CASE nástroj slouží především k navrhování databázových struktur. V programu je možné snadno vizuálně vytvářet ER diagramy pro různé typy databází (Oracle, MS SQL, DB2, Firebird, Advantage DB server, Interbase, MaxDB, MS Access, MySQL, PostgreSQL a další). Kromě ER diagramů nástroj umožňuje také tvorbu diagramu datových toků (DFD). Je rovněž silným nástrojem pro reverse engineering - umožňuje vytvořit model struktury již existující databáze; Nástroj slouží také jako správce verzí - umožňuje porovnávat jednotlivé verze modelů. Mezi další silné stránky nástroje patří rovněž velice detailní logické i fyzické HTML reporty, vytvoření galerií pro uložení nejčastěji používaných částí modelů, podpora uživatelů, uživatelských skupin a uživatelských práv, uživatelsky definovaných šablon, možnost tvorby tzv. "ToDo" seznamu, vytvoření datového slovníku, atd. Více informací na stránkách výrobce: http://www.casestudio.com/enu/index.aspx 9.4.3 Oracle Designer (Oracle) Oracle Designer je dodáván v rámci balíku Oracle Developer Suite. Designer zahrnuje podporu pro modelování podnikových procesů, systémovou analýzu, návrh software a tvorbu systémů. Poskytuje víceuživatelský repozitář založený na Oracle SCM, který je úzce integrován s nástrojem Oracle Forms Developer (nástroj pro vytváření deklarativních databázových aplikací). Tímto způsobem Oracle designer umožňuje organizacím navrhovat a rychle dodávat systémy v architektuře klient-server, které jsou přizpůsobitelné měnícím se potřebám podniku. Více informací na stránkách výrobce: http://www.oracle.com/technetwork/developer- tools/designer/overview/index-082236.html 9.4.4 Další CASE nástroje Mezi další nástroje pro podporu modelování systémů patří například:  MagicDraw (No Magic) - https://www.nomagic.com/products/magicdraw  Powerdesigner (Sybase) - https://www.sap.com/cz/products/powerdesigner-data- modeling-tools.html  Rational Rose (IBM) - http://www-03.ibm.com/software/products/en/enterprise  Microsoft Visio (Microsoft) - https://www.microsoft.com/en-us/store/collections/visio Shrnutí pojmů 9.1. V této kapitole jsme se dozvěděli informace o tom, co jsou CASE (Computer Aided System (Software) Engineering) nástroje. Víme, že se často jedná o množinu integrovaných softwarových nástrojů. Účelem jejich použití je zejména automatizace některých fází vývoje software. Jinými slovy, CASE nástroje pomáhají při tvorbě grafických modelů softwarových systémů. CASE nástroje řadíme do kategorií podle různých kritérií:  podle životního cyklu software pre, upper, middle, lower, post  podle interaktivity  podle fáze projektu - front-end, back-end  podle délky využívání – vertikální, horizontální  podle stupně integrace - CASE Tools, CASE Toolkits, CASE Workbenches, I- CASE V kapitole jsme si uvedli rovněž příklady některých komerčních CASE nástrojů: MagicDraw, Powerdesigner, Rational Rose (IBM), Microsoft Visio, Enterprise Architekt, Oracle Designer a Case Studio. Otázky 9.1. 1. Co jsou CASE nástroje a k čemu slouží? 2. Jak dělíme CASE nástroje? 3. Jaký je rozdíl mezi horizontálními a vertikálními CASE nástroji? 4. Jaké CASE nástroje znáte? 5. Jaký CASE nástroj byste použili pro modelování ER digramu a diagramu datových toků (DFD)? 10 TRENDY V OBLASTI MODELOVÁNÍ SW: AKTUALITY, VÝVOJ, VÝZKUM, TECHNICKÉ NOVINKY V OBORU SW INŽENÝRSTVÍ. V této kapitole se seznámíme s některými trendy v oblasti softwarového inženýrství. Seznámíme se s rozšířením jazyka UML – MDA a jeho hlavních vlastnostech. V několika bodech rovněž uvedeme hlavní body současného vývoje oboru softwarového inženýrství. V závěru kapitoly se stručně seznámíme s výhodami/nevýhodami automatizace modelování a důvodech prospěšnosti využívání šablon. Čas ke studiu: 2 hodiny Cíl: Po prostudování této kapitoly budete umět Objasnit vztah UML a MDA. Uvést hlavní prvky MDA a jejich notaci. Orientovat se ve výhodách automatizace modelování a využití šablon. Výklad 10.1 Obecné trendy v oboru softwarového inženýrství Obecně je možné trendy v oblasti modelování SW shrnout do několika bodů, které stručně vyjadřují aktuální směr a vývoj v tomto oboru:  použití iterativních postupů - aplikováno v podobě spirálového modelu a techniky prototypování.  pronikání objektových metod, technik a nástrojů  „globalizace“ pojetí analýzy - před automatizací podnikových procesů je nutné je optimalizovat a teprve pak provést analýzu…  posun od „hard“ k „soft“ metodám - Software je nutno chápat jako sociálnětechnický. Současné metodiky tedy zahrnují i techniky analýzy zájmů a postojů různých skupin uživatelů, školení, konzultací…prostě – i lidská dimenze je důležitá.  aplikace metodik pro implementaci typového aplikačního SW (TASW) – např. zavádění ekonomického systému SAP/R3, produktů Oracle, atd.  vznik a rozvoj agilních metodik – metodik, které se snaží oprostit od náročnějších postupů vývoje v zájmu rychlosti vývoje… Mimo tyto body lze v této souvislosti nastínit i skutečnosti uvedené dále v této kapitole: 10.2 UML a MDA V minulosti byly používány verze UML s číselným označením nižším než 2. Schválená verze 2 normy UML s označením UML 2.0 zavádí změny, které se týkají především modelování činností (aktivit), komponent a interakcí. Pořád však existuje mírná „neomalenost“ UML 2.0, vzhledem k tomu, že je směsí nejednotných způsobů notace pro tvorbu real-time a podnikových systémů, což jej činí složitějším v používání, pro pochopení a zvládnutí. Uvedená skutečnost vedla konsorcium OMG (jakožto vývojáře jazyka UML) k vývoji novější architektury, s názvem MDA (Model Driven Architecture/Modelem řízená architektura). 10.2.1 Modelování v MDA a členění modelů MDA umožňuje standardizaci dvou rovin modelování:  členění modelů během vývoje  obecné zásady transformace modelů (jednoho modelu na druhý) V MDA existují tři typy modelů:  ICIM – zkratka pro Computation Independent Model, model, který je nezávislý na počítačovém zpracování  IPIM – zkratka pro Platform Independent Model, model, který je nezávislý na platformě pro implementaci  IPSM – zkratka pro Platform Specific Model, model určený pro specifickou platformu Tyto tři modely mají z hlediska tvorby modelů aplikací své specifické vlastnosti. S těmito vlastnosti se podrobněji seznámíme v dalším textu. ICIM – tento model vznikl na základě začlenění normy iniciativy BPMI (Business Process Modeling Initiative) pod správu konsorcia OMG. Iniciativa BPMI vytvořila normu BPMN – Business Process Modeling Notation, kterou je možné využít k modelování podnikových procesů. Dosud používané nejednotné notace byly touto normou ve značné míře standardizovány a ujednoceny. BPMN nejenže klade důraz na standardizovanou vizualizaci procesu, ale rovněž na mapování symbolů BPMN do jazyka BPEL (Business Process Execution Language), používaného pro tvorbu vizuálních modelů. Toto mapování by mělo ulehčit automatizaci procesu při modelování v systémech workflow a také při jejich případné simulaci. Zatím se nedá hovořit o přímém začlenění BPMN do jazyka UML, nicméně BPMN je zavedena jako rozšíření (rozšiřující norma) jazyka UML určená pro modelování podnikových procesů. V roce 2011 byla společností OMG vydána verze BPMN 2.0, která je využívána do současné doby (2017). Obrázek 10-1 Příklad notace BPMN. Zdroj: https://www.lucidchart.com/pages/bpmn 10.1.1.1 Notace v BPMN Pro diagramy podnikových procesů BPMN definuje čtyři typy elementů: 1. Objekty toků – události, činnosti a brány 2. Spojovací objekty – sekvenční toky, toky zpráv a asociace 3. Plavecké dráhy – bazén nebo pruh (cesta) 4. Artefakty – datový objekt, skupina, anotace Události – jsou spouštěče, které spouští, modifikují nebo ukončují proces. Typy událostí jsou např. zprávy, časovače, chyby, signály, zrušení apod. Zobrazují se jako kruhy obsahující další symboly v závislosti na typu události. Jsou také dále klasifikovány jako události vyvolávající nebo reagující. Obrázek 10-2 Události. Zdroj: https://www.lucidchart.com/pages/bpmn Činnosti (aktivity) – zobrazení konkrétní činnosti nebo úlohy prováděné osobou nebo systémem. Značí se obdélníkem se zaoblenými rohy. Obrázek 10-3 Činnosti. Zdroj: https://www.lucidchart.com/pages/bpmn Brány – jsou rozhodovacími body, které nastavují cestu v závislosti na podmínkách nebo událostech. Jejich notací je čtverec otočený vrcholem dolů. Mohou být exkluzivní nebo inkluzivní, paralelní, složené nebo založené na datech či událostech. Obrázek 10-4 Brány. Zdroj: https://www.lucidchart.com/pages/bpmn Sekvenční toky – znázorňují pořadí prováděných činností. Značí se rovnou čárou zakončenou šipkou. Používá se pro znázornění podmíněného toku nebo běžného toku. Obrázek 10-5 Sekvenční toky Toky zpráv- označují zprávy, které jsou předávány přes „bazény“ (pooly) nebo hranice organizací (např. jednotlivá oddělení). Neměly by být používány pro spojení mezi událostmi a činnostmi v poolu. Znázorňují se přerušovanou čarou s kroužkem na jedné straně a šipkou na straně druhé. Obrázek 10-6 Toky zpráv. Zdroj: https://www.lucidchart.com/pages/bpmn Asociace – asociují artefakt nebo text s událostí, činností nebo bránou. Značí se tečkovanou čarou. Obrázek 10-7 Asociace. Zdroj: https://www.lucidchart.com/pages/bpmn Bazén (pool) a plavecká dráha – pool znázorňuje hlavní účastníky procesu. Rozdílný pool může představovat jinou společnost nebo oddělení, které jsou však stále zapojeny do procesu. Plavecké dráhy v bazénu znázorňují činnosti a toky pro určitou roli nebo účastníka, čímž definují odpovědnost – kdo je odpovědný za dané části nebo proces. Artefakt – dodatečné informace přidávané vývojáři za účelem zpřístupnění dalších podrobností. Používají se tři typy artefaktů: datový objekt, skupina nebo anotace. Datový objekt ukazuje potřebnost dat pro činnost. Skupina znázorňuje logické seskupení činností, avšak nemění toky diagramu. Anotace poskytuje další vysvětlení k části diagramu. IPIM – v současné době je dominujícím nástrojem pro tvorbu platformě nezávislého modelu v etapě analýzy jazyk UML. I přesto, že UML 2.0 zavádí přehlednější členění a lepší provázanost diagramů při modelování interakcí, stále existuje mezera v podobě formálního specifikačního jazyka, který by byl vhodný i pro účely analýz. Současná specifikace UML sice umožňuje využití doplňku OCL (Object Constraint Language), ale ten je z hlediska čitelnosti běžnými uživateli nevhodný, neboť se podobá objektově orientovaným jazykům, do kterých je zasvěcena pouze úzká skupina uživatelů, zejména programátorů a informatiků. Z vizuálního hlediska jsou sice analytické modely normovány, avšak popisy jednotlivých elementů jsou zcela na uvážení tvůrců těchto modelů. Tento neduh se, bohužel, objevuje i nadále v MDA, neboť ani tato architektura neobsahuje přesná vymezení toho, co by mělo být obsahem na platformě nezávislého modelu. Určitým přínosem a zlepšením MDA v této oblasti je alespoň začlenění opakovaně použitelných částí – iterace se tak díky nim stávají rovněž součástí analýzy a mají zjevně podstatný vliv na náklady projektu, management jakosti a postup prací na projektu. IPSM – v současné době různá IDE (Integrated Development Environment, integrovaná vývojová prostředí) nabízí programátorům vizualizaci programového kódu ve formě modelu UML. Nezbytnou součástí aktivních znalostí vývojáře se tedy stává i UML. Modely UML, vygenerované ve vývojových prostředích jsou svou strukturou shodné se zdrojovým kódem, a tudíž nepříliš čitelné pro běžného uživatele, který nemá znalosti programátora. Analytik většinou tyto modely s obtížemi pochopí, pro běžného uživatele aplikace je však porozumění takovýmto modelům nad rámec jeho chápání. Jistým řešením je synchronizace programových kódů s modely prostřednictvím různě sofistikovaných nástrojů CASE, s využitím XMI (XML Metadata Interchange) – standardů zavedených a vypracovaných sdružením OMG. Současným trendem je využívání diagramu interakcí (Diagram Interchange), který rozšiřuje specifikaci formátu XMI scílem standardizace přenosu a prezentace diagramů UML. 10.3 Automatizace modelování Automatická tvorba různých částí modelů pomocí modelovacích nástrojů (CASE) je dalším trendem současné doby (2017). Tyto nástroje se mohou pyšnit stále se rozšiřující podporou a integrací nástrojů automatizace tvorby modelů. Obvyklým fenoménem při práci vývojářů je propracované vytvoření diagramu či modelu tříd na úkor ostatních modelů systému. Zmíněný fenomén je častým důsledkem nedostatku času a ve vytvářených modelech jsou pak zahrnuty pouze nejdůležitější části systému a podrobnější zpracování chybí. To má za následek zvýšené riziko chybovosti a nekonzistentnosti, protože provádět důkladné automatické testování těchto nekompletních modelů je často nemožné. Vytváření kompletních modelů však stojí mnoho času a jedná se o velice pracnou a zdlouhavou a nepříliš oblíbenou činnost. Určitým řešením tohoto problému je automatizace na základě předem připravených šablon, a to zejména u mnoha rutinních činností. Šablony jsou však často závislé na mnoha faktorech a proto jsou využívány zejména při modelování pro specifické platformy. Velmi obvyklá je také tvorba šablon na základě návrhových vzorů. Pro společnosti, zabývající se častým vývojem software pro specifické platformy, může být investice do vytvoření šablon pro používané stereotypy modelů velice přínosná. Šablony využijí totiž nejen při vlastním modelování systému a s ním související důkladném automatizovaném testování konzistence modelů, ale i později ve fázi údržby sytému, protože jsou do vytvořeného modelu zahrnuty veškeré závislosti. Shrnutí pojmů 10.1. V kapitole zabývající se trendy v oblasti modelování software jsme se dotkli některých nedokonalostí UML a uvedli si jejich řešení (do určité míry), zaváděná MDA. Popsali jsme tři hlavní typy modelů v MDA:  ICIM  IPIM  IPSM Ukázali jsme si také způsoby notace standardizované v BPMN a popsali čtyři typy prvků, které BPMN využívá:  Objekty toků, mezi které patří události, činnosti a brány  Spojovací objekty, mezi které patří sekvenční toky, toky zpráv a asociace  Plavecké dráhy, mezi které patří bazén nebo pruh (dráha)  Artefakty, mezi které patří datový objekt, skupina a anotace V posledním odstavci o automatizovaném modelování jsme nastínili důvody využití šablon a výhody jejich využívání při častém modelování procesů softwarových systémů. Řekli jsme si také, k čemu vede modelování s neuvedením podrobností do dostatečné hloubky. Otázky 10.1. 1. Co znamená zkratka MDA? 2. Jaké byly důvody vzniku MDA? 3. Jaké jsou hlavní typy modelů v MDA? 4. Proč je současným trendem posun od hard k soft metodám? 5. Uveďte typy prvků používané v notaci BPMN a popište jejich značení a význam. 6. Jaké výhody má využití šablon modelů?