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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE

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

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

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

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

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

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce WORKFLOW Procesní přístup Základ perspektivního úspěšného podnikového řízení Funkčnířízení založené na dělbě práce Procesní řízení princip integrace činností do ucelených procesů 1 Funkční řízení Dělba

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

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky.

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky. Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky. Projekt ESF OP VK reg.č. CZ.1.07/2.2.00/28.0209 Elektronické opory a e-learning pro obory výpočtového

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

MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ

MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ Ing. Jan Smolík Vysoká škola finanční a správní PROČ JINÝ ZPŮSOB MODELOVÁNÍ PROCESŮ Základní žurnalistické otázky Co, kdo, kdy, kde, jak,

Více

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

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

Design systému. Komponentová versus procesní architektura

Design systému. Komponentová versus procesní architektura Design systému Komponentová versus procesní architektura Architektura : třídy statické aspekty propojení logický pohled struktura popisu systému Architektura procesů: objekty dynamické aspekty koordinace

Více

4IT218 Databáze. 4IT218 Databáze

4IT218 Databáze. 4IT218 Databáze 4IT218 Databáze Osmá přednáška Dušan Chlapek (katedra informačních technologií, VŠE Praha) 4IT218 Databáze Osmá přednáška Normalizace dat - dokončení Transakce v databázovém zpracování Program přednášek

Více

Úvod do principů objektově orientovaného programování

Úvod do principů objektově orientovaného programování OBSAH DISTANČNÍHO E-LEARNINGOVÉHO KURZU PROFESNÍ RŮST ANALYTIKA OD ZÁKLADŮ (BASE) ÚVOD DO TECHNOLOGIÍ INFORMAČNÍCH SYSTÉMŮ Jak funguje počítač na základní úrovni Základy HTML Skripty ve webovských technologiích

Více

TEORIE ZPRACOVÁNÍ DAT

TEORIE ZPRACOVÁNÍ DAT Vysoká škola báňská - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky TEORIE ZPRACOVÁNÍ DAT pro kombinované a distanční studium Jana Šarmanová Ostrava 2003 Jana Šarmanová, 2003 Fakulta

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

8.2 Používání a tvorba databází

8.2 Používání a tvorba databází 8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam

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

Příprava dat v softwaru Statistica

Příprava dat v softwaru Statistica Příprava dat v softwaru Statistica Software Statistica obsahuje pokročilé nástroje pro přípravu dat a tvorbu nových proměnných. Tyto funkcionality přinášejí značnou úsporu času při přípravě datového souboru,

Více

Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux.

Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux. Jan Smolík UML UML Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux Zdroj: Wikipedia Unified modelling language Neproprietární

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

Modelování řízené případy užití

Modelování řízené případy užití Modelování řízené případy užití kompletní proces od UC po implementaci, robustnost 2005 Radek Ošlejšek, Jiří Sochor FI MU Brno oslejsek@fi.muni.cz http://www.fi.muni.cz/~oslejsek/pa103 30. 3. 2005 PA103:

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

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

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 21. Otázka : Softwarový process. Jeho definice, modely a vyspělostní úrovně. Standardizovaný přístup pomocí RUP (Rational Unified Process). Obsah :

Více

Diagram tříd (class diagram)

Diagram tříd (class diagram) Diagramy tříd 1 Diagram tříd (class diagram) Zobrazuje třídy v daném systému a vztahy mezi nimi Zobrazuje statický stav ukazuje vzájemné interakce, ale neukazuje co se při těchto interakcích děje Při znázornění

Více

SOFTWAROVÉ INŽENÝRSTVÍ 1

SOFTWAROVÉ INŽENÝRSTVÍ 1 Metodický list č. 1 Název tématického celku: Úvod do softwarového inženýrství Základním cílem tohoto tematického celku je vysvětlení smyslu discipliny nazývané softwarové inženýrství. Tematický celek zahrnuje

Více

MST - sběr dat pomocí mobilních terminálů on-line/off-line

MST - sběr dat pomocí mobilních terminálů on-line/off-line MST - sběr dat pomocí mobilních terminálů on-line/off-line Stručný přehled název: MST, software pro sběr dat mobilními terminály ve skladu (příjem, výdej, inventura) autor aplikace: FASK, spol. s r.o.,

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

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

Jiří Mašek BIVŠ V Pra r ha 20 2 08

Jiří Mašek BIVŠ V Pra r ha 20 2 08 Jiří Mašek BIVŠ Praha 2008 Procesvývoje IS Unifiedprocess(UP) Iterace vývoje Rysy CASE nástrojů Podpora metodických přístupů modelování Integrační mechanismy propojení modelů Podpora etap vývoje Generování

Více

Profilová část maturitní zkoušky 2013/2014

Profilová část maturitní zkoušky 2013/2014 Střední průmyslová škola, Přerov, Havlíčkova 2 751 52 Přerov Profilová část maturitní zkoušky 2013/2014 TEMATICKÉ OKRUHY A HODNOTÍCÍ KRITÉRIA Studijní obor: 78-42-M/01 Technické lyceum Předmět: TECHNIKA

Více

Roční periodická zpráva projektu

Roční periodická zpráva projektu WAK-1F44C-2005-2 WAK System Název projektu: Automatizovaná výměna dat mezi informačními systémy krizového řízení v dopravě s jednotným univerzálním a implementovaným rozhraním založeným na standardu webových

Více

Maturitní otázky z předmětu PROGRAMOVÁNÍ

Maturitní otázky z předmětu PROGRAMOVÁNÍ Wichterlovo gymnázium, Ostrava-Poruba, příspěvková organizace Maturitní otázky z předmětu PROGRAMOVÁNÍ 1. Algoritmus a jeho vlastnosti algoritmus a jeho vlastnosti, formy zápisu algoritmu ověřování správnosti

Více

Systémy pro podporu. rozhodování. 2. Úvod do problematiky systémů pro podporu. rozhodování

Systémy pro podporu. rozhodování. 2. Úvod do problematiky systémů pro podporu. rozhodování 1 Systémy pro podporu rozhodování 2. Úvod do problematiky systémů pro podporu rozhodování 2 Připomenutí obsahu minulé přednášky Rozhodování a jeho počítačová podpora Manažeři a rozhodování K čemu počítačová

Více

Modelování webových služeb v UML

Modelování webových služeb v UML Modelování webových služeb v UML Jaromír Šveřepa LBMS, s.r.o. Abstrakt: Tento příspěvek se zaměřuje na praktický postup pro identifikaci potřeby webové služby, modelování způsobu jejího použití, popřípadě

Více

Nemocnice. Prvotní analýza a plán projektu

Nemocnice. Prvotní analýza a plán projektu Nemocnice Projekt do předmětu AIS Prvotní analýza a plán projektu Lukáš Pohl, xpohll00, xkosti03 Jan Novák, xnovak79 2009/2010 1 Neformální specifikace FN potřebuje informační systém, který bude obsahovat

Více

Zajištění kvality programového vybavení - testování

Zajištění kvality programového vybavení - testování Zajištění kvality programového vybavení - testování Základy testování Proč se to dělá? Kvalita software 100% testování není možné Různé pohledy: Vývojářské testování (testy komponent, integrační, systémové

Více

Databáze v MS ACCESS

Databáze v MS ACCESS 1 z 14 19.1.2014 18:43 Databáze v MS ACCESS Úvod do databází, návrh databáze, formuláře, dotazy, relace 1. Pojem databáze Informací se data a vztahy mezi nimi stávají vhodnou interpretací pro uživatele,

Více

Informační systém pro řízení projektu vývoje software

Informační systém pro řízení projektu vývoje software ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ KATEDRA KYBERNETIKY DIPLOMOVÁ PRÁCE Informační systém pro řízení projektu vývoje software Praha, 2002 Jan Breznay Prohlášení Prohlašuji, že

Více

Úvod do MS Access. Modelování v řízení. Ing. Petr Kalčev

Úvod do MS Access. Modelování v řízení. Ing. Petr Kalčev Úvod do MS Access Modelování v řízení Ing. Petr Kalčev Postup při tvorbě aplikace Vytvoření tabulek Vytvoření relací Vytvoření dotazů Vytvoření formulářů Vytvoření sestav Tabulky Slouží k definování polí,

Více

MANAGEMENT - ORGANIZOVÁNÍ

MANAGEMENT - ORGANIZOVÁNÍ Autorem materiálu a všech jeho částí, není-li uvedeno jinak, je Ing. Jan Weiser. Dostupné z Metodického portálu www.rvp.cz, ISSN: 1802-4785, financovaného z ESF a státního rozpočtu ČR. Provozuje Národní

Více

Modelování procesů (2) 23.3.2009 Procesní řízení 1

Modelování procesů (2) 23.3.2009 Procesní řízení 1 Modelování procesů (2) 23.3.2009 Procesní řízení 1 Seznam notací Síťové diagramy Notace WfMC Notace Workflow Together Editor Aktivity diagram (UML) FirsStep Designer Procesní mapa Select Prespective (procesní

Více

Informační systémy. Jaroslav Žáček jaroslav.zacek@osu.cz

Informační systémy. Jaroslav Žáček jaroslav.zacek@osu.cz Informační systémy Jaroslav Žáček jaroslav.zacek@osu.cz Úvod - co možná umíte z předmětu SWENG Rozdělení IT Architektura IS Klíčový prvek řízení IS z něj vycházejí detailní analytické i plánovací charakteristiky

Více

Praktické aspekty ABC

Praktické aspekty ABC Praktické aspekty ABC Metoda maticového propočtu 1. Zjednodušený procesní model 2. Produktový přístup k nákladům 3. Analýza vnitřních produktů 4. Sestavení ABC rozpočtů 5. Maticový propočet Tomáš Nekvapil

Více

MANAŽERSKÉ INFORMAČNÍ SYSTÉMY

MANAŽERSKÉ INFORMAČNÍ SYSTÉMY Metodický list č. 1 MANAŽERSKÉ INFORMAČNÍ SYSTÉMY Úvodem: Protože předmětu manažerské informační systémy (MIS) je vyhrazeno ve studijním plánu kombinovaného studia pouze 10 prezenční hodin (5 dvouhodinových

Více

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Datová podpora na úrovni kontaktního pracoviště Úřadu práce pro státní sociální podporu Josef Hájek Bakalářská

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1 Dominik Vymětal 2009, Ostrava 1.-2.10.2009 1 Procesní model Výhody Orientace na konkrétní činnosti a možnost reengineeringu Nevýhody Malá orientace na průřezové nebo opakované činnosti Modely na základě

Více

Databázové systémy trocha teorie

Databázové systémy trocha teorie Databázové systémy trocha teorie Základní pojmy Historie vývoje zpracování dat: 50. Léta vše v programu nevýhody poměrně jasné Aplikace1 alg.1 Aplikace2 alg.2 typy1 data1 typy2 data2 vytvoření systémů

Více

Úvod do softwarového inženýrství IUS 2009/2010 p.1/30

Úvod do softwarového inženýrství IUS 2009/2010 p.1/30 Úvod do softwarového inženýrství IUS 2009/2010 5. přednáška Ing. Radek Kočí, Ph.D. Ing. Bohuslav Křena, Ph.D. Vytvořeno na základě přednášky doc. Ing. Jaroslava Zendulky, CSc. Úvod do softwarového inženýrství

Více

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1. Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1. Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1 P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1 Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1 Vznik a historie projektového řízení Akad. rok 2015/2016, LS Projektové řízení a marketing

Více

7.5 Diagram tříd pokročilé techniky

7.5 Diagram tříd pokročilé techniky 7.5 Diagram tříd pokročilé techniky Stereotypy - jeden ze základních prostředků rozšiřitelnosti UML - pro modelovací konstrukce neexistující v UML, ale podobné předdefinované v UML definované uživatelem

Více

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Databázové systémy Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Vývoj databázových systémů Ukládání dat Aktualizace dat Vyhledávání dat Třídění dat Výpočty a agregace 60.-70. léta Program Komunikace Výpočty

Více

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt Projektový management Lekce: 8 Projektový management Doc. Ing. Alois Kutscherauer, CSc. Projektový management je typ managementu uplatňovaného k zabezpečení realizace jedinečných, neopakovatelných, časově

Více