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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Obsah 10.2.2000. 2.1 Charakteristiky software... 2 2.2 Programování ve velkém... 3

Obsah 10.2.2000. 2.1 Charakteristiky software... 2 2.2 Programování ve velkém... 3 Softwarové inženýrství (státnicová otázka 2 8) Ladislav Dobiáš 10.2.2000 Obsah 1 Zadání 2 2 Základní pojmy 2 2.1 Charakteristiky software................................ 2 2.2 Programování ve velkém................................

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

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

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

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

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

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

RDF DSPS ROZVOJ PORTÁLU

RDF DSPS ROZVOJ PORTÁLU RDF DSPS ROZVOJ PORTÁLU ČEZ Distribuce, a.s. HSI, spol. s r.o. Zbyněk Businský Miroslav Kaňka ZÁKAZNÍK A DODAVATEL ČEZ DISTRIBUCE, A.S. ČEZ distribuční síť Od r. 2012 implementován GEOPORTÁL (1. ETAPA),

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

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

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

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu VÝUKOVÝ MATERIÁL Identifikační údaje školy Vyšší odborná škola a Střední škola, Varnsdorf, příspěvková organizace Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632

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

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

Ú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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Infrastruktura UML. Modelování struktury v UML. Superstruktura UML. Notace objektů. Diagramy objektů

Infrastruktura UML. Modelování struktury v UML. Superstruktura UML. Notace objektů. Diagramy objektů Infrastruktura UML v UML Karel Richta listopad 2011 Richta: B101TMM - v UML 2 Superstruktura UML Směr pohledu na systém dle UML Diagramy popisující strukturu diagramy tříd, objektů, kompozitní struktury,

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

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

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

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

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

14 Úvod do plánování projektu Řízení projektu

14 Úvod do plánování projektu Řízení projektu 14 Úvod do plánování projektu Řízení projektu Plánování projektu Vývoj - rozbor zadání odhad pracnosti, doby řešení, nákladů,... analýza rizik strategie řešení organizace týmu PLÁN PROJEKTU 14.1 Softwarové

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

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

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT)

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta projektu rozpracována do

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 Komunikační infrastruktura pro pozemní ISO 24101-2 mobilní

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ápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ

Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ 10. 5. 2011 Tým: Simplesoft Členové: Zdeněk Malík Jan Rada Ladislav Račák Václav Král Marta Pechová malikz@students.zcu.cz jrada1@students.zcu.cz

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

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

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

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

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

RELAČNÍ DATABÁZOVÉ SYSTÉMY

RELAČNÍ DATABÁZOVÉ SYSTÉMY RELAČNÍ DATABÁZOVÉ SYSTÉMY VÝPIS KONTROLNÍCH OTÁZEK S ODPOVĚDMI: Základní pojmy databázové technologie: 1. Uveďte základní aspekty pro vymezení jednotlivých přístupů ke zpracování hromadných dat: Pro vymezení

Více

PRODUKTY. Tovek Tools

PRODUKTY. Tovek Tools jsou desktopovou aplikací určenou k vyhledávání informací, tvorbě různých typů analýz a vytváření přehledů a rešerší. Jsou vhodné pro práci i s velkým objemem textových dat z různorodých informačních zdrojů.

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

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

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

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

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

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

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

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

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

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

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

11 Diagram tříd, asociace, dědičnost, abstraktní třídy

11 Diagram tříd, asociace, dědičnost, abstraktní třídy 11 Diagram tříd, asociace, dědičnost, abstraktní třídy 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 diagramům tříd, asociaci,

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

Kolaborativní aplikace

Kolaborativní aplikace Kolaborativní aplikace Michal Máčel Vema, a. s. Okružní 3a, 638 00 Brno - Lesná, macel@vema.cz Tomáš Hruška Fakulta informačních technologií Vysokého učení technického v Brně, Ústav informačních systémů,

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

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

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

Architektury počítačů a procesorů

Architektury počítačů a procesorů Kapitola 3 Architektury počítačů a procesorů 3.1 Von Neumannova (a harvardská) architektura Von Neumann 1. počítač se skládá z funkčních jednotek - paměť, řadič, aritmetická jednotka, vstupní a výstupní

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním 35.240.60 materiálem o normě. Komunikační infrastruktura pro pozemní mobilní zařízení (CALM) Architektura

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

PowerOPTI Řízení účinnosti tepelného cyklu

PowerOPTI Řízení účinnosti tepelného cyklu PowerOPTI Řízení účinnosti tepelného cyklu VIZE Zvýšit konkurenceschopnost provozovatelů elektráren a tepláren. Základní funkce: Spolehlivé hodnocení a řízení účinnosti tepelného cyklu, včasná diagnostika

Více

Informace a znalosti v organizaci

Informace a znalosti v organizaci Informace a znalosti v organizaci Vladimíra Zádová Postavení informací a znalostí z hlediska úspěšnosti firmy Vnitřní faktory Rámec 7S faktorů úspěchu firmy [ Mc Kinsey ] Struktura Strategie Systémy Spolupracovníci

Více

S T R A T E G I C K Ý M A N A G E M E N T

S T R A T E G I C K Ý M A N A G E M E N T S T R A T E G I C K Ý M A N A G E M E N T 3 LS, akad.rok 2014/2015 Strategický management - VŽ 1 Proces strategického managementu LS, akad.rok 2014/2015 Strategický management - VŽ 2 Strategický management

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

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

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

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

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

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

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