Projektování informačních systémů 10 Modelování v přípravě a projektování IS Doc. Mgr. Petr Suchánek, Ph.D. Doc. RNDr. Ing. Roman Šperka, Ph.D. Převzato od: Ing. Dominik Vymětal, DrSc. Základní pojmy -opakování oMetodika, metodologie nDoporučený souhrn přístupů, zásad, postupů, metod, technik atd. pro tvůrce IS nKdo co a proč oMetoda určuje co je třeba dělat v určité fázi nPřístupy jako funkční, datový, objektový nŘeší postup v určité fázi oTechnika – přesné postupy, oNástroj – prostředek uskutečnění určité činnosti nDiagramy, atd. 2 > Modelování oModel – zjednodušené zobrazení určitého objektu oZobrazuje zpravidla jen ty vlastnosti, které nás v daném kontextu zajímají oV rámci projektování IS model úzce souvisí s pojmem re-engineering oReengineering – Davenport : inovativnost nHammer a Champy: potřeby zákazníka o 3 > Modelování podstata oPři využívání modelů vystupují vždy nejméně dva prvky: nzobrazovaný objekt (originál) njeho model (obraz) oModelování úzce souvisí s BPM – Business process management nBPM má za cíl zlepšit operační účinnost procesů nK tomu využívá oModelování procesu oSimulace procesu oMetody řízení a podpory operativních procesů oZ toho vyplývá, že projekty IS se modelováním úzce souvisí o 4 > Model vs. Diagram (technický plán) oModel je nZjednodušená reprezentace reality nPopis systému z jednoho úhlu pohledu nAbstrakce s konkrétním účelem o oProč modelujeme nUsnadnění úvah díky vyšší abstrakci nLepší porozumění vytvářenému systému nSložitý systém není možné vnímat vcelku n oDiagram njeden pohled do modelu (1:N) ngrafické znázornění n n n 5 L:\franek\plan\1NP.png > Omezení oModely nejsou samospasitelné oVýhody: nMůžeme si ověřit naše rozhodnutí nMůžeme simulovat důsledky změn nMůžeme dnes dokonce simulovat on line oZákladní rizika: nHodnota modelu je omezena souladem modelu s realitou oPříliš „napasované“ – overfitted – nelze použít obecněji oMálo „ napasované“ – underfitted – neúnosná zjednodušení oPřílišná obecnost referenčních modelů oNěkteré nástroje lze použít pouze pro určité SW systémy oNesprávný výběr problémové oblasti - domény 6 > Princip modelování v rámci IS oObjektem zkoumání jsou nprocesy v podniku (procesní modelování) ntok hodnot (hodnotové modelování) oVýsledkem zkoumání je model procesu (toku) v různých stádiích jejich existence nSoučasný nebo minulý stav – deskriptivní model nProjektovaný stav – normativní model o o o 7 > Domény 8 Zdroj: přeloženo z Hrubý > Vývoj v doméně, doménové jazyky 9 Zdroj: přeloženo z Hrubý Jazyk domény > Ontologie oPůvod slova nŘečtina – filozofická kategorie zabývající se základními otázkami bytí nSoftware – definice pojmů a vztahů mezi nimi oGruberova definice ontologie nOntologie je formální specifikace vzájemně sdílené konceptualizace 10 > Ontologie 11 “Study of the categories of things that exist or may exist in some domain.” Sowa, J.: Knowledge Representation: Logical, Philosophical, and Computational Foundations, Course Technology, 1999. “Explicit specification of a conceptualization” Gruber, T. R.: A Translation Approach to Portable Ontology Specifications, Knowledge Acquisition, 1993. > Trojí účel ontologií oKomunikace mezi lidmi (vývojáři, dodavatelé – odběratelé aj.) oPodpora navrhování na konceptuální úrovni oProváděcí specifikace zaváděného systému oTyto tři oblasti nejsou obecně disjunktní!!! o o 12 > Příklad grafické ontologie – Hrubý a REA 13 > Další – negrafická forma ontologie: OWL 14 oWeb Ontology Language oRozsáhlá ontologie určená k popisu tříd a závislostí mezi třídami v rámci webovských dokumentů oZápisy v XML oPříklad zápisu v OWL: Zde RDF – resource description framework – klíčový pojem OWL > Požadavky na přesnost ontologií se různí dle účelu použití o o o o 15 oJestliže má být ontologie použita jako formát specifikující modelování procesů, pak záleží na úrovni automatizace modelování, čím více automatizováno, tím větší požadavky na přesnost specifikace vlastní ontologie oJestliže je ontologie použita jako průvodce modelování procesů, nejsou tyto požadavky tak přísné > Od metodologie k notaci v modelování oKonkrétní forma 3 architektury: nKonceptuální, logická, fyzická oFormy abstrakce na konceptuální úrovní nRůzné druhy schémat nObchodní vzory nOntologie oForma zápisu : notace nPříklad jednoduché notace Infixová notace : 3 + 4, aRb o 16 > Základní typy procesních modelů oCíl modelu: nMějme množinu aktivit A. Cílem je stanovit, které aktivity a v jakém pořadí probíhají v naší doméně. Při tom aktivity mohou probíhat za sebou, paralelně nebo i ve smyčkách. oModely na bázi změny stavu oPetriho sítě oWorkflow sítě oBPMN oIDEF oYet Another Workflow Language o 17 > Co popisují procesní modely? oProcesní modely popisují životní cykly případů v procesu oPříklady případů: nProdejní objednávka nNákupní objednávka nReklamace, nDoplnění skladu oInstance každého případu je pak konkrétní (jedna) např. prodejní objednávka, reklamace, výdejka, apod. 18 > Modelování pomocí obchodních vzorů (Businesss patterns) oVychází z toho, že procesy lze v zásadě zobecnit na určité typy (vzory) oJe podporováno potřebou SOA oPředstavuje určitou mezi úroveň mezi konceptuálním schématem a nižšími úrovněmi – viz později oNepoužívá bloková schémata (dají se ale odvodit) oVyvíjí se od roku 1982 oTypický představitel: REA (autor Bill McCarthy 1982) onyní ISO standard 19 > Obchodní vzory oObchodní vzor je obecně použitelný popis pravidel, která používají vývojáři oJde o to tato pravidla definovat pro určitou oblast ekonomických činností - doménu oPrvní soupisy obchodních vzorů se objevily až v devadesátých letech oDůvodem je, že jsou skutečně použitelné při důsledném použití OO přístupu oDalším důvodem pro vznik obchodních vzorů byly snahy o standardizaci e-commerce 20 > Vzor (pattern) oMějme text nABCDZCKCDCEABCD@EABCD oV tomto textu se určité sekvence znaků opakují – vytvářejí obrazce (patterns) oMyšlenka využít opakujících se činností při analýze a návrhu IS vedla ke vzniku obchodních vzorů 21 > Použití vzorů oNejlepší praktiky oModelování ekonomických procesů oAnalýza činností při reengineeringu oHledání vzorů pro SOA oVýznam použití nSystematické porozumění funkcí podniku nCelostní - konceptuální pohled nAbstrakce od problematiky implementace o 22 > Základy praktického procesního modelování nProces nČinnost nPodnět (činnost vyvolávající) nVazba - návaznost 23 oZákladními prvky každého procesního modelu jsou: > Model struktury oStruktura v různých kontextech oOrganizační struktura nPrincip postupné dekompozice organizační struktury oStruktura procesů nPři postupné dekompozici dojdeme až na jednotlivé činnosti oNástroj – různé typy organizačních schémat oOrganizační schéma 24 Konkrétní osoby – výskyty pracovních pozic > 25 Příklad diagramu hierarchie procesů o o Objednávky Sklad Provoz Vyúčtování > Model procesu oNejjednodušší - vývojový diagram 26 > Standardy oBPM – business process management oWorkflow management oIDEF oISO oAj. 27 > Business process management oMetody a techniky analýzy, tvorby a kontroly podnikových procesů oJiž ze své podstaty je BPM vhodné pro přípravu a tvorbu IS oAktivity BPM: nNávrh nVlastní modelování nMonitorování, měření, statistika nOptimalizace 28 > Fáze BPM (životní cyklus) Projektování IS 29 H:\Knihy\Informační_podpora_podnikových_procesů_Academia_2018\Obrázky_monografie\Obrázek 7.JPG > 30 Notace příklad (část) Workflow management coalition WfMC oMezinárodní organizace pro standardizace systémů workflow nProces: jedna nebo více propojených činností přispívajících k dosažení cíle nZákladní vlastnosti systému workflow: oNávrh pracovního toku (graficky) oDefinice rolí oDefinice pravidel (logika procesu) oPráce s výjimkami oGenerování statistik oMožnost simulací oPřipojování dokumentů k pracovním krokům oRozhraní na databázový systém oSystém upozornění uživatele na termíny, úkoly atd. 31 > IDEF oIDEF = the Integrated Definition nRodina metod vytvořená v USA Projektování IS 32 metoda název metoda název IDEF0 Modelování funkcí IDEF8 Model uživatelského rozhraní IDEF1 Modelování informací IDEF9 Návrh pomocí scénářů IDEF1X Modelování dat IDEF10 Modelování implementační architektury IDEF2 Návrh modelu simulací IDEF11 Modelování informačních artefaktů IDEF3 Popis procesů IDEF12 Modelování organizace IDEF4 OO návrh aplikací IDEF13 Návrh mapování do tří schémat IDEF5 Ontologie IDEF14 Návrh sítí IDEF6 Zdůvodnění návrhu > IDEF0 oModelování rozhodování, akcí, činností v IS nebo organizaci oModelují se nHlavní činnosti nVstupy a výstupy těchto činností nŘídící vstupy nMechanizmus činnosti oZákladní stavební jednotka ICOM n 33 > IDEF0 – ICOM (input, control, output, mechanism) 34 Zdroj: Šperka, Techniky a nástroje modelování podnikových procesů > IDEF1 a IDEF1X oIDEF 1 nInformační model podniku oIdentifikace pojmů a vztahů mezi nimi nMateriál, klik - SM smlouva (vztah kliku k paušálu apod) oVyvodí se základní potřeby funkčnosti IS oIDEF1X nModelování dat oTýká se návrhu relačních databází oNení vhodná pro OO návrh 35 > IDEF3 oPopis chování systému oGrafický jazyk oZákladní element – scénář nZdrojem pro popis scénáře - interview, pozorování oDvě strategie nStrategie zaměřená na procesy : model procesů oUOB Jednotka chování –obecný typ činnosti v systému (např. výdej nářadí pro výrobní zakázku) oVazby mezi jednotkami –popisují vztahy mezi UOB a postup procesu oUzly – logika větvení n 36 > Příklad 37 Zdroj: http://upload.wikimedia.org/wikipedia/commons/c/c8/3-01a_Symbols_Used_for_IDEF3_Process_Description _Schematics.jpg > IDEF3 pokr. nStrategie zaměřená na objekty – model stavů objektů oZpůsob změny stavu – referenční symboly 38 A B C UOB A UOB B UOB C Zdroj: Řepa 2006 > 39 > Petriho síť Projektování IS 40 Petriho síť je graf skládající se z míst a přechodů. Její stav je dán pohybem značek (token) mezi jednotlivými místy. > YAWL Projektování IS 41 Zdroj: van der Aalst Popis workflow rozšiřující přístup podle Petriho sítí, Open source > Co je to UML oUML je otevřený standard (OMG Object Management Group) – standardizační komise) oModelovací jazyk UML = Unified Modeling Language popis procesů objektovou metodou, návrh SW oUML je hlavně souhrn grafických pravidel a schémat (notací) oUML je prostředek vizualizace, specifikace, stavby a dokumentace SW systémů oSouhrn metod – UML 1997 verze 1.5, nyní 2.0 oCASE nástroje Computer Aided Software Engineering nNapříklad Rational Architect Enterprise o o 42 > UML diagramy o n 43 prehled diagramu.GIF Zdroj: http://objekty.vse.cz/Objekty/MetodikyANotace-UMLDiagramy > Postup analytických prací – modelovací techniky oUživatelské požadavky oProcesní modelování oPřípady užití oModelování tříd a objektů oDiagramy objektové spolupráce oStavové diagramy oDiagramy aktivit oDatové modelování a mapování tříd objektů do tabulek relačních databází oPřípadové studie – příklady 44 > Případy užití - úvod oPřípady užití, typové úlohy, užitné případy = USE CASE oPřípady užití zachycují přesně funkčnost, která bude IS pokryta a vymezují tak jednoznačně rozsah prací. oJe součástí UML oKaždý případ užití popisuje jeden ze způsobu užití systému, popisuje tedy jednu jeho požadovanou funkčnost oScenář, základní scenář oPřípad užití je sada scenářů, které spojuje dohromady cíl 45 > UML Use case oPřípad užití nSoubor scénářů pro používání systému nJe to popis toho, jak se systému bude jevit budoucím uživatelům nJak nachystat? Rozhovor s uživateli 46 Systém Případ užití > Případy užití - scenář oScenář, základní scenář - Případ užití: Realizace výrobního příkazu nKROK Role AKCE n1 Uživatel mistr spustí volbu Výrobní příkaz n2 Systém zobrazí formulář výrobního příkazu pro vstup dat n3 Uživatel mistr zadá detaily výrobního příkazu a spustí provedení n4 Systém zobrazí formuláře výrobního příkazu u skladníka a dělníka n5 Uživatel skladník1 vydá materiál, skladník2 vydá nářadí, dělník převezme n6 Systém čeká n7 Uživatel dělník zadá data o splnění výrobního příkazu a zašle do systému n8 Systém zobrazí formulář výrobního příkazu u mistra n9 Uživatel dělník vrátí nářadí, skladník 2 přebere a zavede data do systému n10 Systém nastaví formulář odevzdání výrobku u mistra n11 Uživatel mistr potvrdí splnění výrobního příkazu n12 Systém vytiskne list výrobního příkazu a uzavře formulář 47 > Aktéři oAktér = role, ve které vystupuje uživatel v rámci jeho komunikace se systémem oPř. Aktér= uživatelská role vůči systému 48 Vytvořit list výrobního příkazu Přijmout nářadí zpět na sklad > Aktéři oAktérem nemusí být nutně člověk, může to být např. externí systém oPř. Aktér ve více rolích vůči systému 49 Vytvořit výrobní příkaz Převzít výrobek Vést statistiku Přidat stroj pro plán Upravit kusovník Zobrazit přehled Výrobních příkazů > UML diagram tříd 50 Konzultant Klient Zpráva Projekt Nabídka Data pracuje na čte figuruje v předkládá se obsluhuje figuruje v vede k 1 1 1 1 1 1 1 1..* 1..* 1..* 1..* 1..* 1..* 1..* Zdroj: Schmuller > Vztahy mezi třídami oDiagram tříd zobrazuje strukturu a vztahy mezi objektovými třídami navrhovaného IS o oAgregace njedna třída je částí druhé oKompozice nagregace, kdy podřízený objekt nemůže existovat samostatně oAsociace - násobnost nznázorňuje vztahy mezi jednou či více třídami (1 ku 1, 1 k mnoha, …) oGeneralizace (dědění) nvztah mezi obecnou třídou (super class resp. parent) a jejími potomky (subclass resp. child) ndědí se všechny vlastnosti tj. atributy, relace, operace a omezení) oSpecializace (opak generalizace) oAbstraktní třída (zvláštní třída bez konkrétní instance, zobecnění) oPolymorfismus (některé objekty mají totožná rozhraní realizovaná pomocí operací, ale metody, které se skrývají za těmito operacemi, jsou rozdílné) oAsociační třídy (typ vazby mnoha ku mnoha) 51 > Odvozené třídy a kompozice Projektování IS 52 > Diagram aktivit oZnázorňuje vztahy mezi aktivitami a aktéry oBere do úvahy objekty – předměty, se kterými aktéři v rámci aktivit pracují oPlavební dráhy (swimlanes) oManipulované objekty se umísťují do plavebních drah nebo na jejich rozhraní oZáznamy spojování a větvení 53 > UML diagram aktivit 54 > Sekvenční diagramy oMají nejblíže k programátorskému popsání v objektovém přístupu oSvisle – činnosti oVodorovně – zprávy nZprávy synchronní – musí na sebe navazovat – nová začne po ukončení nějaké sekvence (činnosti) nZprávy asynchronní – zpráva je poslána a vysílající činnost může pokračovat 55 > UML sekvenční diagram Projektování IS 56 > Děkuji za pozornost. Otázky?