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

Rozměr: px
Začít zobrazení ze stránky:

Download "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

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme Smysl metodiky IS/IT Koncentrovaná zkušenost Checklist na nic nezapomeneme Přínosy metodik Větší produktivita a kooperace týmů Komunikační standard Specializace projektových týmů Nezávislost na konkrétních

Více

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

Návrh IS - UML. Jaroslav Žáček

Návrh IS - UML. Jaroslav Žáček Návrh IS - UML Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ UML UML není metodikou ani programovacím jazykem, je to pouze vizuální modelovací nastroj pro objektově orientované systémy.

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování. 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Business modelling, základní nástroje a metody business modelování.

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 22. Otázka : Úvodní fáze rozpracování softwarového projektu. Postupy při specifikaci byznys modelů. Specifikace požadavků a jejich rozpracování pomocí

Více

6 Objektově-orientovaný vývoj programového vybavení

6 Objektově-orientovaný vývoj programového vybavení 6 Objektově-orientovaný vývoj programového vybavení 6.1 Co značí objektově-orientovaný - organizace SW jako kolekce diskrétních objektů, které zahrnují jak data tak chování objekt: OMG: Objekt je věc (thing).

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

Architektura softwarových systémů

Architektura softwarových systémů Architektura softwarových systémů Ing. Jiří Mlejnek Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze Jiří Mlejnek, 2011 jiri.mlejnek@fit.cvut.cz Softwarové

Více

Analýza a modelování dat. Helena Palovská

Analýza a modelování dat. Helena Palovská Analýza a modelování dat Helena Palovská Analýza a modelování pro SW projekt Strukturovaný přístup Dynamická část (procesy, aktivity, funkce) Statická část (data) Objektově orientovaný přístup use case

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů Vývoj informačních systémů Přehled témat a úkolů Organizace výuky doc. Mgr. Miloš Kudělka, Ph.D. EA 439, +420 597 325 877 homel.vsb.cz/~kud007 milos.kudelka@vsb.cz Přednáška Teorie Praxe Cvičení Diskuze

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

Více

8 Přehled OO metodik (metod, metodologií)

8 Přehled OO metodik (metod, metodologií) 8 Přehled OO metodik (metod, metodologií) 8.1 OO metodiky konce 80. a začátku 90.let - všechny populární OO metodiky předpokládají, že: a) zadavatel jasný názor na svoje požadavky, b) zadavatel a vývojáři

Více

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika 2 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk UML, základní modely, diagramy aktivit, diagramy entit.

Více

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken Jazyk UML - přehled Unified Modeling Language jazyk pro popis objektově orientované analýzy a návrhu aplikací slouží k vzájemné komunikaci mezi zadavatelem a návrhářem systému má několik částí, není nutné

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

Modelování procesů s využitím MS Visio.

Modelování procesů s využitím MS Visio. Modelování procesů s využitím MS Visio jan.matula@autocont.cz Co je to modelování procesů? Kreslení unifikovaných či standardizovaných symbolů, tvarů a grafů, které graficky znázorňují hlavní, řídící nebo

Více

TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů

TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů Číslo otázky : 16. Otázka : Funkční a dynamická analýza informačního systému. Obsah : 1. Úvod 2. Funkční

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

Předmluva 11. Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14

Předmluva 11. Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14 Obsah Předmluva 11 Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14 KAPITOLA 1 Úvod do architektury softwaru 15 Použití procesu 16 Stručný popis

Více

Pokročilé typové úlohy a scénáře 2006 UOMO 71

Pokročilé typové úlohy a scénáře 2006 UOMO 71 Pokročilé typové úlohy a scénáře 2006 UOMO 71 Osnova Interní model typové úlohy Vazby include a extend Provázanost typových úloh na firemní procesy a objekty Nejčastější chyby 2006 UOMO 72 Interní model

Více

Databázové modelování. Analýza Návrh konceptuálního schématu

Databázové modelování. Analýza Návrh konceptuálního schématu Databázové modelování Analýza Návrh konceptuálního schématu 1 Vytváření IS Analýza Návrh Implementace Testování Předání SW Jednotlivé fáze mezi sebou iterují 2 Proč modelovat/analyzovat? Standardizované

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

5 Požadavky a jejich specifikace

5 Požadavky a jejich specifikace 5 Požadavky a jejich specifikace 5.1 Inženýrství (requirements engineering) - proces stanovení služeb, které by měl vyvíjený systém poskytovat a omezení, za nichž musí pracovat - CO má systém dělat, ne

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel I

Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel I Návrh řešení IS Vývoj informačních systémů Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel IS a jaký

Více

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

Architektura informačních systémů. - dílčí architektury - strategické řízení taktické řízení. operativní řízení a provozu. Globální architektura

Architektura informačních systémů. - dílčí architektury - strategické řízení taktické řízení. operativní řízení a provozu. Globální architektura Dílčí architektury Informační systémy - dílčí architektury - EIS MIS TPS strategické řízení taktické řízení operativní řízení a provozu 1 Globální Funkční Procesní Datová SW Technologická HW Aplikační

Více

Analýza. Roman Danel 1. Metody analýzy

Analýza. Roman Danel 1. Metody analýzy Analýza Analýza je vědecká metoda založená na dekompozici celku na elementární části, je to metoda zkoumání složitějších skutečností rozkladem (dissolution) na jednodušší. Cílem analýzy je tedy identifikovat

Více

5 Požadavky a jejich specifikace

5 Požadavky a jejich specifikace 5 Požadavky a jejich specifikace 5.1 Inženýrství (requirements engineering) - proces stanovení služeb, které by měl vyvíjený systém poskytovat a omezení, za nichž musí pracovat - CO má systém dělat, ne

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Požadavky a případy užití Daniela Szturcová Institut geoinformatiky, HGF Osnova Systém Uživatelé Případy užití Vazby (asociace, generalizace, include a extend) Shrnutí

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Požadavky a případy užití Daniela Szturcová, Pavel Děrgel Institut geoinformatiky, HGF Osnova Systém Uživatelé Případy užití Vazby (asociace, generalizace, include

Více

1. Dědičnost a polymorfismus

1. Dědičnost a polymorfismus 1. Dědičnost a polymorfismus Cíl látky Cílem této kapitoly je představit klíčové pojmy dědičnosti a polymorfismu. Předtím však je nutné se seznámit se základními pojmy zobecnění neboli generalizace. Komentář

Více

UML úvod. Zdroje: Kanisová Hana, Müller Miroslav: UML srozumitelně, Computer Press 2007

UML úvod. Zdroje: Kanisová Hana, Müller Miroslav: UML srozumitelně, Computer Press 2007 UML úvod Kapitola má seznámit se základy modelovacího jazyka UML. Klíčové pojmy: UML, CASE nástroje, procesní modelování, případy užití, role, diagram tříd, diagram objektů, sekvenční diagramy, digram

Více

Konceptuální modelování. Pavel Tyl 21. 3. 2013

Konceptuální modelování. Pavel Tyl 21. 3. 2013 Konceptuální modelování Pavel Tyl 21. 3. 2013 Vytváření IS Vytváření IS Analýza Návrh Implementace Testování Předání Jednotlivé fáze mezi sebou iterují Proč modelovat a analyzovat? Standardizované pracovní

Více

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Tel. +420 543426329 TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Autor: Vít Chvál Verze dokumentu: 1.0 Datum poslední změny: 18.2.2013 Obsah: 1 Pracovník 3 2 Pracovní činnosti (Náplň práce)

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz RUP - Disciplíny Jaroslav Žáček jaroslav.zacek@osu.cz Disciplíny Množství disciplíny v dané iteraci Disciplíny podle RUP Šest základních: Business modeling - pro pochopení problémové domény Requirements

Více

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda 1. Lze vždy z tzv. instanční třídy vytvořit objekt? 2. Co je nejčastější příčinou vzniku chyb? A. Specifikace B. Testování C. Návrh D. Analýza E. Kódování 3. Je defenzivní programování technikou skrývání

Více

DBS Konceptuální modelování

DBS Konceptuální modelování DBS Konceptuální modelování Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze Michal.Valenta@fit.cvut.cz c Michal Valenta, 2010 BIVŠ DBS I, ZS 2010/11 https://users.fit.cvut.cz/

Více

4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM

4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM 41 4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM V této kapitole vysvětlíme potřebu strukturované architektury podnikových procesů, a seznámíme se s běžnými typy modelů, používaných v ARISu k reprezentaci

Více

3 druhy UML diagramů

3 druhy UML diagramů UML grafický jazyk se pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů zjednodušuje komunikaci mezi zadavatelem a řešitelem projektu UML podporuje objektově orientovaný přístup

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází

Informační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází 1 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Požadavky kreditového systému. Relační datový model, relace, atributy,

Více

Manažerská informatika - projektové řízení

Manažerská informatika - projektové řízení VŠE, fakulta Podnikohospodářská Manažerská informatika - projektové řízení Projekt implementace informačního systému Jiří Mikloš 2009 Obsah Obsah Obsah... 2 Úvod... 3 Zadání... 4 Projektový postup... 5

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz Ročníkový projekt Jaroslav Žáček jaroslav.zacek@osu.cz Cíle předmětů Vytvoření fungující aplikace, která splňuje definované požadavky Vyzkoušet si celý životní cyklus projektu - specifikace zadání, formování

Více

Principy OOP při tvorbě aplikací v JEE. Michal Čejchan

Principy OOP při tvorbě aplikací v JEE. Michal Čejchan Principy OOP při tvorbě aplikací v JEE Michal Čejchan Témata přednášky Principy OOP - připomenutí Úvod - co nás vede k používání OOP Reálný svět - jak (ne)používáme OOP Nedostatky na úrovni programovacích

Více

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Pořadové číslo dodatečných informací: 14. ČÁST 1: Přesné znění žádosti dodavatele o dodatečné informace Otázka

Více

Vyřešené teoretické otázky do OOP ( )

Vyřešené teoretické otázky do OOP ( ) Vyřešené teoretické otázky do OOP (16. 1. 2013) 1) Vyjmenujte v historickém pořadí hlavní programovací paradigmata a stručně charakterizujte každé paradigma. a) Naivní chaotičnost, špatná syntaxe a sémantika

Více

Učíme se maturitní otázku Organizování z výkladové prezentace. Zpracoval Ing. Jan Weiser

Učíme se maturitní otázku Organizování z výkladové prezentace. Zpracoval Ing. Jan Weiser Učíme se maturitní otázku Organizování z výkladové prezentace Zpracoval Ing. Jan Weiser Osnova prezentace Postup jak uložit obsah tématu do dlouhodobé paměti? Obecnější začlenění problému Funkce řízení

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007 Základy analýzy autor Jan Novotný http://blog.novoj.net/ 15. února 2007 V prezentaci jsou použity diagramy z: Wikipedia, Sparx UML Tutorial, Argo UML Metodiky vývoje Různé metodiky vývoje vazba na fáze

Více

Metody popisu systému, základy UML

Metody popisu systému, základy UML Metody popisu systému, základy UML Strukturovaný přístup Klasickou metodou analýzy a návrhu informačních systémů je strukturovaný přístup, navržený v 70. letech (Tom DeMarco, Ken Orr, Larry Constantine,

Více

Business Process Modeling Notation

Business Process Modeling Notation Business Process Modeling Notation Stephen A. White, IBM Corporation Procesní řízení 1 Co to je BPMN? Standard Business Process Modeling Notation (BPMN) byl vyvinutý skupinou Business Process Management

Více

ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická. Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy

ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická. Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy Bc. Petr Pokorný Letní semestr 2009/2010 1 Obsah 1 Úvod... 3 2 Workflow... 3 3 Workflow

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

2 Životní cyklus programového díla

2 Životní cyklus programového díla 2 Životní cyklus programového díla Typické etapy: 1. Specifikace požadavků - specifikace problému - analýza požadavků 2. Vývoj programu - návrh - kódování (programování) 3. Verifikace a validace 4. Provoz

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

1. Integrační koncept

1. Integrační koncept Příloha č. 2: Technický popis integrace 1. Integrační koncept Z hlediska koncepčního budování Smart Administration na Magistrátu města Mostu je možno hovořit o potřebě integrace tří úrovní systémové architektury

Více

Objektově orientované databáze. Miroslav Beneš

Objektově orientované databáze. Miroslav Beneš Objektově orientované databáze Miroslav Beneš Obsah přednášky Motivace Vlastnosti databázových systémů Logické datové modely Nevýhody modelů založených na záznamech Co potřebujeme modelovat? Identifikace

Více

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče.

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče. Primární a cizí klíč Kandidát primárního klíče (KPK) Je taková množina atributů, která splňuje podmínky: Unikátnosti Minimálnosti (neredukovatelnosti) Primární klíč (Primary Key - PK) Je právě jedna množina

Více

Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda

Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda Proces vývoje HRIS Vema Vlastnosti HRIS (Human Resources Information System) HRIS Vema Proces vývoje HRIS Vema Vema, a. s. Přední

Více

Hierarchický databázový model

Hierarchický databázový model 12. Základy relačních databází Když před desítkami let doktor E. F. Codd zavedl pojem relační databáze, pohlíželo se na tabulky jako na relace, se kterými se daly provádět různé operace. Z matematického

Více

Novinky v UML 2.5 a agilní modelování

Novinky v UML 2.5 a agilní modelování Novinky v UML 2.5 a agilní modelování Marek Rychlý Vysoké učení technické v Brně Fakulta informačních technologií Ústav informačních systémů Přednáška pro AIS 15. října 2015 Marek Rychlý Novinky v UML

Více

Vývoj IS - strukturované paradigma II

Vývoj IS - strukturované paradigma II Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 05 1/18 Vývoj IS - strukturované paradigma II Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

Úvod do databázových systémů. Ing. Jan Šudřich

Úvod do databázových systémů. Ing. Jan Šudřich Ing. Jan Šudřich jan.sudrich@mail.vsfs.cz 1. Cíl předmětu: Úvod do databázových systémů Poskytnutí informací o vývoji databázových systémů Seznámení s nejčastějšími databázovými systémy Vysvětlení používaných

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

Úvod do databázových systémů 6. cvičení

Úvod do databázových systémů 6. cvičení Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Úvod do databázových systémů 6. cvičení Ing. Petr Lukáš petr.lukas@nativa.cz Ostrava, 2012 Modelování databází [1]

Více

Systém elektronického rádce v životních situacích portálu www.senorady.cz

Systém elektronického rádce v životních situacích portálu www.senorady.cz Systém elektronického rádce v životních situacích portálu www.senorady.cz Obec Senorady Miroslav Patočka 2006 Obsah: 1. Úvodní informace 1.1 Informace pro uživatele 1.1.1 Přístupnost HTML, PDA, WAP, XML

Více

POKROČILÉ POUŽITÍ DATABÁZÍ

POKROČILÉ POUŽITÍ DATABÁZÍ POKROČILÉ POUŽITÍ DATABÁZÍ Barbora Tesařová Cíle kurzu Po ukončení tohoto kurzu budete schopni pochopit podstatu koncepce databází, navrhnout relační databázi s využitím pokročilých metod, navrhovat a

Více

Problémové domény a jejich charakteristiky

Problémové domény a jejich charakteristiky Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 02 1/16 Problémové domény a jejich charakteristiky Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta

Více

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette Kapitola 1 PHP framework Nette 1.1 Úvod Zkratka PHP (z anglického PHP: Hypertext Preprocessor) označuje populární skriptovací jazyk primárně navržený pro vývoj webových aplikací. Jeho oblíbenost vyplývá

Více

SQL - trigger, Databázové modelování

SQL - trigger, Databázové modelování 6. přednáška z předmětu Datové struktury a databáze (DSD) Ústav nových technologií a aplikované informatiky Fakulta mechatroniky, informatiky a mezioborových studií Technická univerzita v Liberci jan.lisal@tul.cz

Více

Objektově orientované technologie. Daniela Szturcová

Objektově orientované technologie. Daniela Szturcová Objektově orientované technologie Cvičení 5 - Tvorba třídního diagramu Daniela Szturcová 1 5 Tvorba třídního diagramu Cíl cvičení Vyhledat třídy, jejich atributy a operace. Navrhnout vazby mezi třídami.

Více

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph)

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) Marketingová komunikace Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) 2. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Minulé soustředění úvod

Více

Databázové systémy. Ing. Radek Holý

Databázové systémy. Ing. Radek Holý Databázové systémy Ing. Radek Holý holy@cvut.cz Literatura: Skripta: Jeřábek, Kaliková, Krčál, Krčálová, Kalika: Databázové systémy pro dopravní aplikace Vydavatelství ČVUT, 09/2010 Co je relační databáze?

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Logická struktura systému (Diagram tříd) Daniela Szturcová Institut geoinformatiky, HGF Osnova Třídy Statický pohled na systém Atributy a operace, řízení přístupu

Více

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS

Více

Diagramy tříd - základy

Diagramy tříd - základy Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka Zákazník -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

Seminární práce Vývoj informačního systému. Manažerská informatika 2 Ing. Miroslav Lorenc

Seminární práce Vývoj informačního systému. Manažerská informatika 2 Ing. Miroslav Lorenc Seminární práce Vývoj informačního systému Manažerská informatika 2 Ing. Miroslav Lorenc Vypracoval: Jan Vít (xvitj17) LS 2007/2008 1. ÚVOD...3 1.1. POPIS PROJEKTU...3 2. OBSAH PROJEKTU...3 2.1. SEZNAM

Více

Systémy pro podporu rozhodování. Hlubší pohled 2

Systémy pro podporu rozhodování. Hlubší pohled 2 Systémy pro podporu rozhodování Hlubší pohled 2 1 Připomenutí obsahu minulé přednášky Motivační příklad Konfigurace DSS Co to je DSS? definice Charakterizace a možnosti DSS Komponenty DSS Subsystém datového

Více

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů Zuzana Šochová 30.10.2008 1 Metody řízení projektů Týmová spolupráce Agilní metody Scrum proces Backlog úloh a odhady Jak plánovat Tým a zákazník 2 Executive support User involvement Experienced project

Více

MULTIMEDIÁLNÍ A HYPERMEDIÁLNÍ SYSTÉMY

MULTIMEDIÁLNÍ A HYPERMEDIÁLNÍ SYSTÉMY MULTIMEDIÁLNÍ A HYPERMEDIÁLNÍ SYSTÉMY 1) Úvod do problematiky Petr Lobaz, 18. 2. 2004 ORGANIZACE PŘ EDMĚ TU POŽADAVKY KE ZKOUŠCE vypracování semestrální práce (max. 70 bodů) napsání testu (max. 30 bodů)

Více

CASE. Jaroslav Žáček

CASE. Jaroslav Žáček CASE Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Co znamená CASE? Definice dle SEI A CASE tool is a computer-based product aimed at supporting one or more software engineering activities

Více

Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit (entitní množiny) Atributy

Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit (entitní množiny) Atributy - 2.1 - Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit Množiny vztahů Otázky návrhu Plánování mezí Klíče E-R diagram Rozšířené E-R rysy Návrh E-R databázového schématu Redukce

Více

Dolování v objektových datech. Ivana Rudolfová

Dolování v objektových datech. Ivana Rudolfová Dolování v objektových datech Ivana Rudolfová Relační databáze - nevýhody První normální forma neumožňuje vyjádřit vztahy A je podtypem B nebo vytvořit struktury typu pole nebo množiny SQL omezení omezený

Více

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová Objektově orientované technologie Logická struktura systému Objektový diagram Pavel Děrgel, Daniela Szturcová Osnova Modelování objektů objektový diagram Struktura a vazby mezi objekty Dobré zvyky při

Více

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH Jindřich Kaluža Ludmila Kalužová Recenzenti: prof. Ing. Milan Turčáni, CSc. prof. Ing. Ivan Vrana, DrSc. Tato kniha vznikla za finanční podpory Studentské grantové

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

Požadavky Modelování případů užití

Požadavky Modelování případů užití Požadavky Modelování případů užití Požadavky část 2 Clear View Training 2005 v2.2 1 4.2 Modelování případů užití Modelování případů užití je jednou z forem inženýrství požadavků Modelování případů užití

Více

Softwarové inženýrství 01. doc. Ing. František Huňka, CSc.

Softwarové inženýrství 01. doc. Ing. František Huňka, CSc. Softwarové inženýrství 01 doc. Ing. František Huňka, CSc. Obsah kurzu Softwarové inženýrství obecně vodopádová model spirálový model RUP agilní metodiky vývoj řízený vlastnostmi (Feature Development Design)

Více

10 Balíčky, grafické znázornění tříd, základy zapozdření

10 Balíčky, grafické znázornění tříd, základy zapozdření 10 Balíčky, grafické znázornění tříd, základy zapozdření Studijní cíl Tento studijní blok má za cíl pokračovat v základních prvcích jazyka Java. Konkrétně bude věnována pozornost příkazům balíčkům, grafickému

Více

KIV/ASWI 2007/2008 Metody získávání a zachycení požadavků. Postupy a UML modely Zachycení požadavků Model užití Popis problémové oblasti

KIV/ASWI 2007/2008 Metody získávání a zachycení požadavků. Postupy a UML modely Zachycení požadavků Model užití Popis problémové oblasti KIV/ASWI 2007/2008 Metody získávání a zachycení požadavků Postupy a UML modely Zachycení požadavků Model užití Popis problémové oblasti Objektová analýza a návrh Sběr požadavků, analýza: co se chce objektový

Více

Bridge. Známý jako. Účel. Použitelnost. Handle/Body

Bridge. Známý jako. Účel. Použitelnost. Handle/Body Bridge Bridge Známý jako Handle/Body Účel odděluje abstrakci (rozhraní a jeho sémantiku) od její konkrétní implementace předchází zbytečnému nárůstu počtu tříd při přidávání implementací používá se v době

Více