Objektové metody modelování Tutoriál IV RNDr. Zdeněk Franěk, Ph.D. Metodika RUP, UP a agilní metodiky tvorby software a informačních systémů Co je to UP 2 • • •SEP nebo SDP definuje při vývoje software otázky kdo, co, kdy a jak. •SEP je proces v němž jsou uživatelské požadavky realizovány vytvořeným softwarem viz obrázek další slide •Požadavek = vyjádření přání uživatele •UP – Unified Process je rozsáhlá, propracovaná objektově orientovaná iterativní metodologie vývoje softwaru. •UP je vyspělý otevřený standard procesu tvorby softwarového vybavení vyvinutý autory jazyka UML •RUP – Rational Unified Process je komerčním produktem, který rozšiřuje metodiku UP •Pro každý nový projekt je třeba vytvořit novou instanci metodiky RUP; specifická komerční podtřída UP – – – – – Software engineering process Software development process SEP graficky 3 – – – – – Historie UP 4 • – 1967 2001 UP a RUP 5 •Modelují aspekty kdo, kdy a co nepatrně odlišným způsobem •RUP vykazuje určité terminologické a syntaktické odlišnosti •Sématika elementů jednotlivých metod se nezměnila •Mapování symbolů metodiky RUP na symboly metodiky UP – UP a RUP - modelování aspektů 6 •Kdo ⁃Metodika UP nabizí koncepci dělníka (worker), popisuje roli jedince, týmu uvnitř projektu ⁃Metodika RUP nabízí koncepci role •Kdy ⁃Aspekty kdy jsou v UP modelovány jako aktivity = úlohy, které budou dělníci týmy vykonávat – přijímají role ⁃Posloupnost aktivit je v metodice UP i RUP označována jako pracovní postup - workflow ⁃Tok pracovních činností a dokumentů •Co ⁃Aspekty „co“ procesu tvorby SW jsou v UP i RUP označovány jako artefakty (artefacts) ⁃Artefakty jsou předměty, které do projektu vstupují nebo jsou jeho produkty, používá se termínu „Meziprodukty“ ⁃Např. model, element modelu (např. třída, případ užití, subsystém), zdrojový kód, spustitelná aplikace •Jak ⁃Na otázku jak odpovídají činnosti (activities) ⁃Činnost je jednotkou práce, kterou má provést workers ⁃Jasně definovaný účel ve vztahu k meziproduktu ⁃Činnost se obvykle týká jednoho pracovníka a ovlivňuje několik málo meziprofuktů (artefaktů) n n n Konkrétní aplikace metodiky UP v novém projektu 7 •Metodika UP je obecnou metodou tvorby software •Pro každou organizaci a pro každý jednotlivý projekt je třeba vytvořit novou instanci. •Uznává se, že každý SW produkt se od ostatních liší – –Definice a začlenění: – •vnitropodnikových standardů •šablon dokumentů •nástrojů – překladačů, nastrojů pro správu konfigurace •databází – sledování chyb, sledování projektu •úprav životnosti, např. kontrola kvality bezpečnostních systémů – • Axiomy metodiky UP 8 •Zásada řízení případem užití a rizikem •Zásada soustředění se na architekturu •Zásada iterace a přírůstku (inkrementu) •POZN. •Případy užití jsou způsobem, jak zachytit požadavky •Metodika UP posuzuje stavbu SW na základě analýzy možných rizik •Metodika UP je založena na návrhu a vývoji robustní architektury systému •Architektura popisuje rozklad systému na komponenty, ale také jak se ovlivňují a jak jsou nasazeny do hardware •Iterační proces znamená rozklad projektu na menší podprojekty (iterace) nebo na přírůstky (inkrementy) •Tvoříme SW v procesu postupného upřesňování našeho konečného záměru •Např. k analýze se vracíme několikrát (dříve jen postupně analýza, návrh, tvorba). Iterativní a přírůstkový proces 9 •Menší problémy se řeší lépe, něž větší •Rozložení velkého softwarového projektu na řadu menších miniprojektů •Každý takový miniprojekt je považován za iteraci, která obsahuje všechny prvky normálního sw projektu: –Plánování –Analýza a návrh –Tvorba –Integrace a testování –Interní nebo externí uvedení – –Baseline - každá iterace generuje vlastní základní linii, která se skládá z částečné kompletní verze finálního systému a z veškeré přidružené projektové dokumentace. –Základní linie jsou postupně vrstveny, až je dosažena konečná podoba vytvářeného systému. –Inkrement (přírustek) = rozdíl mezi základními liniemi – –UP JE OZNAČOVÁN ZA ITERATIVNÍ a PŘÍRUSTKOVÝ Pracovní postupy iterace (workflows) 10 •5 hlavních aktivit: •Požadavky. Zachycují, co by měl systém dělat • •Analýza. Vybroušení požadavků a jejich strukturování • •Návrh. Realizace požadavků v architektuře systému. • •Implementace. Tvorba softwaru. • •Testování. Ověření, zda implementace funguje tak, jak se od ní očekává. Základny iterací a přírůstky 11 •ITERACE –Každá iterace generuje baseline. –Baseline - Poskytuje smluvený základ pro další přezkoumání a vývoj, může být měněna pouze prostřednictvím formálních metod správy konfigurace a změn – – •PŘÍRŮSTEK (INKREMENT) –Jsou pouze rozdílem jednou a další základní linií –Jsou to dílčí kroky k finální odevzdávané verzi systému 10.12.2021 Úvod do objektového modelování 11 STRUKTURA METODIKY UP 12 •4 základní po sobě následující • •Začátek (inception) – období plánování • •Rozpracování (elaboration) – období architektury • •Konstrukce (construction) – počátky provozuschopnosti • •Zavedení (transition) – nasazení produktu do uživatelského prostředí • 10.12.2021 Úvod do objektového modelování 12 Struktura metodiky UP 13 • – 1967 2001 Fáze a pracovní postupy a objem prací UP 14 10.12.2021 Úvod do objektového modelování 14 Fáze a pracovní postupy a objem prací RUP 15 10.12.2021 Úvod do objektového modelování 15 Fáze METODIKY UP - Začátek (inception) – období plánování 16 •Každá fáze má svůj cíl. •Cílem fáze Začátek je „odstartování projektu“ –Tvorba podmínek proveditelnosti (virtual prototyping) –Nadnesení obchodního (podnikatelského případu –Zachycení podstatných požadavků –Označení kritických rizik –Hlavní pracovníci: manažer projektu a systémový projektant •Primární zaměření –Hlavní důraz na pracovní postupy specifikace požadavků a jejich analýza –Technický prototyp, pak návrhářské a implementační práce –Jedinými sw artefakty jsou prototypy, není nutno testovat •Milník (nastavuje určité cíle, kterých má být dosaženo) –Milníkem počáteční fáze je předmět životního cyklu a rozsah systému, tzv. Life Cycle Objektivies •Podmínky, které musí být splněny: • – Začátek (inception) – podmínky splnění 17 Fáze METODIKY UP Rozpracování (elaboration) – období architektury 18 •Cílem fáze Rozpracování –Tvorba sputitelného architektonického základu –Vylepšení odhadu rizik –Definice atributů kvality –! Zachycení případů užití pro 80% funkčních požadavků –Tvorba přesného plánu konstrukční fáze –Formulace nabídky, prostředky, čas, vybavení, personál a náklady •Primární zaměření –Požadavky – upřesnění rozsahu systému a požadavků na něj kladených –Analýza – stanovení toho, co budeme tvořit –Návrh – tvorba stabilní architektury –Implementace – tvorba spustitelného architektonického základu –Testování – testování architektonického základu •Milník této fáze je architektura (Life Cycle Architecture) –Prověřujeme detailní předměty systému, architecturu a rozsah, výběr architectury a výsledek základních rizik – – – Rozpracování (elaboration) – podmínky splnění 19 – – Fáze METODIKY UP Konstrukce (construction) – počátky provozuschopnosti 20 •Cílem fáze Konstrukce –Splnění požadavků analýzy a návrhu a vyvinout ze spustitelného základu konečnou verzi systému –Zachování integrity vytvářeného systému !!! •Primární zaměření –Důraz na pracovní postup implementace –Požadavky – odhalit požadavky, které byly v dřívějších fázích přehlédnuty –Analýza – dokončit analytický model –Model – dokončit návrh modelu –Implementace – zajistit počáteční provozní způsobilost (Initial Operational Capability) –Testování – testovat počáteční funkční variantu •Milník – sw systém je připraven pro testování –tzv. beta verze – Konstrukce (construction) – podmínky splnění 21 • – – Fáze METODIKY UP Zavedení (transition) – nasazení produktu do uživatelského prostředí 22 •Cílem fáze Zavedení –Začíná v okamžiku dokončení testování a konečné nasazení systému –Oprava chyb –Příprava uživatelského pracoviště –Přizpůsobení sw na pracovišti uživatele –Úprava software v případě problémů –Tvorba manuálů a dokuntace –Konzultace s uživateli –Koncová revize •Primární zaměření – důraz na implementaci a testování –Požadavky a analýza se už nepoužívá –Návrh – úprava návrhu, jsouli během testování nalezeny chyby –Implementace – přizpůsobení SW pracovišti uživatele a oprava chyb –Testování – beta-testy a přejímací testy na pracovišti uživatele •Milník – PRODUKT JE UVOLNĚN A PŘIJAT DO UŽÍVÁNÍ NA PRAC. UŽIVATELE –poslední milník - beta-testy, přejímací testy a oprava chyb jsou dokončeny Zavedení (transition) – podmínky splnění 23 10.12.2021 Úvod do objektového modelování 23 Diagram pracovního procesu projektu vývoje SW 24 Metodiky vývoje, údržby a provozu IS/ICT 25 •metodik je velké množství a nejsou jednotně popsány •obtížně je lze srovnávat a vyhledat vhodnou metodiku •mnohé metodiky se zaměřují jen na určité aspekty vývoje, jen na určité fáze živ.cyklu •většinou jsou zaměřeny jen na vývoj nového SW •tradiční rigorózní metodiky pro současné projekty nevyhovují •většina metodik je v angličtině – Problémy Velké množství metodik 26 • • • •Objektivní důvody ⁃různé technologie vyžadují různé techniky ⁃organizace se liší firemní kulturou ⁃každý jedinec je jedinečný ⁃každý tým je jedinečný ⁃projekty se liší velikostí ⁃projekty se liší důležitostí ⁃snaha prezentovat se ⁃komerční důvody Kritérium přístupu k vývoji a kritérium způsobu vývoje 27 Kritérium přístupu k vývoji •Strukturované metodiky ⁃RAD metodiky ⁃RAD nástroje, prototypování •Objektově orientované metodiky Kritérium způsobu vývoje •Tradiční metodiky s vodopádovým životním cyklem •metodiky pro iterativní a přírůstkový vývoj Charakteristika rigorózních technik 28 •těžké metodiky ⁃podrobné, hodně formalit, direktivní řízení •předpokládají ⁃opakovatelnost procesů ⁃možnost definovat všechny požadavky na řešení předem •příklady •OPEN, RUP, EUP, OOSP •metodiky pro hodnocení SW procesů ⁃(Software Process Assesment ) ⁃Capability Maturity Model (CMM ) Charakteristika agilních metodik 29 Společné principy •iterativní vývoj s velmi krátkými iteracemi, •zaměření na fungující SW, který má hodnotu pro zákazníka, •lidé jsou prvořadým faktorem – důraz na spolupráci a komunikaci, •tolerantní ke změnám, •automatizované testování. Agilní metodiky 30 Hodnota pro zákazníka jestliže SW musí dodávat hodnotu pro zákazníka, kdo může nejlépe určit, jaká hodnota to je? vývojáři ne, ale zákazníci ano, přesun zodpovědnosti na zákazníka zákazník určuje a mění priority funkcí zákazník nevidí do budoucna, proto my, vývojáři musíme do systému zabudovat funkce a data , které by mohl zákazník v budoucnu potřebovat X je lepší vytvořit systém tolerantní ke změnám, který umí akceptovat změny v budoucnu Agilní metodiky 31 Osobní komunikace Spolupráce zákazníků a vývojářů 32 Rigorózní metodiky •postaveny na nedůvěře. •Nevěřím ti, že uděláš práci správně, tak tě musím neustále sledovat a kontrolovat. Agilní metodiky •vůdcovství a spolupráce - jsou formovány na důvěře a respektu. •Věřím ti, že uděláš práci dobře, a tak budeme spolupracovat, abychom dosáhli výsledku. Spolupráce zákazníků a vývojářů II 33 Rigorózní metodiky •standardizují lidi v organizaci •snaží se vykázat lidi do role zaměnitelné součástky •čím větší projekty se realizují, tím více specialistů je třeba zapojit Agilní metodiky •využívají individualit a silných stránek lidí •požadují integraci znalostí, stálá interakce a kooperace, sdílení znalostí v týmu, týmové řešení problému. Spolupráce zákazníků a vývojářů II 34 Rigorózní metodiky •standardizují lidi v organizaci •snaží se vykázat lidi do role zaměnitelné součástky •čím větší projekty se realizují, tím více specialistů je třeba zapojit Agilní metodiky •využívají individualit a silných stránek lidí •požadují integraci znalostí, stálá interakce a kooperace, sdílení znalostí v týmu, týmové řešení problému. Které metodiky řadíme mezi agilní? 35 • • • • • •Adaptive Software Development (ASD), •Dynamic Systems Development Method (DSDM), •Feature-Driven Development (FDD), •Extreme Programming (XP), •Lean Development, •SCRUM, •Crystal metodiky, •Agile Modeling manifest je výsledkem schůzky ve SnowBird v Utahu, které se účastnilo 17 osobností z oblasti vývoje SW zpravidla autorů a zastánců tzv. Light metodik. Slovo light nemá jednoznačný význam, proto se začalo používat slovo agilní I když jde o významné osobnosti, přesto se v manifestu objevuje slovo uncovering, které naznačuje, že ne všechny odpovědi jsou zodpovězeny. Manifest obsahuje 4 deklarace hodnot, prvky na levé straně mají větší význam než prvky na pravé straně, to neznamená, že prvky na pravé straně by neměly existovat, ale je třeba si položit následující otázky - relativní význam · mohu mít úspěšný projekt. když dodám dokumentaci bez fungujícího systému? · mohu mít úspěšný projekt. když dodám fungující systém bez dokumentace? Když se podíváme na tyto dva koncové body, můžeme lépe uchopit relativní význam (důležitost). Ačkoli zde musí být rovnováha dokumentace - fungující Sw, smlouvy a spolupráce, odpovědnost a plánování, lidé a procesy, musíme vyznačit extrémy a koncové body, aby organizace, týmy i jednotlivci mohly nalézt svůj vlastní rovnovážný bod (těžko bude uprostřed) Manifest deklaruje 12 principů, které by měly být uplatňovány při vývoji SW Porovnání rigorózních a agilních metodik 36 BS00975_ BS00554_ rigorózní metodiky agilní metodiky • SW procesy lze popsat • požadavky je možné definovat předem • SW procesy nelze popsat • předem jen hrubé požadavky výzkumné projekty time-to-market menší týmy standardní projekty, velké projekty přesně definované procesy, činnosti, artefakty jen generativní pravidla, praktiky a principy SCRUM 37 •vývoj SW není definovaný proces, který je možné přesně popsat a opakovat, ale empirický proces •empirický proces vyžaduje odlišný styl řízení - vyžaduje konstantní monitorování a adaptaci ScrumObr2 SCRUM meetings 38 • • • • • •umožňují monitorovat stav, •konají se ve stejný čas na stejném místě •trvají méně než 30 minut (cílem je 15 minut) •vede je Scrum master •účastní se jich všichni členové týmu (vývojáři, uživatelé , testeři,..) •navštěvují je manažeři, aby věděli o stavu, ale aktivně se neúčastní •slouží ke zjištění problémů, ale ne k jejich řešení •každý účastník musí zodpovědět 3 otázky –co udělal od poslední scrum porady –co bude dělat do příští scrum porady –jaké překážky mu stojí v cestě manifest je výsledkem schůzky ve SnowBird v Utahu, které se účastnilo 17 osobností z oblasti vývoje SW zpravidla autorů a zastánců tzv. Light metodik. Slovo light nemá jednoznačný význam, proto se začalo používat slovo agilní I když jde o významné osobnosti, přesto se v manifestu objevuje slovo uncovering, které naznačuje, že ne všechny odpovědi jsou zodpovězeny. Manifest obsahuje 4 deklarace hodnot, prvky na levé straně mají větší význam než prvky na pravé straně, to neznamená, že prvky na pravé straně by neměly existovat, ale je třeba si položit následující otázky - relativní význam · mohu mít úspěšný projekt. když dodám dokumentaci bez fungujícího systému? · mohu mít úspěšný projekt. když dodám fungující systém bez dokumentace? Když se podíváme na tyto dva koncové body, můžeme lépe uchopit relativní význam (důležitost). Ačkoli zde musí být rovnováha dokumentace - fungující Sw, smlouvy a spolupráce, odpovědnost a plánování, lidé a procesy, musíme vyznačit extrémy a koncové body, aby organizace, týmy i jednotlivci mohly nalézt svůj vlastní rovnovážný bod (těžko bude uprostřed) Manifest deklaruje 12 principů, které by měly být uplatňovány při vývoji SW Modelování 39 • • • • • • •modelování základní částí vývoje SW ať v lehkých nebo těžkých metodikách •dva primární důvody, proč modelovat: •abyste pochopili podstatu toho, co vytváříte, •abyste mohli komunikovat v týmu •je bohužel obětí mýtů a nepochopení manifest je výsledkem schůzky ve SnowBird v Utahu, které se účastnilo 17 osobností z oblasti vývoje SW zpravidla autorů a zastánců tzv. Light metodik. Slovo light nemá jednoznačný význam, proto se začalo používat slovo agilní I když jde o významné osobnosti, přesto se v manifestu objevuje slovo uncovering, které naznačuje, že ne všechny odpovědi jsou zodpovězeny. Manifest obsahuje 4 deklarace hodnot, prvky na levé straně mají větší význam než prvky na pravé straně, to neznamená, že prvky na pravé straně by neměly existovat, ale je třeba si položit následující otázky - relativní význam · mohu mít úspěšný projekt. když dodám dokumentaci bez fungujícího systému? · mohu mít úspěšný projekt. když dodám fungující systém bez dokumentace? Když se podíváme na tyto dva koncové body, můžeme lépe uchopit relativní význam (důležitost). Ačkoli zde musí být rovnováha dokumentace - fungující Sw, smlouvy a spolupráce, odpovědnost a plánování, lidé a procesy, musíme vyznačit extrémy a koncové body, aby organizace, týmy i jednotlivci mohly nalézt svůj vlastní rovnovážný bod (těžko bude uprostřed) Manifest deklaruje 12 principů, které by měly být uplatňovány při vývoji SW Nesprávné tvrzení o modelování Modelování je vždy svázáno s dokumentací 40 •model je abstrakce, která popisuje jeden nebo více aspektů problému a možné řešení problému •tradičně jsou modely chápány jako diagramy a odpovídající dokumentace •Realita •nevizuální artefakty jako CRC karty, textový popis byznys pravidel jsou považovány také za modely •při modelování nejde o model jako takový, ale o proces modelování •většina modelů není součástí oficiální dokumentace systému, ale některé modely je dobré uchovat - persistentní modely Nesprávné tvrzení o modelování ) Je možné vše namodelovat předem a správně 41 •snaha namodelovat vše předem a správně a zmrazit požadavky před začátkem kódování • Realita •nemá smysl modelovat ve všech podrobnostech •programátoři příliš neuznávají modely •základem vývoje SW je iterativní přístup - trochu modelování, trochu kódování, trochu testování a hlavně nasazení fungující verze SW a zpětná vazba od zákazníka Nesprávné tvrzení o modelování Při modelování je nutné používat CASE nástroj 42 •Ten nejlépe zachytí všechny aspekty modelu a zajistí konzistenci mezi modely •Realita •daleko efektivnější je vytvářet jednoduché modely, které zachycují jen podstatné informace •a používat jednoduché nástroje Nesprávné tvrzení o modelování Při vývoji softwaru je třeba zmrazit požadavky 43 •Při zmrazení požadavků na začátku životního cyklu nejspíš dodáte to, co bylo požadováno, ale pravděpodobně ne to, co je třeba. •Realita •dochází ke změnám, mění se požadavky •protože se mění byznys priority •protože zákazník po dodání části systému jej lépe pochopí •lepší než zmrazit požadavky a riskovat neúspěch je uchopit změnu a odpovědět na ni • Nesprávné tvrzení o modelování Návrh je vytesán do kamene 44 •Realita •nikdo, ani nejlepší návrhář není dokonalý a stejně tak jeho dílo, nemá smysl fixovat chyby •pokud nechceme zmrazit požadavky, není možné zmrazit návrh •návrh je hotov, až po dodání kódu Nesprávné tvrzení o modelování Modelování je ztráta času 45 •častý názor nových vývojářů, kteří se orientují jen na kódování •Realita •často se produktivita vývojáře zvýší náčrtkem diagramu, vytvořením prototypu UI atd. •produktivní vývojáři modelují před psaním kódu Mýty o modelování Základem je datové modelování 46 •datová komunita má politickou sílu •Realita •datové modelování je důležitý, ale sekundární úkol modelování Nesprávné tvrzení o modelování Všichni vývojáři umí modelovat 47 • •Realita •Umění modelovat vyžaduje velké zkušenosti Nesprávné tvrzení o modelování Modelování je spojeno s rigorózními metodikami 48 •Realita •je možné modelovat agilním způsobem – používat jednoduché modely a jednoduché nástroje • Děkuji za pozornost Otázky? 49