Transcript Metoda BORM
Slide 1
BORM
Busines Object Relation Modeling
Přednáška 8
Převzato od Ing. Merunky
Slide 2
BORM - program prezentace
Metoda BORM - úvod
Návod na tvorbu procesních diagramů
Názorný příklad
Slide 3
Metoda BORM - úvod
Vyvíjena postupně od roku 1993
Od počátku součástí grantu VAPPIENS
(který je součástí programu “Know how
fund of Czech Academic Link Programme“
Britské vlády)
od r.1996 další vývoj podporován firmou
Deloitte&Touche
Slide 4
Metoda BORM-jak se liší od jiných
metod
Velká pozornost je věnována úvodním
fázím projektu (na rozdíl od jiných
metod (např. usecase))
BORM využívá v diagramech jen
omezenou sadu pojmů pro každou
jednotlivou fázi životního cyklu.
(Předpokládá se, že během
projektování dochází k postupným
přeměnám pojmů na jiné)
Slide 5
Slide 6
Metoda BORM-jak se liší od jiných
metod
Metoda nevyžaduje oddělování od sebe statických a
dynamických pohledů - umožnění kombinace
Pro znázornění konceptuálních a softwarových pojmů
používá většinu symbolů shodné s UML
Úvodní fáze analýzy jsou podporovány technikou
analýzy objektů podle chování OBA (Object
Behavioral Analysis) s náśtrojem ORD (object
Relation Diagram)
Slide 7
Slide 8
Metoda BORM - OBA
5 kroků (zjednodušeno)
1.krok: a) interview
b) seznam požadovaných funkcí systámu
c) seznam scénářů (procesů, agend, ...) v systému
2.krok: a) obsazování jednotlivých rolí ve scénářích
b) odvozování dalších participantů v systému
3.krok: a) klasifikace participantů
b) odvozování dalších participantů v systému
4.krok: a) modelování vztahů mezi nalezenými participanty
5.krok : a) simulace scénářů
b) sestavení procesních diagramů
Slide 9
Návod na tvorbu procesních diagramů-participanty a jejich
aktivity
Participant
je hlavní pojem diagramu. Reprezentuje
nějakou konkrétní jednotku z modelové
Jméno participantu
reality.
(s velkým písmem)
Chování
Chování (aktivita) vždy náleží nějakému
participantu
popis aktivity
jak kreslit participanty a jejich aktivity
(pozn. stejným způsobem se kreslí i aktivity viz-dale)
a)
Zákazník
b)
Zákazník
Požaduje
službu
Požaduje
službu
Slide 10
Návod na tvorbu procesních diagramů-komunikace mezi
participanty
Komunikace představuje propojení/návaznost
aktivit jednotlivých participantů na sebe.
Komunikace vždy vychází od jedné
aktivity participantu (který zahajuje komunikaci) a vede k
jedné aktivitě participantu (který přijímá komunikaci)
Parametry komunikace jsou participanty (např. data,
materiál, …), které mohou být součástí
komunikace. Rozlišujeme parametry ve
směru komunikace (které vstupují do komunikace
vyvolané aktivity)a parametry proti směru komunikace
(které představují odpovědi od aktivity, která byla
komunikací vyvolána)
Jak kreslit komunikace a jejich parametry
Zákazník
žádost
Požaduje
službu
Obsluha
vykonává
službu
potvrzení
Slide 11
Návod na tvorbu procesních diagramů-stavy a přechody participantu
= role
Stejný participant se může v průběhu procesu měnit. To znamená,
že v různých fázích provádí různé aktivity. Některé z aktivit, které
participant provádí v jednom stavu mohou způsobit přechod od
jednoho stavu tohoto participantu k druhému stavu téhož
participantu. Vzájemě související stavy a přechody jednoho
participantu tvoří jeho roli v systému
Jak kreslit stavy a přechody
(jednoho) participantu
Zákazník
Požaduje
službu
začátek role
stav
zahajuje
službu
aktivita, která mění
stav perticipantu
ukončuje
službu
konec role
čeká na službu
v kontraktu
uskutečňuje
službu
aktivita, která
je prováděna
ve stavu, ale
stav nemění
Slide 12
Návod na tvorbu procesních diagramů - tvorba
podmínek
V případě potřeby je možné znázornit komunikaci i u
přechodů podmínky, které blíže vymezují okolnosti, za
jakých komunikace nebo přechod nastává
jak kreslit podmínky u přechodů
vyřizuje požadavek
rozhoduje o
požadavku
souhlas
potvrzuje
požadavek
a u komunikací
nedostatek Specialista
podkladů
konzultuje
nesouhlas
zamítá
požadavek
Slide 13
Zákazník
Aktivity více participantů
jsou provázány
komunikacemi
aktivity, které jsou vyvolány
komunikací jiného
participantu a které pouze
způsobují přechod do jiného
stavu a neváže se na ně pro
model významná operace,
nemusejí být pojmenovány
žádost
požaduje
službu
čeká na službu
přijímá
požadavek
v rozhodování
rozhoduje o
požadavku
zdůvodnění
souhlas
zahajuje
službu
smlouva
Návod na tvorbu
procesních diagramů
Propojení stavů a
přechodů více
participantů = proces
Obsluha
v kontaraktu (ve
smlouvě)
nesouhlas
potvrzuje
požadavek
zamítá
požadavek
ve službě
uskutečňuje
službu
poskytuje
službu
ukončuje
službu
ukončuje
službu
Slide 14
Nejčastější chyby při konstrukci diagramů procesů
1.střídání stavů a procesů
Každá role participantu je tvořena střídáním stavů a
přechodů, přičemž každý přechod má nějakou aktivit.
Role může začít i končit stavem nebo aktivitou (podle
potřeby),ale stavy a přechody se musejí střídat.
požaduje
službu
čeká na službu
zahajuje
službu
v kontraktu
Slide 15
Nejčastější chyby při konstrukci diagramů procesů
2.komunikace bez aktivit
Každá komunikace vychází z nějaké aktivity a vede
do nějaké aktivity. Není nutné, aby byla komunikaci
přijímací aktivita pojmenována, ale je zakázáno vést
komunikaci mezi participanty nebo jejich stavy přímo
bez aktivit.
Zákazník
požaduje
službu
Obsluha
Zákazník
Obsluha
vykoná
službu
Slide 16
Nejčastější chyby při konstrukci diagramů procesů
3.záměna přechodu s komunikací
Přechody představují znázornění pohybu daného
participantu v čase. Proto na přechodech nelze
zobrazovat například parametry. Pokud tato situace
nastane, tak je třeba najít příslušné aktivity a
komunikace vést mezi nimi.
čeká na službu
čeká na službu
ohlášení
zahajuje
službu
zahajuje
službu
ohlášení
v kontraktu
v kontraktu
?
Slide 17
Nejčastější chyby při konstrukci diagramů procesů
4.přechody mezi různými participanty
Přechody se týkají výhradně stavů a aktivit
náležejících stejnému participantu. Není dovoleno
vést přechody mezi stavy různých participantů.
Pokud tato situace nastane, je třeba najít příslušné
aktivity a vyznačit komunikace mezi nimi.
Zákazník
požaduje
Obsluha
v rozhodování
Zákazník
požaduje
čeká na
službu
v kontarktu
Obsluha
přijímá
v rozhodování
potvrzuje
zahajuje
v kontarktu
potvrzuje
Slide 18
Názorný příklad-zadání
-
Host
přišel se najíst
musí čekat
dostane něco k jídlu
proces jezení
proces placení
končí
-
Číšnice
zjišťuje přání
někdo to vaří
servírování pokrmu
čeká na pokyn k
placení
kasíruje
čeká na dalšího
zájemce
Slide 19
Možné řešení příkladu
Host
Číšnice
čeká na
zájemce
přichází do
restaurace
sleduje rajon
moc
dlouho
čekal
čeká na jídelní
lístek
Kuchyně
popis jídla
odchází pryč
vybral si jídlo
jídelní lístek
čeká na jídlo
popis jídla
čeká na jídlo
vybral si jídlo
v připravě
přináši jídlo
má jídlo
čeká na
zákazníka, že
zaplatí
konzumuje
jídlo
požaduje platit
požaduje platit
čeká na placení
předává jídlo
připravené
jídlo
připravené
jídlo
ví, že zákazník
chce platit
peníze
platí
dostává požadavek
na jídlo
zjišťuje přání
zákazníka
kasíruje
zákazníka
Slide 20
Literatura
Stranky katedry informačního inženýrství PEF ČZU v Praze
www.pef.czu.cz
Metaedit - Metaedit Plus 3.0 - www.metacase.com
BORM
Busines Object Relation Modeling
Přednáška 8
Převzato od Ing. Merunky
Slide 2
BORM - program prezentace
Metoda BORM - úvod
Návod na tvorbu procesních diagramů
Názorný příklad
Slide 3
Metoda BORM - úvod
Vyvíjena postupně od roku 1993
Od počátku součástí grantu VAPPIENS
(který je součástí programu “Know how
fund of Czech Academic Link Programme“
Britské vlády)
od r.1996 další vývoj podporován firmou
Deloitte&Touche
Slide 4
Metoda BORM-jak se liší od jiných
metod
Velká pozornost je věnována úvodním
fázím projektu (na rozdíl od jiných
metod (např. usecase))
BORM využívá v diagramech jen
omezenou sadu pojmů pro každou
jednotlivou fázi životního cyklu.
(Předpokládá se, že během
projektování dochází k postupným
přeměnám pojmů na jiné)
Slide 5
Slide 6
Metoda BORM-jak se liší od jiných
metod
Metoda nevyžaduje oddělování od sebe statických a
dynamických pohledů - umožnění kombinace
Pro znázornění konceptuálních a softwarových pojmů
používá většinu symbolů shodné s UML
Úvodní fáze analýzy jsou podporovány technikou
analýzy objektů podle chování OBA (Object
Behavioral Analysis) s náśtrojem ORD (object
Relation Diagram)
Slide 7
Slide 8
Metoda BORM - OBA
5 kroků (zjednodušeno)
1.krok: a) interview
b) seznam požadovaných funkcí systámu
c) seznam scénářů (procesů, agend, ...) v systému
2.krok: a) obsazování jednotlivých rolí ve scénářích
b) odvozování dalších participantů v systému
3.krok: a) klasifikace participantů
b) odvozování dalších participantů v systému
4.krok: a) modelování vztahů mezi nalezenými participanty
5.krok : a) simulace scénářů
b) sestavení procesních diagramů
Slide 9
Návod na tvorbu procesních diagramů-participanty a jejich
aktivity
Participant
je hlavní pojem diagramu. Reprezentuje
nějakou konkrétní jednotku z modelové
Jméno participantu
reality.
(s velkým písmem)
Chování
Chování (aktivita) vždy náleží nějakému
participantu
popis aktivity
jak kreslit participanty a jejich aktivity
(pozn. stejným způsobem se kreslí i aktivity viz-dale)
a)
Zákazník
b)
Zákazník
Požaduje
službu
Požaduje
službu
Slide 10
Návod na tvorbu procesních diagramů-komunikace mezi
participanty
Komunikace představuje propojení/návaznost
aktivit jednotlivých participantů na sebe.
Komunikace vždy vychází od jedné
aktivity participantu (který zahajuje komunikaci) a vede k
jedné aktivitě participantu (který přijímá komunikaci)
Parametry komunikace jsou participanty (např. data,
materiál, …), které mohou být součástí
komunikace. Rozlišujeme parametry ve
směru komunikace (které vstupují do komunikace
vyvolané aktivity)a parametry proti směru komunikace
(které představují odpovědi od aktivity, která byla
komunikací vyvolána)
Jak kreslit komunikace a jejich parametry
Zákazník
žádost
Požaduje
službu
Obsluha
vykonává
službu
potvrzení
Slide 11
Návod na tvorbu procesních diagramů-stavy a přechody participantu
= role
Stejný participant se může v průběhu procesu měnit. To znamená,
že v různých fázích provádí různé aktivity. Některé z aktivit, které
participant provádí v jednom stavu mohou způsobit přechod od
jednoho stavu tohoto participantu k druhému stavu téhož
participantu. Vzájemě související stavy a přechody jednoho
participantu tvoří jeho roli v systému
Jak kreslit stavy a přechody
(jednoho) participantu
Zákazník
Požaduje
službu
začátek role
stav
zahajuje
službu
aktivita, která mění
stav perticipantu
ukončuje
službu
konec role
čeká na službu
v kontraktu
uskutečňuje
službu
aktivita, která
je prováděna
ve stavu, ale
stav nemění
Slide 12
Návod na tvorbu procesních diagramů - tvorba
podmínek
V případě potřeby je možné znázornit komunikaci i u
přechodů podmínky, které blíže vymezují okolnosti, za
jakých komunikace nebo přechod nastává
jak kreslit podmínky u přechodů
vyřizuje požadavek
rozhoduje o
požadavku
souhlas
potvrzuje
požadavek
a u komunikací
nedostatek Specialista
podkladů
konzultuje
nesouhlas
zamítá
požadavek
Slide 13
Zákazník
Aktivity více participantů
jsou provázány
komunikacemi
aktivity, které jsou vyvolány
komunikací jiného
participantu a které pouze
způsobují přechod do jiného
stavu a neváže se na ně pro
model významná operace,
nemusejí být pojmenovány
žádost
požaduje
službu
čeká na službu
přijímá
požadavek
v rozhodování
rozhoduje o
požadavku
zdůvodnění
souhlas
zahajuje
službu
smlouva
Návod na tvorbu
procesních diagramů
Propojení stavů a
přechodů více
participantů = proces
Obsluha
v kontaraktu (ve
smlouvě)
nesouhlas
potvrzuje
požadavek
zamítá
požadavek
ve službě
uskutečňuje
službu
poskytuje
službu
ukončuje
službu
ukončuje
službu
Slide 14
Nejčastější chyby při konstrukci diagramů procesů
1.střídání stavů a procesů
Každá role participantu je tvořena střídáním stavů a
přechodů, přičemž každý přechod má nějakou aktivit.
Role může začít i končit stavem nebo aktivitou (podle
potřeby),ale stavy a přechody se musejí střídat.
požaduje
službu
čeká na službu
zahajuje
službu
v kontraktu
Slide 15
Nejčastější chyby při konstrukci diagramů procesů
2.komunikace bez aktivit
Každá komunikace vychází z nějaké aktivity a vede
do nějaké aktivity. Není nutné, aby byla komunikaci
přijímací aktivita pojmenována, ale je zakázáno vést
komunikaci mezi participanty nebo jejich stavy přímo
bez aktivit.
Zákazník
požaduje
službu
Obsluha
Zákazník
Obsluha
vykoná
službu
Slide 16
Nejčastější chyby při konstrukci diagramů procesů
3.záměna přechodu s komunikací
Přechody představují znázornění pohybu daného
participantu v čase. Proto na přechodech nelze
zobrazovat například parametry. Pokud tato situace
nastane, tak je třeba najít příslušné aktivity a
komunikace vést mezi nimi.
čeká na službu
čeká na službu
ohlášení
zahajuje
službu
zahajuje
službu
ohlášení
v kontraktu
v kontraktu
?
Slide 17
Nejčastější chyby při konstrukci diagramů procesů
4.přechody mezi různými participanty
Přechody se týkají výhradně stavů a aktivit
náležejících stejnému participantu. Není dovoleno
vést přechody mezi stavy různých participantů.
Pokud tato situace nastane, je třeba najít příslušné
aktivity a vyznačit komunikace mezi nimi.
Zákazník
požaduje
Obsluha
v rozhodování
Zákazník
požaduje
čeká na
službu
v kontarktu
Obsluha
přijímá
v rozhodování
potvrzuje
zahajuje
v kontarktu
potvrzuje
Slide 18
Názorný příklad-zadání
-
Host
přišel se najíst
musí čekat
dostane něco k jídlu
proces jezení
proces placení
končí
-
Číšnice
zjišťuje přání
někdo to vaří
servírování pokrmu
čeká na pokyn k
placení
kasíruje
čeká na dalšího
zájemce
Slide 19
Možné řešení příkladu
Host
Číšnice
čeká na
zájemce
přichází do
restaurace
sleduje rajon
moc
dlouho
čekal
čeká na jídelní
lístek
Kuchyně
popis jídla
odchází pryč
vybral si jídlo
jídelní lístek
čeká na jídlo
popis jídla
čeká na jídlo
vybral si jídlo
v připravě
přináši jídlo
má jídlo
čeká na
zákazníka, že
zaplatí
konzumuje
jídlo
požaduje platit
požaduje platit
čeká na placení
předává jídlo
připravené
jídlo
připravené
jídlo
ví, že zákazník
chce platit
peníze
platí
dostává požadavek
na jídlo
zjišťuje přání
zákazníka
kasíruje
zákazníka
Slide 20
Literatura
Stranky katedry informačního inženýrství PEF ČZU v Praze
www.pef.czu.cz
Metaedit - Metaedit Plus 3.0 - www.metacase.com