Metodika vývoje IS Jan Smolík.

Prezentace na téma: "Metodika vývoje IS Jan Smolík."— 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
Zdroj Cíl Informace <<input>> <<supply>> <<goal>> <<process>> Podnikový proces Událost Výstup <<output>>

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

17 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

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

19 PDT – příklad Primitivní proces

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

21 PDT příklad 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 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

24 Č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

25 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

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 Stavové diagramy Životní cykly tříd

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 Popis funkcí informačního systému
Data flow diagramy

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

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

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

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

59 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

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

65 Vztahy mezi modely