SOFTWAROVÉ INŽENÝRSTVÍ

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

Download "SOFTWAROVÉ INŽENÝRSTVÍ"

Transkript

1 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky SOFTWAROVÉ INŽENÝRSTVÍ ČÁST II. ARCHITEKTURY SOFTWARE STUDIJNÍ TEXT PRO KOMBINOVANOU FORMU STUDIA Milan Mišovič 2011

2 Prof. RNDr. Milan Mišovič, CSc. SOFTWAROVÉ INŽENÝRSTVÍ 1. vydání Vydala Vysoká škola polytechnická Jihlava, Tolstého 16, Jihlava, 2011 Tisk Ediční oddělení VŠPJ, Tolstého 16, Jihlava Za jazykovou a věcnou správnost obsahu díla odpovídá autor. Text neprošel jazykovou ani redakční úpravou. Milan Mišovič, 2011

3 Obsah Část II. Architektura software 1 Úvod Pojetí architektury v malém a velkém.chyba! Záložka není definována. 2.1 Historie pojmu Architektura IS... Chyba! Záložka není definována. 2.2 Vzory architektury... Chyba! Záložka není definována. 2.3 Pojetí architektury v komponentách... Chyba! Záložka není definována. 3 Architektura založená na vrstváchchyba! Záložka není definována. 4 Architektura založená na úrovníchchyba! Záložka není definována. 5 Modulární architektura... Chyba! Záložka není definována. 5.1 Axiomy modulární architektury... Chyba! Záložka není definována. 5.2 Koncepce řídících vazeb v modulárním systémuchyba! Záložka není definována. 5.3 Některá reálná pojetí Modulární architektury... Chyba! Záložka není definována. 6 Jazyk UML a architektura rozsáhlého softwarechyba! Záložka není definována. 7 Architektura klient server... Chyba! Záložka není definována. 8 Distribuovaná objektová architekturachyba! Záložka není definována. 9 Distribuovaná architektura na komponentách.chyba! Záložka není definována. 9.1 Realizační modely komponentové architektury Chyba! Záložka není definována. 10 Servisně orientovaná architektura SOA.Chyba! Záložka není definována Podnikové služby... Chyba! Záložka není definována. 11 Pojetí logické architektury rozsáhlého softwarového systému Modelování logické architektury Proces tvorby logické architektury Úkol A: Průzkum prvků architektury Úkol B: Definice přehledu architektury Úkol C: Dokumentace rozhodnutí o architektuře Literatura... 14

4

5 Část II. Architektura software Učební cíle: Seznámit se 1. se všemi koncepcemi logické architektury software. 2. problematikou zabezpečení jednotlivých koncepcí logické architektury software. Znát 1. základy tvorby Logické architektury. 2. základy pojetí logické, návrhové a fyzické architektury, základy prvotního přístupu k logické architektuře. Umět, mít dovednosti 1. SKUTEČNĚ tvořit Schéma logické architektury pro cílový software problémových domén. 2. Vložit do Schématu Logické architektury potřebnou filosofii funkcionality cílového software. 1 Úvod Ačkoliv na první pohled se mnoho programátorů nezabývá problematikou architektury svých aplikací, přesto jimi vytvořené aplikace jistou architekturu mají, a jde jen o to, tento pojem precisněji definovat. Porozumění podstatě pojmu architektura dá možnost se k její tvorbě cílevědomě postavit a využívat možnosti, které pro software přináší. Architektura software není jen jeho pouhá struktura. Ano, je to sice členění na jisté architektonické jednotky, které je obrazem struktury, ale jde rovněž o vzájemný život těchto jednotek v softwarovém celku. To ovšem vyžaduje vytvoření jistých pravidel, platných pro všechny jednotky, z nichž je software složen: 1. Pravidla pro koncepci jednotek (složení jednotek). 2. Pravidla pro vzájemnou spolupráci jednotek (přechody a vstupní a výstupní interface pro spolupráci). 3. Pravidla pro konzistentnost jednotek (říkající, že dvě jednotky jsou zcela zaměnitelné v sestavě softwarového celku s danou architekturou). Je již alespoň trochu zřejmé, že architektura, postavená na poměrně inteligentních jednotkách, přinese softwarovému celku jisté výhody: 1. Vhodné rozčlenění celkové funkcionality software mezi jednotlivé jednotky, což umožní pečlivější a hlubší propracování dílčích aktivit a méně analytických a programátorských chyb. 2. Snadnější modifikaci funkcionality celku, protože víme kterou jednotku/-y máme modifikovat a kterou/-é ne. 3. Využití distribuce jednotlivých jednotek do operační paměti a jejich spouštění, jen tehdy, kdy jsou potřebné. Co ale úspěšné využití možností cílově budované architektury od programátora vyžaduje? Pečlivou analytickou práci s funkcionalitou software (požadavky na funkcionalitu). Návrh architektury prostřednictvím návrhu architektonických jednotek. Chápání života jednotek v celku ze systémového pohledu. Analytickou práci nad koncepcí a životem architektonických jednotek. Vytvoření jisté deskripce architektury, např. graficky, verbálně, -5-

6 Pochopitelně, velmi jednoduché aplikace je jistě možné oprostit od architektury. Na druhé straně u robustních aplikací, které již vyhovují pojetí rozsáhlých softwarových systémů, se architekturou již musíme pečlivě zabývat. Praxe ukazuje, že architekturou robustných aplikací se musíme zabývat počínaje zpracováním požadavků na funkcionalitu cílového software. Nejen že musíme stanovit mapování požadavků do architektonických jednotek, ale rovněž navrhnout spolupráci jednotek. Tyto analytické práce vedou k tzv. logické architektuře. Nic není naprogramováno, ale je již jistá vize jak to s architekturou robustné aplikace bude vypadat. Dokonce je možné tuto logickou architekturu naprogramovat a použít jako elektronický spustitelný základ pro tzv. návrhovou architekturu a rovněž pro závěr fyzickou (naprogramovanou) a nasazenou architekturu. Aby práce na tvorbě cílového software měla v produkční softwarové firmě jistý řád, často se problematikou funkcionality zabývá architekt požadavků a architekturou zase hlavní softwarový architekt. Více pochopení architektury přinese až vlastní uplatnění objektové metodiky UP (Unified Process), kde budou vysvětleny používané postupy, grafické notace a rozdíly mezi logickou, návrhovou a fyzickou architekturou (viz Část IV. Vývoj objektových aplikací podle metodiky UP). Dnes existují konkrétní vývojové systémy, pro které jsou všechna potřebná architektonická pravidla stanovena a v podpůrném vývojovém software-framework podporována. Často se u prvního přístupu k architektuře cílového software za architektonické jednotky považují podsystémy nebo moduly. Později se obojí zobecňuje zavedením komponenty. Použití podsystémů, nebo modulů vychází z prvního přístupu k architektuře cílového software pod vlivem relevantních vlastností komputerizované problémové domény. Objektové metodiky, které jsou dnes základem pro vývoj cílového software se k problematice architektur staví poměrně zodpovědně. Chápou architekturu teoretičtěji, než běžná praxe. Objektové metodiky chtějí respektovat řádnou gnoseoligii vývoje software a respektují současně poznané typy architektur: LOGICKÁ ARCHITEKTURA NÁVRHOVÁ ARCHITEKTURA FYZICKÁ ARCHITEKTURA ARCHITEKTURA IMPLEMENTAČNÍ, NASAZENÍ. Logická architektura dává programátorovi první postřehy, jak bude cílový software vypadat, zejména po stránce filosofie jeho funkcionality. Návrhová architektura již předkládá podobu cílového software, která je programovatelná. Fyzická architektura již náleží naprogramovanému cílovému software. Architektura implementační již ukazuje jak je cílový software, konstruovaný v souladu s Návrhovou a Fyzickou architekturou osazen na Informační infrastruktuře zákazníka (IIS). Nejblíže se budeme věnovat Logické architektuře. Ostatní architektury probereme v rámci objektové metodiky. Pro postup vývoje komponentové ho charakteru architektur máme Workflow, tj. pracovní postup. -6-

7 1 Pojetí logické architektury rozsáhlého softwarového systému metodická kapitola Cíle: Znát (umět vysvětlit): 1. Pojetí termínu architektura software. 2. Pojetí logické, návrhové a fyzické architektury software. 3. Proč je architektura software jednou z jeho relevantních charakteristik? 4. Přístup k modelování logické architektury podle publikace [EelCrip011]. Dovednosti (umět prakticky): 1. Realizovat prvotní přístup k logické architektuře na základě relevantních vlastností problémové domény a sestrojit Prvotní schéma logické architektury. 2. Sestavit seznam klíčových rozhodnutí a otázek o architektuře. Klíčová slova: Architektura software, logická, návrhová a fyzická architektura, prvotní přístup k logické architektuře, opakovatelně využitelné prvky logické architektury, Prvotní schéma logické architektury Architektura rozsáhlého software je jedním z relevantních atributů software. Pochopitelně, cesta, která vede k jejímu modelování a realizaci je poměrně dlouhá a silně závislá na procesech-požadavcích výchozí problémové domény. Je to v souladu s věhlasnými objektovými metodikami (např. RUP, UP, Select Perspective, ), které jsou postaveny na dominanci zpracování požadavků zákazníka. Procesem postupného modelování architektury, v známých objektových metodikách, dospějeme k tzv. logické architektuře, která se musí převést na základě zvolené metody na tzv. návrhovou architekturu. Návrhová architektura se realizuje prostřednictvím zdrojového kódu ve zvoleném programovacím jazyku a vzniká tak architektura fyzická. Sémantika všech tří úrovní je konzistentní a týká se to rovněž vytvořených modelů, resp. diagramů. Rozdíl je ovšem v tom, že návrhový model je velmi blízko implementační fyzické realizaci architektury cílového software a rovněž fyzická architektura souvisí s jejím nasazením v informační infrastruktuře zákazníka. Stačí, vyslovíme-li několik význačných charakteristik jednotlivých modelů architektury: Logická architektura vychází z požadavků problémové domény a je nezávislá na informačních technologiích. Jelikož není možné neuvažovat o architektuře cílového software, je logická architektura prostředkem přechodu od požadavků k návrhovému modelu architektury a potom ke konstrukci fyzické architektury cílového software. Návrhová architektura sice vychází z logické architektury, ale vzniká pod vlivem uplatnění zvoleného modelu informační technologie. Návrhová architektura je potom snadno převoditelná do formy zdrojového kódu. Pojetí všech tří architektur a zejména logické architektury, je uvedeno v publikaci [EelCrip011]. Některé pozoruhodné skutečnosti z této knihy, týkající se zejména logické architektury, jsou diskutované v následujícím textu a řešené ve fázi ZAHÁJENÍ klasických pokročilých objektových metodik vývoje software. Návrhová architektura nebude zde rozvíjena, ale bude o ní mluveno až ve fázi ROZPRACOVÁNÍ zmíněných metodik. Co vše potřebujeme znát pro zahájení a pokračování ve vývoji logické architektury jako vstupy procesu tvorby logické architektury? Jsou to následující skutečnosti: -7-

8 Pojetí podnikové architektury 1. Stávající IT prostředí (informační infrastruktura) zákazníka. Procesy jako funkční požadavky, jejich priority a členění do známých procesních setů. Nefunkční požadavky. Pojmový model podniku obsahující procesy a zpracovávaná data (např. klasický procesní diagram, nebo objektový model tříd). Podniková pravidla nebo podmínky týkající se života podniku (tedy zejména podnikových procesů/služeb). Kontext organizačních součástí podniku (v souladu s jeho architekturou) a vazby na okolí podniku. Znalost uvedených skutečností evokuje správný názor, že logická architektura cílového software by měla zmíněné skutečnosti jaksi odrážet. Např. logická architektura může být postavena na podnikových podsystémech, na jejich částech, na procesních setech, na procesních podsetech, na organizačních jednotkách, nebo na vymezených skupinách podnikových dat. Nejčastěji je ovšem používána procesní platforma. Toto je prvotní přístup, tedy obecná problematika odvozování logické architektury cílového software z kvalit problémové domény. Kde se dovíme zmíněné skutečnosti o podniku? Zjistíme je v provádění stanovených úkolů Úvodní studie (pro strukturované metodiky), nebo fáze ZAHÁJENÍ objektových metodik. Za výsledek procesu modelování logické architektury považujeme: Vyhodnocení kvality vstupů a jejich vlivu na architekturu cílového software. Rozhodnutí o logické architektuře, jaká bude a zdůvodnění proč takovou musí být. Přehled architektury - prvotní model vycházející: z Prvotního schématu logické architektury, z pozdějšího funkčního modelu na komponentách, tj. finálních architektonických jednotkách, z dat a procesů versus komponenty, ze života komponentrozhraní, z nasazení architektury v uzlech informační infrastruktury podniku. Změnová kontrola logické architektury (jak architektura odolává změnám v podniku, zejména v jeho podnikové architektuře). Výsledný dokument o logické architektuře. 1.1 Modelování logické architektury Kniha [Hofm, 05] se zabývá několika přístupy k odvozování logické architektury cílového software. Již dříve uvedený prvotní přístup je v knize rovněž uvažován. Uveďme tři z nich bez hlubší charakteristiky: 1. Přístup na základě atributů celkové kvality problémové domény Attribute Driven Design (ADD). 2. Metoda 4 pohledů od firmy Siemens. 3. Přístup objektových metodik (RUP-Rational Unified Process, UP-Unified Process a dalších), které vycházejí z dominance procesů-požadavků. 1 Architektura podniku je koherentní celek principů, metod a modelů, které jsou použity v návrhu a realizaci: podnikové organizační struktury, business procesů, podnikového informačního systému a podnikové informační infrastruktury. -8-

9 O posledním přístupu budeme později mluvit podrobněji (viz fáze ZAHÁJENÍ a ROZPRACOVÁNÍ metodik RUP/UP). Modelování logické architektury je součástí fáze ZAHÁJENÍ a pokračuje do fáze ROZPRACOVÁNÍ. Finálním nástrojem pro modelování logické architektury v metodice UP jsou UML grafické notace komponent a deskripce života komponent v logické architektuře. Často se pro návrh logické architektury používá na začátku koncept založený na podsystémech, např. procesních, pro jisté oblasti života podniku. To může být prvotní, velmi hrubé schéma logické architektury (např. ve fázi ZAHÁJENÍ metodiky UP). Podsystém je potom chápán jako sada souvisejících součástí, do kterých se promítají procesy-požadavky přes případy užití, a tak vznikne poněkud detailnější schéma logické architektury. Logickou architekturu můžeme převést na logické využití komponent, za které považujeme již zmíněné moduly/podsystémy. Zaznamenáme-li v předchozím schématu logické architektury život zmíněných komponent (naznačení spolupráce), dojde k dalšímu užitečnému zjemnění pojetí logické architektury. Přidáme-li verbální deskripce funkcionality komponent, jejich rozhraní (poskytovaných a požadovaných) a zakreslíme-li schéma nasazení logické architektury v uzlech informační infrastruktury podniku, mohli bychom získané poznatky o logické architektuře považovat za užitečné pro její převod do architektury návrhové. 1.2 Proces tvorby logické architektury Publikace [EelCrip011] se zabývá v podstatě celým procesem tvorby architektury cílového software. Tvorba je rozdělena do tří podprocesů: podprocesy pro tvorbu logické architektury, návrhové architektury a fyzické architektury. Abychom se příliš nevzdálili od pracovních postupů jednotlivých fází objektových metodik, vybereme z knihy [EelCrip011] jen některé myšlenky, protože uvedená kniha ne zcela jasně je navzájem spojuje. Proces tvorby logické architektury, který budeme sledovat je popsán na základě úkolů a kroků, tak jak ukazuje Obrázek 10-1 aktivitního diagramu. Na druhé straně, tyto úkoly nejsou v rozporu s později použitou metodikou UP. Pokusíme se teď naznačit, co se pod jednotlivými úkoly/kroky procesu tvorby logické architektury myslí. Jak se tyto úkoly odrazí v metodice UP zjistíme až v Části IV. Vývoj objektových aplikací podle metodiky UP. Jisté je, že prvotní přístup k architektuře cílového software je ve fázi ZAHÁJENÍ metodik RUP a UP postaven právě na logické architektuře. Pro čtenáře bude jistě užitečný příklad modelování logické architektury cílového komputerizačního software jednoduché domény Evidence soukromých zbraní v ČR, který bude uveden později v Část IV. Scénář fáze ZAHÁJENÍ na doméně SSZ v ČR. Ve vysvětlování metodiky UP se dovíme, že problematika logické architektury se začíná řešit již ve fázi ZAHÁJENÍ a poté řešení pokračuje velmi široce ve fázi ROZPRACOVÁNÍ, kde se důsledně rozpracuje návrhová architektura. Ve fázi KONSTRUKCE se problematika architektury soustřeďuje jen na dokončení návrhové architektury a potom na její fyzickou realizaci v programovacím systému. Ve fázi ZAVEDENÍ se potom řeší nasazení fyzické architektury na informační infrastruktuře zákazníka. V softwarovém projektu, který je pro řízení vývoje software IS ustanoven a který využívá zmíněnou metodiku, je za architekturu zodpovědný hlavní architekt. Pochopitelně, je-li komputerizovaná problémová doména rozsáhlá, potom v projektu figurují rovněž datový architekt, procesní architekt, architekt infrastruktury a aplikační architekt. Velmi užitečný je následující metamodel vývoje logické architektury. -9-

10 A B C Obrázek 10-1: Proces tvorby logické architektury (převzato a upraveno z [EelCrip011], str. 167) Úkol A: Průzkum prvků architektury software Znalost procesní charakteristiky celé problémové domény, nebo jen jejího výseku, pomůže provést průzkum, jestli již existují nějaké opětovně využitelné prvky architektury 2, které bychom mohli využít. Opakovatelně využitelné prvky architektury se člení na prvky využitelné v logické architektuře a návrhové architektuře. Protože nás zajímá jen logická architektura, tak uvedeme jen prvky v ní použitelné: Opakovaně se vyskytující proces požadavek/podsystém/modul, nebo komponenta objevující se rovněž v jiné problémové doméně. Opakovaně využitelný vzor logické architektury. Je to vzor, který již byl využit v jiné problémové doméně. Např. u podniku je komputerizace orientována jen na problematiku personalistiky a my známe skupiny procesů a jejich osazení jednotlivými procesy. Hledání potom orientujeme na prověření, jestli náhodou neexistuje služba ve formě komponenty pro jednu nebo více skupin personálních procesů. Jestliže jsou pro komputerizaci problémové domény, nebo její části, předepsány jisté principy týkající se architektury, tak je nutné na ně brát ohled. Např. platí princip, že průzkum existence opakovaně využitelných prvků architektury musí být proveden jako první a musí být vyhotovena příslušná zpráva o výsledku Úkol B: Definice přehledu architektury Následující obrázek ilustruje vstupy a výstupy tohoto úkolu, jehož cílem je vytvořit tzv. Přehled architektury. 2 Za opětovně použitelné prvky architektury považujeme již existující prvky, opakovaně využitelné pro logickou nebo návrhovou architekturu nově tvořeného software. -10-

11 Procesy-funkční požadavky Nefunkční požadavky Principy podn. architektury Výsledky kontextové analýzy Slovník pojmů Vstup Definice přehledu architektury Výstup Přehled architektury Obsah Přehledu architektury: Přehled architektury je spíše schematický a doplněn potřebnou verbální deskripcí. Představuje prvotní odvození architektury z procesů-požadavků problémové domény. Analýzu procesů, jejich seskupení do skupin/množin/podsystémů musíme ovšem provést jako první. Důležité je, že musíme mít procesní model domény, resp. její části. Schéma, které se musí v Přehledu architektury vytvořit je souhrnem obdélníků, které jsou pospojovány závislostními spojnicemi. Spojnice většinou nejsou interakčního charakteru. Jde o seskupení funkcionalit (daných procesy-požadavky) uvedených v obdélnících. Seskupení funkcionality jsou následujících typů: do skupiny/množiny/oblasti procesů, do podsystémů nebo modulů, do komponenty. V prvotním schématu pro logickou architekturu použijeme jen jeden typ seskupení funkcionalit. Budou to podsystémy. Spojnice označují ze začátku jen jisté souvislosti. Jsou to souvislosti, které jsme objevili mezi skupinami/množinami/oblastmi procesů, nebo mezi podsystémy /moduly. Spojnice se dále upřesňují, což souvisí rovněž s upřesňováním logické architektury. Podsystémy se chápou jako možné sady souvisejících částí (s mapováním 1:1, 1:N). Schéma doplníme tak, aby dalo první obraz architektury cílového software, např. je načrtnuta komunikace s klienty a závislosti prvků schématu. 1 Hrubý přehled funkčních prvků, funkční model Cílem je nalezení základních funkčních prvků a jejich mapování do podsystémů/modulů, později do finálních komponent a tak vytvořit první představu o funkčním modelu problémové domény. Např. A B C D E Obrázek 10-2: První představa o funkčním modelu. Jednotlivé podsystémy by měly být později identifikované a rovněž identifikované závislosti mezi nimi. Závislosti můžeme kreslit pomocí relace <<využívá>> -11-

12 Následující příklad může sloužit jako vzorový pro získání hrubého funkčního modelu domény. Příklad 10-1: Ze znalosti funkcionality problémové domény Evidence soukromých zbraní v ČR, viz Část IV -5, můžeme poznat následující skupiny/moduly/podsystémy procesů a souvislosti mezi nimi. 1. Správa zbraní a Průkazů zbraní. 2. Správa majitelů zbraní. 3. Správa ZP. 4. Správa klientů. 5. Statistiky a vyhledávání. Pro naši doménu SSZ v ČR má schéma Prvotního pohledu na problémovou doménu následující tvar: Správa soukromých zbraní na teritoriu ČR Statistiky a vyhledávání Správa MZP Správa ZP Správa klientů Správa zbraní a PZ Obrázek 10-3: Prvotní pohled na problémovou doménu. Sestavíme Model hrubé funkční - procesní závislosti v problémové doméně: Správa zbraní a průkazů zbraní <<využívá>>. 7 Statistiky a vyhledávání <<využívá>>. 2 4 <<využívá>>. 1 <<využívá>>. Správa majitelů zbraní <<využívá>>. 3 5 Správa zbrojních <<využívá>> průkazů <<využívá>>.. <<využívá>>. 6 Správa klientů Obrázek 10-4: Příklad hrubého funkčního modelu problémové domény s relací <<využívá>>. Můžeme tedy sestavit schematický přehled architektury, který bude doplněn o další -12-

13 nezbytné prvky logické architektury (Řízení a komunikace s klienty, Řízení výstupních sestav a Báze dat), což dále objasní cestu k návrhové architektuře. Schéma, které to ilustruje, nazveme pracovně Prvotním schématem logické architektury. a) Prvotní schéma logické architektury: Komunikace s klienty Správa výstupních sestav Správa zbraní a průkazů zbraní (ZP) Správa statistiky a vyhledávání BD Správa majitelů zbraní Správa zbrojních průkazů (ZP) Správa klientů Obrázek 10-5: Prvotní schéma logické architektury pro doménu Evidence soukromých zbraní v ČR. b) Deskripce schématu: Systém potřebuje centrální řízení komunikace s klienty, které umožní nejen autentizaci a autorizaci, ale i organizaci plnění jejich požadavků. Klienti mohou spouštět jednotlivé podsystémy. Veškerá informace podsystémů je uložena v bázi dat. Podsystém Řízení statistiky nebude využívat ostatní podsystémy (jak je ve funkčním modelu), ale jen jejich data z báze dat-bd. Podsystém Řízení výstupních sestav bude organizovat výstup podle připravených výstupních šablon v podsystému Řízení statistiky. 2 Přehled prvků nasazení Zde uvažujeme o informační infrastruktuře (IT prostředí pro nasazení) problémové domény a identifikujeme lokality, v kterých bude cílový software nasazen, a pochopitelně uvažujeme o výpočetních uzlech, které se v daných lokalitách nacházejí. Můžeme načrtnout, jaké podsystémy budou v uzlech nasazeny. Zavedení komponentového pojetí 3 Zavedení komponentového pojetí Jak již bylo načrtnuto, můžeme Prvotní schéma logické architektury dále upravovat, zejména jeho převedením na ilustraci komponent (finálních architektonických jednotek): Podsystémy mapujeme na komponenty. Stanovíme spolupráci komponent (nabízená a požadovaná rozhraní). Můžeme již nakreslit Diagram prvotního přístupu k nasazení komponent v informační infrastruktuře. -13-

14 Uvedenou úpravu můžeme provést, protože jsme již o architektuře koncepce Distribuovaná architektura, postavené na komponentách již poučeni. Jaká je geneze dalšího využití diagramu Prvotní schéma logické architektury? Počítá se s tím, že komponenty budou později (ve fázi ZAHÁJENÍ), jakoby formálně naplněny případy užití, později (ve fázi ROZPRACOVÁNÍ) jakoby formálně naplněny Diagramy realizačních analytických tříd a souvisejícími Sekvenčními diagramy. Jestliže se toto naplnění (opět ve fázi ROZPRACOVÁNÍ) provede návrhovou formou Diagramů analytických tříd a souvisejících Sekvenčních diagramů, vznikne Návrhová architektura. Nakonec budou komponenty již reálně naplněny zdrojovým kódem návrhových tříd a souvisejících Sekvenčních diagramů (ve fázi KONSTRUKCE) a vznikne Fyzická architektura. 4 Ukázka koncepce architektury Je v objektových metodikách RUP a UP dokumentována tzv. Spustitelným architektonickým modelem software, což je tzv. komponentové klišé, které je sice postaveno na spustitelných, ale většinou prázdných komponentách. Pozoruhodné je to, že toto klišé se již nezahazuje, ale neustále se přetvářídoplňuje na Fyzickou architekturu, a je snahou jeho koncepci příliš neměnit. S tímto postupem se jistě setkáme v obou zmíněných objektových metodikách Úkol C: Dokumentace rozhodnutí o architektuře Cílem tohoto úkolu je zaznamenat veškerá provedená a plánovaná klíčová rozhodnutí o architektuře. Všechny dosud provedené práce v souvislosti s architekturou Vstup Dokumentace rozhodnutí o architektuře Výstup Rozhodnutí o architektuře Sestaví se soupis otázek spojených s architekturou, charakterizují se možnosti, vybere se preferovaná možnost a toto rozhodnutí se dokumentuje v dokumentu Rozhodnutí o architektuře. Jedna z otázek se soustřeďuje na vyřešení pozice podnikových pravidel (pravidla víceméně spojená s podnikovými procesy) v architektuře cílového software. To vše budeme řešit ve fázi ZAHÁJENÍ a fázi ROZPRACOVÁNÍ metodiky UP. Uvedené myšlenky počátečního přístupu k architektuře cílového software nám ukázaly, jak vyjít od požadavků a relevantních vlastností problémové domény a kráčet k logické architektuře. Tyto myšlenky jistě využijeme v metodice UP. Poznámka Modelování logické architektury cílového software může ve fázi ZAHÁJENÍ končit již u Prvotního schématu logické architektury. Potom ovšem do komponentové podoby musí být převedeno ve fázi ROZPRACOVÁNÍ. Shrnutí kapitoly: Kapitola podává pojetí logické architektury a prvotní přístup k ní. V kapitole se využívá postupu, který je navržen v publikaci [EelCrip011]. Začíná se zhodnocením vlivu relevantních vlastností problémové domény na logickou architekturu. Provede se průzkum prvků architektury, které by se daly v logické architektuře využít. V přehledu architektury se Σ -14-

15 sestrojí Prvotní schéma logické architektury. Buď ještě ve fázi ZAHÁJENÍ dojde k převodu Prvotního schématu logické architektury do komponentové podoby, anebo se to provede až ve fázi ROZPRACOVÁNÍ (krok Architektonický návrh). V této fázi rovněž dojde k tvorbě Spustitelného architektonického modelu, který bude ilustrovat běh cílového software na komponentách a bude dále dopracováván. Nakonec se logická architektura verbálně dokumentuje v tzv. Rozhodnutí o architektuře. Pojmy k zapamatování: logická, návrhová a fyzická architektura software, Prvotní schéma logické architektury, Spustitelný architektonický model, Rozhodnutí o architektuře. Testy a otázky: 1. Jaké je pojetí logické, návrhové a fyzické architektury? 2. V čem tkví přístup k logické architektuře podle publikace [EelCrip011]? Kde se začíná v tomto přístupu? 3. Jaký mají význam hrubý funkční model problémové domény, Prvotní schéma logické architektury a Rozhodnutí o architektuře? Úkoly k zamyšlení: 1. Zamyslete se, pro koho může být významné spojení problematiky logické architektury s pojetím komponent již ve fázi ZAHÁJENÍ a pro koho až ve fázi ROZPRACOVÁNÍ (krok Architektonický návrh). 2. Co si představujete pod Spustitelným architektonickým modelem a k čemu slouží? 2 Literatura [EelCri, 2011] Eeles, P. Cripps, P.: Architektura software. Nepostradatelný průvodce návrhem softwarové architektury, která funguje. Brno: Computer Press, ISBN [WoMa, 2006] [Erl, 2006] [KrŽe, 2004] [Tan, 2007] [ArNeu, 2007] [Som, 2010] [wiksof] [Kač, 2000] [Hofm, 05] WOODS, D., MATTERN, T.: Enterprise SOA. Designing IT for Business Innovation. O'REILLY, Tokyo. ISBN ERL, T.: Service-oriented Architecture. A Field Guide to Interacting XML and Web Services. Prentice Hall, USA, ISBN Král, J., Žemlička, M.: Architektury orientované na služby jako nové paradigma: mýty, problémy, výzvy, přínosy. In: Sborník z konference Systems Integration Praha, Vysoká škola ekonomická. Tanenbaum, A. S.: Distributed Systems. Principles and Paradigms. Printice Hall, Arlow, J., Neustad, I. UML 2 a unifikovaný proces vývoje aplikací. Brno: Computer Press, ISBN Sommerville, I. Software Engineering (the 9 th edition). London: Publisher PEARSON, ISBN 10: Kačmár, D.: Programujeme v COM a COM+. Computer Press, Praha, ISBN Hofmeister, CH.: Generalizing a Model of Software Architecture Design -15-

16 [RuJaBo, 99] [Če-Va-Zi, 06] from five Industrial Approaches. Proceedings of the 5th Working IEEE/IFIP Conferences on Software Architecture (WICSA5). Washington, DC: IEEE Computer Society, Rumbaugh, J., Jacobson, I., Booch, G.: The unified Modeling Language. Reference Manual. Amsterdam: ADDISON-WESLEY, ISBN X. Bock, H.: The Definition Guide to Net Beans Platform. Brno: Computer Press, ISBN

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

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

Komputerizace problémových domén

Komputerizace problémových domén Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 03 1/19 Komputerizace problémových domén Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

PŘÍLOHA C Požadavky na Dokumentaci

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

Více

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

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

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

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

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

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

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

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

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

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

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

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

Komponentový systém Personalistika Autor: Milan Mišovič, PEF, Ústav informatiky, Mendelova univerzita v Brně

Komponentový systém Personalistika Autor: Milan Mišovič, PEF, Ústav informatiky, Mendelova univerzita v Brně Komponentový systém Personalistika Autor: Milan Mišovič, PEF, Ústav informatiky, Mendelova univerzita v Brně -1- Základy podnikové personalistiky popis Úvod Jednou z prvořadých povinností každého podniku

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

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

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

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

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

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

12 Metody snižování barevného prostoru

12 Metody snižování barevného prostoru 12 Metody snižování barevného prostoru Studijní cíl Tento blok je věnován základním metodám pro snižování barevného rozsahu pro rastrové obrázky. Postupně zde jsou vysvětleny důvody k použití těchto algoritmů

Více

Obsah. ÚVOD 1 Poděkování 3

Obsah. ÚVOD 1 Poděkování 3 ÚVOD 1 Poděkování 3 Kapitola 1 CO JE TO PROCES? 5 Co všechno musíme vědět o procesním řízení, abychom ho mohli zavést 6 Různá důležitost procesů 13 Strategické plánování 16 Provedení strategické analýzy

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

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

D1 Trvalá organizace

D1 Trvalá organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D1 Trvalá organizace Toto téma obsahuje informace o trvalé organizaci, jejích základních principech a prostředí.

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

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

Management informačních systémů. Název Information systems management Způsob ukončení * přednášek týdně

Management informačních systémů. Název Information systems management Způsob ukončení * přednášek týdně Identifikační karta modulu v. 4 Kód modulu Typ modulu profilující Jazyk výuky čeština v jazyce výuky Management informačních systémů česky Management informačních systémů anglicky Information systems management

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

Náležitosti ICT plánu Cíl kapitoly. Základní pojmy. Kam patří ICT plán?

Náležitosti ICT plánu Cíl kapitoly. Základní pojmy. Kam patří ICT plán? Náležitosti ICT plánu Cíl kapitoly Podrobněji přiblížit proces plánování, začlenění ICT plánu do systému plánů ve škole a předložení oblastí, které je třeba v ICT plánu popsat ve fázích: popisu aktuálního

Více

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

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

Více

INFORMATIKA. Jindřich Kaluža. Ludmila Kalužová

INFORMATIKA. Jindřich Kaluža. Ludmila Kalužová INFORMATIKA Jindřich Kaluža Ludmila Kalužová Recenzenti: doc. RNDr. František Koliba, CSc. prof. RNDr. Peter Mikulecký, PhD. Vydání knihy bylo schváleno vědeckou radou nakladatelství. Všechna práva vyhrazena.

Více

Enterprise Architecture na MPSV 23.9.2015

Enterprise Architecture na MPSV 23.9.2015 Enterprise Architecture na MPSV 23.9.2015 Mgr. Bc. et Bc. Robert Baxa, náměstek ministryně Mgr. Jiří Károly, ředitel odboru rozvoje a bezpečnosti ICT Enterprise Architecture (EA) na MPSV Východiska pro

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

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy Ing. Jiří Fejfar, Ph.D. Geo-informační systémy Definice, budování a život GIS Kapitola 1: Vztahy strana 2 Data, informace, IS, GIS Kapitola 1: Vztahy strana 3 Rozhodnutí Znalosti Znalostní systémy. Informace

Více

Návrh integrační architektury informačního prostředí HMP První krok k integraci IS a datových vazeb

Návrh integrační architektury informačního prostředí HMP První krok k integraci IS a datových vazeb Návrh integrační architektury informačního prostředí HMP První krok k integraci IS a datových vazeb Jaroslav Šolc, INF MHMP Jiří Slabý, Deloitte epraha 2015, 18.3.2015 1 Vznik záměru Důvody Problémy identifikované

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

Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě

Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě Tomáš Hrabík ICZ a.s. Konference Řízení informatiky v soukromém a veřejném sektoru 1 Otázky 1. Je egovernment o elektronizaci

Více

Česká zemědělská univerzita v Praze

Česká zemědělská univerzita v Praze Česká zemědělská univerzita v Praze Provozně ekonomická fakulta Katedra informačních technologií Teze diplomové práce Operační systém Google Android Petr Koula 2011 ČZU v Praze Souhrn Diplomová práce zahrnuje

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

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Procesy, procesní řízení organizace Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Co nového přináší ISO 9001:2008? Vnímání jednotlivých procesů organizace jako prostředku a nástroje

Více

SCÉNÁŘ FÁZE ZAHÁJENÍ NAD DOMÉNOU SSZ V ČR (20. Dubna 2012)

SCÉNÁŘ FÁZE ZAHÁJENÍ NAD DOMÉNOU SSZ V ČR (20. Dubna 2012) SCÉNÁŘ FÁZE ZAHÁJENÍ NAD DOMÉNOU SSZ V ČR (20. Dubna 2012) Úvod problémová doména Co je problémová doména? Pojem je sice informatický, ale srozumitelný rovněž managementu. Informatici nemohou do svých

Více

Hospodářská informatika

Hospodářská informatika Hospodářská informatika HINFL, HINFK Vytvořeno s podporou projektu Průřezová inovace studijních programů Lesnické a dřevařské fakulty MENDELU v Brně (LDF) s ohledem na disciplíny společného základu reg.

Více

Transformace dílčích datových zdrojů na jednotnou datovou platformu kontaminovaných míst, analýza potřeb uživatelů a vývoj aplikací

Transformace dílčích datových zdrojů na jednotnou datovou platformu kontaminovaných míst, analýza potřeb uživatelů a vývoj aplikací Transformace dílčích datových zdrojů na jednotnou datovou platformu kontaminovaných míst, analýza potřeb uživatelů a vývoj aplikací Jiří Šíma, AQUATEST a.s. Zpracovatelé a součinnost AQUATEST a.s. ARCDATA

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

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

- Tvorba a implementace procesního řízení - Vytvoření procesní mapy včetně metodické příručku pro její tvorbu.

- Tvorba a implementace procesního řízení - Vytvoření procesní mapy včetně metodické příručku pro její tvorbu. Zavedení procesního řízení - Tvorba a implementace procesního řízení - Vytvoření procesní mapy včetně metodické příručku pro její tvorbu. - Tvorba procesního modelu MMB, podpora identifikace a mapování

Více

Architektura v organizaci

Architektura v organizaci Architektura v organizaci Radek Vácha Seminář CSSI, 23.3.2007 Accenture, its logo, and Accenture High Performance Delivered are trademarks of Accenture. Obsah Můj profil Architektura odraz světa Jiné pohledy

Více

Informační systém o státní službě (ISoSS) a jeho vazba na zákon o státní službě

Informační systém o státní službě (ISoSS) a jeho vazba na zákon o státní službě Informační systém o státní službě (ISoSS) a jeho vazba na zákon o státní službě Ing. Petr Pechar, vedoucí projektu ISoSS Mgr. Karol Ivanko, vedoucí řešitelského týmu Ministerstvo vnitra ČR, odbor provozu

Více

Diagram nebo text? Miroslav Benešovský, BenSoft s.r.o

Diagram nebo text? Miroslav Benešovský, BenSoft s.r.o Diagram nebo text? Miroslav Benešovský, Diagram nebo text? Jaká je role analytika při vývoji SW? Most mezi zákazníkem a vývojáři Jaké má analytik prostředky? Diagramy, vizuální modelování Jaká je zkušenost

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

CISAŽP. Celostátní informační systém pro sběr a hodnocení informací o znečištění životního prostředí

CISAŽP. Celostátní informační systém pro sběr a hodnocení informací o znečištění životního prostředí CISAŽP Celostátní informační systém pro sběr a hodnocení informací o znečištění životního prostředí Cíl budování systému Komplexně přispět k ochraně a zlepšování životního prostředí v České republice prostřednictvím

Více

ZÁKLADY PROGRAMOVÁNÍ. Mgr. Vladislav BEDNÁŘ 2014 5.3-5.8 9/14

ZÁKLADY PROGRAMOVÁNÍ. Mgr. Vladislav BEDNÁŘ 2014 5.3-5.8 9/14 ZÁKLADY PROGRAMOVÁNÍ Mgr. Vladislav BEDNÁŘ 2014 5.3-5.8 9/14 Co je vhodné vědět, než si vybereme programovací jazyk a začneme programovat roboty. 1 / 12 0:40 UML unifikovaný modelovací jazyk Zkratka tohoto

Více

SYLABUS MODUL BUSINESS MODELOVÁNÍ. Doc. RNDr. Vladimír Krajčík, Ph.D.

SYLABUS MODUL BUSINESS MODELOVÁNÍ. Doc. RNDr. Vladimír Krajčík, Ph.D. SYLABUS MODUL BUSINESS MODELOVÁNÍ Doc. RNDr. Vladimír Krajčík, Ph.D. Ostrava 20 : Business modelování Autoři: Doc. RNDr. Vladimír Krajčík, Ph.D. Vydání: první, 20 Počet stran: Tisk: Vysoká škola podnikání,

Více

A. Charakteristika vyučovacího předmětu

A. Charakteristika vyučovacího předmětu Vyučovací předmět:: INFORMATIKA A. Charakteristika vyučovacího předmětu a) Obsahové, časové a organizační vymezení předmětu U vyučovacího předmětu informatika je časové vymezení dáno učebním plánem. V

Více

Architektura počítačů

Architektura počítačů Architektura počítačů Studijní materiál pro předmět Architektury počítačů Ing. Petr Olivka katedra informatiky FEI VŠB-TU Ostrava email: petr.olivka@vsb.cz Ostrava, 2010 1 1 Architektura počítačů Pojem

Více

Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009. 1.Podniková informatika pojmy a komponenty

Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009. 1.Podniková informatika pojmy a komponenty Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009 1.Podniková informatika pojmy a komponenty (1) Objasněte pojmy: IS, ICT, ICT služba, ICT proces, ICT zdroj. Jakou dokumentaci k ICT službám,

Více

Antonín Přibyl Odborná praxe oborů PS a AI

Antonín Přibyl Odborná praxe oborů PS a AI Výchozí stav Vysoká škola polytechnická Jihlava je veřejná vysoká škola zaměřená na aplikovanou vzdělanost, jejímž posláním je poskytovat studijní programy zaměřené zejména na potřeby regionálního trhu

Více

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

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

Více

Úvodem... 9 O Metodikách... 37 O Metodách... 135

Úvodem... 9 O Metodikách... 37 O Metodách... 135 Obsah A. Úvodem... 9 A. 1. Projektování informačního systému... 10 A. 2. O co jde při vývoji IS... 16 A. 3. Historie vývoje metodik, metod a technik... 33 B. O Metodikách... 37 B. 1. Metody a metodiky...

Více

Disková pole (RAID) 1

Disková pole (RAID) 1 Disková pole (RAID) 1 Architektury RAID Základní myšlenka: snaha o zpracování dat paralelně. Pozice diskové paměti v klasickém personálním počítači vyhovuje pro aplikace s jedním uživatelem. Řešení: data

Více

Pořízení nových systémů na MPSV děláme to ponovu

Pořízení nových systémů na MPSV děláme to ponovu Pořízení nových systémů na MPSV děláme to ponovu 13. dubna 2015 Hradec Králové Ing. Iva Merhautová, MBA Mgr. Bc. et Bc. Robert Baxa Michal Rada ICT MPSV Základní oblasti řízení: ICT ministerstva práce

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

Stav řešení Enterprise Architektury na Moravskoslezském kraji

Stav řešení Enterprise Architektury na Moravskoslezském kraji Stav řešení Enterprise Architektury na Moravskoslezském kraji Zpracoval(a): Ing. Tomáš Vašica Datum: 23. 9. 2015 Obsah prezentace 1. Představení projektového záměru 2. Co očekává Moravskoslezský kraj od

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

Obsah: Základní pojmy, definice Informační systémy IT architektura Typické aplikační komponenty Implementace aplikací

Obsah: Základní pojmy, definice Informační systémy IT architektura Typické aplikační komponenty Implementace aplikací Monitorovací indikátor: 06.43.10 Počet nově vytvořených/inovovaných produktů Akce: Přednáška, KA 5 Číslo přednášky: 30 Téma: INFORMAČNÍ SYSTÉMY A ARCHITEKTURA IT V PODNIKU Lektor: Ing. Michal Beránek Třída/y:

Více

POKYNY PRO ŽADATELE PŘÍLOHA C2 ZÁVAZNÉ OSNOVY PRO ZPRACOVÁNÍ STUDIE PROVEDITELNOSTI K AKCI PŘEDKLÁDANÉ DO GS JKS GRANTOVÁ SCHÉMATA SROP

POKYNY PRO ŽADATELE PŘÍLOHA C2 ZÁVAZNÉ OSNOVY PRO ZPRACOVÁNÍ STUDIE PROVEDITELNOSTI K AKCI PŘEDKLÁDANÉ DO GS JKS GRANTOVÁ SCHÉMATA SROP Moravskoslezský kraj POKYNY PRO ŽADATELE PŘÍLOHA C2 ZÁVAZNÉ OSNOVY PRO ZPRACOVÁNÍ STUDIE PROVEDITELNOSTI K AKCI PŘEDKLÁDANÉ DO GS JKS 28.6.2006 Strana 1 z 5 ZÁVAZNÁ OSNOVA STUDIE PROVEDITELNOSTI (SP) TITULNÍ

Více

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B5 Program Téma obsahuje informace o programech a programovém řízení a klade si za cíl především vysvětlit

Více

Česká zemědělská univerzita v Praze. Provozně ekonomická fakulta. Katedra informačních technologií

Česká zemědělská univerzita v Praze. Provozně ekonomická fakulta. Katedra informačních technologií Česká zemědělská univerzita v Praze Provozně ekonomická fakulta Katedra informačních technologií Teze diplomové práce Analýza a návrh informačního systému Miloš Rajdl 2012 ČZU v Praze 1 Souhrn Diplomová

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

Cíl výuky: Cílem předmětu je uvedení studentů do problematiky projektování, seznámit posluchače se zásadami

Cíl výuky: Cílem předmětu je uvedení studentů do problematiky projektování, seznámit posluchače se zásadami PM_prezenční a kombinované bakalářské studium Česky Projektový management Anglicky Project Management Garant Ing. Zdeněk Voznička, CSc. Zakončení Zápočet Anotace: Úvod do projektového managementu, základní

Více

ADOit. IT architektura a řízení IT služeb. Luděk Kryšpín, Lukáš Dvořák, PADCOM, s.r.o.

ADOit. IT architektura a řízení IT služeb. Luděk Kryšpín, Lukáš Dvořák, PADCOM, s.r.o. ADOit IT architektura a řízení IT služeb Luděk Kryšpín, Lukáš Dvořák, PADCOM, s.r.o. Představení PADCOM Základní informace o firmě Poradenská firma s výhradně českým kapitálem Zahájení činnosti 2008 Počet

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

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

1 POPIS FIRMY BODY- CARE

1 POPIS FIRMY BODY- CARE 1 POPIS FIRMY BODY- CARE Na českém trhu je několik dodavatelských firem, které poskytují zákazníkům celou řadu věhlasných kosmetických přípravků. Stačí jmenovat dvě, které na českém trhu s kosmetikou vévodí.

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

Elektronická provozní dokumentace (epd) případová studie MPSV

Elektronická provozní dokumentace (epd) případová studie MPSV Elektronická provozní dokumentace (epd) případová studie MPSV Ing. Petra Marešová, Ministerstvo práce a sociálních věcí Ing. Stanislav Borecký, ANECT a.s. Tomáš Sailer, ANECT a.s. ISSS 2011 4.dubna, Hradec

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

End-to-end testování. 26. dubna Bořek Zelinka

End-to-end testování. 26. dubna Bořek Zelinka End-to-end testování 26. dubna 2013 Bořek Zelinka Bořek Zelinka Unicorn Systems, Test architekt Unicorn, 2004 Testování Quality Assurance ČVUT, Fakulta stavební, 2004 2 Agenda Princip end-to-end testů

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

Témata pro maturitní práci oboru 78-42-M/01 Technické lyceum školní rok 2013/2014

Témata pro maturitní práci oboru 78-42-M/01 Technické lyceum školní rok 2013/2014 Střední průmyslová škola strojnická Vsetín 1) Alternativní zdroje energie Obsah z předmětu: Fyzika Vedoucí maturitní práce: RNDr. Jiří Homolka Témata pro maturitní práci oboru 78-42-M/01 Technické lyceum

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

Tvar dat a nástroj přeskupování

Tvar dat a nástroj přeskupování StatSoft Tvar dat a nástroj přeskupování Chtěli jste někdy použít data v jistém tvaru a STATISTICA Vám to nedovolila? Jistě se najde někdo, kdo se v této situaci již ocitl. Není ale potřeba propadat panice,

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

Referenční projekty STRANA 1 (CELKEM 6)

Referenční projekty STRANA 1 (CELKEM 6) Níže uvedený přehled referencí poskytuje informace o našich zkušenostech a obsahuje také projekty, na kterých jsme se účastnili ve spolupráci s jinými partnerskými společnostmi: Zákazník Františkovy Lázně

Více

Protokol o atestačním řízení

Protokol o atestačním řízení Atestační středisko: ADA, s. r. o. pověření k výkonu atestací MI ČR reg. č. 3 rozhodnutím č. j. 3/2001 A ze dne 11.10.2001, se sídlem Čermákova 28, 625 00 Brno adresa pro poštovní styk Sokolská 725, 664

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

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

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 12. Virtuální sítě (VLAN) Studijní cíl Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 1 hodina VLAN Virtuální síť bývá definována jako logický segment LAN, který spojuje koncové uzly, které

Více

Analýza problémové domény

Analýza problémové domény Analýza problémové domény Ing. Jiří Mlejnek Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze Jiří Mlejnek, 2011 jiri.mlejnek@fit.cvut.cz Softwarové

Více

BEZPEČNOST IS. Ukončení předmětu: Předmět je zakončen zkouškou sestávající z písemné a doplňkové ústní části.

BEZPEČNOST IS. Ukončení předmětu: Předmět je zakončen zkouškou sestávající z písemné a doplňkové ústní části. BEZPEČNOST IS Předmět Bezpečnost IS je zaměřen na bezpečnostní aspekty informačních systémů a na zkoumání základních prvků vytváření podnikového bezpečnostního programu. Má představit studentům hlavní

Více

Databázové systémy úvod

Databázové systémy úvod Databázové systémy úvod Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze c Michal Valenta, 2012 BI-DBS, ZS 2012/13 https://edux.fit.cvut.cz/courses/bi-dbs/ Michal

Více

Znalostní systém nad ontologií ve formátu Topic Maps

Znalostní systém nad ontologií ve formátu Topic Maps Znalostní systém nad ontologií ve formátu Topic Maps Ladislav Buřita, Petr Do ladislav.burita@unob.cz; petr.do@unob.cz Univerzita obrany, Fakulta vojenských technologií Kounicova 65, 662 10 Brno Abstrakt:

Více

ve spolupráci s Zavádíme a provozujeme užitečné informační technologie v organizacích.

ve spolupráci s Zavádíme a provozujeme užitečné informační technologie v organizacích. ve spolupráci s 1 Portál úředníka Lubomír Forejtek Ing. lubomir.forejtek@autocont.cz Pavlinec Petr Ing. pavlinec.p@kr-vysocina.cz Portál úředníka aneb proč bych se měl o PÚ zajímat Sdílení informací a

Více