Metodika vývoje IS Jan Smolík

Globální analýza systému Pohled na firmu a systém jako celek Analyzujeme do šířky, nikoliv do hloubky Užité metody: BSP Globální pohled na procesy (např. Eriksson- Penkerův diagram) Hrubý Class diagram (většinou bez metod) DFD (Konceptuální, úroveň 0)

Detailní analýza systému Analyzujeme jen část firmy a jejího IS Tu, která je předmětem řešení Do hloubky, nikoliv do šířky Užité metody: Detailní Class diagram Detailní popis relevantních procesů Data flow diagram (nižší úrovně) Životní cykly objektů

Vztahy mezi modely

Konceptuální popis Diagram tříd Slouží k definování pojmů Velmi blízký ontologiím

Model tříd Třída = abstrakce jednotlivých objektů

Vztahy mezi třídami Asociace – mezi třídami existuje nějaký vztah, mezi instancemi bude spojení Agregace – komponenta je částí celku Komozice – silnější forma agregace, se zánikem celku zaniká i komponenta

Model procesů

Role popisu procesů

Globální procesní popis Slouží k identifikaci procesů ve firmě Znázorněje jejich vstupy, výstupy, cíle Návaznosti procesů

Eriksson-Penkerův Diagram Zdroj Cíl Informace <<input>> <<supply>> <<goal>> <<process>> Podnikový proces Událost Výstup <<output>>

Komplexní příklad Krahulec Jan a kol.: Práce týmu Smart Solutions pro projekt 4IT415 na VŠE v Praze. 2008.

Detailní popis procesů

Process Diagram Technique Není profilem UML ani standardem Technika pro popis procesů Neusiluje o standardizace způsobu modelování ani notace Vyvíjena na katedře informačních technologií VŠE

PDT – popis prvků 1/3 Množina údajů nesoucích informaci Př.: výrobní plán, dodací list Množina dat Materiál v kombinaci s informací Př.: dodávka společně s dodacím listem Smíšená množina Množina materiálu Surovina či výrobek hmotný i nehmotný Př.: náhradní díly, automobil

PDT – popis prvků 2/3 Rozhodovací činnost Zpracování vstupů na výstupy – lze na ni nahlížet i jako na proces Činnost Vnější podnět. Informace vzniklá mimo proces. Událost Rozhodovací činnost Elementární činnost, jejímž výstupem je rozhodnutí o dalším postupu. Stav

PDT – popis prvků 3/3 Problém spojený s procesem v jeho určitém místě (stavu) Problém Aktér Abstraktní účastník procesu (osoba, útvar, systém, ...) Organizační jednotka AND Primitivní rozhodovací činnost (jen AND a XOR)

PDT – příklad Primitivní proces

PDT příklad Primitivní proces v notaci ARIS (stejný proces jako minule)

PDT příklad Komplexní proces (má vnitřní stavy)

Fundovanější popis – elementy modelu Pojem Hlavní pojem Stimul (podnět) Stav Činnost Vstupně-výstupní množina Materiálové Informační Smíšené Externí aspekt Aktér, organizační jednotka, problém, …

Stimulus a stav Stimulus Stav Stavy a stimuly Přípustný podnět činnosti Událost, řídící činnost Stav Objektivně nutná přestávka v procesu Neovlivnitelná, čeká se na událost ležící mimo proces Stavy a stimuly Každý stimulus přichází do procesu v určitém jeho stavu Výjimky: počáteční událost, koncový stav

Činnost Komplexní Elementární Neelementární část podnikového procesu Uspořádaný souhrn stimulů, činností a stavů Zvláštním případem je podnikový proces Relativita pojmu činnost a proces Elementární Výkonná Řídící Zvláštním případem činnost, která nemá žádný vstup – logická spojka

Proces Primitivní Komplexní Neexistuje objektivní důvod modelovat jej podrobněji než jako elementární činnost Objektivním důvodem je potřeba čekání na vnější událost Mohou existovat neobjektivní důvody pro podrobnější popis Komplexní Je nutno modelovat jejich stavy

BPMN Business Process Management Notation Standard definovaný Business Process Management Coalition (BPMI) Snaha o standardizaci procesní modelování Reakce na neschopnost UML v oblasti 2005 včleněna do OMG

BPMN Spíše technologicky orientovaný jazyk Původně jen jako notace spustitelného jazyka BPML (nahrazen BPEL4WS) Pro modelování business procesů není úplně vhodný

Základy notace BPMN Událost Primitivní rozhodovací činnost

Přihnutí notace BPMN pro potřeby PDT Událost a činnosti a koncové stavy jsou BPMN definovány Problém je s vnitřními stavy Je využito vlastnosti AND brány Proces bude pokračovat právě tehdy když jsou oba vstupy splněny Jeden vstup vede od činnosti Druhý vstup vede od události AND brána se chová jako stav – po ukončení činnosti se čeká na událost

Elementy PDT v notaci BPMN

Druhy událostí v BPMN

PDT příklad v notaci BPMN

Vazba mezi Class a procesním diagramem A) Každá třída objekt z modelu tříd musí být zastoupena v modelu proces v alespoň jednom z jeho vstupů, či výstupů a/nebo aktérů, či jiných externích aspektů. B) Každý vstup, i výstup procesu, jakož i každý externí aspekt procesu, musí být zastoupen v modelu tříd jako třída, nebo asociace mezi třídami, či jako kombinace obojího.

Stavové diagramy Životní cykly tříd

Stavový diagram – elementy Přechod mezi stavy popsán jako Událost / Činnost (metoda)

Stavový diagram Obecně pro popis přechodu mezi stavy objektu V této metodice k popisu životních cyklů tříd Přechod mezi stavy je vyvolán událostí, která spustí nějakou činnost (metodu třídy) Každá třída má počáteční stav a jeden nebo více koncových

Příklad

Smysl životního cyklu Vývoj objektu v čase Není cílově orientován Popisuje zákonitosti, které musí být respektovány každým chováním Žádný proces nemůže způsobit přechod mezi stavy, který není popsaný Musíme být procesně připraveni na všechny stavy a jejich přechody

Pravidla konzistence C) Každá třída objektů z modelu tříd musí mít specifikovány alespoň tři metody: metodu, jíž objekt (instance třídy) vzniká (konstruktor), metodu, jíž objekt (instance třídy) zaniká (destruktor), alespoň jednu metodu, jíž se mění atributy objektu (transformer). D) Pro každý atribut třídy objektů z modelu tříd musí být u této třídy specifikována metoda, jíž je tomuto atributu přidělena počáteční hodnota a metoda, jíž je hodnota atributu změněna. E) Pro každou asociaci mezi třídami musí být u každé takto asociované třídy specifikována metoda, odpovídající této asociaci. F) Ke každé třídě objektů, která není považována za primitivní, je přiřazen stavový diagram, popisující její životní cyklus.

Pravidla konzistence G) Stavový diagram životního cyklu třídy musí mít popsány všechny přechody mezi všemi svými stavy. Popis každého přechodu specifikuje jednak událost, na základě které se přechod uskuteční (spoušťí), jednak metodu, jíž se tento přechod uskuteční. H) Stavový diagram životního cyklu třídy musí obsahovat v popisech přechodů mezi stavy všechny metody této třídy. Popisy přechodů mezi stavy nesmí obsahovat metody, které nejsou specifikovány u této třídy. I) Každá událost, specifikovaná v popisech přechodů ve stavovém diagramu životního cyklu třídy, musí korespondovat s událostí, specifikovanou v popisu nějakého (nějakých) business procesu (procesů).

Popis funkcí informačního systému Data flow diagramy

Projevy funkcí v UML Use case diagram Vhodné pro modelování scénářů užití modelování přístupových práv modelování vzorů uživatelského rozhraní

Use Case Diagram Zdroj: Wikipedia

Scénáře use case pomocí sekvenčních diagramů Vyřízení objednávky Sekvenční diagram lze svázat s Use Case Host požádá o menu Číšník přinese menu Host si objedná jídlo Číšník předá objednávku kuchaři Kuchař uvaří jídlo a zavolá číšníka Číšník předá jídlo hostovi

Data Flow Diagram Grafický prostředek návrhu a zobrazení funkčního modelu systému Vrstvený (hierarchický) – různé úrovně podrobnosti Nástroj

DFD – základní prvky Terminátor (externí entita) Datový tok (Data Flow) Datový sklad (Data Store) Proces

Terminátor Objekt, který nepatří do systému, ale do jeho okolí Začátek nebo konec datového toku, zdroj dat Terminátor

Proces Datový proces (fyzická transformace dat) Řídící proces Číslování: V úrovni 0 od 1 do 9 V nižších úrovních číslo nadřazeného procesu + .1 -- .9 1. Proces

Datový tok Abstrakce jakékoliv formy přesunu (předání) dat Objednávka

Data Store Místo (dočasného) uložení dat Umožní překlenout časovou mezeru mezi procesy (komunikace procesů v různých časech musí přes data store) Zákazníci

Pravidla DFD 3 – 9 procesů v jednom diagramu S datastorem vždy komunikuje proces (nelze datovým tokem spojit dva datastory, či datastor s terminátorem)

Hierarchie DFD Kontextový diagram – jen terminátory a jeden proces = systém Úroveň „0“ rozvedení systému z kontextového diagramu Nižší úrovně – vždy rozvádějí 1 proces z vyšší úrovně

Příklad Jednoduchý systém pro známkování studentů. Učitel známkuje studenty podle seznamu, ti se pak mohou dívat na své známky.

Kontextový diagram ID Udělaná známka Známkovací systém Seznam studentů Učitel Udělaná známka Student Známkovací systém Seznam studentů Získaná známka Studenti Správce

Úroveň „0“ ID Známka Udělaná známka Student Získaná známka Známky 3 Zápis známky 4 Vyhl známky stud známky Student Získaná známka Studenti 2 Čtení seznamu stud. 1 Zápis seznamu stud. Seznam studentů Studenti

Úroveň 1 Vezmeme právě jeden proces z úrovně 0 Překreslíme si všechny vstupy a výstupy Dále postupujeme jako při tvorbě úrovně 0

Event Partitioning Approach Technika sloužící k sestavení DFD nejnižší úrovně Seskupením souvisejících částí se pak dotváří hierarchie Metodu lze s úspěchem použít na dílčí části systému zjištěné v globální analýze

Postup Sestavíme seznam událostí Ke každé události nakreslíme bublinu představující reakci na tuto událost. Vhodně ji pojmenujeme podle této reakce. K funkci nakreslíme vstupy a výstupy + datastory, ke kterým přistupuje Výsledný DFD porovnáme s kontextovým diagramem a seznamem událostí kvůli úplnosti a konzistenci

Události Tokové Časové Řídící Jednoznačně je k nim přiřazen datový tok Tok není přiřazen přímo – jakési interní hodiny Většinou stejně vyžadují nějaký datový tok (který ale nereprezentuje tuto událost) Řídící Můžeme k nim přiřadit řídící tok

Konzistence mezi DFD a Class J) Každý elementární Datastore v DFD musí být v CD zastoupen jako třída, nebo asociace, anebo kombinace obojího. K) Atributy každého elementárního datastore z DFD musí být datovou strukturou atributů tříd, jimiž je tento Datastore v CD zastoupen. L) Metody každé elementární funkce z DFD musí být algoritmickou strukturou metod tříd, jimiž jsou v CD zastoupeny Datastory, spojené datovými toky s touto funkcí .

Konzistence mezi DFD a procesy M) Každý elementární vstupní datový tok v DFD od terminátoru (tj. zvnějšku systému) musí odpovídat nějaké události,specifikované v popisu nějakého (nějakých) business procesu (procesů) v PD. N) Každý stav každého procesu v PD musí korespondovat s některým(i) elementárním(i) Datastorem(y) v DFD a naopak každý elementární Datastore v DFD musí korespondovat s některým(i) stav(y) proces() v PD. Jde o korespondenci M:N.

Konzistenční pravidla pro odvození tabulky I) Každá událost, specifikovaná v popisech přechodů ve stavovém diagramu životního cyklu třídy, musí korespondovat s událostí, specifikovanou v popisu nějakého (nějakých) business procesu (procesů). M) Každý elementární vstupní datový tok v DFD od terminátoru (tj. zvnějšku systému) musí odpovídat nějaké události,specifikované v popisu nějakého (nějakých) business procesu (procesů) v PD.

Odvození konzistenční tabulky Událost v ŽC odpovídá událostem v PD, odpovídá událostem v DFD V ŽC událost vyvolá akci, která nás posune do stavu V PD událost vyvolá činnost, která nás posune do stavu (kde se opět čeká na událost) V DFD je činnost reakcí na událost (reprezentovanou datovým tokem – viz EPA) I činnosti a stavy si musí odpovídat

V životní m cyklu třídy (STD) Tabulka konzistencí Č. Událost Akce Stav V proces u V životní m cyklu třídy (STD) Ve vstupu IS (DFD) Ve funkci IS (DFD) 1 2 3 4 5 6 7 8

Vztahy mezi modely