NÁVRH INFORMAČNÍCH SYSTÉMŮ (NIS) PŘÍPRAVA NA SZZ

Transkript

1 NÁVRH INFORMAČNÍCH SYSTÉMŮ (NIS) PŘÍPRAVA NA SZZ 1. Základní modely životního cyklu software, softwarový proces Základní modely životního cyklu software Životní cyklus = proces od zahájení vývoje až po vyřazení z provozu. Je to souhrn všech etap projektu, jako je úvodní koncepce, vývoj, implementace a ukončení. Výrazem životní cyklus vývoje systémů označujeme obecný rámec pro popis jednotlivých etap vývoje informačních systémů. Modely prediktivního životního cyklu Prediktivní životní cyklus je postup při vývoji software, který se používá v případě, že je možné jasně formulovat rozsah projektu a současně je možné přesně předvídat časový plán i náklady a projekt. Mezi rozšířené modely životního cyklu patří model vodopádu, spirálový model, inkrementální (přírůstkový model), prototypový model (prototypování) a model rychlého vývoje aplikací (Rapid Application Development RAD). Vodopádový model Je příkladem sekvenčního postupu vývoje, kde hlavní technické aktivity jdou lineárně po sobě. Tento životní cyklus předpokládá, že jednou definované požadavky na systém již zůstanou stabilní (neměnné). Výhodou obecně sekvenčního postupu je přehlednost a kontrolovatelnost pro malé projekty a jeho snadné pochopení. Nevýhodou pak je, že vyžaduje na začátku mít přesně definované požadavky, které však uživatel často nedokáže předem stanovit všechny, dále provozuschopnost vidí zákazník až v závěrečných fázích řešení a případné nedostatky mohou být odhaleny velmi pozdě. U tohoto modelu se také velice složitě reaguje na změny požadavků během vývoje. Jednou z nejznámějších variant vodopádového modelu je V-model, ve kterém je kladen důraz na testování SW a každá aktivita musí být verifikována. 1

2 Spirálový model Je příkladem cyklického postupu, který opakuje technické aktivity s obsahem podle sekvenční fáze a zabíhá u nich více do detailů. Produkt postupně roste znalost, funkcionalita, kvalita. Tento postup rozbije velký projekt do řady malých, na které vlastně aplikuje sekvenční postup, který pro malé projekty funguje. Spirálový model byl vyvinut na základě zkušeností s různými vylepšeními vodopádu, konkrétně na základě řešení velkých státních zakázek. Model uznává skutečnost, že se většina softwaru vyvíjí ve spirálovitých iteracích. 2

3 Výhody uvažuje rizika projektu, první verze možné sledovat již při jejich postupném vzniku, umožňuje konzultovat požadavky zákazníků v jednotlivých krocích a podle nich modifikovat systém. Nevýhody neumožňuje přesné naplánování termínů, je nutné provést bezchybnou analýzu rizik, neboť na této analýze jsou založeny další fáze projektu, není vhodný pro systémy vyvíjené na zakázku bez účasti budoucích uživatelů produktu u vývoje (řešení totiž vyžaduje neustálou spolupráci zákazníků). Inkrementální model Nabízí progresivní možnosti rychlého vývoje provozního softwaru, přičemž s každým vydání softwaru se rozšiřují jeho funkce. Plán životního cyklus tohoto modelu je rámcový, kde rámec může tvořit několik milníků. V milníku probíhá řetězec několika iterací, které představují miniaturní úplný projekt (cca vodopádový model) a jejich cílem je iterační release (interní) = produkt funkčně neúplný, ale otestovaný a funkční. Výhody- včasná reakce na problémy při vývoji. Typickým příkladem tohoto modelu je RUP (Rational unified process). RUP má čtyři základní fáze, kde v každé z těchto fází může proběhnout několik iterací. Fáze jsou (zahájení, rozpracování, tvorba, předání). Prototypový model U tohoto modelu se namísto výsledného softwaru nejprve vytvářejí prototypy (makety), na kterých se upřesní uživatelské požadavky kladené na cílový provozní software. Tento model vyžaduje výrazné zapojení uživatelů a vývojáři v něm na základě prototypu současně vygenerují funkční požadavky a specifikace fyzického návrhu. Hotové prototypy pak mohou vývojáři zahodit, nebo je ponechat pro další implementaci podle podmínek konkrétního projektu. Model rychlého vývoje aplikací (RAD) Používá zvláštní přístup, při kterém vývojáři pracují s neustále se vyvíjejícím prototypem. Také do tohoto modelu musí být výrazně zapojeni uživatelé a výsledný systém je možné vyvinout dost rychle a to bez ohrožení kvality. Vývojáři používají vhodné nástroje pro rychlý vývoj aplikací jako je např. CASE, které usnadňují rychlé prototypování a generování kódu. Modely adaptivního (evolučního) vývoje softwaru Adaptivní vývoj softwaru je metoda vývoje softwaru, která se používá v případě, kdy na začátku životního cyklu nelze přesně stanovit cílové požadavky. Požadavky se sestavují iterativní metodou, vývoj je řízen riziky a je tolerantní ke změnám. Dnes se požívají dva oblíbené životní cykly z agilního vývoje softwaru, a sice extrémní programování a scrum. 3

4 Extrémní programování (XP) Přístup k programování a vývoji softwaru v rychle se měnícím prostředí. Scrum Iterativní proces vývoje softwaru, jehož jednotlivým iteracím se říká běhy, neboli sprinty, ty zpravidla trvají 30 dní. Softwarový proces Proces = systematická série akcí vedoucích k určitému výsledku. Softwarový proces je proces, jehož výsledkem by měl být kvalitní software. Přesněji řečeno, softwarový proces je množina aktivit a (mezi)výsledků, kde všechny aktivity a mezivýsledky musí mít smysl a jejichž výsledkem je softwarový produkt. Proces je jedinečný pro každou firmu. SW proces se člení na fáze, aktivity, produkty. Typickými aktivitami software procesu jsou: Technické aktivity komunikace, plánování, modelování, konstrukce, nasazení Podpůrné řízení, kontrola kvality, správa konfigurace, dokumentace Role lidí v procesu: Technické analytik (konzultant), architekt, návrhář, vývojář, buildovač a správce konfigurace, tester, databázista, poradce, kouč. Manažerské project manager (team leader), technický vedoucí projektu, šéf vývojářů, šéf projektů. Podpůrné lektor, uživatelská podpora, dokumentace. Artefakty a jejich role v procesu: Technické specifikace, dokumentace, kód, data, testy, modely Komunikační specifikace, plán Obchodní plán, rozpočet, produkt Účel popis-dokumentace, kontrakt Varianty procesu, jejichž společnou snahou je snížení rizika chaotického postupu: Řízené plánem (jistotou) typicky sekvenční vodopád, V-model. Řízené riziky průzkumník/prototypování, spirála. Řízené změnou iterativní, agilní 2. Iterativní přístup k vývoji software, vlastnosti iterace, způsoby dodávky produktu Člověku se lépe řeší menší problémy, než větší. V iterativním přístupu je tedy snaha o rozložení velkého softwarového projektu na řadu menších miniprojektů (iterací). Výsledkem by pak měla být jejich snazší správa a úspěšné dokončení. Iterace dodávají systému funkce dávkově. Iterativní aspekt znamená rozklad projektu na menší podprojekty (iterace), které dodávají systému funkce dávkově, nebo na přírůstky (inkrementy), které vedou k tvorbě plně funkčního systému. Iterativní vývoj vede na přírůstkový vývoj (inkrementální). Jinými slovy, iterativní přístup znamená, že tvoříme software v procesu postupných zpřesňování našeho konečného záměru. Ke klíčovým pracovním postupům tvorby software (analýza, návrh, tvorba ) se vracíme průběžně v projektu několikrát. Vlastnosti iterace Iterace představuje podprojekt v iteračním vývoji. Iterace obsahuje všechny prvky normálního softwarového projektu: Plánování, analýzu a návrh, tvorbu, integraci a testování, interní, nebo externí uvedení. 4

5 Každá iterace generuje vlastní základní linii (baseline), 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 tak dlouho, dokud není dosažená konečná podoba vytvářeného systému. Rozdíl mezi dvěma základními liniemi je označován jako přírůstek (inkrement). Iterace je miniaturní úplný projekt cca vodopádový model. Průběh iterace by měl zahrnovat následující pracovní postupy, které určují, co je třeba udělat a způsob, jakým toho dosáhnout: 1. Plánování cíle iterace (funkčnost) 2. Doplnění / zpřesnění požadavků 3. Dotváření návrhu 4. Implementace přírůstku funkčností 5. Integrace přírůstku ověření, otestování 6. Předání do provozu (release interní / externí) Iterace by měla mít pevné datum ukončení a již běžící iterace by měla být uzavřená změnám zvenčí (nutné pro stabilitu projektu). Počet iterací je odvozen od charakteru projektu (rozsah, velikost týmu) a může navíc spadat do různých fází vývoje (viz RUP). Obvykle jsou alespoň tři iterace (Milníky Life cycle objectives, Life cycle architecture, initial Operational Capability, + Product release). Délka iterace malá je lepší, blízký cíl, menší složitost/riziko, vysoká produktivita. (1-4 týdny pro malé, 3-6 týdnů pro velké projekty). Vždy by mělo být dáno pevné datum ukončení. (Timeboxované iterace = délka známa předem scrum 30 dní, XP 1-2 týdny). Iterace mohou být seskupovány do fází u RUP jsou to fáze zahájení (období plánování), rozpracování (období architektury), konstrukce (počátky provozuschopnosti), zavedení (nasazení produktu do uživatelského prostředí). Způsoby dodávky produktu U iterativního přístupu je celková funkcionalita dodávána po částech. Zákazník tak má možnost průběžně sledovat vývoj, může se k němu vyjádřit a oponovat změny. Tím má na konci jistotu, že nedostane něco, co neočekával. Předmětem dodávek jsou jednotlivé iterace, u kterých je pak možnost i jejich průběžného testování. Dodávky na základě fáze obsahují různé artefakty jako např. vize, různé diagramy apod. 3. Metodiky vývoje software účel, obsah metodiky Metodika = definovaný proces pro konkrétní účel, tj. fáze, aktivity, role, artefakty, milníky atd. Jsou dobře popsány: Př. jsou - SSADM, RUP, SCRUM 5

6 Metodika označuje obecný rámec pro popis jednotlivých etap vývoje informačních systémů (produktů). Existuje řada metodik, žádná však nebyla přijata jako referenční. (Prarodičem je vodopádový model). Účelem vhodně zvolené metodiky je zvýšení efektivity softwarového vývoje. Hlavním účelem je určit správné pořadí kroků při vývoji SW a určit kritéria pro přechod k dalšímu kroku. Rizika metodik jsou: Použití nesprávných, příliš náročných modelů, všichni členové týmu musí metodice rozumět a akceptovat ji. Je dobré mít alespoň nějakou metodologii, než žádnou, ale na druhou stranu tato metodologie nenahradí vývojáře, ani technologii. Obsah metodiky Metodiky obsahují postupy, jak spravovat jednotlivé fáze životního cyklu. Specificky obsahují postupy jak: Sbírat požadavky od zákazníka, Jak komunikovat se zákazníkem, Jak navrhovat systém Jak testovat systém, Jak vydávat systém, Jak dokumentovat systém, Jak nasazovat, Jak spravovat, Jak vytvářet týmy a řídit lidské zdroje, Jak se přizpůsobit změnám apod. 4. Příklady strukturální, objektové, iterativní, agilní metodiky (SSADM, RUP, Scrum, ). Strukturální Strukturované metodiky pro analýzu a návrh systému historicky předcházely objektovým metodikám. Na funkce a data se zaměřují víceméně odděleně. Odpovídá strukturovanému programování. Funkce jsou aktivní a nají chování. Data jsou pasivní, ovlivněna funkcemi. Funkce postupně rozdělujeme shora dolu na části, nejčastěji pomocí diagramů datových toků (data-flowdiagrams). Tzn. chápe systém jako celek a postupně ho dekomponuje na jednodušší části. Příklady strukturálních metodik: SADT, SREM/RDD, SA/SD, SSADM, Yourdon, De Marco SSADM (Structured Systems analysis and design method) V ČR asi nejpoužívanější strukturální metodika. Jde o variaci modelu vodopád. V některých dalších zemích je podmínkou pro získání státních zakázek. Jedná se o standard s podrobně definovanými kroky včetně výstupů a předepsaných kontrol před přechodem k dalšímu kroku. Má jednoznačně definované kroky a dílčí cíle. Metodologie má podobný záběr a nástroje jako DeMarcova a Yourdonova strukturovaná analýza. Výstupy této metody jsou DFD (data-flow-diagram, model entit,...) Vychází z datového modelu. Základní datový model se snaží zformulovat už v počátečních etapách. Odděluje logický a fyzický návrh systému. Již v průběhu analýzy by měly být podchyceny nestandardní situace a chybové stavy systému. 6

7 Životní cyklus SSADM ŽC podporuje následující procesy ve vztahu k životnímu cyklu vývoje: Zahájení projektu (etapa 1) Studie proveditelnosti (SSADM feasibility study) Systémová analýza (etapy 1 a 2) Návrh podnikového systému (etapy 3,4,5) Fyzický návrh (etapa 6) Obr rozsah SSADM 3 základní pohledy SSADM Logické datové struktury ukazují, která informace je ukládána a jaké jsou vzájemné vztahy mezi jednotlivými informacemi. Diagramy datových toků ukazují, jak se předává informace v systému. Životní cykly entit ukazují, jak se informace mění během svého života. Objektové Postup zdola nahoru, jehož základní myšlenkou je zobecňování. Začíná se z konkrétní části systému, který se zanalyzuje a popíše. V dalších částech se pak hledají společné rysy, z nichž se odvozují obecné zákonitosti. Příklady objektových metodik: RUP, Select Perspective, Fusion, Booch. RUP Jedná se o rozsáhlou, objektově orientovanou iterativní metodologii vývoje softwaru. Metodika RUP je komerční verzí metodiky unified process dodávanou společností IBM. Obsahuje veškeré standardy, nástroje a další nezbytnosti, jež jsou součástí UP. Navíc je dodávána s bohatým uživatelským prostředím doplněným o úplnou dokumentaci a rádce k jednotlivým nástrojům. 7

8 Metodika modeluje aspekty kdo (role), kdy (pracovní postupy - workflows), co a jak (aktivity, artefakty) procesu tvorby softwarového vybavení. Metodika RUP je založena na iterativním a přírůstkovém procesu a obsahuje tři základní zásady (principy). Jsou to: Zásada řízení případem užití a rizikem Zásada soustředění na architekturu Zásada iterace a přírůstku Základní pracovní postupy v RUP jsou: Požadavky, analýza, návrh, implementace, testování. Životní cyklus metodiky je rozdělen na čtyři fáze a každá z nich končí definovanými hlavními milníky. Každá fáze může obsahovat jednu, nebo více iterací a můžeme v ní realizovat pět základních pracovních postupů a libovolný počet dalších dodatečných postupů. Fáze jsou: Zahájení období plánování,milníkem je Life cycle objectives - výsledek je vize koncového SW produktu, rámec vývoje produktu, počáteční případ užití, hlavní požadavky na projekt, počáteční plán projektu. Rozpracování období architektury, Milníkem je Life cycle architecture výsledkem spustitelný architektonický základ, statický model UML, detailnější zachycení případů užití a požadavků a přesného plánu. Konstrukce počátky provozuschopnosti, Milníkem je Initial operational capability výsledkem je kompletní implementovaný a otestovaný produkt, kompletní model UML, uživatelské příručny, popis verze. Zavedení nasazení produktu do uživatelského prostředí, milníkem product release výsledkem je předaný SW produkt, který zahrnuje aplikované beta-testy, přejímací testy a opravené chyby. Přesný počet iterací v jednotlivých fázích závisí na velikosti projektu. Každá iterace by však neměla trvat déle než 2-3 měsíce. Iterativní Iterativní metodika je RUP, Scrum, XP. Agilní 8

9 Metodiky odpovídající inkrementálnímu modelu. V agilním přístupu je vše iterativní, evoluční (dotažení iterativního přístupu, kde se znalosti o návrhu, požadavcích, odhadech a plánu vyvíjejí v průběhu projektu) a adaptivní (zdůraznění zpětné vazby v evolučním vývoji zpětná vazba od uživatelů). V této metodice se používá timeboxovaného iterativního a evolučního vývoje, adaptivního plánování, evolučních dodávek a dalších hodnot a technik, které podporují čilost rychlou a pružnou odezvu na změny. Hodnoty tohoto přístupu jsou: přivítání změny a schopnost adaptace na změny, komunikace mezi zákazníkem a vývojovým týmem a zpětná vazba od zákazníka, jednoduchost technik komunikačních, programátorských, manažerských. Techniky naplňující hodnoty: jednoduché prostředky, intenzivní komunikace (raději osobní), člověk středem dění (kvalitní a soudržný tým), odvaha (zahodit kód, na kterém jsem dělal týden, když nefunguje), párové programování (jeden programátor kóduje, zabývá se detaily a druhý neustále kontroluje jeho kód a zaměřuje se na celkový obraz, role se pravidelně střídají, páry se mění a díky tomu programátoři získávají dobrý pojem o systému jako celku), test-driven (zadání -> testy -> implementace; testovat vše co by se mohlo pokazit, implementace, která způsobí, že testy nenejadou chybu) a test-first vývoj, refactoring (cesta jak udržet kód zdravý a kvalitní při častých změnách, jedná se o změnu kódu bez změny funkčnosti a cílem je čištění kódu), nepřetržitá integrace. Příklady agilních metodik: Scrum, extrémní programování, Feature-driven development, Microsoft Solutions Framework. Scrum Iterativní proces vývoje softwaru, jehož jednotlivým iteracím se říká běhy, neboli sprinty, ty zpravidla trvají 30 dní. Agilní, iterativní a inkrementální proces, který se skládá ze tří částí, které se opakují po přibližně dnech: Pre-game (Předehra) plánování (vize), jádro požadavků, architektonický prototyp, seznam užitečných vlastností = backlog Vývoj Sprinty, Přírůstková implementace, scrum meetings Post-game (dohra) dodávka Scrum tým je stabilní během sprintu a obsahuje všechny profese. Je do něj začleněn i zákazník a vede ho Scrum master manažer projektu, který dbá na hodnoty a postupy a má také 50% podíl na implementaci. Scrum Sprint Timebox (30 dní) iterace. Zahrnuje plánování (zákazník vybírá, tým odhaduje), kde se vytvoří sprint backlog. Dále samotnou práci, která se reviduje na daily scrum. Žádné změny plánu během sprintu. Na konec se demonstruje přírůstek na Sprint review, kde se sejdou zákazník a tým. 9

10 Scrum backlog Seznam užitečných vlastností features, úkoly, chyby, které identifikuje tým a zákazník jim pak určí priority. Release backlog 1-3 dny práce, Sprint backlog 4-16 hod. Daily scrum Pravidelné setkání týmu každý den, stejný čas, stejné místo, vestoje, doba trvání zhruba 15 min. Řeší se co jste dělali od posledního daily scrum, co budete dělat do dalšího, co stojí v cestě k cíli iterace, jsou nové položky do backlogu? Extrémní programování (XP) Přístup k programování a vývoji softwaru v rychle se měnícím prostředí. Extrémní se mu říká, protože používá osvědčené a známé postupy vývoje software, dotahuje však jejich použití do extrémů. Hodnoty v XP jsou komunikace, jednoduchost, zpětná vazba, odvaha. Protože kontroly nezaujatým čtenářem jsou dobrá věc, budeme kontrolovat kód nepřetržitě, dále budou všichni neustále testovat, dokonce i zákazník, návrh se bude zpřesňovat každý den a návrh bude vždy ten nejjednodušší možný pro zachování aktuální fukčnosti, iterace budou opravdu krátké vteřiny, minuty, hodiny. Podstatné rysy: programování jako hlavní aktivita, dokumentace minimální, jen pokud je opravdu potřebná, důraz na komunikaci. Hodí se pro menší projekty a malé týmy vyvíjející SW podle zadání, které je nejasné, nebo se rychle mění. V XP týmu jsou: vývojář (programátor, tester), zákazník, management (kouč, tracker), konzultant externí. XP proces Průzkum jádro požadavků, odhad Plánování release planning game (hlavní plánovací proces, který se odehrává jednou za iteracia skládá se z plánování vydání a plánování iterace Vývoj- iterace, přírůstková implementace Nasazení XP nejdůležitější techniky Vývoj - Refactoring, test-first, párové programování, sdílený kód, nepřetržitá integrace, jednoduchost. Management udržitelné tempo, kompletní tým, kartičky (story cards, task). 10

11 5. Nástroje pro modelování DFD, ERA a UML modely, využití v analýze a návrhu. DFD Data-flow diagram je grafická reprezentace tok dat skrze informační systém. Je jedním z nástrojů pro modelování funkcí informačních systémů a je součástí strukturované analýzy a návrhu systémů. Je součástí i některých OO metodik. Notace Notace čerpá z teorie grafů a sestává se z: Procesů znázorněn kolečkem (bublinou) a provádí transformaci dat (část systému, která mění vstupy na výstupy). Popisují, co funkce dělá a co je výsledkem funkce. Měli by se číslovat (třeba i víceúrovňově). Toků znázorněn šipkou a reprezentuje data v pohybu (která se pohybují mezi procesy). Ukazuje směr toku dat a datový prvek by měl být pojmenován. Skladů (Data store) znázorněn dvěma vodorovnými čárami a představuje úložiště dat pro použití jedním, nebo více procesy, pracujícími v různých časových obdobích. Data jsou uložena pro pozdější použití. Terminátorů znázorněn obdélníkem s názvem uvnitř a představuje producenta, nebo konzumenta dat (začíná, nebo končí v něm tok dat. Je to externí entita (je mimo hranice systému) a může se jednat o osobu, jiný systém, hardware apod. DFD je tvořen systémovým analytikem na základě interview s uživateli systému. Je určen vývojářům systému na jedné straně a na druhé zadavateli projektu proto by měli být názvy entit přizpůsobeny jak odborníkům na danou tématiku, tak laikům. DFD se používá pro reprezentaci systému libovolné úrovně abstrakce. Např. úroveň 0 - model kontextu systému, kde je celý systém zakreslen jako jedna bublina, má jeden nebo více vstupů a výstupů. Další úrovně zobrazují systém na větší úrovni podrobnosti. Využívá se pro funkční analýzu. 11

12 ERA ERA diagramy popisují strukturu uchovávaných dat na vysoké úrovni abstrakce. Slouží jako vstup pro návrh databáze. Slouží k reprezentaci dat obsažených v systému a vztahů mezi nimi. Používá se především pro modelování strukturovaných dat v relačních databázích. Používají se zkratky ERA model ER model, E-R model, kde E=entita (množina dat), R=relace (vztah mezi entitami), A=atribut (jednotlivé položky popisující množinu dat). ERA diagramy se používají v první fázi návrhu IS při analýze požadavků k popisu informační potřeby, nebo typu informace uložené v DB. ERA diagram vychází z n-té úrovně DFD diagramů. Postup vytváření ERA diagramů je zdola nahoru a cílem je vytvořit datový model postihující část světa. Primitiva ERA diagramu jsou: Entita znázorněna jako obdélník (podstatné jméno uvnitř) a je to reálná, nebo imaginární část světa. Každá entita musí mít tolik atributů, aby byla za všech okolností jednoznačně identifikovatelná. Jde o tzv. primární klíč. Atributy entit znázorňují se elipsou propojenou s entitou Vztahy mezi entitami znázorňují se jako kosočtverce (sloveso uvnitř) mezi entitami a vyjadřuje souvislost (závislost) mezi entitami. Např. má, náleží atd Atributy vztahů vztahy mohou obsahovat atributy, znázornění stejné jako u entitních atributů. Parcialita vztahů povinné, nepovinné, oboustranně povinné členství. Kardinalita vztahu 1:1, 1:N, M:N 12

13 Pro ERA diagramy existují různé alternativy znázornění. Např. Crows foot, která má výhodu srozumitelnosti definování kardinality a dědičnosti ze strany vztahu: V ERA diagramech je možné dědění, kdy potomci mají stejné atributy jako rodiče + navíc své vlastní Obr subtype / supertype UML UML (Unified Modeling language, unifikovaný modelovací jazyk) je univerzální jazyk pro vizuální modelování systémů. Je spojován s modelováním OO softwarových systémů, má však ještě mnohem širší využití. Je to modelovací jazyk, který zahrnuje grafickou notaci pro vytváření abstraktního modelu systému označovanému jako UML model. Jedná se o otevřený standard. Stavební bloky jazyka UML Předměty samotné prvky modelu Vztahy jsou pojítkem mezi předměty (relace určují, jak spolu dva nebo více předmětů významově souvisí) Závislost (dependency) změna v určitém předmětu ovlivňuje význam závislého předmětu, znáz čárkovaná šipka Asociace popis množiny spojení mezi objekty, znáz. čára Agregace typ asociace, cílový prvek je součástí zdrojového prvku, znázorňuje čára s prázdným kosočtvercem na konci. Objekt je vytvořen z dalších objektů les je agregátem stromů. Kompozice typ asociace, silnější forma agregace (má více omezení), znázorňuje čára s plným kosočtvercem na konci. Součást nemůže existovat samostatně - strom a jeho listy Zobecnění (generalizace) jeden prvek je specializací jiného prvku a lze jej nahradit obecnějším prvkem, znáz. Šipka s trojúhelníkem na konci Realizace asociace mezi klasifikátory, jeden klasifikátor určuje dohodu, jejíž uskutečnění zaručuje druhý klasifikátor., znz. Čárkovaná šipka s trojúhelníkem na konci. Diagramy pohledy na modely UML, které ukazují kolekce předmětů, které vypráví příběh o softwarovém systému a jsou naším způsobem vizualizace toho, co systém bude dělat a toho, jak to bude dělat. Diagramy 13

14 Pro popis uživatelských požadavků se používá diagram případů užití. Pro detailní analýzu požadavků a shrnutí komunikace aktér-systém se používají sekvenční diagramy. Pro popis scénáře případů užití při složitém rozhodování diagram aktivit. Pro popis doménového modelu, který popisuje strukturu problémové oblasti využijeme doménový diagram tříd. Pro hlubší objektovou analýzu rozvineme doménový model a uděláme rozbor případů užití. Přiřadíme zodpovědnosti z popisu PU a na základě toho vytvoříme digram sekvencí, nebo diagram spolupráce. Pro větší detail získáme z diagramu sekvencí zodpovědné třídy a můžeme vytvořit diagram tříd. Předmětem návrhu bude diagram komponent, stavové diagramy. Diagram tříd Ukazuje statickou strukturu tříd v systému, tj. třídy, jejich vztahy (dědičnost, asociace, závislost), atributy a operace. Využívá se při realizaci případů užití v návrhu diagram tříd obsahující zúčastněné návrhové třídy, které jsou upřesněním analytických diagramů tříd. Diagram tříd využijeme ve fázi analýzy (konceptuální model), ve fázi návrhu (návrh atributů a operací), ve fázi implementace (návrh a tvorba programového kódu). V diagramu lze znázornit dostupnost objektů ( - private, # protected, * package, + public). Třídy v diagramu mohou být děděny a zobecňovány: Další vazba v diagramu je asociace: Dále agregace atd. Diagram případů užití Zobrazuje dynamickou funkční strukturu systému z pohledu uživatele. Je určená k definici chování systému, aniž by odhalil jeho vnitřní strukturu. Popisuje co systém dělá, ne jak to dělá. Use-case diagram využijeme při specifikaci požadavků na systém (podklad pro analýzu a návrh), při komunikaci se zákazníkem, podklad pro řízení projektu, jako tvorbu testovacích případů pro fázi testování systému a pro návrh uživatelského rozhraní. Při modelování případů užití musíme nejprve nalézt hranice systému, pak vyhledat aktéry a nalézt pro ně případy užití a jejich alternativní scénáře. Tento postup opakujeme pro zpřesnění. Model případů užití obsahuje 4 komponenty: Hranice systému ohraničení zobrazené kolem případů užití Aktéři role přidělené osobám používajícím systém Případy užití činnosti, které mohou aktéři se systémem vykonávat Relace vztahy mezi aktéry a případy užití 14

15 Případy užití jsou prvotním vstupem pro modelování tříd. Diagram sekvencí Znázorňují interakce mezi čárami života jako časově uspořádanou posloupnost událostí. Tyto diagramy jsou nejbohatší a nejpružnější formou diagramů interakce. Zdůrazňují časově orientovanou posloupnost zpráv předávaných mezi objekty. Znázorňují aktéry, objekty v systému, se kterými interagují a posloupnost výměny zpráv. Čas plyne shora dolů. Každý objekt má svou lifeline (čáru života svislá čára). Čáry života mohou mít aktivaci, která slouží k signalizaci aktivace příslušné čáry života. Šipky jdou podle typu komunikace: Volání procedury, nebo jiný vnořený tok řízení (vnější sekvence může pokračovat, až po dokončení vnitřní sekvence) Asynchronní komunikace Návrat z procedury Diagram aktivit Reprezentace struktury počítačových a organizačních procesů v systému zaměřená především na jeho vnitřní chování. Zobrazení řídících toků mezi akcemi v systému od počátečního bodu po jeden nebo více koncových bodů. Důraz se klade na zobrazení pořadí aktivit. Diagram lze využít při modelování průběhu jednotlivých Use case a operací v třídách, nebo při modelování podnikových procesů a workflow. Během analýzy modelované scénáře PU a k modelování cest mezi PU Během návrhu k modelování podrobností operace a detailu algoritmu. Diagram se skládá z: začátek, konec, aktivita (činnost), složená aktivita, přechod, rozhodování, spojování, větvení. 15

16 Další diagramy Stavový, komponent, spolupráce, nasazení. 6. Datové modelování Datový model představuje filosofii datové základny informačního systému a zachycujeme v něm reálné objekty, o kterých chceme uchovávat informace. Datové modely mohou být následující: Lineární mezi objekty není žádný vztah a žádná vazba. Každá věta má vztah pouze předchůdce a následovník. Hierarchický mezi objekty je vztah podřízenosti a nadřízenosti rodič, potomek. Síťový mezi objekty je vztah nadřízenosti a podřízenosti a potomek může mít více rodičů. Objektový Relační Datové modelování je proces tvorby datového modelu podle nějakého používaného typu modelu (lineární, hierarchický ). Zahrnuje strukturování a organizování dat, včetně definování omezení na tyto struktury. Tyto datové struktury jsou typicky implementovány v DBMS (Database management system). Datové modelování probíhá tak, že vezmeme doménový model, který vznikl doménovou analýzou, a z něj vytvoříme logický datový model. Existují tři různé pohledy na data, které představují zároveň tři kroky datového modelování. Nejvyšší úroveň je úroveň analytických konceptů, kam patří Konceptuální schéma. Nižší úrovní je úroveň implementačních 16

17 konceptů, kam patří Databázové schéma. Částečně sem patří úložiště jako množina souborů. To patří i do Fyzické úrovně, kam se řadí i úložiště jako množina BOIS bloků. Konceptuální návrh Zachycují pouze vtahy a struktury dat samotných. Zabývá se modelováním reality, není ovlivněna budoucími prostředky řešení. Popisuje sémantiku (význam) domény (oblast zájmu), pro kterou se model vytváří. Skládá se z entitních tříd a vztahů mezi entitami (ER model, class diagram). Je nezávislý na databázi a definuje omezení kladená na data. Logický návrh reprezentuje logickou provázanost a role jednotlivých atributů entit, ale bez závislosti na konkrétní DBMS platformě. Již jsou vytvářeny specifičtější reprezentace modelu (tabulky, sloupečky, objekty, ). Vztahuje se ke konkrétnímu datovému modelu a používá jeho konstrukční dotazovací a manipulační prostředky (relační, objektová, hierarchická, XML,...). (Relační model SQL, Objektový model OQL, XML model Xpath, XQuery). Fyzický návrh představuje fyzické uložení dat pro konkrétní technologii, např. DB schéma pro systém oracle 10g. Programátor je odstíněn od tohoto návrhu typicky vrstvou SŘBD (Systém řízení báze dat). Datové modely popisují především strukturovaná data určená pro uchovávání v DBMS a nikoli nestrukturovaná jako audio, video, dokumenty. Pro datové modelování lze využít různé nástroje a diagramy. Pro konceptuální modelování lze využít ERD (Entity relationship diagram) neboli ERA diagramy (viz ot. Č.5), popř.jejich rozšíření EER (Enchanced ER), který dále zavádí rysy jako dědičnost (návrh podtříd a nadtříd spolu s děděním atributů). Metodologie návrhu relační databáze Analýza požadavků Zjištění datových požadavků v dané oblasti a formální popis informací o objektech a jejich vztazích. Identifikace datových entit a relací. EER model požadavků Identifikují se klíčové atributy, určí se charakter vazby (povinná/volitelná) a kardinalita Transformace EER modelu do relačního schématu Z hotového EER modelu se vytvoří relační model databáze Normalizace relačního schématu Pro každou relaci se odvodí seznam závislostí Relace by měly být ve vyšších normálních formách Je důležité dbát na integritu DB, kde jsou integritní pravidla rozdělena do třech kategorií Entitní integrita každý řádek tabulky musí být jednoznačně identifikovatelný (primární klíč) Doménová integrita omezuje hodnoty atributů entity Relační integrita popisuje a vymezuje vztahy mezi tabulkami. 7. Požadavky na software typy požadavků, formy popisu, obsah a vlastnosti specifikace. Ještě před tím, než se pustíme do objektově orientované analýzy, či návrhu, musíme mít alespoň rámcový přehled o tom, čeho vlastně chceme dosáhnout a jaký je smysl požadavků a jejich specifikace. Požadavek = schopnost, nebo vlastnost, kterou má software mít, aby jej uživatel mohl používat k vyřešení problému, nebo dosažení cíle, který vedl k zadání, nebo aby splnil podmínky stanovené smlouvou, standardem, nebo jinou specifikací. Požadavkem není to, co uživatel nepotřebuje. Požadavky jsou omezeny vnějšími podmínkami. Požadavky by měly vyjadřovat co by měl systém dělat a ne jak by to měl dělat. Typy požadavků Existují dva typy požadavků: 17

18 Funkční požadavky (functional) Tyto požadavky určují, co by měl systém dělat jeho funkce. Př. Požadavky na univerzitní knihovní systém systém by měl poskytovat uživatelům vhodné rozhraní pro čtení dokumentů v úložišti dokumentů. Nefunkční požadavky (non-functional, Mimo funkční) Vyjadřují nefunkční omezení systému a jeho vlastnosti. Týkají se vlastností jako např. spolehlivost, čas odpovědi, obsazené místo na disku, nebo v paměti aj. Často jsou kritičtější, než funkční požadavky, někde může být kladen důraz na spolehlivost. Někdy mohou být dané i vnějšími faktory, tj. legislativními požadavky. Př. omezení veškerá komunikace mezi uživatelem a systémem by měla být vyjádřitelná ve znakové sadě UTF8. Další rozdělení požadavků by mohlo vyplývat z rozdílné úrovně popisu Business požadavky vize a rozsah projektu Uživatelské požadavky uživatelská specifikace požadavků, která popisuje business rules, vysokoúrovňový popis funkčních a nefunkčních požadavků zákazníka. Popis musí být srozumitelný hlavně pro uživatele, kteří nemají technické znalosti problému. Můžeme k tomu využít nástroj Usecases. Systémové požadavky systémová specifikace požadavků popsaná v dokumentu Software requirements specification (SRS) udává podrobnější specifikaci uživatelských požadavků pro vývojáře. Slouží jako výchozí bod pro design systému. Formy popisu Požadavky lze zapsat formou: Textového popisu jako shopping list, na karty, jako strukturovaný text, nebo podle IEEE norem. Správně formulované požadavky by měly být v tomto případě vyjádřeny jednoduchým strukturovaným jazykem s užitím klíčového slova bude., aby je bylo možné snadno zpracovat. V této části je možné vytvořit také dokument vize produktu a rozsah projektu obsahují analýzu co se chce a ve vizi je také proč se to chce.jedná se o popis z pohledu všech zainteresovaných účastníků a zdůvodnění výhodnosti projektu. Obsahuje přehled uživatelů a stakeholders, popis problému, obchodní příležitosti, potencionální konkurenci, přehled očekávaných funkcí, omezení, standardy, závislosti. Grafické notace pomocí případů užití. K popisu požadavků můžeme použít i kontextový model, který zobrazuje vztah systému a okolí. Systém je v tomto případě černou skříňkou a zdůrazněno je znázornění aktérů a stakeholderů a vztah s ostatními systémy. Ukazuje rozsah systému. Pomocí implementace Je možné vytvořit prototyp, nebo uživatelskou příručku. Další formou může být ještě 4 (+1) kategorie požadavků, kde se klasifikuje funkčnost do 4 kategorií: Jaké informace systém obsahuje, udržuje Jaké funkce poskytuje uživatelům Jaké analýzy dat provádí Jaké jsou interakce s jinými systémy + 1 = to co bude až příště mimo rozsah zadání a doplňková funkčnost. Dále Glosář, který obsahuje seznam důležitých pojmů klíčové, nejasné, sporné. Je to stručný, všemi odsouhlasený popis = společný slovník, prevence porozumnění. Fyzický rozsah systému je možné popsat pomocí UML modelu nasazení. Obsah a vlastnosti specifikace Specifikace Softwarových požadavků (Software requirements specification, SRS) obsahuje model požadavků a model případů užití. Tyto modely jsou různými,ale zároveň vzájemně se doplňujícími způsoby, jak zachytit požadavky na systém. Model požadavků obsahuje funkční a nefunkční požadavky. 18

19 Model případů užití obsahuje mnoho balíčků d případy užití. Jejich obsahem jsou případy užití (specifikace funkce systému), aktéři (externí role s přímou interakcí se systémem) a relace. Model užití popisuje požadavky na (Vnější) funkčnost systému jací uživatelé k systému přistupují a co pro ně software dělá a kde je hranice systému. Aktér je uživatel, nebo jiný systém, který analyzovaný systém používá typový uživatel, který se nachází vně systému a spouští případy užití. Aktéři by měly být popsáni rolemi (ne jmény). Je možná vazba generalizace mezi aktéry hierarchie rolí. Případ užití je sekvence akcí, které systém provádí v důsledku nějakého vnějšího podnětu a které vedou k výsledkům viditelným pro některého uživatele. Model užití nemusí být jedinou, úplnou specifikací funkčnosti. Požadavky můžeme specifikovat jako funkcionality dle IEEE standardu DSP (Dokument specifikace požadavků), nebo jako story cards pro agilní metodiky, jako business procesy, jako systémové požadavky pro hw-sw systémy. Detail specifikace se také liší v různých fázích projektu. Ve fázi zahájení bude třeba pouze cíl/vize projektu a modelu užití budou identifikované pouze klíčoví aktéři a jejich cíle a pouze podstatné případy užitím které budou popsány jen stručně. Ve fázi rozpracování již budeme mít kompletní seznam aktérů s popisem těch důležitých. Budeme mít také přesné diagramy užití, 100% PU. Přesně popsané budou důležité PU, stručně pak všechny PU. Přesný popis vlastností Specifikace by měly obsahovat popsané funkční a mimo funkční požadavky, případy užití, cíl projektu a jeho výstupy, zmapovaný počáteční stav a co přibude. Cílové uživatele a stakeholders projektu, potencionální rizika. Co se od systému očekává dohoda mezi zákazníkem a dodavatelem), co má zadaný systém dělat a jak to má vypadat. Vlastnosti specifikace by měly být specifikace by měly být jednoznačné a ověřitelné, reálné, srozumitelné pro zákazníka /analytiky. Měla by z ní vyplynout struktura pro návrháře / programátory / testery. Měla by být strukturována tak, aby bylo snadné v ní provést změny. V praxi je dobré si navrhnout vlastní formát a používat ho pro všechny SRS sníží se tím pravděpodobnost, že se na něco zapomene. 8. Postupy pro sběr požadavků Poznávání požadavků je nekončící proces, protože zákazník a jeho představy se mění a poznání analytiků se zpřesňuje analýzou i implementací. Většina prací při definici a specifikaci požadavků probíhá ve fázích zahájení a rozpracování tj. hned na počátku celého projektu. Sběr požadavků je součástí analýzy, kde se zabýváme tím co se chce a vytváříme tak objektový model reálného/projektovaného světa. Techniky pro sběr požadavků Požadavky vyplývají z kontextu systému, který se snažíme modelovat. Kontextem systému mohou být přímí uživatelé systému, ostatní zainteresované osoby, další systémy, s kterými bude systém v kontaktu, hardwarová zařízení, s nimiž bude systém v interakci, právní a regulační omezení, obchodní cíle. Inženýrství požadavků obecně začíná dokumentem o představě, v němž je hlavních rysech pospáno, co bude nový systém dělat a jakým přínosem bude pro množinu zainteresovaných osob. Smyslem je zachycení podstatných cílů. Analýzy trhu, marketingové průzkumy Pozorování, práce s uživateli monitorování, komentování postupů, kdy zákazníka pozorují analytici, kteří analyzují existující systém. Rozhovory (Pohovory) s uživateli předem připravený rozhovor, který vede moderátor (klade otázky, dává slovo). Neměl by trvat déle než 2 hodiny. Předem si připravit scénář, které okruhy se budou probírat a ten nenásilně dodržovat. 19

20 Dotazníky nenahradí ale osobní pohovory, spíše jsou vhodnými doplňky osobních pohovorů. Musíme předem sestavit seznam dotazů, aniž bychom věděli na co všechno se chceme zeptat. Studium dokumentace, stávajících systémů Studium hlášení problémů (support, bug tracking). Předvedení prototypu tvorba prototypů, podle kterých si zákazník ujasní své požadavky stačí na papír, nebo skutečné programové prototypy. Diskuze nad prototypem jednoduchá testovací data, řízení konečným automatem. Prototyp můžeme poté vyhodit, nebo uchovat a na základě něj vytvořit hraniční třídy pro objektový návrh. Naivní heuristické metody analýza slovního popisu systému podstatná jména = objekty/třídy, slovesa = chování, metody, podst. Jména, příd. Jména = atributy. Zachytíme i předměty a role v dané oblasti. V první fázi se snažíme stručně popsat problém tak, že určíme základní cíl projektu cca 25 slov /jeden odstavec, kde bude zmíněno k čemu má systém sloužit, jaké informace bude udržovat, kdo jej bude používat, co přinese, čemu pomůže. Prostředky pro zachycení požadavků Kontext zachytíme ve vizi a analýzou aktérů Aktér je uživatel, nebo jiný systém, který analyzovaný systém používá. Jedná se o typového uživatele, který se nachází vně systému a spouští případy užití. Aktér by měl být popsán názvem role, seznamem jeho cílů a jak a k čemu používá systém. Mezi aktéry je možné zachytit generalizace hierarchie rolí. Jak najít aktéry systému: Poznají se tak, že odráží způsoby používání aplikace Jsou podstatní pro určení hranice systému Rozlišovat primární x sekundární K rolím, které systém používají, můžeme dospět úvahou o specifických osobách a předmětech a následným zobecňováním (generalizací). Mohou nám pomoci otázky, jako např. Kdo instaluje systém, kdo se stará o jeho údržbu, kdo spouští a vypíná systém atd. Funkčnost zachytíme pomocí případů užití. PU je sekvence akcí, které systém provádí v důsledku nějakého vnějšího podnětu a které vedou k výsledkům viditelným pro některého uživatele. PU je něco, co aktér od systému očekává. Název PU musí být slovesnou vazbou, protože popisuje akci. Jak najít PU? Projít seznam aktérů a zvážit způsob, jímž bude každý z nich systém používat. Hledáme dialogy aktér systém. Začneme definováním názvu PU a později k němu začneme připojovat další podrobnosti. Jedná se vždy o popis problému z pohledu jednoho aktéra, seznam jeho cílů a potřeb. Pomohou nám otázky jako např. Jaké jsou hlavní akce, které aktér provádí, jak vkládá/získává informace, potřebuje vědět o stavu systému? Struktury zachytíme pomocí doménového modelu. Doménové objekty/třídy popisují základní abstrakce používané v oblasti aplikace a věci vyskytující se v problémové doméně. Definují jen základní obrysy a vztahy mezi třídami (asociace, kardinality). Jsou nezávislé na implementaci. Jak najít doménové objekty? Doménovou analýzou konzultace, doménový expert, části systému podstatné z jejich pohledu. Pomůže obrázek, rozhovor s uživatelem, pozorování práce Vlastnosti u případů užití, doménových tříd, samostatně. PU je kompletní uživatelsky užitečná funkce u které zachytíme název, základní kroky postupu, odkazy na zdrojové informace, vstupní podmínky, hlavní a vedlejší aktéry, hlavní a alternativní scénáře, výstupní podmínky, rozšiřující body. Vývoj znalosti požadavků se mění v závislosti na iteraci, fázi, release. 20

21 Požadavky lze vyjádřit přirozeným jazykem, ve formulářích, nebo v pseudokódu (smyčky a vnořené podmínky, které se těžko vyjadřují v přirozeném jazyce). Požadavky budeme také kontrolovat ve všech fázích projektu zda jsou úplné, konzistentní, zda odpovídají tomu, co zadavatel chce. Vstupem je vždy SRS Požadavky budeme také spravovat, protože se stále mění a my musíme tuto změnu identifikovat, sledovat a jednoduše aplikovat, tak aby požadavky zůstali konzistentní. 9. Objektová analýza požadavků, doménový model, případy užití Předmětem objektové analýzy požadavků je analyzovat nasbírané požadavky. Cílem analýzy je uspořádat skupiny dle funkčnosti, vybrat priority, rozebrat a lépe poznat důležité scénáře, souvislosti, důsledky, vazby a na základě toho vytvořit podklady k realizaci. Lidé v analýze jsou zákazník (externí, interní, doménový expert), zainteresovaný hráč (stakeholder ředitel, investor, daňový poplatník), analytik. Říká, co se chce, co bude systém dělat a ne jak to bude dělat. Nezabývá se žádnými implementačními omezeními, ty přijdou na řadu až při návrhu. Analytický model zachycuje pojmy v problémové doméně, účelem je najít/vymyslet třídy a vazby, které se vyskytují při realizaci (nebo mohou realizovat) funkčnosti tzv. logický objektový model (objektový popis světa, funkčnosti aplikace). Klíčová vlastnost analytického modelu je stabilita, získaná díky tomu, že je založený na doménovém modelu, odvozený ze scénářů užití a relativně nezávislý na implementaci. Úkolem je tedy zíkat třídy logického modelu, jejich zodpovědnosti a přiřadit zodpovědnosti z popisu PU. Dále také vlastnosti a chování tříd. Základem získání tříd logického modelu jsou prvotní třídy získané rozvojem doménového modelu (úvodní převod 1:1). Postup je postaven na rozboru případů užití a jeho detailů. Identifikujeme a navrhneme kandidátské objekty třídy a určíme zodpovědnosti a metody pro realizaci funkčnosti. Každý objekt je zodpovědný za realizaci konkrétní funkčnosti a znalost dat potřebných k funkčnosti. Zodpovědnosti jsou viditelné navenek v případech užití a jsou důležité pro práci ostatních tříd. Nástroje Pro přiřazení zodpovědností se ptáme např. Kniha je označena jako vrácena. => kdo to zařídí? některá ze stávajících tříd => nová zodpovědnost. K tomu můžeme využít nástroje: CRC karty mechanická technika pro brainstorming. Class-Responsibility-Collaborators (třídazodpovědnost-spolupracovník). Jedná se o papírové karty, kde nahoře je jméno třídy, vlevo zodpovědnost a vpravo spolupracující třídy. Je to nepřehledné pro větší systém, protože vazby nejsou znázorněny graficky. Používá se k tomu tužka, guma, stůl. Diagram sekvencí cílem je vymyslet třídy, které to zařídí. Popisuje výměnu zpráv mezi třídami. Objekty reprezentují třídy, zprávy představují fráze pro zachycení zodpovědnosti. Obsahuje detaily jako třídy, metody, větvení, cykly). Viz také ot. Č.5. Diagram spolupráce Dobré třídy mají následující vlastnosti: Správce informací (information expert) zodpovědnosti přiřazeny třídám, které mají potřebná data Vysoká soudržnost zodpovědnosti třídy jsou si podobné souvisí spolu Malá provázanost třída má málo vazeb na jiné. Doménový model 21

22 Popisuje struktury doménové oblasti. Jaké mají názvy, vzájemné vztahy a vlastnosti. Doménové objekty/třídy popisují základní abstrakce používané v oblasti aplikace a věci vyskytující se v problémové doméně. Definují jen základní obrysy a vztahy mezi třídami (asociace, kardinality). Jsou nezávislé na implementaci. S třídami z doménového modelu můžeme najisto počítat. V analýze se těmto objektům, přiřadí zodpovědnosti, detaily vlastností a chování, návrh je pak transformuje a přidaá implementační třídy. Oménový model se pak transformuje na logický datový model. Doménový model zpřesňuje vazby v analýze. Skoro všechny jsou asociace: Atributy Agregace/kompozice Rozklad na třídy, zejména vazby M:N Asociace tříd Okrajově se používá dědičnost nahrazení vícenásobné dědičnosti agregací / rozhraním. Pro větší detail z doménového modelu vytvoříme diagram tříd, kam přibudou základní atributy, metodya typy, statické vztahy, druhy tříd/objektů => stereotypy, role tříd => rozhraní. Případy užití Případ užití je sekvence akcí, které systém provádí v důsledku nějakého vnějšího podnětu a které vedou výsledkům viditelným pro některého jeho uživatele. Případ užití je něco co aktér od systému očekává. Jedná se o dialogy aktér-systém. PU jsou tedy vždy iniciovány aktérem. PU popisuje požadavky na funkčnost systému uživatele, kteří k němu přistupují, co pro ně software dělá, jakým způsobem zpracovává požadavky a kde je hranice systému. Specifikace detailu případů užití by měla obsahovat: název PU, jedinečný identifikátor, stručný popis, aktéry (hlavní, vedlejší). Vstupní a výstupní podmínky, kroky PU hlavní scénář a alternativní scénáře. Hlavní scénáře lze větvit pomocí slova IF a lze v nich opakovat události FOR, WHILE. V pokročilém modelování PU lze zobecnit aktéry (generalizace), zobecnit případy užití (Najít knihu je odvozeno od abstraktního obecného předka najít produkt). Lze využít relaci include - kroky opakující se v několika PU 22

23 vyčlení do samostatného PU, který bude moci zahrnout do bázového PU. Bázové PU jsou bez dodavatelských neúplné. Lze využít relaci extend přidává do bázového PU nové chování z rozšiřujícího PU. Bázové třídy jsou bez rozšiřujících úplné a využívají jen toho rozšíření. 10. Architektura softwarových systémů, význam a součásti architektury, architektonické styly Softwarová architektura je struktura komponent programu/systému, jejich vzájemné vazby, interakce, principy a předpisy určující jejich návrh a vývoj. Je důležité dodržet konceptuální integritu systému systém má nějakou architekturu a navíc pouze jednu (přesto může využívat více architektonických stylů. Architektura systému představuje koncept systému na nejvyšší úrovni v jeho okolí (prostředí). Význam architektury Je prvním krokem návrhu, poskytuje jakýsi návod, podle něhož bude proveden podrobný návrh (implementace) systému. Umožňuje myšlenkově uchopit návrh i velmi složitých systémů a jejich pochopení. Velmi ovlivňuje samotný návrh (především v počátcích vývoje) a následnou údržbu systému. Architektura dodává k návrhu klíčové aspekty organizace projektu říká jak systém členit. Součásti architektury Architektura člení systém hrubě na subsystémy a balíky a definuje rozhraní a závislosti mezi nimi. Dále přiřazuje třídy do balíků/subsystémů. Dodává konvence, které budou vývojáři využívat v celé implementaci a tím jim dává organizaci. Říká, jakou podobu bude mít např. lokalizace, udává jednotný přístup k tvorbě objektů. Architektura systému by měla být zdokumentovaná: v referenční architektuře (dokument,kostra aplikace), v Dokumentu (RUP Artifact: Software architecture document), v modelech (UML komponenty, třídy, interakce, stavový model) Logické členění - balíky Motivace k tomuto členění je to, že je logický objektový model velký a proto ho rozčleníme do balíků, abychom získali přehled o systému a rozdělili implementaci mezi členy týmu. Balík je skupina souvisejících tříd, které tvoří organizační celek, vytváří jmenný prostor a umožňuje hierarchické vnořování. Třídy v balíku by měly mít příbuznou funkčnost a být v jedné vrstvě aplikace, nebo kdekoli. Balíky mezi sebou komunikují pomocí rozhraní. Funkční členění subsystémy Motivace k tomuto členění je to, že monolitická aplikace je nepraktická. Subsystém je skupina souvisejících balíků a/nebo tříd tvořících funkční celek. Třídy v subsystému jsou funkčně soudržné a často vázané na jednoho aktéra. (Horizontální vrstvy vs. Vertikální domény finance, personalistika, řízení, utility). Pro nalezení subsystému (ale i balíků) je nutné vidět všechny třídy a vztahy a shluk těsně vázaných tříd pak tvoří kandidáty (nalezení na základě objektového modelu). Může to být ale zřejmé na první pohled (jednoduché architektonické styly). Nalézt je možné i na základě případů užití potlačíme nepodstatné PU a pro zbylé zkusíme vyjmout klíčovou třídu. Konvence a politiky Obecná pravidla pro návrh v libovolné části aplikace, která musí dodržovat všichni vývojáři. Týkají se správy paměti, synchronizace, transakce, lokalizace (L10N, I18N). 23

24 Architektonické styly - vzory Základní architektonické styly jsou: Klient-server 3vrstvé a vícevrstvé oddělují prezentaci, business logiku a datovou část. dnes jsou standardem např. MVC Vrstvené delegování na podřízené. Prezentace / řízení / doména / business služby / technická infrastruktura /knihovní třídy / systémové. Další architektonické styly mohou být: Service oriented architecture (SOA) Pipes and filters Blackboard Broker MVC struktura aplikace 3vrstvá architektura v malém oddělení vrstev, které se nejčastěji mění. Základem je návrhový vzor Modelview-controller a realizuje se pomocí tříd/objektů: Hraniční rozhraní obsahují funkčnost přímo závislou na okolí. Dialog s uživateli a komunikace s externími systémy. Úlohy hraničních objektů jsou prezentace informací a zapouzdření externích prvků. Řídící mechanismy funkčnost, která se může změnit nezávisle na datech, obsahují stavové přechody a mechnismy (business rules) Datové persistence údajů entitní třídy, které zapouzdřují informace uchovávané delší dobu (typicky přežívají mezi případy užití). Mají atributy a metody (funkčnost svázaná s přístupem k informacím). + knihovní, systémové realizace nízkoúrovňových úloh (komunikace, soubory, zobrazování). Cílem je reuse využití již hotového. 11. Návrh systému postup vytváření návrhu, kvalita návrhu, návrhové vzory, použití UML. Cílem návrhu systému je rozpracovat výsledky analýzy tak, aby šly jednoznačně implementovat v konkrétním programovacím jazyce a provozní platformě. Tak aby implementaci mohlo provádět více lidí, aby byla efektivní (co do výkonu i tvorby) a výsledek by byl snadno udržovatelný. Aspekty návrhu jsou: postup návrhu tříd, architektura, konvence, vzory řešení typických situací, jazykové idiomy. Když vize říkala proč a jestli a požadavky s analýzou říkali co, pak návrh říká jak. Postup vytváření návrhu Nejprve je nutné zvolit architekturu a vybrat technologii, protože postup tvorby návrhu i jeho konečnou podobu ovlivňují/omezují vlastnosti prostředí. Jedná se o programovací jazyk, databáze, knihovny, použití frameworků a hotových komponent. Ovlivňující faktory budou: stávající systém, efektivita vývoje a marketing. Koncepty analytického modelu jsou mapovány na implementační třídy a rozhraní. Výsledkem je detailní popis toho, jak bude systém naprogramován (nízkoúrovňové komponenty, algoritmy ). Přechod od návrhu k implementaci by pak měl být téměř mechanický, ve výsledku totiž známe téměř všechny detaily implementace: vazba na konkrétní technologie, okolní prostředí, způsob uložení persistentních dat, struktura aplikace, používané konvence a návrhové vzory. Detaily návrhů získáme převážně tak, že rozebereme a realizujeme PU: 24

25 Metody tříd rozborem PU, zodpovědnost = metoda. Cílem je interní funkčnost jednoznačně odvozená od požadované vnější. Mechanismy spolupráce tříd spolupráce více tříd na realizaci funkčnosti rámují jednotlivé zodpovědnosti a získáme rozborem scénáře PU. Využijeme zde návrhové vzory (Listener, Strategy...) Stavové modely objektů přechody mezi stavy na základě volání metod, podmíněné částmi interního stavu. Zahrnují objekty řízené podněty (nezávislost na stavu) a objekty řízené stavem (stav určuje možná volání) Kvalita návrhu Kvalitní návrh by měl zvážit (řešit) tyto aspekty: Rozšiřitelnost přidání nových funkcí nenaruší původní návrh a architekturu Robustnost schopnost vypořádat se s mimořádnými stavy (málo paměti, chybný výstup) Spolehlivost software dělá to, co má dělat Bezpečnost odolný proti útokům Kompatibilita jak se staršími verzemi, tak cizími systémy Modularita navržený systém se skládá z dobře definovaných a nezávislých komponent, které mohou být případně znovu použity. V kvalitním návrhu je nutné konsolidovat syntaxi a sémantiku tříd snaha o minimalitu, reuse, viditelnost vlastností (public, private). Následně podle toho upravit scénáře. Také bychom měli vzít v potaz úpravy celkového chování třídy Role třídy (zodpovědnosti, mechanismy) diagram tříd, komponent Postup implementačního mechanismu pořadí volání metod, protokol obvykle stavové modely Dohromady kontrakt třídy důležitá součást specifikace návrhu Úpravy vztahů modelu úpravy objektového modelu vyhledání opakujících se prvků => rodičovské třídy, vyjasnění vztahů (asociace - > agregace, c-s), nové řídící objekty, nové vztahy mezi třídami. Návrhové vzory Využijeme se pro řešení standardních problémů. Jejich cílem je rozvinout esenciální model tříd z analýzy a systematicky přistupovat k řešení. Základní prostředky jsou: návrhářská/programátorská zkušenost, návrhové vzory (GoF patterns, J2EE patterns,...), jazykové idiomy, konvence. Základní návrhové vzory vychází GOF (gang of four) design patterns, publikace od čtveřice autorů a jsou nejpoužívanějšími návrhovými vzory pro OOP. Tam jsou návrhové vzory rozděleny do skupin: Creational (vytvářející) řeší problémy související s vytvářením objektů v systému. Snahou těchto vzorů je popsat postup výběru třídy nového objektu a zajištění správného počtu těchto objektů. Factory method pattern Abstract factory Singleton pattern globální objekt v čistě objektové implementaci, sdílená data, nastavení. Je to třída, která může mít jednu a právě jednu instanci. Prototype pattern Builder Structural (strukturální) představují skupinu návrhových vzorů zaměřujících se na možnosti uspořádání jednotlivých tříd nebo komponent v systému. Snahou je zpřehlednit systém a využít možnosti strukturalizace kódu. Adapter pattern přizpůsobení rozhraní prostředí pro aplikaci, mapování dat. Bridge Facade jedna třída / rozhraní pro subsystém, deleguje na implementační objekty. Proxy přístup ke vzdáleným zařízením / objektům, lokální cache, pozdní zápis. 25

26 Behavioral (chování) se zajímají o chování systému. Mohou být založeny na třídách nebo objektech. U tříd využívají při návrhu řešení především principu dědičnosti. V druhém přístupu je řešena spolupráce mezi objekty a skupinami objektů. Template pattern Mediator Iterator Observer Strategy Nikdo neporozumí návrhovým vzorům na první přečtení, i autoři o sobě tvrdí, že jim na první přečtení nerozumí. Mediator Mediator představuje zapouzdření logiky komunikace mezi několika třídamido jedné třídy Mediatoru. Rozhraní mediator definuje způsob, jakým jednotlivé objekty komunikují s centrálním prvkem vzoru. V této třídě jsou uchovávány informace o komunikaci mezi třídami. Abstract factory method pattern Řeší problém, jak vytvořit na základě rozhodnutí v běhu programu instanci třídy, která dále vytváří instanci souvisejících, nebo závislých tříd. Klient vytváří konkrétní instanci typu Factory, která je poděděna z Abstract Factory, nebo implementuje odpovídající rozhraní. Tato konkrétní instance potom vytváří různé objekty (např. product A1, Product B1), které jsou předávány objektu Client. 26

27 Factory pattern Jakým způsobem rozhodnout až v průběhu programu o vytvoření instance konkrétní třídy. Adapter pattern Jedná se o přizpůsobení urřité třídy, aby ji bylo možné využívat i jiným způsobem. Problémem je zajištění konverze jedné třídy na rozhraní jiné třídy. Adaptér je třída, která zajišťuje funkcionalitu systému, ale neimplementuje požadované rozhraní. Rozhraní, které očekává třída Client, je definované v abstraktní třídě Target. Tato třída slouží jako předek pro konkrétní třídu Adapter, která má za úkol transformovat volání od klienta na příslušné metody tříd typu Adaptee. 27

28 Použití UML Výstupem návrhu bývá podrobný ULM diagram tříd a sekvenční diagramy pro důležité netriviální události v systému. Využijeme také diagram komponent a stavové modely. Tyto představují pro programátora návod, jak systém implementovat a také jsou důležitým zdrojem dokumentace. 12. Konfigurační management, role ve vývoji Konfigurační management = Software Configuration Management (SCM) = řízení konfigurace (konfigurační řízení). Konfigurační management je proces identifikování a definování prvků systému, řízení změn těchto prvků během životního cyklu, zaznamenávání a oznamování stavu prvků a změn, a ověřování úplnosti a správnosti prvků (IEEE-Std ). Konfigurační management určuje, jak vytvářet, sestavovat a uvolňovat produkt, identifikovat jeho části a verze a sledovat změny. Jedná se o administrativní a manažerskou část vývoje. Cílem SCM je při vývoji produktu ve více verzích a/nebo ve více lidech zamezit zmatkům při provádění změn na jednom objektu (dokumentu, souboru, tabulce). Problémy s tím související jsou: Separátní kopie => problém: dvojí údržba, každý má svou kopii, kterou nesdílí s ostatními. Jedna sdílená kopie => konfliktní změny, kopie putuje mezi vývojáři, pracuje na ní vždy jen jeden Soukromé kopie + sdílený originál => překrývání změn, originál ve sdíleném adresáři, pracuje se na lokálních kopiích, po úpravách se kopie překopíruje zpět. Prvek konfigurace konstituující složka systému. Může se jednat o různé typy: zdrojový soubor, dokument, knihovna, skript, spustitelný soubor, testovací data. Ve správě SCM má následující vlastnosti: Ví se o jeho existenci, vlastníkovi, změnách, umístění v produktu Je atomický z hlediska identifikace, změn Jednoznačně identifikovatelný: např. MSW/WS/IFE/SD/01.2 typ prvku (dokument,zdrojový text, testovací data), označení projektu, název prvku, identifikátor verze 28

29 Konfigurace je souhrn prvků konfigurace reprezentující určitou podobu daného SW systému. Př. první kompilovatelná verze programu XY pro LINUX. V konfiguraci musí být vše, co je potřebné k jednoznačnému opakovatelnému vytvoření příslušné verze produktu (včetně překladačů, build skriptů, inicializačních dat, dokumentace. SW konfigurace je konfigurace, jejíž prvky jsou navzájem bezrozporné. Např. zdrojové soubory jdou přeložit, knihovny přilinkovat. Může být jednoznačně identifikovatelná. Popis konfigurace struktura produktu jako množinu prvků a jejich vzájemných vztahů. Prvek = výsledek SW procesu, který má různou granularitu a reprezentaci (soubor/modul/deklarace). Vztahy určují strukturu a závislosti (celek-část, master-dependent), určují způsob produkce, tj. build produktu (zdrojový-odvozený) Role ve vývoji Change control manager má za úkol review (přezkoumání) požadavku na změnu, potvrzení duplikátu, nebo zamítnutí požadavku na změnu. Project manager plánuje a přiděluje práci a tedy i schválené požadavky na změnu Testovací analytik ověřuje, zda jsou změny funkční v novém release, buildu. Tester Implementuje testy Vývojáři implementují úkoly přidělené project managerem. Buildovač má na starosti řízení sestavení produktu. Jakákoli z těchto rolí (popř. i sám dodavatel a další role, uživatelé[přes help desk]) mohou vykonávat akce: předložení požadavku na změnu na přezkoumání, aktualizovat požadavky na změnu. 13. Základní postupy SCM, podpůrné nástroje Úlohy SCM Určení a správa konfigurace (cfg identification and control) určení prvků systému, přiřazení zodpovědnosti za správu, identifikace jednotlivých verzí prvků, kontrolované release produktu, řízení změn produktu během vývoje Zjišťování stavu systému (status accounting) udržení informovanosti o změnách a stavu prvků, zaznamenávání stavu prvků konfigurace a požadavků na změny, poskytování informací o těchto stavech, statistiky a analýzy Správa sestavení (Build) a koordinace prací (release management) určování postupů a nástrojů pro tvorbu spustitelné verze produktu, ověřování úplnosti, konzistence a správnosti produktu, koordinace spolupráce vývojářů při zpracování, zveřejňování a sestavení změn. Aktivity SCM v cyklu vývoje Správa změn Identifikace a správa verzí Sestavení 29

30 Postupy jednotlivých aktivit budou zmíněny v následujících třech otázkách. Podpůrné nástroje Nástroje pro správu změn Nástroje pro podporu řízení změn se nazývají Systémy pro správu změn (Bug tracking systémy - BT). Jejich úkolem je: Evidence, archivace požadavků Vyhledávání Přehled, reporty, grafy, statistiky Sledování stavu požadavku Jejich realizace jsou ové, webové, klientské. Měly by dodržovat strukturu projektu, která obsahuje minimálně: název, kategorie hlášení, úrovně závažnosti, priority, verze produktu, operační systém, přidělování vývojářů k úkolům. Příklady nástrojů jsou: Flyspray jednoduché, snadná instalace, webové rozhraní, ová notifikace, napsaný v PHP. Mantis - jednoduché, snadná instalace, webové rozhraní, ová notifikace, napsaný v PHP. Bugzilla rozbustní, pro velké projekty (mozilla), konfigurovatelná. Př. Vyhledávání > seznam > detail > historie. Nástroje pro správu verzí Ruční verzování Základní správa verzí správa verzí souborů, obvykle extensionální verzování modulů, poskytují centrální úložiště. Ukládají všechny verze v zapouzdřené úsporné formě. RCS, CVS, Subversion Distribuované poskytují více úložišť, které synchronizují, flexibilnější postupy. SVK, GIT, Mercurial Pokročilé integrace do CASE. Obvykle se jedná o kombinaci extenzionálního a intenzionálního verzování s automatickou podporou pro ci/co prvků z repository do nástrojů 30

31 ClearCase, Adele. Nástroje pro verzování by měly umět Operace s úložištěm ci, co, add, rename, move, import, export, stav prvků, diff, historie změn Verzování ci, co, data revize, branch, merge, značkování Podpora týmu a procesu vzdálený přístup, konfigurovatelné zamykání a přístupová práva, automatické oznamování, spouštění scriptů při operacích, integrace do IDE RCS Revision control system Správa verzí pro jednotlivé textové soubory v UNIX, Windows, DOS. Jedná se o extenzionální stavové verzování komponent. CVS Concurent Versioning System Práce s celými konfiguracemi najednou. Má sdílené úložiště + soukromé pracovní prostory. Úložiště je lokální, nebo vzdálené. Optimistický přístup ke kontrole paralelního přístupu. Jedná se o free software. Původně nadstavba nad RCS. Integrace do mnoha IDE a CASE nástrojů. Příkazová řádka, grafické nadstavby. SVN Subversion Následník CVS, způsob práce a příkazy velmi podobné CVS. Přibyly nové možnosti: binární diff, meta-data, abstraktní síťová vrstva (DAV), čisté API. Doporučená struktura úložiště oddělené adresáře pro kmen, větve a značky (branches, trunk, tag). Řízení sestavení Make Scriptovací nástroje pro podporu sestavení Shell, perl, python, php, Make Ant, maven CruiseControl Verifikace sestavení xunit (JUnit apod., Cactus) testovací roboti. Nástroj pro automatizaci build (překladu a sestavení) projektu na základě popisu závislostí typu zdrojovýodvozený. Definice pravidel se provádí v Makefile a spouští se příkazem make. Pojmy u nástroje make jsou: pravidlo (rule), cíl (target), závislost (dependency), příkaz (command). Ant Rozšiřitelný nástroj pro automatizaci sestavení Java. Používá se zde Buildfile (build.xml). Zahrnuje 3 hlavní typy elementů: Project root element dokumentu 31