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

Save this PDF as:
 WORD  PNG  TXT  JPG

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

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

Transkript

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

2 Prohlášení Prohlašuji, že jsem zadanou diplomovou práci zpracoval samostatně s přispěním vedoucího diplomové práce a používal jsem pouze literaturu v práci uvedenou. Prohlašuji, že nemám námitek proti využití výsledků této práce fakultou ani proti zveřejňování nebo půjčování se souhlasem vedoucího diplomové práce. V Praze, dne

3 Poděkování Na tomto místě bych chtěl poděkovat Ing. Petru Mikšovskému a Ing. Zdeňku Koubovi za vedení mé diplomové práce. Dále pak děkuji mým rodičům a přátelům, kteří za mnou po celou dobu studia stáli a podporovali mě.

4 Abstrakt Cílem této práce bylo navrhnout a implementovat informační systém pro řízení projektu vývoje software. Byla vytvořena aplikace, která přes rozhraní sítě internet nabízí komplexní přístup k řešení vývoje zejména rozsáhlých softwarových produktů, vznikajících jako výsledek týmové práce skupiny vývojářů. Základním prvkem v aplikaci je projekt, ke kterému mohou být přiřazeny různé komponenty zefektivňující práci na softwarovém projektu (diskusní fórum, seznam úkolů, seznam chyb, zdrojové kódy a zveřejňování vznikajících produktů). Správa uživatelů je podpořena možností sdružovat uživatele do skupin. Informační systém byl vytvořen pro vývoj aplikací v Gernstnerově laboratoři Katedry kybernetiky. Abstract This diploma thesis deals with design and implementation of the Information system for software development project control. Designed application provides through the Internet an integrated access to the large-scale software products development. Application is centered on teamwork. Each registered project can own a few of components to assure teamwork to be effective (mail forum, task list, bug list, file releases, source codes). Application provides user management include availability of user groups. The information system is developed for Gernstner laboratory of the Department of Cybernetics.

5 Obsah Obsah Úvod Softwarové inženýrství Základní pojmy Specifikace požadavků Nástroje pro analýzu systému a návrh SW produktu Modely softwarového procesu Vodopádový model Prototypování Spirálový model Další modely Nástroje analýzy systému Metody návrhu systému UML Případy užití Diagramy tříd Diagramy objektů Sekvenční diagramy Diagramy spolupráce Stavové diagramy Diagramy aktivit Diagramy komponent Diagramy rozmístění SSADM Hlavní složky SSADM Struktura SSADM Techniky a postupy Specifikace požadavků Popis života entit Identifikace uživatelských rolí Identifikace a návrh dialogů

6 2.4 Řízení projektu vývoje software Metriky softwarového projektu Odhadování a plánování rozsahu projektu Řízení rizik a zabezpečení kvality softwarového produktu Řízení změn softwarového produktu Testování softwaru Projektový management IS pro řízení projektu vývoje software Návrh a implementace ISSDPC Specifikace požadavků na ISSDPC Vývojový nástroj systému Server ISSDPC Databáze ISSDPC Struktura aplikace Implementace Inicializace systému Popis ISSDPC z pohledu uživatele Uživatelské role Skupiny uživatelů Registrace uživatele Přihlášení uživatele do systému a odhlášení Osobní stránka uživatele Administrace systému Projekt (Project) Seznam úkolů (Task list) Seznam chyb (Bug list) Diskusní fórum (Mail forum) Zveřejněné soubory (Releases) Zdrojové kódy (Source codes) Přístupová práva k objektům Závěr Literatura Obsah přiloženého CD Přílohy

7 1 Úvod Se vstupem počítačů do rozmanitých odvětví činnosti člověka nabývá na významu otázka vývoje software jako dílčího nástroje pro realizaci určitých cílů lidského snažení. Počítače jsou využívány pro řešení stále důležitějších a komplexnějších úloh, kdy se hlavními ukazateli stávají zejména spolehlivost a cena. V současné době dosahuje hardware počítačů již takové úrovně, že v aplikacích s počítačovými systémy jsou tyto ukazatele převážně určeny právě softwarovým vybavením. Rozsah úloh řešených za pomoci software byl impulsem ke vzniku vědní disciplíny zvané softwarové inženýrství. Jelikož vývoj téměř každého softwarového produktu je náročnou a rozsáhlou prací, neobejde se bez týmové práce řady spolupracovníků, kteří musí vzájemně sdílet zdrojový kód projektu, na kterém společně pracují. Musí komunikovat, zveřejňovat požadavky, připomínky a návrhy, zveřejňovat své dílčí výsledky apod. Právě k tomuto účelu slouží informační systém pro řízení projektu vývoje software. Kapitola 2 pojednává o softwarovém inženýrství. Nejprve jsou zmíněny základní pojmy problematiky vývoje software se zaměřením na vývoj rozsáhlých softwarových produktů. Kapitola pokračuje tématem specifikace požadavků. Následuje část věnovaná nástrojům pro analýzu systému a návrh softwarového produktu. Jsou zmíněny základní pojmy a metody analýzy a návrhu a poté jsou popsány dvě konkrétní, v praxi používané, metody s odlišným přístupem k problematice analýzy a návrhu softwarového produktu. V závěru kapitoly je zmíněn přístup k problematice řízení projektu vývoje software zejména z pohledu manažera projektu. Kapitola 3 popisuje navrženou aplikaci Informačního systému pro řízení projektu vývoje software. Nejprve je popsána analýza, návrh a implementace tohoto systému. Následují informace nutné k uvedení sytému do provozu a kapitola popisující aplikaci z pohledu uživatele. Jsou zmíněny uživatelské role a každý objekt aplikace je popsán z pohledu všech uživatelských rolí. Zvláštní kapitola je věnována nastavování přístupových práv k vytvořeným objektům. V textu je pro názornost umístěno několik obrázků zachycujících aplikaci v různých stavech. 3

8 2 Softwarové inženýrství Softwarové inženýrství je podle [1] systematický, disciplinovaný a kvalifikovaný přístup k vývoji, provádění a údržbě softwaru. 2.1 Základní pojmy Systém Systém je množina vzájemně souvisejících objektů či komponent, na kterou nahlížíme jako na celek a která byla vytvořena pro určitý účel. Systém je ohraničený a to, co je vně této hranice, se nazývá okolí, s nímž systém interaguje prostřednictvím svých rozhraní. Analýzou systému rozumíme nacházení faktů, zákonitostí a omezení v systému [2]. Projekt Projekt je dobře definovaná posloupnost činností, která má určen začátek a konec. Je zaměřena na dosažení jistého cíle a je uskutečňována pomocí zdrojů lidí a prostředků. Projekt je specifická nerutinní akce, která vyžaduje plánování, neboť je problematické stanovit jeho časovou a finanční náročnost. Plánování projektu má za cíl důkladně promyslet to, čeho chceme dosáhnout. Slouží také k sestavení časového harmonogramu a rozpočtu projektu [3]. Softwarový proces Softwarový proces je sada postupů, pravidel a norem pro řízení softwarového projektu. Definuje fáze projektu, produkty, role pracovníků a jejich zodpovědnost, kvalitativní kriteria, použití nástrojů včetně šablon. Softwarový produkt Softwarový produkt je správním či řídícím systémem nad systémem základním, definovaným výše, jakožto výsledek softwarového procesu definovaného v předchozím odstavci. IEEE definuje software jako souhrn programů, metod, pravidel a přidružené dokumentace a dat [4]. Softwarový produkt tedy není jenom programem používaným pouze autorem programu s minimem dokumentace. Takový produkt by byl pro 4

9 uživatele nedostačující. Software podle [5] znamená průmyslově-kvalitní software, kdy uvažujeme, že je předmětem zájmu jak týmu vývojářů, tak uživatelů. Jako takový tedy zahrnuje kromě programů (ve smyslu uvedeném výše) s vhodným uživatelským rozhraním také adekvátní množství dokumentace a před uvedením do provozu byl řádně systematicky testován. Programování ve velkém Při programování rozsáhlých softwarových produktů se jedná o řešení rozsáhlých programových celků, které řídí, ovlivňují či spoluvytvářejí složitý systém. Nelze tedy aplikovat pouze metodiky určené pro programování v malém, kterými jsou zejména programovací techniky pro návrh dat a algoritmů. Při programování ve velkém je nutná dekompozice projektu na menší celky do takové míry, kdy lze využít technik programování v malém. Při řešení rozsáhlého softwarového projektu se tedy uplatní jak programování ve velkém, tak i programování v malém. Vývoj takového projektu je obvykle řešen v etapách, jež jsou součástí životního cyklu softwarového produktu. Životní cyklus softwarového produktu Životní cyklus softwarového produktu začíná prvotní představou o programu a končí ve chvíli stažení produktu z používání. Životní cyklus každého rozsáhlého softwarového produktu by měl vždy obsahovat následující etapy: Specifikace problému je prvním krokem ke vzniku softwarového produktu. Tato etapa spočívá v zadání problému, jeho specifikaci, prvotních návrzích komunikace s programem a v závěru spočívá v testování vytvořené specifikace. Kvalita specifikace ovlivňuje další fáze vývoje produktu, je proto velmi důležitá. Její úspěch je založen zejména na hojné komunikaci řešitelů se zadavatelem. Analýza sytému si klade za cíl vytvoření logického modelu stávajícího a požadovaného sytému. V této fázi vývoje je velice důležitá komunikace mezi pracovníky provádějícími analýzu a zadavateli projektu, neboť nepochopení požadavků zadavatele může vést k rozsáhlým nežádoucím časovým i finančním následkům. Při analýze je výhodné použít grafických technik, díky jejich srozumitelnosti i pro osoby neznalé metod softwarového inženýrství, neboť takovými osobami většinou zadavatelé projektu jsou. V etapě návrhu systému se uplatňují metody programování ve velkém. Je nutná dekompozice problémů na problémy dílčí, návrh metod řešení jednotlivých problémů 5

10 a návrh podpůrných prostředků. Velmi důležitá je volba metody návrhu systému, neboť právě na ní závisí časová náročnost návrhu a tím i výsledná cena softwarového produktu. Třetí etapou je implementace, při které se uplatní metody programování v malém. Nejprve je nutné provést návrhy reprezentace lokálních dat, návrhy algoritmů realizujících dílčí problémy. Poté následuje zápis kódu programu a jeho modulů ve zvoleném programovacím jazyce a ladění programu. Po odladění jednotlivých komponent následuje jejich syntéza do požadovaných výsledných celků. Nedílnou součástí kvalitního softwarového produktu musí být dokumentace produktu. Obsahuje nejen příručku k používání produktu, ale také dokumentaci k programu samotnému, dokumentaci pro údržbu a modifikace systému a případně další dokumenty k bezproblémovému nasazení, užívání produktu či jeho stažení z užívání. V další etapě následuje testování produktu. Spočívá ve validaci či verifikaci produktu proti specifikaci vzniklé v první etapě vývoje produktu a proti dokumentaci vzniklé v předchozí etapě. Teprve nyní následuje zadavateli nejvíce očekávaná etapa, kterou je nasazení, provoz a údržba produktu. Začíná v předání softwarového produktu včetně potřebné dokumentace zadavateli, případně v instalaci produktu u zadavatele, bylo-li tak ujednáno. V případě potřeby výroba médií a dokumentace, školení k produktu a podpora. Po uvedení rozsáhlého softwarového produktu do fungování následují opravy chyb objevených při provozu systému a opravy v dokumentaci k produktu. Dále pak vývoj a údržba verzí produktu. Po určité době používání softwarového produktu nastane situace, kdy produkt již nevyhovuje požadavkům uživatelů sytému a jediným řešením je návrh systému nového. V takovém případě se softwarový produkt dostává do poslední etapy, kterou je stažení produktu z používání. Je zřejmé a ze zkušeností vyplývá, že vývoj rozsáhlých softwarových produktů se neobejde bez zpětných kroků, kdy je nutné některé etapy opakovat. Z hlediska efektivity vývoje produktu je však žádoucí vyloučit zpětné kroky přes více etap. V některých případech je ovšem nutné zopakovat i celý cyklus. Existuje proto několik modelů životního cyklu, viz. kapitola

11 Objektově orientované programování Základním pojmem objektově orientovaného programování je objekt. Objekt je v obecném slova smyslu cokoliv, co jsme citem schopni označit jako objekt. Objekt má svou identitu, vlastnosti, chování a zodpovědnost. Abstrakcí objektu vznikne tzv. třída, která je jakousi šablonou pro podobné objekty. Vlastnosti objektů určují data třídy a chování objektu definuje metody třídy. Objekt je tedy instancí třídy a definujeme tzv. zapouzdření, které znamená umístění dat a metod pracujících nad těmito daty do jediného objektu. Objektově orientovanému programování předchází objektově orientovaná analýza systému, která se zabývá zkoumáním systémů z pohledu objektů. Výhodou objektového přístupu je fakt, že identifikované objekty v pojetí uživatelů i programátorů znamenají totéž. Na základě nalezených objektů se definují jejich třídy. Hledají se jejich společné rysy a generalizací lze dospět ke vzniku tříd nových a vytvořit určitou hierarchii, ve které budou mezi třídami existovat vztahy dědičnosti. Potomek třídy tak zdědí vlastnosti a chování rodičovské třídy a rozšíří je o své vlastní. Hierarchie tříd založených na dědičnosti vede ke vzniku spolehlivějšího a přehlednějšího kódu programu oproti kódu, ve kterém nebylo generalizace využito. Rozsáhlost kódu je snížena při zachování funkčnosti. 2.2 Specifikace požadavků Na počátku softwarového procesu vždy stojí specifikace požadavků. Obvykle probíhá v několika krocích, kdy výstupem každého kroku je určitý dokument, sloužící jako podklad pro řešení dalších kroků. V prvém kroku je vytvořen návrh požadavků, který je obvykle nazýván neformální specifikace nebo též odborný článek. Odborný článek by měl být prvním psaným dokumentem, ovšem jako základ smlouvy mezi zadavatelem projektu a řešitelem sám o sobě není dostačující, neboť použití pouze přirozeného jazyka neposkytuje dostatečně přesnou formu vyjádření specifikace požadavků na softwarový produkt. Dalším krokem při specifikaci požadavků je vytvoření funkční specifikace softwarového produktu. Tento dokument musí být mnohem přesnější než odborný článek, a proto je žádoucí použít při jeho vytváření mnohem formálnější notaci. 7

12 Požadavky se dělí na funkční a nefunkční. Funkční požadavky určují, jak bude program fungovat, ostatní požadavky jsou zahrnuty v požadavcích nefunkčních. Více informací o tomto dělení požadavků lze nalézt v kapitole Specifikaci požadavků lze rozdělit na neformální a formální. Neformální specifikace je vyjádřena přirozeným jazykem. Je proto poměrně dobře srozumitelná i pro uživatele nezabývající se vývojem software (zadavatele projektu), ovšem může obsahovat jisté nedostatky, které nejsou na první pohled zřejmé a projeví se až v dalších etapách vývoje produktu. Velkou část těchto problémů lze eliminovat zápisem požadavků ve formálním jazyce, jehož sémantika je jednoznačně definována. Poměrně universálním nástrojem je jazyk predikátové logiky, který však není v běžné praxi příliš použitelný. Lze však využít jiné prostředky, např. známé z teorie automatu, nebo Bacus- Naurovu formu. Pokud máme k dispozici podpůrné nástroje pro zpracování formálních specifikací, je možné je využít k validaci a verifikaci specifikace. 2.3 Nástroje pro analýzu systému a návrh SW produktu Modely softwarového procesu Model softwarového procesu si klade za cíl naznačit možné způsoby průchodu životním cyklem rozsáhlého softwarového produktu. Modelů existuje hned několik, protože různorodost problematiky vývoje software zabraňuje sjednocení postupů do jediné optimální metody Vodopádový model Vodopádový model (viz. Obrázek 2.1), též lineární sekvenční model, je základním modelem životního cyklu softwarového produktu. Je složen z činností, které na sebe navazují a vzájemně se neprolínají. Předpokládá, že výchozí požadavky na softwarový produkt se nebudou během vývoje zásadně měnit. Tento model vývoje softwarového produktu popisuje klasický životní cyklus. Má však některé nedostatky, kterými jsou zejména: reálné projekty zřídkakdy sledují jednotlivé kroky v předepsaném pořadí pro zadavatele je ve většině případů obtížné přesně specifikovat požadavky provozuschopná verze je k dispozici až po dlouhé době a většinou s časovou prodlevou. 8

13 Přes všechny zmíněné nedostatky je vodopádový model vhodnou a používanou šablonou pro přístup k vývoji rozsáhlých softwarových produktů a v každém případě je vhodnější, než náhodný, metodicky neřízený přístup k řešení problému. definice požadavků návrh systému a SW produktu implementace a testování dílčích částí integrace dílčích částí testování celku provoz a údržba Obrázek 2.1: Vodopádový model životního cyklu softwarového produktu Prototypování Prototypování, na rozdíl od vodopádového modelu, již předpokládá, že nemáme podrobně analyzovaný systém a požadavky na systém nejde dostatečně dobře specifikovat předem. Je založeno na vytváření (programování) prototypů, které slouží k modelování některých vlastností systému. Prototyp je částečnou implementací produktu nebo jeho části v logické či fyzické formě, který prezentuje všechna vnější rozhraní. Prototypování umožní jak zadavateli, tak vývojovému týmu ujasnit si a specifikovat požadavky, včetně jejich interpretace. Prototypování je často využíváno i v jiných modelech a sestává z následujících kroků: 1. sběr a analýza dat 2. rychlý návrh 3. tvorba prototypu 4. vyhodnocení prototypu zadavatelem 5. vylepšení návrhu prototypu 6. jestliže zadavatel není spokojen s prototypem, je nutné opakovat od bodu 2 7. je-li zadavatel projektu spokojen, poté následuje úplný návrh. 9

14 Prototypování lze většinou aplikovat při vývoji menších systémů anebo na úrovni subsystému systému rozsáhlého, neboť prototypování rozsáhlého systému je obtížné a neekonomické Spirálový model Spirálový model je založen na kombinaci prototypování a analýzy rizik. Práce na projektu jsou realizovány tak, aby problémy spojené s klasickým vodopádovým modelem byly cílevědomě minimalizovány. Jednotlivé kroky vývoje produktu známé z vodopádového modelu se ve spirále opakují, ale pokud možno na vyšším stupni zvládnutí problematiky. Spirálový model života softwarového produktu začíná v počátku souřadnic. Směrem od středu ubíhá čas. V každé fázi opakování vodopádového modelu (řez spirálou) se provádí identifikace a řešení rizik. Spirálový model je založen na prioritě tvorby verze s vyšší rizikovostí, tedy části produktu s vyšší mírou rizika jsou realizovány dříve. Nevýhodou spirálového modelu je, že nelze přesně stanovit přesné časové termíny a tím pádem ani finanční rozpočet, což jsou ovšem při vývoji software na zakázku velmi důležité ukazatele. Spirálový model je vhodný při vývoji rozsáhlých systémů Další modely Další typy modelů softwarového procesu budou zmíněny jen krátce, neboť jsou vesměs založeny na výše zmíněných modelech. RAD model (Rapid Application Development) je založen na aplikaci vodopádového modelu a spočívá v krátkém vývojovém cyklu (doba trvání do 3 měsíců). Je vhodný pro dobře srozumitelné a dobře vymezené problémy s nízkou úrovní rizik. Problém je rozdělen na samostatné moduly, jejichž vývoj je přidělen jednotlivým týmům pracovníků. Rychlý vývojový cyklus je umožněn zejména častým využíváním již hotových softwarových komponent. Přírůstkový (evoluční) model kombinuje vodopádový model s iterativní filosofií. Produkt je vytvářen po částech, tzv. přírůstcích, které jsou funkční, na rozdíl např. od prototypu. První přírůstek je označován jako jádro. Tento model je vhodný pro malý tým a rozsáhlý úkol, jehož vývoj lze zvládnout po částech v předem domluvených termínech. 10

15 Model skládání komponent je založen na spirálovém modelu a je určen pro technologie s objektovým přístupem k softwarovému procesu. Při vývoji se využívá hotových knihoven tříd objektů. Model souběžného vývoje modeluje vývoj softwarového procesu jako paralelní procesy, kdy jsou jednotlivé komponenty vyvíjeny souběžně. Tento model je vhodný např. pro aplikace typu klient/server. Formální metody vývoje spočívají na formálních specifikacích a podporují formální verifikaci produktů. Praktickému nasazení takových metod zatím brání jejich časové a finanční nároky, nároky na vysokou kvalifikaci řešitelů a jejich obtížnost při komunikaci se zadavatelem projektu. Tzv. techniky čtvrté generace jsou založeny na programování s vysokou úrovní abstrakce. Jejich výhodou je zvýšení produktivity a tím rychlosti vývoje. Nevýhodou některých prostředků určených pro tento způsob vývoje je srovnatelná složitost s programovacími jazyky, užívanými při aplikaci předchozích metod. Další nevýhodou je fakt, že výsledný kód generovaný těmito prostředky nemusí být dostatečně efektivní. Perspektivní metody vývoje software by mohli spočívat ve využití CASE nástrojů ve spojení s modelem skládání komponent Nástroje analýzy systému Stěžejní část analýzy systému je založena na tvorbě modelů systému. Důvodem modelování je fakt, že nejsme schopni plně pochopit komplexní systém jako celek. Cílem modelování je porozumět problému, komunikovat prostřednictvím modelů se zadavateli a uživateli. Modely umožní odhalit řadu chyb a opomenutí, simulují složité situace, umožní plánovat návrh a generovat kód. Modely odstraňují možnou jazykovou bariéru a umožňují vidění problému všemi zainteresovanými stranami ze stejného pohledu. V první fázi se modeluje stávající systém, poté následuje tvorba modelu systému požadovaného. Vždy lze na systém pohlížet několika způsoby. Vnikají tak různé pohledy na systém a tedy i různé modely systému. Model by měl hovořit slovníkem uživatele modelu, oddělovat podstatné od podružného a oddělovat koncept a implementaci. 11

16 Diagramy datových toků Nazývány též procesní modely, diagramy toků práce, funkční modely, bublinové diagramy, ale nejčastěji diagramy datových toků, DFD (Data Flow Diagrams). Představují síťovou reprezentaci systému. Reálné systémy jsou většinou natolik rozsáhlé, že je nelze popsat jediným diagramem. Proto se používá stromová struktura, v jejímž kořeni je tzv. kontextový diagram. Existuje několik druhů notací, přičemž jedna z nepoužívanějších je součástí metody SSADM (viz. kapitola ). Modely vnějšího chování Tyto modely mohou být reprezentovány např. výše zmíněným kontextovým diagramem, dále potom seznamem událostí, které působí na systém z jeho okolí. Datové modely Datové modely, tzv. E-R diagramy jsou jádrem analýzy při návrhu databázových systémů. Datové modelování se uplatňuje zejména u informačních systémů, neboť tyto systémy pracují z rozsáhlým množstvím dat. Modelují objekty v systému a vztahy mezi nimi pomocí tabulek. Obrázek 2.2 znázorňuje logický model vztahu mezi uživatelem a skupinou uživatelů v příkladu informačního systému. Jeden uživatel může být v několika skupinách uživatelů a současně jedna skupina uživatelů může sdružovat několik uživatelů. kardinalita uživatel N (1,N) je ve skupině M (1,M) skupina uživatelů id uživatele jméno uživatele parcialita id skupiny jméno skupiny primární klíč primární klíč Obrázek 2.2: Příklad logického modelu části databáze. 12

17 2.3.3 Metody návrhu systému Obecně rozeznáváme dva možné přístupy k návrhu systému Přístup zdola nahoru je založen na generalizaci. Začíná identifikací a analýzou několika jednoduchých struktur. Snaží se najít jejich společné charakteristiky a chování a zobecnit je tak, aby původní byly jejich speciálními případy. Typickým příkladem, kde je tento přístup aplikován, je objektově orientovaná analýza. Vychází z objektově orientovaného programování. Pohlíží na svět jako na soustavu spolupracujících objektů. Tento přístup je poměrně blízký lidskému chápání a přináší kvalitativní změnu myšlení při návrhu systémů. Výhodou je možnost rychlého paralelního vývoje prototypového softwaru. Nevýhodou je nedostatek ověřených metodických postupů a hlubší zkušenosti s rozsáhlými systémy. Konkrétní metodou využívající přístup k návrhu systému zdola nahoru je UML (Unified Modeling Language), který je popsán v kapitole Přístup shora dolů je založen naopak na specializaci. Začíná na úrovni komplexního systému, který postupně dekomponuje na subsystémy. Ty jsou dále dekomponovány až na úroveň, kdy je možná implementace. Analytický proces je zobrazitelný stromovou strukturou s originálním systémem v kořeni. Typickým příkladem tohoto postupu je strukturovaná analýza. Je metodicky velmi dobře zvládnuta. Její nevýhodou je absence možnosti ukončit předčasně analýzu a implementovat konkrétní část systému. Konkrétní metodou využívající k návrhu systému metodu přístup shora dolů je SSADM (Structured Systems Analysis and Design Method), která je popsána v kapitole UML UML (Unified Modeling Language) je standardizovaným jazykem pro specifikaci, vizualizaci, konstrukci a dokumentování systémů, nejen softwarových. Jeho použití zefektivňuje softwarový proces na základě standardní notace zejména použitím přehledných a snadno pochopitelných diagramů a schémat, čímž snadno překonává sémantickou mezeru mezi vnímáním skutečností uživateli a řešiteli systému. Dále pak slouží ke zlepšení a zpřesnění komunikace mezi členy vývojového týmu (analytici, vývojáři, testeři, vedoucí pracovníci apod.). Jeho výhodou je podpora celého vývojového cyklu software. UML poskytuje pravidla pro pojmenování, rozsah platnosti, rozsah viditelnosti, integritní omezení a provedení modelu. 13

18 Základní principy UML lze nastínit následujícími body: na každý složitý problém je vhodné nahlížet z více úhlů pohledu každý model může být vyjádřen s různou přesností nejlepší modely jsou spojeny s realitou. Prvky modelů Rozlišujeme prvky struktury, prvky chování a prvky skládání. Prvky struktury tvoří třídy, rozhraní, spolupráce, případy užití, aktivní třída, komponenta, uzel. Prvky chování jsou interakce a stavový diagram. Prvky skládání jsou package a subsystém. Dalším možným prvkem je poznámka. Vztahy mezi prvky jsou popsány závislostmi, asociacemi, dědičností nebo realizací. Způsoby rozšiřování modelů Jedním ze způsobů rozšiřování modelů jsou stereotypy. Stereotyp je šablona určitého typu prvku či vlastnosti. Význam stereotypu definuje autor modelu. Stereotyp se zapisuje mezi závorky << a >>. Stereotypovaný prvek může mít vlastní grafickou reprezentaci. Dalšími způsoby rozšíření modelu jsou přidané atributy, což jsou textové informace přidané k jednotlivým prvkům modelu. Někdy je nutné rozšířit vazby v modelu o určitá omezení. Omezení je přídavná informace upřesňující danou vazbu. Zapisuje se do složených závorek. Lze ji psát přirozeným jazykem, ale existuje také formální jazyk, označovaný OCL (Object Constraint Language), sloužící k zápisu omezení k prvkům objektově orientovaného modelu. Na základě takto vyjádřených omezení lze testovat konzistenci modelu. UML definuje následujících devět typů diagramů, popisující různé pohledy na model systému [6]. Případy užití, tzv. Use Case diagramy Diagramy tříd Diagramy objektů Diagramy komponent Diagramy rozmístění 14

19 Sekvenční diagramy Diagramy spolupráce Stavové diagramy Diagramy aktivit Prvních pět typů diagramů modeluje statický pohled na systém, zbývající představují pohled dynamický. Diagramy musí být sémanticky konzistentní s dalšími pohledy na systém Případy užití Případy užití (Use Cases) zachycují funkce, které systém poskytuje svému okolí a definují využití těchto funkcí. Umožňují zadavateli projektu ověřit, zda systém modelovaný pomocí případů užití splňuje představu o funkcionalitě. Zvyšují porozumění systému a určují jeho rozhraní. Slouží jako základ uživatelské dokumentace a různých testů. Případ užití je popsán dokumentem, který obsahuje jméno, stručný popis, tok událostí (základní, alternativní), speciální požadavky, podmínky před a po případu užití, způsoby rozšíření a vizualizace formou diagramů. Diagramy případu užití jsou tvořeny následujícími UML prvky: případy užití jsou ovály, zachycující funkčnosti systému aktéři jsou schematické postavičky, znázorňující aktéry, kteří pracují se systémem (vstupují do něj, používají ho) asociace jsou čáry, představující vazby mezi aktéry a případy užití vztahy jsou čáry opatřené šipkou, určující vazby mezi jednotlivými případy užití. Každý případ užití představuje určitou funkcionalitu systému, která dává měřitelnou hodnotu uživatelům tohoto systému. Aktéři představují určité zachycení okolí systému. Představují prvky aktivně komunikující se systémem. Aktéry mohou být buď uživatelé, či spíše uživatelské role nebo jiné softwarové systémy. Aktér je stereotypem třídy, je to tedy třída. Pomocí Asociace komunikuje aktér se systémem, vyvolává a účastní se případů užití. U diagramů případů užití obvykle nemají asociace přiřazené jméno. 15

20 Vztahy mezi případy užití umožňují případům užití vzájemnou spolupráci. Jsou definovány dva typy vztahů include a extend. Jsou rozlišeny pomocí tzv. stereotypů, v tomto případě se jedná o stereotyp závislosti. Vazba typu include definuje, že případ užití A musí povinně vykonávat to, co případ užití B, případně něco navíc. Vazba extend znamená, že případ užití A rozšiřuje chování B. B může tedy za určitých okolností provádět funkčnost A. V diagramech případů užití lze zavést vazbu dědičnosti. Jedná se o tzv. generalizaci, která je definována mezi rodičem a potomky. Generalizace mezi dvěma případy užití se využívá v případě, že jeden případ užití je podobný druhému, přičemž se liší v malých částech, nikoliv zanedbatelných. Specifikace rodiče je základem specifikace potomků, tedy obsahuje základní kostru použitou ve všech potomcích. Specifikace potomků upřesňují popis rodiče (každý potomek má jinou funkčnost) Diagramy tříd Diagramy tříd zachycují slovník systému. Třída je zapouzdřením určitých informací a chování. Informace budeme označovat jako atributy třídy a chování jako metody třídy. Atributy třídy představují informace, které instance třídy (objekty) uchovávají. Metody třídy jsou operace, za které je třída zodpovědná, nebo také zprávy, kterým rozumí. Zdrojem atributů třídy jsou věcné znalosti o dané problematice a analýza podrobných požadavků uživatelů. Atributy třídy by měli být atomické, tedy dále nedělitelné, což částečně odpovídá první normální formě E-R modelu. Pokud by měl být atribut strukturovaný, lze ho nahradit vlastní třídou a asociací. Zdrojem pro hledání operací jsou především scénáře analýzy případů užití. Vytváří se model, který zatím nenavrhuje software, ale zjišťuje, co budoucí software musí umět. Mezi třídami mohou existovat různé vztahy. Sdílení informací mezi třídami lze dosáhnout pomocí asociace a agregace. Komunikaci mezi třídami lze zajistit pomocí asociace, agregace a závislostí. Hierarchii tříd lze vybudovat pomocí vazeb asociace, agregace, dědičnosti a realizace interface. Asociace je slabá vazba mezi třídami. Říká to, že dvě třídy mají mezi sebou vztah, tedy o sobě vědí. Není-li uvedeno jinak, je tato vazba obousměrná. Asociace může mít své jméno, které většinou dává smysl při čtení jedním směrem. Kreslí se plnou čarou spojující příslušné objekty. 16

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

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

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

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

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

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

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

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

Využití SysML pro tvorbu modelů v systémovém inženýrství

Využití SysML pro tvorbu modelů v systémovém inženýrství Využití SysML pro tvorbu modelů v systémovém inženýrství Antonín Srna, Ústav informatiky, Provozně ekonomická fakulta, Mendelova univerzita v Brně, xsrna2@mendelu.cz Abstrakt Článek se zaobírá univerzálním

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

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

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

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

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

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

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

Vývojové diagramy 1/7

Vývojové diagramy 1/7 Vývojové diagramy 1/7 2 Vývojové diagramy Vývojový diagram je symbolický algoritmický jazyk, který se používá pro názorné zobrazení algoritmu zpracování informací a případnou stručnou publikaci programů.

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

Ú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

S M Ě R N I C E č. 6/2014 ministra financí ------------------------------------------------------------------------

S M Ě R N I C E č. 6/2014 ministra financí ------------------------------------------------------------------------ MINISTERSTVO FINANCÍ Praha 1, Letenská 15 V Praze dne 12. prosince 2014 Č.j.: MF 69 949/2014/4703-2 S M Ě R N I C E č. 6/2014 ministra financí ------------------------------------------------------------------------

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

InternetovéTechnologie

InternetovéTechnologie 8 InternetovéTechnologie webdesign, mobile first Ing. Michal Radecký, Ph.D. www.cs.vsb.cz/radecky Webové stránky a aplikace - Webové stránky - množina vzájemně propojených stránek, které obsahují informace

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

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

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

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

Vzdělávací oblast: Informatika a informační a komunikační technologie Vzdělávací obor: Programování. Předmět: Programování

Vzdělávací oblast: Informatika a informační a komunikační technologie Vzdělávací obor: Programování. Předmět: Programování Vzdělávací oblast: Informatika a informační a komunikační technologie Vzdělávací obor: Programování Vzdělávací oblast Informatika a informační a komunikační technologie pro vzdělávací obor Programování

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

Maturitní témata Školní rok: 2015/2016

Maturitní témata Školní rok: 2015/2016 Maturitní témata Školní rok: 2015/2016 Ředitel školy: Předmětová komise: Předseda předmětové komise: Předmět: PhDr. Karel Goš Informatika a výpočetní technika Mgr. Ivan Studnička Informatika a výpočetní

Více

Projekt Metodika přípravy veřejných strategií. Akční plán aktivit v oblasti strategické práce na rok 2013

Projekt Metodika přípravy veřejných strategií. Akční plán aktivit v oblasti strategické práce na rok 2013 Projekt Metodika přípravy veřejných strategií Akční plán aktivit v oblasti strategické práce na rok 2013 Listopad 2012 Obsah Obsah... 2 1. Kontext vzniku akčního plánu... 3 2. Přehled aktivit... 4 3. Akč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

Aplikační Dokumentace Standardy ICT MPSV

Aplikační Dokumentace Standardy ICT MPSV Standardy ICT MPSV Datum: 19.12.2014 Informace o dokumentu Název dokumentu: Aplikační Dokumentace Historie verzí Číslo verze Datum verze Vypracoval Popis Jméno souboru 1.0 31.8.2012 Jan Apfelthaler Doplnění

Více

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE Václav Šebesta Ústav informatiky Akademie věd ČR, e-mail: vasek@cs.cas.cz Abstrakt Jestliže ještě před

Více

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI Cyril Klimeš a) Jan Melzer b) a) Ostravská univerzita, katedra informatiky a počítačů, 30. dubna 22, 701 03 Ostrava, ČR E-mail: cyril.klimes@osu.cz b) DC Concept

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

Zátěžové testy aplikací

Zátěžové testy aplikací Zátěžové testy aplikací Obsah Zátěžové testy v životním cyklu vývoje software Kdy a proč provádět zátěžové testy Projekt zátěžového testu Fáze zátěžového testu Software pro zátěžové testy Zátěžové testy

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

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

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

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka Metody tvorby ontologií a sémantický web Martin Malčík, Rostislav Miarka Obsah Reprezentace znalostí Ontologie a sémantický web Tvorba ontologií Hierarchie znalostí (D.R.Tobin) Data jakékoliv znakové řetězce

Více

Analýza. Pracovní postup Analýza

Analýza. Pracovní postup Analýza Otázka 4 - Analýza - hledání analytických tříd, hledání atributů a stavů, analýza chování a odpovídající diagramy v UML. (A7B36SIN) Analýza Pracovní postup Analýza Analýza v metodice UP zahrnuje architektonickou

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

Databáze Bc. Veronika Tomsová

Databáze Bc. Veronika Tomsová Databáze Bc. Veronika Tomsová Databázové schéma Mapování konceptuálního modelu do (relačního) databázového schématu. 2/21 Fyzické ik schéma databáze Určuje č jakým způsobem ů jsou data v databázi ukládána

Více

Základní informace. Modelování. Notace

Základní informace. Modelování. Notace Základní informace BPMS = business process management systems - systémy pro modelování a optimalizace business procesů uvnitř organizace BPMN = business process modeling notation - součást BPMS, notace

Více

Obsah ČÁST I JAK SE UCHÁZET O ZÁKAZNÍKY NA WEBU KAPITOLA 1

Obsah ČÁST I JAK SE UCHÁZET O ZÁKAZNÍKY NA WEBU KAPITOLA 1 Obsah O autorech 11 Poděkování 13 Předmluva 15 Úvod 17 Proč byste se měli přečíst tuto knihu 17 Co tato kniha obsahuje 18 Jak používat tuto knihu 19 Zpětná vazba od čtenářů 20 Errata 20 ČÁST I JAK SE UCHÁZET

Více

WEBOVÉ SYSTÉMY PORADENSKÝCH SLUŽEB WEB-BASED ADVISORY SERVICE SYSTEMS. Milan Mišovič, Jana Andrýsková

WEBOVÉ SYSTÉMY PORADENSKÝCH SLUŽEB WEB-BASED ADVISORY SERVICE SYSTEMS. Milan Mišovič, Jana Andrýsková WEBOVÉ SYSTÉMY PORADENSKÝCH SLUŽEB WEB-BASED ADVISORY SERVICE SYSTEMS Milan Mišovič, Jana Andrýsková Anotace: Poradenská služba je zákaznicky orientovaný proces, pro který je na bázi současných webových

Více

Aplikační standard - Dokumentace ICT Standardy MPSV MPSV

Aplikační standard - Dokumentace ICT Standardy MPSV MPSV ICT Standardy MPSV MPSV Vedoucí projektu Objednatele: Milan Hojer Vedoucí projektu Zhotovitele: Michal Čanda HEWLETT-PACKARD s.r.o. Vyskočilova 1/1410 140 21 Praha 4 Tel: 261 307 111 Datum: 7.10.2012 Informace

Více

Zpráva o zhotoveném plnění

Zpráva o zhotoveném plnění Zpráva o zhotoveném plnění Aplikace byla vytvořena v souladu se Smlouvou a na základě průběžných konzultací s pověřenými pracovníky referátu Manuscriptorium. Toto je zpráva o zhotoveném plnění. Autor:

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

46 Objekty a atributy

46 Objekty a atributy 46 Objekty a atributy Modul Objekty a atributy je určen pro pokročilé uživatele zodpovědné za mapování přístupnosti architektonických bariér. Modul umožňuje stanovit jaké objekty budou mapovány, jaké skutečnosti

Více

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY 29 HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY POKORNÝ Karel Abstrakt: Metoda Balanced Scorecard (BSC) její podstata, obsah a principy. Vztah BSC ke strategickému a operativnímu řízení

Více

Analýza a návrh webových aplikací 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

Analýza a návrh webových aplikací 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 Analýza a návrh webových aplikací 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 dnešní přednášky Proč tento předmět vlastně existuje? Proč nestačí standardní metodiky SI? Co standardním

Více

Projekt: Koordinační centrum pro zavádění e-gov v územní veřejné správě. Koncepční dokument pro oblast řízení. Procesní model

Projekt: Koordinační centrum pro zavádění e-gov v územní veřejné správě. Koncepční dokument pro oblast řízení. Procesní model Koncepční dokument pro oblast řízení a koordinaci e-gov: Procesní model 18. 09. 2013 OBSAH Obsah... 2 Seznam zkratek... 3 Použité pojmy... 4 1 Úvodní informace... 6 2 Procesní model: životní cyklus e-gov...

Více

Jazyk UML VST (Velmi stručný tutorial) verze 1.0

Jazyk UML VST (Velmi stručný tutorial) verze 1.0 Jazyk UML VST (Velmi stručný tutorial) verze 1.0 Softwarové inženýrství školní rok 2004 2005 Ing. Ladislava Smítková Janků (Praha, 24.5.2005) Obsah Obsah Obsah...2 1 Co je to UML...3 2 Diagram případů

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

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

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

UML: Unified Modeling Language

UML: Unified Modeling Language UML 1 UML: Unified Modeling Language Systém kombinace softwaru, hardwaru, dat a uživatelů, která umožňuje řešení konkrétního problému Vývoj systémů vytváření systémů pro klienta Vývoj probíhá na základě

Více

1. Stavební management

1. Stavební management 1. Stavební management Klíčová slova: Management, podstata managementu, organizační uspořádání podniku, organizační struktura, rozhodování, osobnost manažera, projektové a procesní řízení. Anotace textu:

Více

ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH

ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH 3. část RNDr. Ilja Kraval, srpen 2009 http://www.objects.cz ÚVOD Tento článek je pokračováním předešlých článků. Článek vysvětluje použití vztahu

Více

Případy užití (use case) Projektování SW systémů

Případy užití (use case) Projektování SW systémů Univerzita Pardubice Fakulta elektrotechniky a informatiky Případy užití (use case) Projektování SW systémů Matěj Trakal Poslední úprava: 24. ledna 2012, 17:06 INPSW 2011 (Šimerda) OBSAH Obsah 1 Co jsou

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

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

1. Úvod do Ajaxu 11. Jak Ajax funguje? 13

1. Úvod do Ajaxu 11. Jak Ajax funguje? 13 Obsah Úvodem 9 1. Úvod do Ajaxu 11 Jak Ajax funguje? 13 Popis 13 Ukázky 13 Jaké jsou možnosti tvorby interaktivních webových aplikací? 15 Co je třeba znát? 16 Jak fungují technologie Ajaxu 16 Jak funguje

Více

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ ŽIVOTNÍ CYKLUS IS Stejně jako stroje a technologické linky, které jsou pořízeny, provozovány a následně, po opotřebování vyřazeny, má i informační systém svůj

Více

Struktura e-learningových výukových programù a možnosti jejího využití

Struktura e-learningových výukových programù a možnosti jejího využití Struktura e-learningových výukových programù a možnosti jejího využití Jana Šarmanová Klíčová slova: e-learning, programovaná výuka, režimy učení Abstrakt: Autorská tvorba výukových studijních opor je

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

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

Západočeská univerzita FAKULTA APLIKOVANÝCH VĚD

Západočeská univerzita FAKULTA APLIKOVANÝCH VĚD Západočeská univerzita FAKULTA APLIKOVANÝCH VĚD Okruhy otázek ke státní závěrečné zkoušce z předmětu Databázové technologie (DB) Databázové systémy 1(DB1) Databázové systémy 2 (DB2) Případové studie databázových

Více

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko Obsah Kvalita SW, jak zajistit kvalitu SW a jak ji ověřit Zabezpečení kvality, techniky řízení kvality SW. Potřeba kultivovat kvalitu, Cena za jakost Procesy pro řízení kvality, harmonogram řízení kvality

Více

Program a životní cyklus programu

Program a životní cyklus programu Program a životní cyklus programu Program algoritmus zapsaný formálně, srozumitelně pro počítač program se skládá z elementárních kroků Elementární kroky mohou být: instrukce operačního kódu počítače příkazy

Více

Základy databází. O autorech 17 PRVNÍ ČÁST. KAPITOLA 1 Začínáme 19

Základy databází. O autorech 17 PRVNÍ ČÁST. KAPITOLA 1 Začínáme 19 3 Obsah Novinky v tomto vydání 10 Význam základních principů 11 Výuka principů nezávisle na databázových produktech 12 Klíčové pojmy, kontrolní otázky, cvičení, případové studie a projekty 12 Software,

Více

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta. Začínáme s BPM. Učební pomůcka. Vypracoval: Ing.

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta. Začínáme s BPM. Učební pomůcka. Vypracoval: Ing. Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta Začínáme s BPM Učební pomůcka Vypracoval: Ing. Michael Štencl Brno 2007 OBSAH 2 Obsah 1 Jak přistupovat k BPM 3 2 Prvky BPM

Více

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV Manažerský informační systém na MPSV Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV Konference ISSS-2009 Hradec Králové Aldis 6. dubna 2009 MIS na MPSV časové údaje projektu Vytvoření MIS MPSV

Více

WAK System. Ministerstvo dopravy ČR WAK System, spol. s r.o. Petržílkova 2564/21, 158 00 Praha 5 - Stodůlky

WAK System. Ministerstvo dopravy ČR WAK System, spol. s r.o. Petržílkova 2564/21, 158 00 Praha 5 - Stodůlky WAK System Název projektu: Systém automatizované kontroly a detekce změn bezpečnostního nastavení informačních systémů založený na specifikaci bezpečnostní politiky podle standardu BS7799 Číslo projektu:

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 materiálem o normě ICS 55.180.01; 35.240.60; 03.220.20 Inteligentní dopravní systémy (ITS) Elektronická

Více

GIS Libereckého kraje

GIS Libereckého kraje Funkční rámec Zpracoval: Odbor informatiky květen 2004 Obsah 1. ÚVOD...3 1.1. Vztah GIS a IS... 3 2. ANALÝZA SOUČASNÉHO STAVU...3 2.1. Technické zázemí... 3 2.2. Personální zázemí... 3 2.3. Datová základna...

Více

Příklad dobré praxe VII

Příklad dobré praxe VII Projekt Další vzdělávání pedagogických pracovníků středních škol v oblasti kariérového poradenství CZ 1.07/1.3.00/08.0181 Příklad dobré praxe VII pro průřezové téma Člověk a svět práce Mgr. Miroslav Široký

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 materiálem o normě ICS 03.220.01;35.240.60 Inteligentní dopravní systémy (ITS) Rozšíření specifikací mapové

Více

Bezpečnostní politika společnosti synlab czech s.r.o.

Bezpečnostní politika společnosti synlab czech s.r.o. Bezpečnostní politika společnosti synlab czech s.r.o. Platnost dokumentu: 14. ledna 2015 Datum vypracování: 8. ledna 2015 Datum schválení: 13. ledna 2015 Vypracoval: Schválil: Bc. Adéla Wosková, Ing. Jaroslav

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

Informační systém sportovního klubu

Informační systém sportovního klubu Mendelova univerzita v Brně Provozně ekonomická fakulta Informační systém sportovního klubu Informační systémy projektování Vypracovali: Jiří Adolf Vlastimil Knápek Jakub Kočí Jiří Krampol Petr Ondrejka

Více

Úvod. Boj se zavlečeným impedančním nesouladem na úrovni databáze

Úvod. Boj se zavlečeným impedančním nesouladem na úrovni databáze Boj se zavlečeným impedančním nesouladem na úrovni databáze ABSTRACT: Impedanční nesoulad může být zmírněn správnou volbou databázové technologie. Článek vysvětluje, co to impedanční nesoulad je a uvádí

Více

Řízení reálných projektů, agilní metodiky

Řízení reálných projektů, agilní metodiky Agent Technology Group Katedra kybernetiky Fakulta elektrotechnická - České vysoké učení technické Praha, 2009 Osnova Lze vyvíjet software bez metodiky? - bohužel ano menší komerční firmy (zejména vývoj

Více

9. Může dojít k situaci, že ZP je nutno aktualizovat (změna vzhledu, změna příjmení, změna -1- dále ZP).

9. Může dojít k situaci, že ZP je nutno aktualizovat (změna vzhledu, změna příjmení, změna -1- dále ZP). 1 Popis ucelené problémové domény Následující komplexní příklad se týká domény soukromých zbraní v ČR (SSZ v ČR) Ukážeme nejdříve její obecný popis, ale nebudeme se přísně držet současně platného zákona

Více

Microsoft Access tvorba databáze jednoduše

Microsoft Access tvorba databáze jednoduše Microsoft Access tvorba databáze jednoduše Časový rozsah: 2 dny (9:00-16:00) Cena: 3300 Kč + DPH Úvod do relačních databází. Funkce databázových objektů Microsoft Access. Návrh tabulek, definice základních

Více

Řízení procesů ICT prostřednictvím Architektury

Řízení procesů ICT prostřednictvím Architektury Petr Klučka Solution architect / ARKO 03/06 2 0 1 5 Řízení procesů ICT prostřednictvím Architektury prezentace pro Krajský úřad Plzeňského kraje Agenda souvislosti o nichž bude řeč Strategie Soubor souvisejících

Více

1. Programování proti rozhraní

1. Programování proti rozhraní 1. Programování proti rozhraní Cíl látky Cílem tohoto bloku je seznámení se s jednou z nejdůležitější programátorskou technikou v objektově orientovaném programování. Tou technikou je využívaní rozhraní

Více

Balíček vzorové dokumentace pro projektové manažery ve školství v rámci projektu PM 250+

Balíček vzorové dokumentace pro projektové manažery ve školství v rámci projektu PM 250+ Balíček vzorové dokumentace pro projektové manažery ve školství v rámci projektu PM 250+ Co je Balíček a k čemu slouží Jedná se o sadu 23 formulářů pro podporu řízení projektů ve školách a školských zařízeních.

Více

ŠVP Gymnázium Ostrava-Zábřeh. 4.8.16. Úvod do programování

ŠVP Gymnázium Ostrava-Zábřeh. 4.8.16. Úvod do programování 4.8.16. Úvod do programování Vyučovací předmět Úvod do programování je na naší škole nabízen v rámci volitelných předmětů v sextě, septimě nebo v oktávě jako jednoletý dvouhodinový kurz. V případě hlubšího

Více

MS Project jako nástroj pro analýzu spolehlivosti

MS Project jako nástroj pro analýzu spolehlivosti MS Project jako nástroj pro analýzu spolehlivosti Petr Kolář 1. Představení aplikace MS Project Manažeři, kteří koordinují plánování, průběh a hodnocení libovolných projektů, jsou nuceni pracovat s velkým

Více

ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ

ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ ROZDÍLY V NÁVRZÍCH RELAČNÍCH A OBJEKTOVÝCH DATABÁZÍ A JEJICH DŮSLEDKY PRO TRANSFORMACI MODELŮ RELATIONAL AND OBJECT DATABASES DESIGN DIFFERENCES AND IT S IMPLICATIONS TO MODEL TRANSFORMATION Vít Holub

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Personální audit. Audit informačního systému. Audit SW a HW

Personální audit. Audit informačního systému. Audit SW a HW Personální audit Audit informačního systému Audit SW a HW Jméno: UČO: forma studia: ročník: 2014 Brno Úvodní zpráva Konkretizujte předmět auditovaní. Identifikace objektu pozorování. Účel auditu. Stanovené

Více

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. 2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových

Více

PORTÁL STÁTNÍ ROSTLINOLÉKAŘSKÉ SPRÁVY VE SLUŽBÁCH

PORTÁL STÁTNÍ ROSTLINOLÉKAŘSKÉ SPRÁVY VE SLUŽBÁCH PORTÁL STÁTNÍ ROSTLINOLÉKAŘSKÉ SPRÁVY VE SLUŽBÁCH VEŘEJNOSTI I ZAMĚSTNANCŮ O zákazníkovi Státní rostlinolékařská správa (SRS) je úředním orgánem rostlinolékařské péče České republiky. Činnost Státní rostlinolékařské

Více

Aplikace pro srovna ní cen povinne ho ruc ení

Aplikace pro srovna ní cen povinne ho ruc ení Aplikace pro srovna ní cen povinne ho ruc ení Ukázkový přiklad mikroaplikace systému Formcrates 2010 Naucrates s.r.o. Veškerá práva vyhrazena. Vyskočilova 741/3, 140 00 Praha 4 Czech Republic tel.: +420

Více

Unified Communications. Customer Contact. Cisco Unified Contact Center Enterprise. Hlavní výhody. Způsoby nasazení

Unified Communications. Customer Contact. Cisco Unified Contact Center Enterprise. Hlavní výhody. Způsoby nasazení Unified Communications Customer Contact Cisco Unified Contact Center Enterprise Cisco Unified Contact Center Enterprise přináší ucelené řešení poskytující inteligentní směrování a obsloužení hovorů. Jedná

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