Objektová procesní analýza a inovace informačního systému v podniku Kentico Software s. r. o.

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

Download "Objektová procesní analýza a inovace informačního systému v podniku Kentico Software s. r. o."

Transkript

1 Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta Objektová procesní analýza a inovace informačního systému v podniku Kentico Software s. r. o. Diplomová práce Vedoucí práce: doc. Ing. Ivana Rábová, Ph.D. Bc. Ondřej Vasil Brno 2009

2 Na tomto místě bych rád poděkoval vedoucí diplomové práce paní doc. Ing. Ivaně Rábové, Ph.D. za její cenné rady a připomínky v průběhu zpracování diplomové práce. Také děkuji panu doc. Ing. Dr. Jiřímu Rybičkovi za poskytnutý styl pro sazbu diplomových prací v systému L A TEX.

3 Zadání

4

5 Prohlašuji, že jsem tuto práci vytvořil samostatně za pomoci metodických pokynů vedoucí diplomové práce a s použitím zdrojů, softwaru a dalších podkladů uvedených v diplomové práci. V Brně dne

6 6 Abstract Vasil, O. The object-oriented process analysis and information system innovation in Kentico Software. Diploma thesis, Brno The diploma thesis focuses on process analysis in Kentico Software. At the beginning, the business process analysis is made up and Use Case analysis is accomplished. Information system innovation is shown based on the analyses above by creating library administration application. There are presented the most important UML schemes for chosen processes within the library administration model. The alternative solution is compared and the economical review is made at the end. Abstrakt Vasil, O. Objektová procesní analýza a inovace informačního systému v podniku Kentico Software s. r. o. Diplomová práce, Brno Diplomová práce se zaměřuje na procesní analýzu ve firmě Kentico Software s. r. o. Je zpracována analýza podnikových procesů a ukázána Use Case analýza. Na jejich základě je provedena inovace informačního systému vytvořením aplikace pro knihovní administrativu. Pro vybrané procesy jsou sestaveny nejdůležitější UML diagramy. Závěr práce stručně hodnotí alternativní řešení a je provedeno ekonomické hodnocení.

7 OBSAH 7 Obsah 1 Úvod a cíl práce Úvod Cíl práce Přehled literatury UML Historie UML Metodika UP Metodika Select Perspective Diagramy Diagram tříd - Class diagram Diagram případů užití - Use Case diagram Sekvenční diagram - Sequence diagram Komunikační diagram - Communication diagram Diagram aktivit - Activity diagram Stavový diagram - State diagram Entitně-relační diagram - Entity-relationship diagram Model podnikových procesů - Business process model CASE nástroje - Enterprise Architect Použité technologie Ekonomická efektivnost zavedení IS Analyzovaná firma Předmět podnikání Vize, poslání, produkt a cíl CMS Kentico CMS Organizační struktura Současný stav IS Vlastní práce Byznys modelování současného stavu Základní pohled procesu vývoje produktu Příprava a plánování nové verze Implementace modulu Kontrola projektu Vypuštění nové verze Use Case model současných podnikových procesů Náprava defektu Zlepšení části podnikového procesu - knihovní administrativa BPM - knihovní administrativa Use Case - knihovní administrativa

8 OBSAH Use Case - rezervace knihy Sekvenční diagram - rezervace knihy Diagram tříd - knihovní administrativa Diagram aktivit - rezervace knihy Stavový diagram - třída kniha ERD diagram - knihovní administrativa Funkce systému Vylepšení systému knihovny Ekonomické hodnocení navrženého řešení Alternativní řešení Závěr 62 7 Literatura 63 Přílohy 65 A Slovníček pojmů 66

9 1 ÚVOD A CÍL PRÁCE 9 1 Úvod a cíl práce 1.1 Úvod Podnikový informační systém ovlivňuje samotné základy fungování společnosti, která jej využívá. Informační systém je doslova páteří firmy, bez které si nelze samotnou existenci vůbec představit. Proto je důležité se o něj starat a pečovat o jeho správný vývoj. Zlepšování podnikových procesů je dnes nezbytností pro udržení firmy na konkurencí přeplněném trhu. Takové procesní změny dokonce vyvolávají samotní zákazníci. Ti totiž žádají stále lepší produkty a pokud je nedostanou, mají možnost se obrátit na další konkurenční firmy. Nejinak je tomu v IT odvětví, ve kterém se mnou modelovaná firma Kentico Software s. r. o pohybuje. I její informační systém musí reflektovat všechny podnikové procesy tak, aby byl vývoj samotného produktu co nejefektivnější. Firma má velikou výhodu v tom, že její hlavní výrobek lze po sérii adekvátních úprav s výhodou použít i jako samostatný informační systém. Nemá tedy dodatečné náklady na nákup a správu zvláštního software, který by zajišťoval informační systém. Díky dnes velmi populárním analytickým nástrojům lze podnikové procesy velmi dobře popsat a pochopit jejich vzájemnou provázanost. Jedná se především o nástroje typu Computer Aided Software Engineering (CASE), což v překladu znamená počítačem podporované softwarové (systémové) inženýrství nebo li vývoj software s využitím počítačové podpory. CASE nástroje jsou nástroje, které primárně umožňují: modelování IT systému pomocí diagramů (člověk lépe chápe obrázek než složitě psané slovo), generování zdrojového kódu z modelu (usnadňuje práci programátorům), zpětné vytvoření modelu podle existujícího zdrojového kódu (reverse engeneering), synchronizaci modelu a zdrojového kódu či dokonce vytvoření dokumentace z modelu. Úspěch využití CASE nástrojů záleží mimo jiné na vybrané metodice a způsobu zpracování informací a jejich interpretaci. 1.2 Cíl práce Cílem této práce je analyzovat firemní procesy v reálném podniku (Kentico Software s. r. o.) a provést inovaci části informačního systému. Pro analýzu procesů budu využívat nejdůležitějších diagramů modelovacího jazyka UML spolu s jeho rozšířením pro byznys modelování podnikových procesů. Výslednou analýzu využiji jako podklad pro návrh a realizaci betaverze aplikace knihovní administrativy, která by měla zefektivnit úkony spojené s fungováním knihovny. Tato aplikace bude mít podobu plně integrovaného modulu v rámci existujícího informačního systému. Jako nástroj prezentace návrhu bude sloužit programový prostředek Enterprise Architect od společnosti Sparx System. Aplikace bude vytvořena s použitím objektového programovacího jazyka C# v prostředí ASP.NET a relační databáze MSSQL. Provedené řešení bude následně srovnáno s typově podobným řešením a provedeno

10 1.2 Cíl práce 10 ekonomické hodnocení projektu. Součástí práce je též přehled literatury, která se touto tématikou zabývá, jakož i popis použitých technologií.

11 2 PŘEHLED LITERATURY 11 2 Přehled literatury 2.1 UML Modelovací jazyk UML 1 je souhrnem především grafických notací k vyjádření analytických a návrhových modelů. UML je jazyk, který umožňuje modelovat jednoduché i složité aplikace pomocí stejné formální syntaxe. Tím umožňuje výsledky práce sdílet s ostatními návrháři. Vybrané modely jsou pochopitelné i pro zadavatele aplikace a umožní kvalitní vyjasnění požadavků uživatelů na vytvářený systém. Žádný diagram nezachycuje navrhovaný systém jako celek, ale soustředí se vždy právě na jeden pohled na vyvíjený systém. UML je také jazyk pro vizualizaci, specifikaci, stavbu a dokumentaci softwarových systémů. (Kanisová, Müller, 2006) Jazyk UML je univerzální jazyk pro vizuální modelování systémů. Byl navržen proto, aby spojil nejlepší postupy modelovacích technik a softwarového inženýrství. Je navržen tak, aby jej mohly implementovat všechny nástroje CASE 2. Diagramy vytvořené v jazyku UML jsou srozumitelné pro lidi, ale navíc je mohou snadno interpretovat i programy CASE. Jak zdůrazňuje Arlow a Neustadt (Arlow, Neustadt, 2007, strana 28) je nesmírně důležité uvědomit si, že jazyk UML nenabízí žádný druh metodiky modelování. Samotný jazyk UML však poskytuje pouze vizuální syntaxi, kterou můžeme využít při sestavování svých modelů. Jazyk UML není vázán na žádnou specifickou metodiku nebo životní cyklus. Lze jej použít společně se všemi existujícími metodami. 2.2 Historie UML Historie jazyka UML je velice spletitá a v jeho počátcích trochu chaotická. Existovala spousta jazyků pro vizuální modelování a metodiky. Pokusím se zde uvést ty nejdůležitější mezníky jeho vývoje. Modelovací jazyk UML je výsledkem snažení analytiků a designerů, kteří v průběhu 80. a 90. let vytvářeli metody umožňující popsat objektově orientovanou analýzu a návrh. V polovině 90. let byly velmi rozšířené metody OMT 3, jejich autory byli Booch a Rumbaugh, a dále metodika Ivara Jacobsona - Objectory. (Kanisová, Müller, 2006) V roce 1995 byly zahájeny práce na sjednocení různých metod a syntaxí pro modelování pod záštitou firmy Rational. Výsledkem tohoto snažení bylo v roce 1997 vytvoření první verze modelovacího jazyka UML. (Kanisová, Müller, 2006) V dalších letech se díky sdružení OMG 4 podařilo vytvořit specifikaci RFP 5, která sloužila k standardizaci objektově orientovaného modelování a následný rok 1 UML Unified Modeling Language - unifikovaný modelovací jazyk 2 CASE Computer-Aided Software/System Engineering 3 OMT Object Modeling Technique 4 OMG Object Management Group 5 RFP Request For Proposal

12 2.3 Metodika UP se stává důležitým mezníkem, kdy bylo UML přijato jako průmyslový standard objektově orientovaného jazyka pro vizuální modelování. V roce 2005 vznikla specifikace jazyka UML 2. V jazyce UML 2 bylo zavedeno mnoho nových prvků vizuální syntaxe. Některé z nich nahrazují a objasňují existencí syntaxi verzí UML 1.x. Jiné jsou úplně nové a ztělesňují novou sémantiku přidanou k jazyku. (Arlow, Neustadt, 2007, strana 30) 2.3 Metodika UP Proces vývoje softwaru známý rovněž jako metodika tvorby softwarového vybavení 6 definuje při vývoji softwaru otázky kdo, co, kdy a jak. Projekt UML vznikl z potřeby nabídnout jak vizuální jazyk, tak proces tvorby softwarového vybavení. To, co známe dnes pod pojmem UML, je jazykovou částí projektu, metodika Unified Process je částí procesní. Narozdíl však od jazyka UML není metodika UP standardem organizace OMG. Tato metodika je založena na metodách Ericsson 7, Rational 8 a na dalších zdrojích vycházejících z nejlepších postupů. (Arlow, Neustadt, 2007, strana 53) Důležité je pochopit, že metodika UP je založena na iterativním a přírůstkovém procesu. Celý velký projekt se rozdělí na menší části, které jsou jednodušší na správu a je pak pravděpodobnější úspěšné dokončení. Arlow (Arlow, Neustadt, 2007, strana 60) uvádí pro takovou podčást označení miniprojekt. Každý z miniprojektů je považován za iteraci. Ta obsahuje prvky softwarového produktu jako: Plánování, analýzu a návrh, implementaci, integraci a testování interní nebo externí uvedení. Konkrétně pro metodiku UP jsou v každé iteraci definovány následující pracovní postupy: Požadavky - Zachycují to, co by měl systém dělat. Analýza - Vybroušení požadavků a jejich strukturování. Návrh - Realizace požadavků v architektuře systému. Implementace - Tvorba softwaru. Testování - Ověření, zda implementace funguje tak, jak se od ní očekává. (Arlow, Neustadt, 2007, strana 60) Metodika UP se tedy skládá ze čtyř po sobě jdoucích fází, z nichž každá končí hlavním milníkem. Důležité je, že v každé fázi probíhá iterace s tím, že se mění objem prací vykonávaných v každém z pěti pracovních postupů. Viz obrázek 1. 6 SEP Software Engineering Process 7 Ericsson approach, Rational Objectory Process,

13 2.4 Metodika Select Perspective 13 Obr. 1: Struktura metodiky UP, zdroj: Arlow, Neustadt, 2007, strana 62 Pozn.: R - Requirements, A - Analysis, D - Design, I Implementation, T - Testing 2.4 Metodika Select Perspective Metodika Select Perspective je objektově orientovaná metodika vytvořená Stuartem Frostem a Paulem Allenem z firmy SELECT Software Tools. Vychází z kombinace Objektově orientovaných technik modelování (OMT) Jamese Rumbaugha a Objektově orientovaného softwarového inženýrství (OOSE) Ivara Jacobsona. Select Perspective zahrnuje kromě UML i modelování firemních procesů a datové modelování. Projekt návrhu informačního systému obsahuje tři základní fáze, a to uspořádání (Align), architektury (Architect) a sestavení (Assemble). V každé fázi je vytvořeno několik přírůstků (částí návrhu, které produkují nějaký viditelný výsledek). Fáze uspořádání zabezpečuje dodržení byznys požadavků na systém. Fáze architektury vytváří komponentově orientovanou architekturu. Fáze sestavení dodává řešení složením vývojových částí a komponent. Cílem fáze uspořádání je propojit byznys procesy a programové řešení. Tato fáze obsahuje tyto hlavní aktivity. Musí být provedena analýza byznys procesů díky níž mohou být identifikovány důležité systémové funkce (Use Case). Dále se provádí základní rozhodnutí o architektuře systému (např. o komponentách technické infrastruktury). Je zde také vhodné rozdělit pole aplikace na funkcionální segmenty (komponenty), které pak mohou byt vyvíjeny paralelně. Ve fázi architektury je hlouběji rozpracovaná architektura byznys procesů a technická architektura. Fáze sestavení se detailněji zabývá designem, vývojem a nasazením aplikace. Pro kompletaci a správu komponent se využívá model vytvořit-spravovat-užívat. (Objektová analýza, návrh a programování, 2005) 2.5 Diagramy Jazyk UML se skládá z mnoha grafických prvků, které se dají vzájemně kombinovat do podoby diagramů. Účelem diagramů je představit několik pohledů na systém. Tato skupina pohledů se nazývá model. Model jazyka UML popisuje, co má systém dělat. Neříká nám však, jak systém implementovat. (Schmuller, 2001, strana 16)

14 2.5 Diagramy 14 Ve všech nástrojích CASE založených na jazyku UML jsou každý nově vytvořený předmět nebo nově vytvořená relace automaticky přidávány do vznikajícího modelu. Diagramy jsou okna nebo pohledy na model. Diagram není model! Celkem existuje třináct různých typů diagramů UML. (Arlow, Neustadt, 2007, strana 37) Obr. 2: Rozdělení diagramů, zdroj: Arlow, Neustadt, 2007, strana 37 Uvedené diagramy je možné rozdělit na ty, které modelují statickou strukturu systému (kde jsou zachyceny předměty a strukturní asociace mezi předměty) a na ty, které modelují dynamickou strukturu (kde je zachycen způsob, jímž na sebe tyto předměty působí). Podrobné rozdělení je znázorněno na obrázku 2. Systém je možné namodelovat za použití různých diagramů, které jazyk UML nabízí. Pro modelování podnikového systému v této práci jsem použil následujících diagramů: diagram podnikových procesů 9, Use Case diagram 10, diagram tříd, sekvenční diagram, diagram aktivit, stavový diagram a ERD diagram Diagram tříd - Class diagram Řepa označuje diagram tříd jako interní model a definuje ho následovně Diagram tříd je základním diagramem UML, slouží popisu a klasifikaci tříd objektů a jejich vzájemných vztahů. (Řepa, 2007, strana 148) Diagramy tříd poskytují modelářům tři důležité objektově orientované konstrukce: strukturu dědičnosti, strukturu asociací a vztah mezi celkem a částmi. (Page-Jones, 2001, stana 100) Kanisová definuje diagram tříd poměrně detailněji - Diagramy tříd zobrazují statickou stránku systému, především vztahy mezi třídami. Vztahy, které jednotlivé třídy navzájem pojí, jsou asociace, agregace, kompozice a specializace/generalizace. Podřízenost jednoho objektu vůči druhému je v analýze chápána dvojím způsobem, buď jako agregace, nebo jako kompozice. (Kanisová, Müller, 2006, stana 55) 9 Též označovaný zkráceně BPM Business Process Model 10 Dále uváděn pod jedním z označení - buď diagram přípaů užití nebo Use Case diagram.

15 2.5 Diagramy 15 Arlow pak vysvětluje, jak vypadá analytická třída - analytické třídy: Reprezentují křehkou abstrakci problémové domény. Měly by mapovat pojmy skutečného světa. Nejdůležitějším aspektem analytické třídy je skutečnost, že by měla jednoznačně mapovat určitý pojem skutečného obchodního světa, jako je třeba zákazník, produkt nebo účet. (Arlow, Neustadt, 2007, strana 173) Na začátku projektu při analytické činnosti (při sestavování diagramu tříd) hledáme objekty v problémové oblasti. Třídy objektů pak představují zobecnění reálných objektů modelovaných v zájmové oblasti. Každý objekt poskytuje služby prostřednictvím svých operací. Minimální podoba analytické třídy se skládá z následujících součástí: Název Obsahuje název třídy, který je povinný. Atributy Atribut jakožto nositel informací o objektu je definován svým jménem, formátem a viditelností. Název atributu jednoznačně pojmenovává danou vlastnost objektu. Dále pak definujeme formát atributu. Při modelování analytického návrhu máme většinou k dispozici formáty běžně používané v objektových vývojových prostředích (např. integer, long, array, boolean atd.). Poslední charakteristikou atributů objektové třídy je jejich viditelnost. V UML rozlišujeme tyto základní typy: Public (veřejný přístup: kterýkoliv element systému může k těmto atributům přistupovat), Private (soukromý přístup: k atributům mají pouze přístup operace implementované v dané třídě), Protected (chráněný přístup: k atributům mají přístup pouze operace implementované v dané třídě a v jejích potomcích. Operace Nedílnou součástí struktury objektu je jeho chování, které je definováno operacemi. Některé z těchto operací poskytují rozhraní ostatním objektům, které požadují služby tohoto objektu. Operace, stejně jako atributy, mají svou charakteristiku. Ta je dána jejich názvem seznamem parametrů a návratovými hodnotami. Stereotypy Stereotypy jsou založeny na existujících elementech jazyka UML a upravují jejich význam. Každý stereotyp se vytváří přidáním dvojice lomených závorek s názvem stereotypu k původnímu elementu «Název sterotypu». Mohou být zobrazeny, pokud vylepšují model. (Kanisová, Müller, 2006, strana 56) Stereotyp je meta-třídou UML, pomocí níž lze definovat virtuální podtřídy standardních meta-tříd UML s novými meta-atributy a přidaným významem. Stereotypy tak umožňují zavádět nové typy elementů modelu. Lze si tak vytvořit nový stereotyp a ten pak přiřadit k vybranému elementu modelu. Každý stereotyp definuje

16 2.5 Diagramy 16 určitou množinu vlastností, které bude mít element daného stereotypu a pravidla, která musí element držet. (Řepa, 2007, strana 145) Diagram případů užití - Use Case diagram Schmuller (Schmuller, 2001, strana 18) definuje případ užití (Use Case) následovně případ užití je popis chování systému z pohledu uživatele. Pro vývojáře systému je to cenný nástroj: je to osvědčený způsob shromáždění údajů o požadavcích systému z hlediska uživatele. Obzvláště důležité je to v případě, kdy je nutné vytvořit systém, který by mohli používat normální lidé (nejenom počítačoví maniaci). Přesněji popisuje Use Case diagram Řepa - Diagram Use Case, původně v UML určený ke specifikaci funkčních požadavků a uživatelského rozhraní informačního systému, je chápán jako model, popisující podnikové procesy a jejich interakce s aktéry. Tento model je označován jako tzv. Externí model, sloužící popisu vztahů organizace s okolím. (Řepa, 2007, strana 147) Sestavení seznamu případů užití je jedním z hlavních cílů systémové analýzy. S takovým seznamem je poté možné dále pracovat a využívat ho např. ke katalogizování, je možné se na něj odkázat. Díky němu je možné systém popsat tak, jak ho vidí uživatel. Jak uvádí autor Arlow, modelování případů užití se skládá z následujících aktivit: Nalezení hranic systému. Vyhledání aktérů. Nalezení případů užití. Opakování uvedeného postupu, dokud nedojde k ustálení případů užití, aktérů a hranic systému. (Arlow, Neustadt, 2007, strana 91) Po provedení výše uvedených aktivit získáme sestavený model případu užití, který obsahuje následující komponenty: hranice systému, aktéry, případy užití, relace a volitelně slovníček pojmů 11 Hranice systému První věcí, kterou musíte udělat, přemýšlíte-li o tvorbě softwarového systému, je stanovení jeho hranic. Jinými slovy to znamená, že musíte určit, co je součástí systému a co naopak není jeho součástí. Stanovení hranic systému má obrovský dopad na funkční požadavky (a leckdy i na požadavky nefunkční). (Arlow, Neustadt, 2007, strana 92) 11 Pro praktickou část byl sestaven slovníček pojmů viz přílohu A.

17 2.5 Diagramy 17 Obecně lze pod pojmem okolí systému (subjekt 12 ) rozumět uživatele, procesy a vztahy, jež sice systém ovlivňují, ale nejsou jeho přímou součástí. Aktéři Pod pojmem aktor je důležité přestavit si roli, kterou může v systému hrát mnoho osob nebo jiný systém. Aktorem není nikdy konkrétní osoba. Jedna konkrétní osoba může v průběhu práce vystupovat ve více rolích. Cockburn aktéry rozděluje podrobněji. Podle něj aktéry mohou být: účastníci systému, primární aktéři případu užití, sám vyvíjený systém, pomocní aktéři případu užití, interní aktéři - komponenty systému. (Cockburn, 2005, strana 64) Aktér specifikuje roli, kterou určitá externí entita přijímá v okamžiku, kdy začíná daný systém bezprostředně používat. Může vyjadřovat roli uživatele, roli dalšího systému, který se dotýká hranic vašeho systému. V UML 2 mohou aktéři zastupovat jiné subjekty, což umožňuje propojit různé modely případů užití. Aktéři jsou vůči systému externími entitami. (Arlow, Neustadt, 2007, strana 93) V rámci firemních procesů vystupuje řada firemních aktérů. Ne každý z nich ale komunikuje s daným informačním systémem. Pod pojmem aktér budeme rozumět roli, ve které vystupuje uživatel v rámci své komunikace se systémem. (Kanisová, Müller, 2006, strana 37) V této souvislosti je zajímavou skutečností fakt, že pokud je potřeba modelovat něco, co se systému stane v určitém časovém bodě, je možno zavést jako aktéra čas. Zároveň je ale potřeba, aby tato událost nebyla způsobena žádným jiným aktérem. Případy užití (Use Case) Velmi hezky popisuje případ užití Cockburn - Případ užití představuje dohodu mezi účastníky a uživateli systému o chování systému. Případ užití popisuje chování systému za různých situací ve formě reakcí systému na požadavky jednoho z uživatelů systému, nazývaného primární aktér. Primární aktér vyvolává v rámci případu užití interakci se systémem za účelem dosažení určitého cíle. Systém odpovídá způsobem, při němž chrání zájmy všech uživatelů. V závislosti na zvláštních požadavcích a podmínkách doprovázejících původní požadavek se mohou objevit odlišné způsoby chování, neboli scénáře. Případy užití sdružují tyto rozdílné scénáře v jeden celek. (Cockburn, 2005, strana 19) Arlow pro případy užití udává 2 důležité zásady: Případy užití jsou vždy iniciovány aktérem. Případy užití jsou vždy napsány z pohledu aktéra. 12 UML 2 označuje nově hranice systému jako subjekt.

18 2.5 Diagramy 18 (Arlow, Neustadt, 2007, strana 95) Pro popis a definici případu užití považuje Kanisová za nutné definovat nejprve pojem scénář případu užití. Scénář je sekvence kroků popisujících interakci mezi aktérem a systémem. Poté je možné definovat případ užití jako sadu scénářů, které spojuje dohromady společný cíl. V praxi bývá téměř pravidlem, že případ užití má základní scénář typu všechno jde hladce a řadu alternativních scénářů, které představují postup při zjištění různých chyb, mimořádných stavů a z nich odvozených větví průchodu. (Kanisová, Müller, 2006, strany 39 a 41) Toto všechno směřuje k ulehčení práce při komunikaci s uživateli systému. Případy užití nám zjednoduší pochopení jejich potřeb a tak nám umožní přesnější namodelování systému. Relace V diagramu případů užití se kromě vztahů mezi případy užití a aktéry setkáváme ještě s dalšími důležitými vztahy: Relace «include» objevuje se tam, kde existuje podobná nebo stejná část sekvence scénáře opakující se ve více případech užití. Relace «extend» tímto typem relace přidává rozšiřující případ užití nové, doplňkové chování do základního případu užití. Základní případ užití je sám o sobě zcela soběstačný. Generalizace případů užití - umožňuje převést chování společné pro více případů užití do rodičovského případu užití (Kanisová ovšem tuto techniku příliš nedoporučuje kvůli následné nepřehlednosti). (Kanisová, Müller, 2006, strany 45 a 46) Arlow popisuje výše uvedené relace podobně. Avšak dodává Obecně platí, že byste měli všechny modely udržovat co nejjednodušší. Uvedené relace používejte s rozvahou a jedině tam, kde zlepšují celkovou srozumitelnost modelu případu užití. Klíčová slova «include» a «extend» vás mohou snadno smést přes palubu. (Arlow, Neustadt, 2007, strana 116) Slovníček pojmů Slovníček pojmů je velice důležitou součástí modelování systému. Díky němu je možné se při práci s kolegy a též uživateli samotnými ujednotit na použitém názvosloví. Slovníček pojmů poskytuje lexikon klíčových obchodních termínů a definicí. Jednotlivým položkám v tomto slovníku by měli rozumět všichni, kdo se na projektu určitým způsobem podílejí - včetně uživatelů. (Arlow, Neustadt, 2007, strana 97) Sekvenční diagram - Sequence diagram Sekvenční diagram lze v literatuře najít též jako diagram posloupnosti. Oproti statickým diagramům se sekvenční diagramy nezabývají pouze jediným objektem a změ-

19 2.5 Diagramy 19 nami, kterými tento objekt prochází. Je tedy možné popsat to, jak objekt spolupracuje a komunikuje s jinými objekty ve svém okolí. Patří mezi diagramy interakce objektů. Sekvenční diagram je typ diagramu interakce objektů, který zdůrazňuje časovou posloupnost vztahů mezi statickými objekty. S pomocí sekvenčního diagramu dokáži ihned určit, co kdo komu říká a kdy. (Page-Jones, 2001, strana 130) Arlow vysvětluje funkci sekvenčních diagramů následovně: Sekvenční diagramy zdůrazňují časově orientovanou posloupnost zpráv předávaných mezi objekty. Uživatelé většinou lépe a rychleji porozumí sekvenčním diagramům než diagramům komunikačním, protože jsou přehlednější. Sekvenční diagramy znázorňují interakce mezi čárami života jako časově uspořádanou posloupnost událostí. (Arlow, Neustadt, 2007, strana 253) Schmuller popisuje, jak tento diagram vypadá: Diagram sekvencí se skládá z objektů zakreslených běžným způsobem (jako obdélníčky s podtrženým jménem), ze zpráv zakreslených jako plné šipky a z času, který je znázorněn vertikálním postupem v diagramu. Objekty se umisťují do horní části diagramu a zakreslují se vedle sebe zleva doprava. Je vhodné je seřadit tak, aby byl výsledný diagram na pohled co nejjednodušší. Směrem dolů od každého objektu míří přerušovaná čára, která se nazývá životočára. Podél životočáry je položen úzký obdélníček nazývaný aktivace. Délka obdélníku naznačuje, jak dlouho aktivace trvá. (Schmuller, 2001, strana 100) Sekvenční diagramy umožňují rovněž znázornění vazeb mezi modelovanými případy užití, tedy vazeb typu «include» nebo «extend». Na diagramech se k tomu používá symbol sondy. Sonda představuje odkaz na jiný případ užití, pro který může být zpracován vlastní sekvenční diagram. (Kanisová, Müller, 2006, strana 70) Komunikační diagram - Communication diagram Ve starší verzi UML 1 je uváděn tento diagram pod názvem diagram spolupráce (Collaboration diagram). Od verze jazyka UML 2 se již nazývá komunikační diagram. Tento diagram se podobá předešlému sekvenčnímu diagramu. Patří rovněž do skupiny diagramů interakce objektů. Umí tedy zobrazit interakce mezi objekty avšak lehce odlišně. Proto se doporučuje používat ho spolu se sekvenčním diagramem. Zobrazuje jednotlivé objekty spolu se zprávami, které zasílají ostatním objektům. Zmíněné dva typy diagramů jsou podobné, dokonce jsou významově ekvivalentní. To znamená, že obsahují stejné informace a je možné převést diagram sekvencí na odpovídající diagram spolupráce 13 a zase nazpátek. Zatímco diagram sekvencí klade při zobrazení důraz především na pořadí jednotlivých událostí, diagram spolupráce zdůrazňuje spíše kontext a uspořádání spolupracujících objektů. Rozdíl lze charakterizovat ještě jinak: Diagram sekvencí popisuje, co se děje v čase, zatímco diagram spolupráce popisuje, co se děje v prostoru. (Schmuller, 2001, strana 113) 13 Resp. komunikační diagram ve verzi UML 2. Platí i pro všechny další výskyty.

20 2.5 Diagramy 20 Page-Jones popisuje komunikační diagram následovně: Diagram spolupráce 14 má tendenci nabývat volnější a flexibilnější formy v tom, jak se kreslí. Rovněž dává stejnou váhu statickým vztahům mezi objekty a dynamickým posíláním zpráv mezi objekty. Diagram posloupnosti je na druhou stranu těsněji organizován a zdůrazňuje časovou sekvenci. (Page-Jones, 2001, strana 123) Jak tento diagram vypadá ve verzi UML 2 se dovídáme v Arlowi, který popisuje komunikační diagram pouze jako podmnožinu sekvenčních diagramů a říká, že tento diagram zdůrazňuje strukturální vztahy mezi objekty. (Arlow, Neustadt, 2007, strana 253) Dále Arlow říká: Komunikační diagramy zdůrazňují strukturální aspekty interakce - způsob spojení životních čar. V UML 2 jsou ve srovnání se sekvenčními diagramy sémanticky poměrně slabé. (Arlow, Neustadt, 2007, strana 267) Porovnání sekvenčních a komunikačních diagramů Kanisová poměrně hezky shrnuje rozdíly obou výše zmíněných diagramů - sekvenčního diagramu a diagramu komunikace - Z praktických zkušeností můžeme doporučit spíše sekvenční diagramy, neboť oceňujeme jejich přehlednost v sekvenci zpracování. Je na nich velmi dobře vidět pořadí probíhání akcí a umožňují zapisovat k jednotlivým krokům slovní popis korespondující se scénářem daného případu užití. (Kanisová, Müller, 2006, strana 75) Vychází při tom z předpokladu, že oba diagramy popisují stejný případ užití. Popis diagramu zde uvádím pouze pro ilustraci. Na radu Kanisové se budu věnovat jen sestavení sekvenčního diagramu Diagram aktivit - Activity diagram Diagram aktivit slouží k modelování podnikových (business) procesů nebo dynamické části modelu (například výpočetní algoritmy). Mohou být autonomní a reprezentovat proces nebo chování operace. Jednotlivé operace mohou být odděleny horizontálně nebo vertikálně. (Objecteering, 2008) Arlow připodobňuje tento diagram k vývojovým diagramům Diagramy aktivit jsou objektově orientovanými vývojovými diagramy. Díky nim lze procesy modelovat jako aktivitu, která se skládá z kolekce uzlů spojených hranami. Ve specifikaci UML 2 mají diagramy aktivit úplně novou sémantiku založenou na Petriho sítích. Existují dvě základní výhody: Formalismus Petriho sítí nabízí větší přizpůsobivost při modelování různých typů cest. Nyní lze v jazyce UML zřetelně odlišit diagramy aktivit od stavových automatů. (Arlow, Neustadt, 2007, strana 286) 14 Opět čti a mysli komunikační diagram.

21 2.5 Diagramy 21 Oddíly v activity diagramu mohou obsahovat své okraje, plavecké dráhy 15 mohou být v případě, že je jejich popis příliš nešikovný, obsahovat dodatečné popisy, oddíly mohou být hierarchicky nebo multidimenzionálně řazeny. (Jan [Zubíček.eu], 2006) Vrana konstatuje, že se diagram aktivit podobá stavovému diagramu, a co je zajímavé, že nahrazuje diagram datových toků - Do jisté míry připomínají variantu stavových diagramů, kde můžeme navíc modelovat tzv. aktivity. Aktivita je synchronní - následný přechod k další aktivitě je vyvolán dokončením aktivity, zatímco ve stavu se čeká na vnější událost. Používají se pro dokumentaci případu užití (jako tzv. workflow). Nahrazují do určité míry v UML neexistující diagramy datových toků. Proti stavovým diagramům mohou navíc kromě akcí obsahovat ještě symbol rozhodnutí, kde je výběr přechodu vázán na přidruženou podmínku. (Vrana, Richta, 2005) Kanisová vyjmenovává jednotlivé elementy diagramu aktivit - Na diagramech aktivit se setkáte s těmito symboly: Akce - Jádrem diagramů aktivit jsou stavy akcí nebo také aktivity. Za aktivitu přitom považujeme stav dělání čehokoliv. Stav akce je dále nedělitelnou jednotkou diagramu aktivit. Přechody - Mezi jednotlivými stavy dochází k přechodům. Tyto přechody nastávají automaticky bezprostředně po ukončení akce. Symbolem pro přechod je šipka od jednoho stavu ke druhému. Hodnocení přechodů - Dalším důležitým elementem diagramů aktivit je hodnocení přechodu, pomocí kterého můžeme přerušit lineární zpracování. Termín hodnocení přechodu se zde používá pro vyjádření logické podmínky, která podmiňuje konkrétní přechod. Rozvětvení - Nebo též rozcestí je právě tím prvkem diagramů aktivit, který umožňuje modelovat paralelní chování. Přitom dochází k rozvětvení přechodu na několik paralelně běžících vláken, které se následně opět spojí. Plavecké dráhy - Diagramy aktivit až dosud modelovaly chování procesů, ale nevypovídaly nic o tom, kdo provádí jednotlivé aktivity. Pro modelování problémové oblasti to znamená, že diagramy aktivit nijak nespecifikují, kdo - jaká osoba nebo jaké oddělení - je zodpovědný za konkrétní aktivity. Abyste mohli použít plavecké dráhy, musíte upravit vaše diagramy aktivit do vertikálních pruhů vzájemně oddělených čarami. Každá taková dráha potom reprezentuje zodpovědnost konkrétní třídy, oddělení nebo osoby. (Kanisová, Müller, 2006, strany ) Stavový diagram - State diagram Velmi pěkně definuje stavový diagram Schmuller - Jednou z možností, jak popsat systémové změny, je prohlásit, že jeho jednotlivé objekty mění v čase svůj stav. Tato změna stavu je reakcí na události či na prostý fakt, že čas ubíhá. Všechny tyto změny lze popsat tzv. stavovým diagramem. Stavový diagram dokáže reprezentovat 15 Swimlane obdélníkové oddíly v activity diagramu

22 2.5 Diagramy 22 všechny stavy, do nichž se objekt může dostat, a také podmínky přechodů mezi jednotlivými stavy. Stejně tak je možné zadat počáteční a koncový stav každého objektu. (Schmuller, 2001, strana 89) Stavový diagram lze použít pro popis dynamiky objektu, pokud má tento objekt dynamické chování. Každý objekt, který se může nacházet v různých stavech, by měl mít svůj stavový model. Stavové diagramy lze dále použít pro popis metody třídy, pokud známe algoritmus, kterým má být realizována. Často se stavové diagramy používají pro popis protokolu o komunikaci s jiným systémem či objektem. (Vrana, Richta, 2005, strana 101) Základem stavových diagramů jsou tedy stavy objektů, které se mění v čase. Ty popisuje Kanisová - Stav objektu můžeme charakterizovat tak, že se jedná o konkrétní situaci, která nastala za doby života objektu. Tato situace je dále charakterizována tak, že během ní objekt vyhovuje nějaké podmínce, realizuje konkrétní operaci nebo třeba jen čeká na příchod události - stimulu. Tímto stimulem bývá událost, ale může to být rovněž požadavek na operaci. Objekt v průběhu svého života mění stav. Stav objektu je dán hodnotami atributů objektu, aktuálními spojeními s ostatními objekty a právě prováděnou operací. (Kanisová, Müller, 2006, strana 87) Arlow k základním prvkům stavových diagramů přidává kromě stavu ještě událost - specifikaci určitého výskytu něčeho v čase a prostoru. A dále Přechod - posun z jednoho stavu do jiného v důsledku nějaké události. (Arlow, Neustadt, 2007, strana 428) Symbolika stavového diagramu je velice jednoduchá. Stav je znázorněn jako obdélník se zakulacenými rohy (může být rozdělen na tři části: název, stavové proměnné, činnosti). Přechod mezi stavy symbolizuje plná šipka. Plný kroužek pak značí počátek a druhý kroužek s bílým okrajem představuje konec. Stav může dále obsahovat akce a aktivity. Přitom za akci považujeme nepřerušitelný rychle probíhající proces, zatímco aktivita je přerušitelný, jistou dobu trvající proces. Kanisová popisuje jak lze stav zachytit pomocí diagramu - Každý stav má dvě implicitní akce - vstupní a výstupní, které jsou svázány s událostmi entry a exit. Událost entry proběhne automaticky jako první při přechodu do daného stavu objektu a zároveň spustí asociovanou vstupní akci. Analogicky událost exit je poslední událostí daného stavu objektu a opět spouští asociovanou výstupní akci. (Kanisová, Müller, 2006, strana 87) Entitně-relační diagram - Entity-relationship diagram Objektové databáze jsou v současnosti ještě v plenkách. Jejich rozmachu brání hlavně kvalita současných relačních databází a jistá uživatelská věrnost k zaběhlým dobře fungujícím relačním modelům datového modelování. Proto je nutné se takovýmto datovým entitně-relačním modelem zabývat a pracovat s ním. Jak uvádí Kanisová metodiky rozdělují datový pohled na logický a fyzický datový model.

23 2.5 Diagramy 23 Logický model Logický datový model je nezávislý na implementaci, není tedy třeba v této fázi analýzy brát v úvahu cílové prostředí, tj. konkrétní typ relační databáze. Pro logický model jsou charakteristické následující pojmy: 1. Entita - Reprezentuje určitý typ objektů. Objekt je nějaká existující realita o které jsou zaznamenávány charakteristické údaje (atributy). Stejné typy entit tvoří třídu datových entit. Název je tvořen podstatným jménem v jednotném čísle. V podstatě můžeme říct, že entita je v logickém návrhu to, co ve fyzickém návrhu relační tabulka. 2. Atribut - Je údaj charakterizující entitu. Jak entity, tak i vztahy mohou obsahovat atributy. Atributy se zobrazují jako elipsy propojené čarou s jejich vlastnící entitou. Každá entita musí mít nejméně tolik atributů, aby byla za všech okolností jednoznačně identifikovatelná. Atribut se jeví ve fyzickém návrhu jako sloupec tabulky. 3. Vazby Představují logické vztahy mezi entitami, vyjadřuje se slovesem. Důležité je i stanovení charakteru vazby (kardinalitu). Kardinalita popisuje vztah mezi výskyty záznamů svázaných entit. Může být následující: 1:1, 1:N, M:N. 4. Klíče - Každá entita má své atributy. Jeden nebo více atributů má význačnější úlohu než ostatní atributy. Takovému atributu se říká klíč. Rozlišujeme různé typy klíčů: primární (Primary key), alternativní (Alternative key) a cizí klíč (Foreign key). (Kanisová, Müller, 2006, strana ) Fyzický model Fyzický model zohledňuje zvolenou relační databázi. Pro něj jsou důležité následující pojmy: 1. Databáze - Je organizovaná struktura dat uspořádaná do tabulek. 2. Tabulka - Je datová struktura organizovaná do řádků a sloupců. Je to vlastně dvourozměrná matice s pojmenovanými sloupci a řádky obsahující vlastní data. 3. Řádek - Nese danou informaci o jednom výskytu entity uloženou v databázi. 4. Sloupec - Je totéž, co v logickém návrhu atribut, představuje druh atomické informace Model podnikových procesů - Business process model Jedním z nejpoužívanějších profilů UML pro potřebu modelování podnikových procesů je profil H. Erikssona. Tento profil je založen na čtyřech základních pohledech na organizaci: Strategický pohled (vize organizace) - zahrnuje klíčové pojmy - hodnoty firmy a její strategické cíle. Zaměřuje se na hlavní problémy a úmysly, které mají být procesní změnou řešeny.

24 2.6 CASE nástroje - Enterprise Architect 24 Procesní pohled - zahrnuje podnikové procesy, činnosti v organizaci a hodnoty, které tyto aktivity vytvářejí. Popisuje vzájemnou spolupráci procesů a využívání zdrojů za účelem dosažení strategických cílů definovaných ve vizi organizace. Strukturní pohled - zahrnuje zdroje organizace, jako jsou organizační jednotky, produkty, dokumenty, informace, znalosti atd. Chování organizace - zahrnuje jak vnitřní chování, tak interakci jednotlivých prvků organizace (zdroje a procesy). Jedním z nejdůležitějších cílů analýzy interakcí je přiřazení odpovědnosti za jednotlivé zdroje. (Řepa, 2007, strany 149) Úroveň detailu každého pohledu zahrnutá v modelu a textovém dokumentu včetně definicí je závislá na jeho účelu. Jestliže model obsahuje vysokou míru abstrakce pohledu, jsou popisy obecnější, některé informace nejsou na první pohled viditelné, naopak v případě velmi komplexního a vysoce detailního popisu může vzniknout těžko pochopitelný a nepružný model. Stanovení základního využití architektury je tedy stěžejní pro rozhodnutí o přiměřené hladině detailu každého pohledu. (Rábová, 2008, strana 52) Eriksson se dále vysvětluje důvod vzniku UML rozšíření známého jako Eriksson- Penker Business Extension - Je důležité si uvědomit, že UML bylo původně vytvořené za účelem modelování softwarové architektury a přestože existují podobnosti mezi softwarovým a podnikovým systém, jsou tu i odlišnosti. Podnikové systémy mají mnoho jedinečných vzorů, které není možné zachytit programovým kódem. Mohou to být lidé pracující v podniku, rukodělná výroba, pravidla a cíle, které určují podnikový proces. A jelikož UML bylo původně navrženo k popisu softwarového systému, muselo být rozšířeno, aby jednodušeji identifikovalo a vykreslilo důležité aspekty procesů, cílu, zdrojů a pravidel podnikového systému. (Eriksson, Penker, 2000) 2.6 CASE nástroje - Enterprise Architect Zkratka CASE je označením pro Computer Aided Software Engineering nebo také Computer Aided Systems Engineering. CASE nástroje jsou nástroje, které primárně umožňují: modelování IT systému pomocí diagramů (člověk lépe chápe obrázek než složitě psané slovo), generování zdrojového kódu z modelu (usnadňuje práci programátorům), zpětné vytvoření modelu podle existujícího zdrojového kódu (Reverse engineering), synchronizaci modelu a zdrojového kódu, vytvoření dokumentace z modelu. CASE nástroje jsou postaveny tak, aby podporovaly týmovou práci při vývoji systému, zajišťují sdílení rozpracovaných fragmentů, správu vývoje, sledují konzistenci modelu systému, automatizují některé procesy, hlídají dodržování zvolené metodiky, některé umožňují řízení celého životního cyklu aplikací. (Barclay, Padusenko, 2001)

25 2.7 Použité technologie 25 Při modelování rozsáhlého systému v jazyce UML je tedy nezbytné využít nějakého CASE nástroje. Pro svoji práci jsem si vybral software Enterprise Architect 7.1. Ten představuje silný nástroj pro UML modelování a analýzu pokrývající vývoj software od počátečního získávání informací, přes analytické fáze, tvorbu modelů po testování a údržbu. Jeho nespornou výhodou je, že podporuje všech 13 diagramů definovaných jazykem UML Použité technologie XHTML XHTML 16 je značkovací jazyk pro tvorbu hypertextových dokumentů v prostředí WWW vyvinutý W3C. Původně se předpokládalo, že se stane nástupcem jazyka HTML, jehož vývoj byl verzí 4.01 ukončen. V roce 2007 však došlo k založení pracovní skupiny, která má za cíl vytvořit novou verzi HTML, která ponese označení HTML 5 a její XML variantu XHTML 5. Vedle toho paralelně pokračuje i vývoj XHTML 2.0. (Wikipedia HTML, 2009) CSS CSS je zkratka pro anglický název Cascading Style Sheets, česky tabulky kaskádových stylů. Je to jazyk pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML. Jazyk byl navržen standardizační organizací W3C, autorem prvotního návrhu byl Hakon Wium Lie. Byly vydány zatím dvě úrovně specifikace CSS1 a CSS2, dokončuje se revize CSS 2.1 a pracuje se na verzi CSS3. Hlavním smyslem je umožnit návrhářům oddělit vzhled dokumentu od jeho struktury a obsahu. (Wikipedia CSS, 2009) ASP.NET ASP.NET je součást.net Frameworku firmy Microsoft pro tvorbu webových aplikací a služeb. Ačkoliv název ASP.NET je odvozen od starší technologie pro vývoj webů ASP, obě technologie jsou velmi odlišné. ASP.NET je založen na CLR 17, který je sdílen všemi aplikacemi postavenými na.net Frameworku. Programátoři tak mohou realizovat své projekty v jakémkoliv jazyce podporujícím CLR, např. Visual Basic.NET, C#, ale i mutace Perlu, Pythonu a další. Aplikace založené na ASP.NET jsou také rychlejší, neboť jsou předkompilovány do jednoho či několika málo DLL 18 souborů, na rozdíl od ryze skriptovacích jazyků, kde jsou stránky při každém přístupu znovu a znovu parsovány. (Wikipedia ASP.NET, 2009) 16 XHTML Zkratka anglického extensible Hypertext Markup Language 17 CLR Common Language Runtime 18 DLL Dynamic Linking Library

26 2.8 Ekonomická efektivnost zavedení IS 26 C# C# je vysoce úrovňový objektově orientovaný programovací jazyk vyvinutý firmou Microsoft zároveň s platformou.net Framework, později schválený standardizačními komisemi ECMA 19 a ISO 20. Microsoft založil C# na jazycích C++ a Java (a je tedy nepřímým potomkem jazyka C, ze kterého čerpá syntaxi). C# lze využít k tvorbě databázových programů, webových aplikací a stránek, webových služeb, formulářových aplikací ve Windows, softwaru pro mobilní zařízení (PDA a mobilní telefony) atd. (Wikipedia C#, 2009) MSSQL Systém řízení báze dat MS SQL Server je natolik robustní a spolehlivý, že tvoří databázovou vrstvu aplikací podnikových informačních systémů strategického významu. Jeho nasazení jako databáze pro interaktivní internetové aplikace je také běžné. Výhodu, že MS SQL obslouží 21 bez problému provozní informační systém firmy i její interaktivní webovou prezentaci, lze spatřovat v jednoduchém propojení těchto aplikací, a z toho plynoucí výhodu pro elektronické obchodování. (Interval, 2002) 2.8 Ekonomická efektivnost zavedení IS Analýza efektivnosti je poměrně náročná a můžeme ji vyjadřovat několika způsoby, jež charakterizují: výstupy z určitého procesu (hrubý odbyt, výroba zboží apod.), rozdíly mezi výstupy a vstupy určitého procesu, relace výstupů ke vstupům určitého procesu, relace rozdílů výstupů a vstupů určitého procesu ke vstupům do tohoto procesu. V praxi se výše uvedené formy vyjádření efektivity často kombinují. Pro určování efektivnosti se využívá celá soustava konkrétních kritérií a ukazatelů, což vede k otázce určení hlavního souhrnného kritéria, které by celá soustava měla odrážet a vyjadřovat. Efektivnost se bude určovat při zavádění nové filozofie i při převodu některých subsystémů na nový způsob zpracování. Jedná se o to, aby i po určité době bylo možno kontrolovat, do jaké míry se splnily předpoklady, s nimiž se v přípravných pracích počítalo. Pro určování efektivnosti zavádění automatizačních prostředků se používají základní a doplňkové ukazatele. Základními ukazateli jsou náklady a výnosy, z nichž se další ukazatele odvozují. Vychází se nejčastěji ze srovnávací metody, přičemž se navzájem srovnávají různé varianty řešení. Metodické pokyny určování ekonomické efektivnosti informačního systému vycházejí z principu zjišťování a porovnávání nákladů a přínosů, které jsou s tvorbou 19 ECMA European Computer Manufacturers Association 20 ISO International Organization for Standardization 21 Anglicky: to serve obsluhovat, proto server obsluha

27 2.8 Ekonomická efektivnost zavedení IS 27 automatizovaného informačního systému spojeny. Mezi nejzávažnější přínosy, určující ekonomickou efektivnost patří: růst objemu výroby na základě intenzifikace a optimalizace výrobního programu, zvýšení rytmičnosti práce, lepší využití fondů, zvýšení úrovně a operativnosti řízení účelným a včasným sběrem informací o průběhu plnění plánu a jejich rozboru pro manažery, zvýšení produktivity práce v důsledku snížení prostojů, přijetí včasných opatření, která zamezí narušování plánu plnění úkolů apod. Další přínosy lze shrnout do skupin: oblast zásobování a odbyt, finanční hospodářská činnost, plánování, administrativa a řízení. (Pezlar, Rybička, 2002)

28 3 ANALYZOVANÁ FIRMA 28 3 Analyzovaná firma 3.1 Předmět podnikání Firma Kentico Software s. r. o. (dále jen Kentico) založená v roce 2004 Ing. Petrem Palasem, se zabývá zejména vývojem Content Management Systému (viz sekci 3.3) pro vývojáře v prostředí ASP.NET Kentico CMS for ASP.NET (dále jen Kentico CMS), ale i softwaru pro porovnávání databází Kentico Compare SQL a synchronizaci serverů Kentico Server Sync. Firma jež byla založena ve skromných podmínkách, dnes sídlí na ulici Křižíkova v Brně a čítá již více než 41 zaměstnanců a řadí se mezi přední světové firmy v rámci svého oboru. Cílem firmy je dodávat svým zákazníkům kvalitní a stabilní systém, jehož stále se zdokonalující vlastnosti a nové moduly přinesou jeho uživatelům, tedy převážně vývojářům, zjednodušení jejich práce, nové technické možnosti a úsporu času při vývoji sofistikovaných webových systémů. V roce 2008 bylo Kentico Software vyhlášeno nejrychleji rostoucí českou firmou v žebříčku FAST 50 Rising Stars vyhlašovaném společností Deloitte a to díky jejímů 553% růstu v průběhu posledních tří let. Tržní orientace Pouze zhruba 1% obratu firmy se uskutečňuje v rámci trhu ČR, produkce firmy se uplatňuje převážně v anglofonních Zemích - zejména pak v USA a Velké Británii, výjimkou však nejsou i státy jako Spojené Arabské Emiráty, Nový Zéland, Izrael nebo Indie. Momentálně na redakčním systému Kentico CMS funguje více než 2000 webových portálů v 74 zemích světa. Veškerá komunikace se zákazníky tedy nutně musí probíhat v angličtině. Tomu je podřízena i vnitro-firemní komunikace, která ovšem není tak striktní (alespoň co se verbálního projevu týče). Nicméně všechny důležité dokumenty týkající se fungování firmy, její struktury a vnitřních nařízení jsou pořizovány v angličtině. Je to důležitý krok pro budoucí růst firmy, díky němuž je možné velice rychle zaškolit nového zaměstnance i v případě, že nemluví česky. Z tohoto důvodu bude v dalším textu použito názvosloví diagramů v angličtině kvůli budoucí použitelnosti modelovaných firemních procesů. Také musíme vzít v úvahu fakt, že některé anglické pojmy již čeština přebrala a překladem by se ztratil či posunul význam odborných termínů. Nicméně jednotlivé popisy chování a struktur budou uvedeny v češtině.

29 3.2 Vize, poslání, produkt a cíl Vize, poslání, produkt a cíl Vize Firma složená z profesionálních zaměstnanců, která pomáhá zákazníkům vytvářet pokročilá a kvalitní řešení pro webové prezentace, social networking, Intranet a týmovou spolupráci. Poslání Pomáháme zákazníkům vytvářet, spravovat a rozvíjet pokročilá a kvalitní řešení pro webové prezentace, social networking, Intranet a týmovou spolupráci. Přispíváme k růstu našich zákazníků a partnerů. Podporujeme profesní a osobní růst našich zaměstnanců. Produkt Kvalitní, včas vydaný, prodaný a zaplacený, plně funkční software, který odpovídá specifikaci vycházející z požadavků zákazníků, s rychlou a přesnou zákaznickou podporou. Cíl Chceme být globální jedničkou na trhu komplexních CMS systémů na platformě.net v segmentu malých a středních firem v cenovém rozmezí 1000 až dolarů do konce roku Chceme rozvinout partnerskou síť na 2000 aktivních partnerů do konce roku Chceme vytvořit profesionální, motivovaný tým s nadstandardním ohodnocením do konce roku CMS Redakční systém neboli Content Management System, tedy CMS, je všeobecný software na správu obsahu. Ten se může skládat z textů, obrázků a jiných mediálních elektronických souborů. Účelem CMS systému je přehledně spravovat obsah různého druhu a umožnit většímu počtu osob přístup k jistým materiálům. Toto značně ulehčuje komunikaci, zvláště ve firmách. Redakční systém je vhodný pro všechny správce a majitele webů, na kterých je nutné často aktualizovat obsah. Všechny webové portály a elektronické obchody využívají nějaký CMS systém. V dnešní době je však stránka s CMS systémem finančně dostupná i pro malé podnikatele a jednotlivce. Tímto způsobem je možno ušetřit na nákladných aktualizacích Kentico CMS Kentico CMS je nyní možné získat ve verzi 4.0, která nabízí kompletní nástroje a možnosti pro tvorbu webových stránek ať už jde o velké weby společností, komunitní weby či osobní stránky, e-shopy, ale i intranet nebo běžnou týmovou spolupráci.

30 3.4 Organizační struktura 30 Vývoj nových verzí produktu Kentico CMS aktivně sleduje trendy v oblasti internetových technologií a potřeby svých zákazníků. Zatímco původní verze produktu Kentico CMS pokrývala potřeby robustního redakčního systému, součastné verze jdou daleko za jeho obzor - jejich součástí jsou moduly řešící internetový obchod, uživatelské blogy, webfarmy, sociální sítě ale i nástroje internetového marketingu jako je sledování úspěšnosti reklamních kampaní včetně konverzního poměru zákazníků. 3.4 Organizační struktura Firma Kentico se řadí mezi malé až střední firmy operující na trhu CMS systémů. Většina zaměstnanců se podílí na vývoji produktů firmy, další skupiny zaměstnanců tvoří web designéři, testeři, obchodníci a pracovníci technické podpory. Jednotliví pracovníci jsou rozděleni zcela transparentně v rámci jednotlivých klobouků 22. Role každého zaměstnance je předem daná, ale díky pružnému vedení je možné zaměstnance přeřadit na jinou pozici, respektive zaměstnanci pozici přidat. Z toho vyplývá, že jeden zaměstnanec může zastávat více pracovních pozic (klobouků) najednou. Rozdělení podle divizí Firma Kentico je rozdělena celkem do 9 divizí. Pro činnost firmy je důležité ji rozdělit na části, tedy divize a do nich systematicky přidělit zaměstnance s jejich rolemi a přesně pro ně definovat klobouky. Takový postup by měl zajistit: Každý ví, co má přesně dělat. Zvýšení produktivity pracovníků. Usnadnění zaškolení nových zaměstnanců. Na obrázku 3 a 4 jsou přehledně zobrazeny všechny zaměstnanecké role, tak jak jsou zařazeny do jednotlivých divizí. Tyto jsou ve skutečnosti detailně popsány a jejich klobouky patřičně zdokumentovány. Dokumentace pracovních klobouků probíhá neustále a je zapotřebí soustavné aktualizace. Ucelenou představu lze získat dále v diagramech jednotlivých podnikových procesů. 22 Soubor informací, které obsahují popis pozice ve firmě, manuály k této pozici, checklisty a veškeré související studijní materiály.

31 3.4 Organizační struktura 31 Obr. 3: Organizační struktura role v jednotlivých divizích (horní část)

32 3.4 Organizační struktura 32 Obr. 4: Organizační struktura role v jednotlivých divizích (spodní část)

33 3.5 Současný stav IS Současný stav IS Současný informační systém je založen na běžné verzi vlastního produktu Kentico CMS 3.1 s tím, že jsou k němu přidány speciální uživatelské prvky 23, které pokrývají specifické funkce jako vytváření a sledování statistik, evidence docházky a dovolených, plánování zdrojů atd. To v praxi znamená nutnost přepsání všech takových prvků při případné aktualizaci na nejnovější verzi produktu a proto se zůstává u poslední dobře fungující verze. K informačnímu systému je připojen dříve vyvinutý CRM 24 systém, který zahrnuje moduly pro správu zákaznických kontaktů, správu testování a plánování projektu a navíc plní funkci Ticket systému 25. V současné době jsou tyto dva systémy propojeny společnou bází dat, nicméně využívají jiné GUI 26. Pro vydání nové verze Kentico CMS se počítá se zabudováním nových funkcí intranetu, čímž by se měly rozdíly eliminovat a být jedním kompaktním systémem. 23 Anglicky nazývané Custom controls. 24 CRM - Customer Relationship Management - systém pro řízení vztahů se zákazníky. 25 Ticket system - systém pro správu ových dotazů zákazníků technickou podporou firmy 26 GUI - Graphic User Interface - grafické uživatelské rozhraní

34 4 VLASTNÍ PRÁCE 34 4 Vlastní práce Při objektové procesní analýze podnikových procesů a inovaci současného informačního systému jsem vycházel z metodiky UP. Ovšem vzhledem k možnostem daným rozsahem práce jsem musel některé kroky vynechat a jiné přizpůsobit. Je tedy zřejmé, že jsem se touto metodikou nechal výrazně ovlivnit, avšak v konečném důsledku plynula jakoby v pozadí. To se týká především analýzy a návrhu, kdy tyto kroky mnohdy splývaly. Také iteraci nebylo možné plnohodnotně využít apod. S výhodou jsem tedy tuto metodiku spojil s některými kroky metodiky Select perspective, čímž bylo dosaženo optimálních výsledků. Všechny následující návrhy byly vytvořeny v modelovacím Case nástroji Enterprise Architect Byznys modelování současného stavu Pro byznys model vývoje nové verze produktu budu používat relativně vysokou úroveň abstrakce. To proto, že má sloužit především k revizi stavu, který byl nedávno nastaven. Může být též východiskem pro organizační změny, reengineeringu a inovacím. V první části procesní analýzy se zaměřím na stěžejní podnikový proces, na kterém firma stojí a padá. Je jím proces tvorby nové verze produktu Kentico CMS. Pro názorné představení jednotlivých částí procesu poslouží nejprve diagram podnikových procesů BPM, a následně je pro popis chování odvozen diagram Use Case. Model, zachycen na obrázcích 5, 6, 7 a 8, je navržen tak, aby znázorňoval určitou časovou následnost jednotlivých procesů. K zpřehlednění jsou rovněž v detailních pohledech přidána pořadová čísla procesů, tak jak na sebe navazují Základní pohled procesu vývoje produktu Základní přehlednou kostru procesu tvorby nového produktu poskytuje obrázek 5. Prvotním impulzem pro nastartování procesu je tlak ze strany zákazníků, kteří mají požadavky na novou verzi. Rovněž by se dalo říci, že z ekonomického hlediska je podobně silným impulzem dokončení předešlé verze produktu Kentico CMS, ale ta by sama o sobě nic neznamenala bez poptávky po lepší funkcionalitě produktu. Platí to ale i obráceně - bez potřeby nové verze ze strany zákazníků by nebyl důvod tvořit nový produkt. Celý proces je rozdělen do čtyř základních bloků: 1. příprava a plánování nové verze (Preparing and planninng new version) 2. implementace modulu (Module implementation) 3. kontrola projektu (Review of solution) 4. vypuštění nové verze (New version release) Než je možné začít vyvíjet novou verzi je nutné vzít do úvahy, co vlastně zákazníci

35 4.1 Byznys modelování současného stavu 35 chtějí a potřebují. K dispozici jsou nejrůznější analytické dokumenty v čele s požadavky zákazníků. Přijmou se nejdůležitější a hlavně v daném čase splnitelné požadavky a podle nich se vytvoří projektový plán (Project plan). Zároveň je potřeba, aby měli vývojáři na čem vyvíjet, tedy mít připravený nový projekt (Solution) 27, databázi atd. Projektový plán spolu s novým fungujícím vývojovým projektem jsou výstupy procesu přípravy a plánování nové verze. Tím byl splněn cíl. Vývoj každého jednotlivého modulu je druhým samostatným celkem. Zahrnuje široké spektrum procesů, které budou popsány dále. Nicméně na konci by měl vzniknout modul, odpovídající specifikaci a řádně zdokumentován. Když jsou všechny plánované moduly implementovány, je čas na finální kontrolu a testování výsledného téměř definitivního projektu (Release Candidate) 28 buildu 29. Po řádném otestování vznikne verze připravená do výroby (Ready To Manufacture) 30, která se předá k oficiálnímu vydání zákazníkům. V procesu vypuštění nové verze se především zaškolují zaměstnanci do novinek v nové verzi (Training), tak aby byli schopni perfektně spolupracovat se zákazníky. Posledními kroky jsou pak procesy vydání verze (Publishing) a propagace (Promotion), díky kterým se o nové verzi dozvědí sami zákazníci. Konečným produktem se tedy stává vypuštěná kvalitní verze nového produktu Kentico CMS. Je vhodné si zde povšimnout, že do tohoto podnikového procesu zasahuje 5 z devíti divizí, což ovšem představuje všech 41 zaměstnanců. I to je důvod, proč jsem si pro modelování vybral právě tento proces. V dalších částech budou tyto procesy rozebrány detailněji. 27 Kentico CMS solution seskupení Visual Studio projektů, které tvoří aplikaci Kentico CMS. Toto seskupení lze otevřít ve Visual Studiu tím, že otevřeme soubor s příponou.sln. Kompilací celého solution lze dostat funkční podobu Kentico CMS. 28 Release Candidate RC kompletní build Kentico CMS připravený na finální testování. 29 Build Kentico CMS zkompilované do podoby setupu. 30 RTM Ready To Manufacture build Kentico CMS určený pro release. Původní význam slova byl připravený pro výrobu instalačních médií proto to manufacture

36 4.1 Byznys modelování současného stavu 36 Obr. 5: BPM diagram základní pohled

37 4.1 Byznys modelování současného stavu Příprava a plánování nové verze Příprava a plánování nové verze je podrobně znázorněna na obrázku 6. Jak již bylo řečeno, prvotním impulsem je jak dokončení stávající verze, tak potřeba zákazníků po nových funkcích. Tyto zákaznické požadavky (Requirements) jsou vstupem procesu nazvaného schvalování marketingových požadavků (Approving marketing requirements). Ne všechny požadavky zákazníků mají reálný podtext a není možné je do nové verze zakomponovat (ať už z časového, technického či jiného hlediska). Marketing manager projedná s CTO 31 požadavky, možné zdroje a čas. Tím by se mělo dospět ke schváleným požadavkům na novou verzi (Approved requirements). Schválené požadavky jsou použity ve fázi schvalování analýzy a specifikací (Approving analysis and specification). Je uspořádána schůze, kde si CTO vyžádá vypracování analýzy od analytika (Software architect) a projednává možnosti a specifikace s technickými vedoucími (Technical leader). Analytik vytvoří analýzu, která je schválena CTO (Approved analysis). Jakmile je analýza schválena, může proběhnout schůzka pro plánování projektu (Project planning), kde se všichni účastníci domluví na časových možnostech, nástinu rozvrhu a na dostupných zdrojích. CTO poté připraví přesný plán a přidělí k němu pracovníky. Tedy vznikne projektový plán (Project Plan). Přípravná fáze je skoro u konce. Vše je naplánované, nicméně je ještě potřeba připravit podmínky pro vývojáře, aby mohli mít jakési centrální úložiště svého kódu - vytvořit nový vývojový projekt (Solution), adekvátně pojmenovanou a připravenou databázi, skripty, kódy a data. Tyto kroky provádí buildmaster v procesu přípravy vývojového projektu (Preparing new solution), který dostane od CTO pokyny s číslem verze (Version number), která se bude vyvíjet. Jakmile vše připraví, pošle informaci vývojářům, kteří si upraví vše potřebné na svém počítači. Na obrázku 6 je zobrazen ještě další proces, kterým je knihovní administrativa (Library administration). Jedná se o proces, který umožňuje využít knižních zdrojů (Book) pracovníky, kteří tak získají potřebné znalosti pro vývoj nového produktu (Prepared employee with necessary knowledge). Důležitou skutečností je, že tento proces je možné najít v kterékoliv fázi vývoje a může být tedy využit jakýmkoli jiným procesem. V části 4.3 je dále tento proces popsán detailněji dalšími diagramy. Byl pro něj připraven návrh aplikace. Více o ní se lze dozvědět v části CTO - Chief technical officer - dále bude uváděn pouze pod zkratkou.

38 4.1 Byznys modelování současného stavu 38 Obr. 6: BPM diagram - příprava a plánování nové verze Implementace modulu V této fázi je stěžejním procesem implementace (Implementation). Viz obrázek 7. Tento proces vystihuje tvorbu nové funkcionality na připraveném pracovním projektu a databázi podle předem naplánovaného projektového plánu. CTO, technický vedoucí nebo manager webového vývoje (Web development manager) vytvoří v systému novou funkcionalitu, kterou pak přiřadí příslušnému vývojáři. Ten má za úkol ji vytvořit. Když je hotová, sám ji zběžně otestuje. V případě, že není potřeba schválení nadřízeným, je funkcionalita připravena k testování. Pokud je však zapotřebí vyrobenou funkcionalitu schválit nadřízeným, je tento povinen zkontrolovat kód a funkčnost. Když je vše v pořádku, je funkcionalita připravena k testování. Jestliže je něco v nepořádku, je možné ji označit, že byl nalezen defekt nebo na ní dále pracovat a upravit další specifikace. Nyní je ještě zapotřebí připojit zprávu pro testery, aby

39 4.1 Byznys modelování současného stavu 39 věděli, jak funkcionalitu otestovat. Následuje samotné testování. Je možné, že tester najde defekt a přiřadí funkcionalitu odpovědnému vývojáři k opravení. Musí samozřejmě popsat, jak chybu nasimulovat. Jakmile vývojář defekt opraví, přistupuje se opět k testování. Nakonec, pokud je funkcionalita bez chyb, je jí přidán příznak, že je hotova. K výše popsanému procesu implementace jsou připojeny další, řekněme podpůrné, procesy. Bez nich by se implementace neobešla, resp. nebyl by vyroben kvalitní a odladěný produkt, jak to cíl procesu vývoje zdůrazňuje. Jejich pořadí a návaznost není většinou přesně daná. Proces náprava defektu 32 (Defect fixing) probíhá následovně: Tester nebo vývojář vytvoří defekt (ve smyslu vytvoření záznamu o něm) a přiřadí ho technickému vedoucímu, který je za danou oblast zodpovědný. Ten dále přiřadí svému vývojáři tento defekt na opravení. Jakmile vývojář defekt opraví a otestuje funkcionalitu je označen a připraven k testování. Tester tento defekt na funkcionalitě otestuje kompletně a pokud je vše v pořádku, označí funkcionalitu jako opravenou (Fixed defect). Náprava chyby 33 (Bug fixing) je dalším podpůrným procesem při vývoji nové verze. Pracovník technické podpory, tester nebo vývojář vytvoří záznam o nalezené chybě. Dále proces probíhá obdobně jako náprava defektu jenom s tím rozdílem, že je veden záznam o chybě a na konci je vyprodukována opravená chyba (Fixed bug). Dalším procesem je tvorba ukázkových webových stránek (Sample site making). Ten začíná u CTO, který zadá požadavek na tvorbu ukázkových webových stránek pro managera webového vývoje a poskytne mu k tomu veškeré potřebné materiály. Manager webového vývoje dá pokyn designérovy k vytvoření návrhu designu a následně, je-li vytvořen, je nutné, aby byl schválen nejprve managerem webového vývoje a následně i CTO. Na základě návrhu jsou vytvořeny webovými vývojáři ukázkové webové stránky ukazující nové funkcionality. Ty musí být samozřejmě managerem webového vývoje a CTO schváleny. Následně je dána žádost o vytvoření dokumentace document writerem, která je opět těmi samými pracovníky schválena. Posledním krokem je otestování nově vytvořených webových stránek, který je obdobný, jako při testování chyb a defektů. Výsledkem jsou funkční a zdokumentované webové stránky. Tvorba designu funkcionality (Design implementation) spočívá v tom, že CTO nebo technický vedoucí podá žádost na vytvoření nového designu, který je designéry vytvořen. Opět je zadavatelem zkontrolován. Dokumentace modulu (Module documentation) - pokud technický vedoucí požaduje napsání dokumentace k modulu, dá žádost k document writerovi, který se postará o napsání příslušného popisu. Pokud potřebuje bližší specifikaci k určité funkcionalitě, domluví si schůzku s autorem funkcionality. Ten nakonec vytvořenou dokumentaci schválí. 32 Anglicky Defect - jedná se o chybu v aplikaci nalezenou během vývoje, tedy před vydáním finální verze 33 Anglicky Bug - je chyba v aplikaci nalezená zákazníkem nebo naším zaměstnancem ve finální, vydané verzi.

40 4.1 Byznys modelování současného stavu 40 Pokud technický vedoucí požaduje testování, proběhne proces testování modulu (Module testing). Je vyzván manažer kvality (QA manager), který přiřadí testování dostupným testerem. Ten postupuje podle testovacího protokolu (up-to-date test suite) do té doby než jsou jemu přiřazené funkcionality v modulu otestovány a modul je v konečném stavu (Module tested). Proces lokalizace (Module localization) je nezávislým procesem, který může být spuštěn kdykoliv během implementace. V nové verzi mohou existovat texty, které je nutné přeložit do cizích jazyků. Proto pokud je potřeba překlad, CTO podá požadavek a manažer lokalizací (Localization manager) připraví soubory pro překlad. Ty jsou poslány lokalizačnímu partnerovi, který je přeloží a pošle nazpět. Manažer lokalizací požádá manažera kvality o jednoduché otestování a pokud vše souhlasí jsou lokalizační řetězce přidány do projektu. Završující proces v této fázi je kontrola modulu (Review of single module), kdy jsou všechny funkcionality modulu dokončeny a připraveny. Technický vedoucí zreviduje kód jednotlivých funkcionalit modulu, zkontroluje, jestli není potřeba ještě něco otestovat a navíc zkontroluje, jestli je jeho dokumentace aktuální a úplná. Pokud je vše v pořádku, je možné prohlásit modul za hotový, odpovídající specifikaci a patřičně zdokumentovaný (Module following specification with its documentation).

41 4.1 Byznys modelování současného stavu 41 Obr. 7: BPM diagram implementace modulu

42 4.1 Byznys modelování současného stavu Kontrola projektu Revizi projektu (Solution review) ukazuje obrázek 8. Samotný proces kontroly projektu vypadá tak, že techničtí vedoucí předají hotové a zdokumentované moduly CTO. Ten zkontroluje, zda odpovídají požadavkům, jsou plně implementovány a zdokumentovány. Pokud ano je projekt schválen (Approved solution). Při procesu zkompilování konečného projektu (Build solution) dává CTO požadavek na buildmastera, který toto vytvoří a zkontroluje téměř definitivní zkompilvaný projekt (Release candidate build). Proces testování výsledného téměř definitivního projektu (RC testing) probíhá tak, že všichni testeři ještě jednou testují všechny nové funkce a hledají defekty, které jsou příslušnými vývojáři opravovány v procesu popsaném výše tak, aby mohla být vydána téměř bezchybná verze, která je prohlášena za připravenou ke zpracování (Ready-to-manufacture RTM version). Obr. 8: BPM diagram kontrola projektu Vypuštění nové verze Celý proces je ukázán na obrázku 9. Ve fázi vypuštění nové verze (New version release) je k dispozici verze připravená ke zpracování, která je v procesu dokončení úkonů s verzí připravenou ke zpracování (RTM version finishing) díky CTO nahrána na

43 4.1 Byznys modelování současného stavu 43 příslušná sdílená místa spolu s dokumentací a aktualizačními procedurami. Zároveň se také CTO postará, aby byl aktualizován Virtual lab 34. Poté co CTO vše připraví je ta pravá chvíle pro manažera vztahů se zákazníky (PR manager), aby publikoval novou verzi (Publishing) na webovém portálu firmy (New version published on web site). Zároveň vedoucí prodeje posílá zdrojový kód zákazníkům, kteří mají adekvátní licenci. Také pokud se jedná o vydání hlavní verze zajišťuje rozesílání nových sériových klíčů pro případnou aktualizaci na novou verzi (Source code or serial numbers sent to the customers). Dalším úkolem je též informovat distributory o nové verzi (Updates sent to the distributors). Jakmile je hotová verze připravená ke zpracování jsou zahájena školení na nové funkcionality (Training) pro pracovníky oddělní prodeje (Sales department), oddělení technické podpory (Customer care) a oddělení vztahů se zákazníky (Public relations). Jedním z posledních kroků v procesu vývoje nové verze je propagace (Promotion) nové verze, kdy manažer oddělení vztahů se zákazníky musí upravit a rozeslat oznámení o nové verzi, zaregistrovat novou verzi do katalogů na Internetu a rozeslat ový leták všem stávajícím zákazníkům a uživatelům, kteří si ho vyžádali. Obr. 9: BPM diagram - vypuštění nové verze 34 On-line server, na kterém si mohou uživatelé zadarmo Kentico CMS vyzkoušet.

44 4.2 Use Case model současných podnikových procesů Use Case model současných podnikových procesů Na obrázku 10 je znázorněn celkový náhled na případy užití vznikající v celém procesu vývoje nové verze produktu Kentico CMS. Znázorňuje hlavní procesy ve zmíněném procesu a dále představuje aktory vstupující do vzájemných interakcí. Pro přehlednost byli aktéři sloučeni do jednotlivých divizí tak, jak vystupují v příslušném případu užití. U procesu knihovní administrativa (Library administration) bylo využito zobecnění aktéra, kdy všechny zaměstnance ve firmě zastupuje jeden zaměstnanec (Employee). Náhled na Use Case byl odvozen z předešlého modelu podnikových procesů. Z hlediska rozsahu této diplomové práce zde není nemožné uvést všechny detailní případy užití. Nicméně jako ilustraci popíši jeden z těchto případů užití - Náprava defektu (Defect fixing) Náprava defektu Diagram případu užití náprava defektu (Defect fixing) je zobrazen na obrázku 11. Jedná se o dílčí proces, proto není příliš složitý, ale pro ilustraci bude stačit. Při modelování vycházím z faktu, že je velice důležité vytvářet analytické diagramy tak, aby modelovaným skutečnostem všichni zúčastnění porozuměli. Hlavními aktéry jsou vývojář (Developer), tester (Tester) a technický vedoucí (Technical leader). V případě, že vývojář nebo tester zjistí defekt vytvoří pro něj záznam, který je nutno opatřit detaily. Tento defekt přiřadí technickému vedoucímu, který se postará o přidělení defektu příslušnému zodpovědnému vývojáři. Vývojář nastaví status na Defekt je právě napravován. Poté co jej opraví, otestuje defekt ve svém projektu a nastaví status Defekt napraven. Jakmile ho otestuje ve sdíleném projektu změní jeho status na Připraven na testování. Tester otestuje napravený defekt a jestliže je vše v pořádku změní status na Připraveno k uzavření. Pokud ne, nastaví status opět na Defekt nalezen a celá procedura se opakuje. Na konci případu užití je defekt napraven. Pro názornost je v tabulce 1 uveden i jeho scénář (anglicky).

45 4.2 Use Case model současných podnikových procesů 45 Obr. 10: Use Case diagram - celkový Use Case pohled na proces vývoje

46 4.2 Use Case model současných podnikových procesů 46 Obr. 11: Use Case diagram - náprava defektu Tab. 1: Use Case scénář - náprava defektu Use Case: Defect fixing Short description: When some defect is found it is necessary to fix it. Primary actors: Technical leader, Tester, Developer. Secondary actors: none. Input conditions: 1. Tester or Developer finds a defect. Primary scenario: 1. Tester or Developer creates a defect and assigns it to the responsible TL. 2. Technical leader assigns the defect to the Developer. 3. Defect fixing by the Developer. 4. Developer sets the defect to Defect is being fixed. 5. Developer fixes the defect, tests the defect in the Solution and sets the defect to Defect fixed. 6. Developer tests the fixed defect in the build and sets the defect to Ready for testing. 7. Tester tests the fixed defect and if the defect is fixed correctly, he sets the status to Ready for close, otherwise, he sets the status to Defect found and adds instructions for developer (the process goes to point 3). Output conditions: 1. Defect is fixed.

47 4.3 Zlepšení části podnikového procesu - knihovní administrativa Zlepšení části podnikového procesu - knihovní administrativa Zlepšení části podnikového procesu vnitro podnikové knihovny vychází z provedené analýzy současného stavu informačního systému a základního procesu vývoje produktu. Pro zlepšení podnikové knihovny mě přiměla nedostatečná elektronická podpora pro činnosti týkající se knihovnické oblasti. Pro práci v oblasti informačních zdrojů je velice nutná neustálá aktualizace znalostí a vědomostí, které je možné nabýt v knihách. Ve firmě Kentico jsou nové knihy pravidelně kupovány a aktualizovány, horší je to již s jejich správou. Proto jsem se rozhodl situaci zlepšit a umožnit tak zaměstnancům knihy vypůjčovat, v případě nedostupnosti rezervovat a sledovat jejich knihovnické transakce. Důležitým aspektem při vývoji knihovního systému byla nutnost integrace tohoto řešení do stávající struktury intranetu. Návrh zlepšení vnitropodnikové knihovny je rozdělen do několika částí, které společně popisují základní procesy a struktury systému a poskytují tak analytický pohled na tento knihovní systém. Základem je model podnikových procesů, který názorně představuje živé části systému. Dalším modelem bude diagram případů užití, jež podává představu o chování a jeho reakce na vnější podněty. K němu uvedu ilustrativní scénáře. Následovat bude diagram aktivit, sekvenční diagram, diagram stavů. Pro popis statické struktury bude vykreslen diagram tříd a ERD diagram. 4.4 BPM - knihovní administrativa V procesu knihovní administrativa (Library administration) vystupují tři hlavní aktéři: zaměstnanec (Employee), asistentka (Office assistent) a čas (Time). Zaměstnanec je v tomto případě zobecněním všech ostatních rolí. Tento proces je zobrazen na obrázcích 12 a 13. Nejprve je nutné, aby byla kniha asistentkou přidána (Add new book), poté může být upravena (Modify book), případně smazána (Remove book) ze systému. V každém případě je nutné, aby kdokoli, kdo chce pracovat s knihovnou, byl přihlášený do systému (Login to intranet). Libovolný zaměstnanec může v knihovně hledat knihy (Book searching) a zjišťovat, jestli je dostupná či nikoli. V případě, že ho kniha zaujme, zobrazí si její detail, kde jsou mu vypsány podrobnosti o stavu knihy, dále kolik je dostupných kusů, kolik jich je celkem, kdo má knihu půjčenou případně reservovanou. Pokud není kniha dostupná, je možné knihu rezervovat (Book reservation). Jakmile je kniha vrácena resp. je zrušena rezervace (Cancel reservation) a zaměstnanec bude první ve frontě rezervací, je mu poslán oznamovací , že si může knihu vypůjčit. Pokud tak neučiní během stanoveného počtu dní, je automaticky rezervace zrušena a příležitost vypůjčit knihu dostane druhý, který je na řadě. Děje se tak na základě kontroly plánovačem 35, který prochází rezervace každý den (Check reservation term). 35 Anglicky Scheduler

48 4.5 Use Case - knihovní administrativa 48 Pokud zaměstnanec zjistí, že je kniha k dispozici, jde knihu najít fyzicky v knihovně a zanese jí asistentce. Ta se postará o vyplnění půjčovní lístku knihy a poté zaměstnanci knihu vypůjčí (Borrow book). Jakmile se zaměstnanec rozhodne knihu vrátit přijde s knihou za asistentkou, ta ji zkontroluje, vyplní půjčovní lístek a knihu vrátí (Return book). V tomto momentu je dobré zmínit, že po dohodě s vedoucími jsme se shodli na tom, že nebude nutné vypracovávat kontrolu délky výpůjční doby. Hlavním důvodem byly především zvýšené administrativní nároky takového řešení, kdy by se asistentka musela starat o dodržování lhůt, resp. o sankce při jejich překročení, v nejhorším případě o vymáhání knihy. Jelikož má firma prozatím relativně malý počet zaměstnanců je taková správa bez výpůjční lhůty poměrně snadná. V případě potřeby však není problém v budoucnu funkcionalitu přidat. 4.5 Use Case - knihovní administrativa Use Case procesu knihovní administrativy (Library administration) byl odvozen z procesního modelu, kdy byly přebrány základní procesy ke kterým bylo nutno přidat doplňující případy užití. Znázorněn je na obrázku 15. Podobně jako v modelu BPM zde vystupují tři aktéři zaměstnanec, asistent a čas. Pro názornost uvedu náhled do jednoho konkrétního případu užití - rezervace knihy (Book reservation). Jeho popis je v podkapitole Use Case - rezervace knihy Na obrázku 14 je vidět poměrně triviální, přesto stěžejní případ užití pro rezervaci knihy. Jako aktor vystupuje zaměstnanec (Employee), tedy zaměstnanec s jakoukoli rolí. Vidíme, že pokud je zaměstnanec přihlášen, je mu zobrazen seznam knih. Při požadavku na rychlé nalezení konkrétní knihy může použít vyhledávání. Rezervovat knihu je možné po zobrazení detailu knihy. Ihned je zaměstnanci odeslán oznamovací o rezervaci. Tato rezervovaná kniha se mu objeví v seznamu jeho rezervovaných knih. Scénář procesu rezervace knihy je přidán v tabulce č. 2 (anglicky). Další případy užití by ukázaly, jakým způsobem probíhají ostatní činnosti jako rušení rezervace a především samotné půjčení a vracení knihy. Z rozsahových důvodů je však není možné uvést.

49 4.5 Use Case - knihovní administrativa 49 Obr. 12: BPM diagram - knihovní administrativa 1/2

50 4.5 Use Case - knihovní administrativa 50 Obr. 13: BPM diagram - knihovní administrativa 2/2 Obr. 14: Use Case diagram - rezervace knihy

51 4.6 Sekvenční diagram - rezervace knihy 51 Obr. 15: Use Case diagram - knihovní administrativa 4.6 Sekvenční diagram - rezervace knihy Model Use Case je vhodné doplnit o patřičný sekvenční diagram, který ukazuje jak jdou jednotlivé kroky po sobě. Navíc lze z diagramu vyčíst jak si jednotlivé objekty mezi sebou předávají zprávy. Na obrázku 16 je zobrazen takový sekvenční diagram upřesňující sekvenci úkonů při rezervování knihy (Book reservation). Zde je potřeba si uvědomit, že kniha jako taková je obecný dokument v Kentico CMS, který je založen na typu dokumentu 36. Proto při zobrazení knihy, potažmo jejím rezervování je nutno pracovat jak s dokumentem samotným, tak s tabulkou, ve které jsou uloženy detaily knihy. Nicméně tyto úkony nemusí zaměstnance zajímat, což je též vyznačeno v sekvenčním diagramu. To co zaměstnanec dostane, je v rozhraní (Interface). A opět knihu si může ručně nalézt v seznamu knih, nebo si ji vyhledat pomocí vyhledávání. U knihy se mu zobrazí zda je dostupná spolu 36 Anglicky Document type

52 4.7 Diagram tříd - knihovní administrativa 52 Tab. 2: Use Case scénář - rezervace knihy Use Case: Book reservation Short description: Employee wants to reserve book. Primary actors: Employee. Secondary actors: none. Input conditions: 1. Employee is logged in. 2. Emloyee doesn t have reserved the book. 3. Emloyee doesn t have borrowed the book. 4. Book is not available. Primary scenario: 1. He enters the library system. 2. He can locate desired book within book list or he can search for it. 3. Appropriate book detail is showed. 4. He checks book status. 5. If book is unavailable he can reserve it by pushing Reserve button. Output conditions: 1. Employee has reserved his book. 2. Notification is sent to his . s dalšími detaily a podle toho bude schopný si knihu rezervovat. V takovém případě je mu poslán oznamovací a rezervace je zobrazena v jeho seznamu rezervací. 4.7 Diagram tříd - knihovní administrativa Na základě provedeného návrhu modelu podnikových procesů knihovní administrativy (Library administration) a případu užití je nyní možné sestavit diagram tříd. Již výše jsem uváděl, že tento projekt knihovny má hlavní specifikum v tom, že je nutné ho zaintegrovat do již fungujícího systému. Ten je založen na vlastním produktu Kentico CMS, který nutno říci, je v nynější podobě poměrně rozsáhlý. Z toho vyplývá nejen to, že struktura některých tříd a objektů je předem daná a je nutno z ní vycházet, ale hlavně že většinu operací a atributů ve svém projektu nevyužiji. Tato skutečnost je naznačena třemi tečkami u příslušných tříd. Diagram tříd pro knihovní systém je znázorněn na obrázku 17. Každá přidaná kniha je ve své podstatě obecný dokument (Document) v rámci systému Kentico CMS, jehož datovou strukturu udává dokumentový typ kniha (Book). Aby systém věděl, kde se ve stromové struktuře stránek dokument na-

53 4.7 Diagram tříd - knihovní administrativa 53 lézá, je zapotřebí vést záznam ve třídě strom (Tree). Dokumentový typ je vázán přes třídu (Class) se stromem. O to co je po načtení příslušné stránky zobrazeno se stará příslušná šablona stránky (PageTemplate) obsahující potřebné prvky stránek. O nejdůležitější knihovní funkce se starají třídy vypůjčené (Borrowed) a rezervované (Reserved). Ty spojují knihu se zaměstnancem (Employee) a jednoznačně tak definují výpůjčku, respektive rezervaci. Každý zaměstnanec je pak rozlišován podle své role (Role), která je s ním svázána vazební třídou (UserRole). Podle této role se pak usuzuje, na které operace má či nemá právo. Obr. 16: Sekvenční diagram - rezervace knihy

54 4.8 Diagram aktivit - rezervace knihy 54 Obr. 17: Diagram tříd - knihovní administrativa 4.8 Diagram aktivit - rezervace knihy V této kapitole je ukázán proces rezervace knihy (Book reservation) v diagramu aktivit. Na obrázku 18 je tento proces zobrazen v kontextu s ostatními procesy, které může vykonávat zaměstnanec (Employee). Přestože by z metodického hlediska a rovněž z důvodu přehlednosti bylo vhodné zkonstruovat diagram aktivit pro každý případ užití zvlášť, není možné tyto jednotlivé diagramy kvůli stanovenému rozsahu práce uvést. Jednotlivé uzly týkající se rezervace knihy jsou tedy zvýrazněny oranžovou barvou. Popis procesu je obdobný jako u výše popsaných diagramů. Jenom s malou úpravou, kdy jsem z důvodu přehlednosti zahrnul do procesu Book searching zobrazení seznamu knih (ať už je uživatel nalezl manuálně nebo získal pomocí vyhledávání). Zajímavé jsou ale i další větve pro půjčování knihy, vracení či rušení rezervace. Přehledně je naznačeno, že uživatel může v systému požadovat i jiné operace jako kontrolovat svoje rezervace (Check my reservations list), kontrolovat své aktuálně vypůjčené knihy (Check my borrowed books), kontrolovat svoje předešlé výpůjčky

55 4.9 Stavový diagram - třída kniha 55 (Check my previously borrowed books), kontrolovat, kdo má knihu půjčenou (Check who has borrowed book) či rezervovanou (Check who has borrowed book). Obr. 18: Diagram aktivit - pohled zaměstnance rezervace knihy 4.9 Stavový diagram - třída kniha Pro stavový diagram jsem si určil klíčovou třídu knihu (Book), která je vzhledem k povaze a zaměření projektu nejvíce určující. Tato třída je též jednoznačně nejaktivnější. Změna stavu knihy je důležitá nejen pro zaměstnance, aby věděl, co může

56 4.10 ERD diagram - knihovní administrativa 56 s knihou provádět za operace, ale je to nutné i z technického hlediska, aby se zobrazovaly vždy jen relevantní informace. Diagram je zobrazen v obrázku 19. Základní dva stavy knihy jsou dostupná (Available) a nedostupná (Unavailable). Dále se u jednotlivých stavů rozlišuje, zda jsou jenom vypůjčené (Borrowed), nebo jenom rezervované (Reserved), případně jestli jsou i vypůjčené i rezervované (Borrowed and Reserved) nebo ani jedno dohromady. Pro detailnější rozlišení lze třídu kniha rozdělit do dalších stavů podle toho, jestli má knihu půjčenou aktuální zaměstnanec. Na obrázku 19 lze vidět, jak se mění stav knihy při půjčování, vracení, rezervaci a rušení rezervace, kdy jsou pro každou akci uvedena pravidla, kterých splněním se do cílového stavu přejde. Obr. 19: Stavový diagram - pro třídu kniha 4.10 ERD diagram - knihovní administrativa Před implementací knihovního systému bylo nutné vytvořit datový model systému. Ten vychází z navrženého modelu tříd. Použité entity s příslušnými relacemi jsou zobrazeny na obrázku 20. Následuje výčet a popis entit.

57 4.10 ERD diagram - knihovní administrativa 57 CMS Class Je spojena přes sloupec ClassTableName s adekvátním typem dokumentu z jeho tabulky. V tomto případě jede o tabulku custom book. custom book Tabulka určená typem dokumentu. Obsahuje data knihy. CMS Tree Obsahuje záznam o příslušné třídě v sloupci NodeClassID, kterým je spojena s tabulkou CMS Class. CMS Document Jeho umístění je určeno spojením s tabulkou CMS Tree přes sloupec DocumentNodeID. Ve sloupci DocumentForeignKeyValue je odkazováno na příslušný typ dokumentu, kterým je tvořen. Díky DocumentcreatedByUserID a DocumentModifiedByUserID je možné přiřadit dokumentu uživatele. CMS PageTemplate Každý dokument je založen na určité šabloně stránky. Na tu se odkazuje pomocí DocumumentPageTemplateID. View CMS Tree Joined Jedná se o pohled, který sdružuje všechny informace o dokumentu. Z něj čerpají standardní.net kontroly. CMS User Uchovává informace o uživateli. Může figurovat ve více rolích. CMS Role V rámci jedné role může vystupovat více uživatelů. Na základě role (a příslušných oprávnění pro ni) je určováno, co může uživatel v systému vykonávat za operace. CMS UserRole Jedná se o spojovací tabulku pro uživatele příslušejícího do některé z rolí.

58 4.11 Funkce systému 58 Obr. 20: ERD diagram - knihovní administrativa 4.11 Funkce systému Na základě všech výše uvedených diagramů - tedy diagramu podnikových procesů, Use Case diagramu, sekvenčního diagramu, diagramu tříd, diagramu aktivit, stavového diagramu a ERD diagramu byla vypracována knihovní aplikace, která vystupuje jako proces knihovní administrativa. Jako hlavní cíl si klade přehledné zjednodušení knihovní administrativy a zvýšení komfortu pro jak asistenta, který se o knihy stará, tak hlavně pro samotné zaměstnance. Asistent může knihy do systému přiřazovat do různých kategorií (podle toho kam ve stromové struktuře knihu

59 4.11 Funkce systému 59 umístí) a zároveň s nimi může dle libosti manipulovat pomocí CMS Desku. Tedy jsou-li přítomny knihy, může zaměstnanec po přihlášení vstoupit do knihovny. Zde hned vidí na pravých bočních lištách, které knihy má vypůjčené, které rezervované a které měl v minulosti vypůjčené. Odtud může přímo najet na knihu ze seznamu knih (lze upřesnit kategoriemi), nebo si požadovanou knihu vyhledat přidán byl ajaxový vyhledávací našeptávač, který vyhledávání výrazně ulehčuje. Viz obrázek 21. Obr. 21: Náhled na knihovní aplikaci - seznam knih Po zobrazení detailu knihy jsou vypsány údaje o knize, kdo má knihu půjčenou a kdo rezervovanou. Důležité je zjištění stavu knihy pro aktuálního uživatele, podle čehož je pak odvozováno, které operace mu budou nabídnuty. Zaměstnanec má právo pouze knihy rezervovat resp. rušit rezervace. Pokud se jedná o asistenta, který je oprávněn knihy půjčovat a vracet, dostává možnost navíc zvolit určitého zaměstnance. Výpis zaměstnanců je závislý od toho, jestli je např. kniha rezervovaná potom může při půjčování knihy vybírat jenom z těch, kteří ji mají rezervovanou. Při vracení se pak výběr omezuje pouze na ty, kteří mají knihu půjčenou. Toto výrazně ulehčuje asistentovi práci při hledání adekvátních zaměstnanců. Nástin takového vracení knihy je na obrázku 22. Jakmile si zaměstnanec knihu rezervuje, přidá se do fronty čekatelů. Ta je každý den automaticky kontrolována pomocí plánovače. V případě, že je kniha vrácena či zrušena rezervace, čímž se stane kniha dostupnou, je automaticky urgován první kdo si knihu rezervoval. Ten by si měl knihu během stanoveného počtu dní přijít vypůjčit. Pokud tak neučiní, je díky plánovači rezervace zrušena a je poslán informační dalšímu zájemci v pořadí. Díky tomu se zamezí situacím, kdy si někdo knihu rezervuje, nevyzvedne a tím blokuje všechny ostatní zájemce o knihu. To, že není takový zaměstnanec poslán na konec fronty, ale jeho rezervace je automaticky

60 4.12 Vylepšení systému knihovny 60 zrušena, zabraňuje vzniku situace, kdy by byl ve frontě sám (zacyklil by se a mohl by tak knihu blokovat donekonečna). U všech hlavních činností, tedy půjčování, vracení, rezervace knih a rušení rezervace je samozřejmostí rozeslání oznamovacího u příslušnému zaměstnanci. Obr. 22: Náhled na knihovní aplikaci - detail knihy 4.12 Vylepšení systému knihovny Knihovní systém je zatím pouze ve fázi beta verze. Prostor tedy na další vylepšení stále zůstává. Největší otázkou v tomto okamžiku zůstává, zda a případně kdy bude zaveden systém kontroly výpůjční lhůty. Po konzultacích s vybranými pracovníky jsme dospěli k závěru, že prozatím není tato funkcionalita potřebná, ba dokonce by mohla být kontraproduktivní. Zaměstnanci by mohli být stresováni danou lhůtou pro vypůjčení a nemuseli by stihnout vše nastudovat. Nehledě na to, že si příliš neumím představit jaké by se musely nastavit sankce pro překročení výpůjční lhůty a jak by se v praxi vymáhaly. Myslím si, že v případě malého počtu zaměstnanců, kterým firma Kentico momentálně disponuje, prozatím funkcionalita kontroly výpůjční lhůty chybět nebude. Nicméně stávající návrh ji modeluje a umožňuje poměrně snadnou implementaci řešení pro širší správu výpůjček. Další možnost pro zlepšení představuje administrativní část, u které by bylo vhodné vylepšit použitelnost samotných intranetových stránek tak, aby měl asistent pracující s knihami co nejvíce usnadněnou práci při půjčování a vracení knih. Pokud jde o možnosti zlepšení systému do budoucna, vidím jako velice zajímavou možnost napojení čtečky čárových kódů k systému. Ta by mohla mít případně uplatnění i v jiných firemních procesech jako je například inventarizace majetku.

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

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

Více

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

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

Obsah. Zpracoval:

Obsah. Zpracoval: Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč

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

Business Process Modeling Notation

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

Více

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

Objektově orientované technologie Dynamický náhled Sekvenční diagram (Realizace UC) Daniela Szturcová

Objektově orientované technologie Dynamický náhled Sekvenční diagram (Realizace UC) Daniela Szturcová Objektově orientované technologie Dynamický náhled Sekvenční diagram (Realizace UC) Daniela Szturcová Osnova Modelování interakcí mezi objekty modelování zpráv (mapování zpráv na operace), vytváření a

Více

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

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

Více

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

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

Více

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

Objektově orientované technologie Business proces Diagram aktivit. Daniela Szturcová

Objektově orientované technologie Business proces Diagram aktivit. Daniela Szturcová Objektově orientované technologie Business proces Diagram aktivit Daniela Szturcová Osnova Bysnys proces pojmy metody, specifikace pomocí diagramů Modelování pomocí aktivitního diagramu prvky diagramu

Více

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

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

Více

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53 Objektová tvorba SW, Analýza požadavků 2006 UOMO 53 Osnova Základní principy tvorby SW Fáze tvorby SW v předmětu UOMO Analýza požadavků Modelování typových úloh 2006 UOMO 54 Tvorba SW Dříve umění vyvolených

Více

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

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

Více

UML. Unified Modeling Language. Součásti UML

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

Více

7.6 Další diagramy UML

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

Více

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

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

Více

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

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

Návrh IS - UML. Jaroslav Žáček Návrh IS - UML Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Trochu historie neuškodí Do roku 1994 chaos ve světě objektově orientovaných metod (několik jazyků pro vizuální modelování,

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

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

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

Více

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

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

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

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová Osnova K čemu slouží diagram komponent obsah komponent závislosti rozhraní

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

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

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

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

Více

Modelování informačních systémů s využitím jazyka UML. Jaroslav Šmarda

Modelování informačních systémů s využitím jazyka UML. Jaroslav Šmarda Modelování informačních systémů s využitím jazyka UML Jaroslav Šmarda Využití jazyka UML při vývoji IS na příkladu jednoduché aplikace pro evidenci knih Model IS Modelování případů užití Diagram případů

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

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

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

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

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

Více

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

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

Více

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

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

Více

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

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

Více

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

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

Více

OOT Objektově orientované technologie

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

Více

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

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

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

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

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

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

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

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

PV207. Business Process Management

PV207. Business Process Management PV207 Business Process Management Úvod do BPMN 12. 3. 2009 Petr Vašíček 2007 2009 IBA Group FI MU Obsah přednášky Opakování BPMS Úvod do BPMN Přehled grafických elementů Flow objects Connecting objects

Více

1. Integrační koncept

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

Více

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

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

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

Metodika analýzy. Příloha č. 1

Metodika analýzy. Příloha č. 1 Metodika analýzy Příloha č. 1 Příloha č. 1 1 Účel dokumentu Dokument popisuje závaznou metodiku systémové analýzy, je upraven na míru pro prostředí Podniku. Dokument je provázán s Podnikovou analýzou,

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

Modelování podnikových procesů

Modelování podnikových procesů Modelování podnikových procesů Co je to podnikový proces? Činnost za účelem splnění určitého podnikového cíle (business goal) Provádění časově ohraničeno Vstupní podmínky Při realizaci probíhají vzájemně

Více

CASE nástroje. Jaroslav Žáček

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

Více

Návrh softwarových systémů - architektura softwarových systémů

Návrh softwarových systémů - architektura softwarových systémů Návrh softwarových systémů - architektura softwarových systémů Martin Tomášek, Jiří Šebek Návrh softwarových systémů (B6B36NSS) Převzato z přednášky X36AAS M. Molhanec Co je to architektura Využívá se

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

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

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

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

CASE. Jaroslav Žáček

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

Více

Objekty, třídy, vazby 2006 UOMO 30

Objekty, třídy, vazby 2006 UOMO 30 Objekty, třídy, vazby 2006 UOMO 30 Osnova Vymezení pojmu objekt Objekt a základní objektové koncepty Třídy, třída vs. objekt Vztahy mezi objekty, vazby mezi třídami Polymorfismus 2006 UOMO 31 Vymezení

Více

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

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

Více

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

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

Více

IS pro podporu BOZP na FIT ČVUT

IS pro podporu BOZP na FIT ČVUT IS pro podporu BOZP na FIT ČVUT Závěrečná zpráva pro 2. iteraci 21. dubna 2011 Zadavatel: Ing. Jiří Chludil Řešitelský tým: Jiří Kopecký Jan Kratochvíl Milan Matějček Štefan Pinďák Kristýna Streitová Úvod

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

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

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

Jak správně psát scénáře k případům užití?

Jak správně psát scénáře k případům užití? Jak správně psát scénáře k případům užití? Autor RNDr. Ilja Kraval 2007 http://www.objects.cz K napsání tohoto článku mne inspiroval tento mail: Dobrý den pane Kravale, chci Vás poprosit o radu, která

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

Hierarchický databázový model

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

Více

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

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

Více

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

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

Více

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

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

PRODUKTY. Tovek Tools

PRODUKTY. Tovek Tools Analyst Pack je 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

Více

4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM

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

Více

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

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

Více

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

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

Více

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

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

Více

Novinky ve Visual Studio 2010. Tomáš Kroupa Tomas.Kroupa@hotmail.com

Novinky ve Visual Studio 2010. Tomáš Kroupa Tomas.Kroupa@hotmail.com Novinky ve Visual Studio 2010 Tomáš Kroupa Tomas.Kroupa@hotmail.com O čem si dnes řekneme Visual studio 2010 (beta 2) Jazyk C# 4.0 ASP.NET 4.0.NET 4.0 Visual Studio 2010 Beta 2 Jak získat Testovací verze

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

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

Ú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

U Úvod do modelování a simulace systémů

U Úvod do modelování a simulace systémů U Úvod do modelování a simulace systémů Vyšetřování rozsáhlých soustav mnohdy nelze provádět analytickým výpočtem.často je nutné zkoumat chování zařízení v mezních situacích, do kterých se skutečné zařízení

Více

Diagram sekvencí (sequence diagram)

Diagram sekvencí (sequence diagram) Diagramy sekvencí 1 Diagram sekvencí (sequence diagram) Zobrazuje, jak objekty spolupracují Na rozdíl od stavového diagramu zachycují komunikaci více objektů Popisuje zprávy mezi objekty jaké zprávy, komu

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

Modelování podnikových procesů a návrh informačního systému ve firmě UNIKOL s.r.o.

Modelování podnikových procesů a návrh informačního systému ve firmě UNIKOL s.r.o. Mendelova univerzita v Brně Provozně ekonomická fakulta Modelování podnikových procesů a návrh informačního systému ve firmě UNIKOL s.r.o. Diplomová práce Vedoucí práce: doc. Ing. Ivana Rábová, Ph.D. Bc.

Více

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

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

Více

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

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

Více

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

Návrh softwarových systémů - architektura softwarových systémů

Návrh softwarových systémů - architektura softwarových systémů Návrh softwarových systémů - architektura softwarových systémů Jiří Šebek Návrh softwarových systémů (B6B36NSS) Převzato z přednášky X36AAS M. Molhanec Co je to architektura 2 Využívá se v různách oborech

Více

PODNIKOVÁ INFORMATIKA

PODNIKOVÁ INFORMATIKA GÁLA Libor POUR Jan TOMAN Prokop PODNIKOVÁ INFORMATIKA Obsah O autorech... 11 Na úvod jak chápat tuto knihu... 13 Část I: Principy podnikové informatiky... 17 1. Informatika, aplikovaná informatika, podniková

Více

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů - 1.1 - Kapitola 1: Úvod Účel databázových systémů Pohled na data Modely dat Jazyk pro definici dat (Data Definition Language; DDL) Jazyk pro manipulaci s daty (Data Manipulation Language; DML) Správa

Více