Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

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.

Podobné prezentace


Prezentace na téma: "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."— Transkript prezentace:

1 Metodika vývoje IS Jan Smolík

2 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)

3 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ů

4 Vztahy mezi modely

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

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

7 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

8 MODEL PROCESŮ

9 Role popisu procesů

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

11 Eriksson-Penkerův Diagram > Podnikový proces Událost Informace ZdrojCíl Výstup >

12

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

14 DETAILNÍ POPIS PROCESŮ

15 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

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

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

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

19 PDT – příklad Primitivní proces

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

21 Komplexní proces (má vnitřní stavy)

22 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, …

23 Stimulus a stav Stimulus ◦ 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

24 Činnost Komplexní ◦ 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

25 Proces Primitivní ◦ 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

26 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

27 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ý

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

29 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

30 Elementy PDT v notaci BPMN

31 Druhy událostí v BPMN

32 PDT příklad v notaci BPMN

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

34 ŽIVOTNÍ CYKLY TŘÍD Stavové diagramy

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

36 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

37 Příklad

38 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

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

40 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ů).

41 DATA FLOW DIAGRAMY Popis funkcí informačního systému

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

43 Use Case Diagram Zdroj: Wikipedia

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

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

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

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

48 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 Proces

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

50 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

51 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)

52 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ě

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

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

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

56 Ú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

57 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

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

59 Události Tokové ◦ Jednoznačně je k nim přiřazen datový tok Časové ◦ 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

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

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

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

63 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

64 Tabulka konzistencí Č.UdálostAkceStav V proces u V životní m cyklu třídy (STD) Ve vstupu IS (DFD) V proces u V životní m cyklu třídy (STD) Ve funkci IS (DFD) V proces u V životní m cyklu třídy (STD)

65 Vztahy mezi modely


Stáhnout ppt "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."

Podobné prezentace


Reklamy Google