Obsah přednášky. Půjčovna aut pokračování Model akcí půjčovny aut Model faktů půjčovny aut Konstrukční a funkční model

EO_09

Obsah přednášky • • • •

Půjčovna aut pokračování Model akcí půjčovny aut Model faktů půjčovny aut Konstrukční a funkční model

2

Model akcí • Konstrukční model, transakční model a vyprávění umožňují vypracovat model akcí. • Samo vysvětlující, kromě: – odpověď na request T1, který je v souladu s no promise, je vydán request T2 – to je zřejmě podnikové pravidlo podle vyprávění;

3

Pravidla akcí pro roli aktéra A1/1

4


• a rental contractor – označuje obecnou roli aktora • the retatal contractor – označuje konkrétní osobu. • Je zde možnost delegování pravomoci. 5


6


7


8

Diagram struktury procesu

• Model jasně ukazuje, v jaké relaci jsou typy transakcí T1 a T2. • Čin [T1/rq] je proveden jako odpověď na externí událost. 9

Diagram struktury procesu • Potom jako odpověď na událost (T1/rq), akrét A1 provede čin [T2/rq], což je v souladu s pravidlem akcí 1. • Aktér A1 čeká dokud nenastane událost (T2/pm) před provedením činu [T1/pm], což je v souladu s pravidlem 2. • Konečně exekuce T1 musí čekat na výskyt události (T2/ac), což je v souladu se 4 pravidlem akcí.

10

Diagram struktury procesu • Podíváme se zpět na konstrukční model a speciálně jeho transakce T3, T4 a T5, které vznikly podle vyprávění (popisu). • Pak z toho vytvoříme diagram struktury procesu (Process Structure Diagram). • PSD názorně ukazuje, jak jsou uvedené transakce vzájemně propojené. • Proces začíná s externí iniciací T3. 11

Konstrukční model AT1

AT2

POBOČKA RAC CA02 A3 T03 vyzvednutí auta

CA01

A1

Vydavatel aut

T04

řidič

T01 pronájem smlouva Nájemce

Uzavíratel nájemní smlouvy

vrácení auta

T02

T05

pronájem platba

placení penalizace

12

• Odpovědí na událost (T3/pm) provede A3 čin [T4/rq]. • Dále A3 čeká dokud nenastane událost (T4/pm) před vykonáním činu [T3/ex]. • Pak vidíme poprvé, jak je odpovězeno na výskyt události výjimky, konkrétně (T4/rj). Praktický význam je, že fáze state provedená řidičem o vrácení auta je odmítnuta A3. 13

Diagram struktury procesu • Důvodem odmítnutí je, že auto je vráceno v jiné pobočce a navíc příliš pozdě. • Dále A3 provede čin [T5/rq] jako odpověď na událost (T4/rj). • Rozsah kardinality „0..1“ indikuje, že tento čin je volitelný (ne vždy se bude konat). • Pro udržení diagramu jednoznačným, rozsah kardinality „0..1“ se opakuje dále u čekací linky z události (T5/ac) do činu [T4/ac] 14

Diagram struktury procesu • Praktický význam této konstrukce je, že A3 čeká s akceptací T5 dokud nebude zaplacena penalizace. • Penalizace je zaplacena řidičem, zatímco poplatek pronájmu je zaplacen nájemcem. • Praktický význam: firma najme auto, ale nechce platit za „nenormální“ chování řidiče. • Obecně ale nájemce i řidič mohou být stejná osoba. 15

Diagram struktury procesu • Zajímavá otázka: jak skutečně budou vypadat pravidla činů, která řídí podnikový proces zobrazen na diagramu struktury procesu. • Pravidla akcí: – pokud není auto odpovídající skupiny aut, je nabídnuto auto z lepší skupiny,

16


17


18

• Popisuje, co se stane, když řidič nesplní svůj slib. • Potom fáze state (T4/st) bude odmítnuta (rejected) místo akceptovaná. Navíc je vydán požadavek na pokutu.

19

• Akce zahrnují dva definované typy faktů, konkrétně penalizaci místa vrácení auta a penalizaci časovou. • Obě mají své jednotkové hodnoty, které jsou násobeny skutečnými hodnotami.

20

• Stav (T4/st) může již nastat předtím, ale daná instance znamená nyní. • Pokud podmínky pro „normální“ zpracování T4 (vrácení auta) nejsou splněny, čin [T4/st] řidiče auta (CA2) bude odmítnut A3. • Ve stavu diskuse (T4/rj) zaměstnanec RAC bude pravděpodobně vysvětlovat řidiči, že auto bylo vráceno na špatném místě (pobočce) a že bylo vráceno příliš pozdě. 21

Pravidla akcí • Požadavek na zaplaceni penalizace bude vykonám činem [T5/rq], po čemž transakce T5 je

provedena. • V nějakém okamžiku proces transakce dosáhne stavu (T5/st) – události. • Pro CA2 (řidiče) to je dostatečný důvod obnovit čin [T4/st], aby mohl transakci úspěšně dokončit. 22

Pravidla akcí • Protože CA2 je role aktéra prostředí, tento čin se neobjeví v modelu. • Avšak z důvodů přehlednosti, tento čin je přidán do transakce T4, což je vidět na příštím obrázku. • Červená cesta z (T4/st) do [T4/rj] představuje to, co se stane nejdříve, je-li auto vráceno neakceptovatelně.

• Ze stavu (události) (T4/rj) je proveden čin [T5/rq].

23

Pravidla akcí • Potom, jakmile je dosažen stav (T5/st), CA2 vykoná čin [T4/st] ještě jednou.

• To představuje zelená cesta z (T4/rj) do [T4/st]. • Dále A3 odpoví na událost (T5/st) buď accept nebo reject. • Je-li odpověď čin [T5/ac], potom A3 bude následně vykonávat pravidla akcí 5. • Protože je nyní T4 ve stavu (T4/st), A3 uspěje ve vykonání pravidla. 24

Pravidla akcí • Proces skončí buď v (T4/ac) nebo v (T4/rj). • V prvním případě instance podnikového procesu je úspěšně provedena. • Ve druhém případě si dva aktéři misí opět spolu sednout a diskutovat jak se dostat ze situace.

25

Procesní diagram

26

Model faktů • Model faktů bez externí třídy [YEAR] a graficky definované třídy GROUP * [YEAR]. • Model faktů obsahuje dva podnikové procesy (T1, T2; T3, T4, T5). • Fáze vrácení auta může být dosažena dvěma různými způsoby: – jako přímý následník fáze „being pick up“ – jako objížďka při placení penalizací. 27

28

Konstrukční model • Poslední část tohoto příkladu se týká přesunu aut mezi jednotlivými pobočkami. • Následující obrázek obsahuje konstrukční diagram organizace spolu s tabulkou transakcí a produktů. • Nový symbol obdélník s transakčním symbolem uvnitř je samo aktivující role aktéra (selfactivation actor role). • Je to standardní cesta pro modelování periodických aktivit – role aktéra A7. 29

30

Konstrukční model • A7 je jak iniciátor, tak i exekutor typu transakce T7 a také iniciátor transakce T6. • Jak vyplývá z tabulky transakcí a produktů, periodická aktivita se provádí denně. • Každý den se A7 dívá, zda není třeba provést nějaký přesun aut.

31

Diagram struktury procesu

• Na obrázku je ukázáno, jak jsou modelovány periodické aktivity v procesním modelu. • Odpovědí na událost (T7/rq) A7 vykoná dva činy: – [T7/pm] – [T7/rq] pro další periodu.

32

Diagram struktury procesu • Dále na stav (událost) (T7/pm) A7 inicializuje řadu transakcí T6, možná nulu. • To vyjadřuje, že manažer přesunu denně určuje, která auta musí být transportovaná a vydaná (k nájmu) podle požadavků kompletního přesunu. • Jakmile jsou všechny přesuny dokončeny, může být vykonáno (exekuce) T7, což znamená, manažer transportu je nyní uvolněn z odpovědnosti manažera transportu dokončené periody. • Dřívější instance T7 mohou ale stále pracovat. 33

Model akcí • Uvedený model akcí obsahuje standardní způsob, kterým jsou modelovány periodické činnosti v Modelu akcí. • Odpovědí na událost (T7/rq) je provedení činu

[T7/pm] pro další periodu, konkrétně pro další den. • Je třeba to udělat nejdříve, protože do části odpovědi (respond part) se nemusíme dostat. • Např. v případě žádných aut k převozu. 34


• Protože exekutor T7 je stejný jako role aktéra (A7), je vyřešení události decline (T7/dc) je jednoduché: exekutor rozhodne ukončit (quit) transakci. • Existuje-li alespoň jedno auto k převozu, A7 bude iniciovat transakci T6 pro každé převážené auto, jako odpověď na being promised transakce T7. 35


• Událost čekání, která se musí vzít do úvahy, je poslední kompletační přesun auta pro daný den. • To co pravidlo dělá je, že každý den provádí kontrolu úplnosti přesunů (transportů) pro daný den. U posledního přesunu kontroluje, zda byla přesunuta všechna auta.

36

Model akcí • Pokud byla všechna auta přesunuta, A7 může bezpečně ukončit svoji práci, což znamená, že T7 může provést exekuci a stated a následně accepted. • Obecně není chyb akceptace statementu transakcí T7.

37


38


39


40


• Jedna z podmínek pravdy (truth) je že musí být možné provést přesun (transport). • Předpokládá se, že tato neformálně specifikovaná podmínka pokryje všechny druhy logických podmínek (je možné jet z A do B požadovaný den? Jak dlouho to bude trvat?)

41


42

Model faktů

• Model akcí doplňuje Model faktů. • Způsob, jakým je modelovaná P7 je také typický generický pro periodické aktivity.

43

Matice funkcí aktérů A1 Teo

X

Úředník

X

A3

A6

Michal

X

X

Franta

X

X

Karel

X

X

A7

X

• Výhodná tabulka mapování fyzických osob do rolí aktérů. • Kontrola úplnosti. 44

Zpracování podstaty organizace • Co skutečně znamená organizační podstata? • Pojem „ organizace“ odkazuje na konstrukční perspektivu podniku, zatímco pojem „byznys“ je rezervován pro funkční perspektivu. • Rozdíl mezi konstrukcí a funkcí podniku, stejně jako jiných systémů je skutečně zásadní a důležitý. • Nejdříve s využitím příkladů – konstrukční perspektiva. 45

Konstrukční perspektiva • Konstrukční perspektiva je uvažování o něčem tak jak je, bez přemýšlení o všem, co se s tím dá dělat. • Není to jednoduché myslet čistě konstrukčně. • Věci kolem nás: šálek na kávu, mobil, auto – mysleme pouze na to jak mohly být vyrobeny bez náznaku jejich funkčnosti. • Pokus se to podaří, studujeme věci z pohledu konstrukce. 46

Konstrukční perspektiva • Je to zásadní pro inženýry, protože každý systém, stejně jako podnik má (v libovolném čase) pouze jednu konstrukci. • Proto přemýšlení o konstrukční perspektivě znamená uvažování pouze o systému jako takovém.

47

Funkční perspektiva • Funkční perspektiva systému znamená, že bereme do úvahy pouze co s tím systémem můžeme dělat, jak ho můžeme užít. • Rozdílnost mezi konstrukcí a funkčností je zřejmá: – konstrukce je inherentně (neodmyslitelná) vlastností systému, systém je vlastností konstrukce – funkčnost je vztah mezi systémem a zainteresovanou osobou.

48

Funkční perspektiva • Skutečně, člověk nemůže mluvit o konkrétní funkci systému, protože každý systém může mít alespoň tolik funkcí, kolik je jeho zainteresovaných osob. • Zamýšlené účely použití daného artefaktu zainteresovanými osobami se nazývají funkcí artefaktu. • Funkce je vztah mezi zainteresovanou osobou a artefaktem. • K primární funkci navrženou návrhářem, lidé vymýšlejí mnoho dalších funkcí. 49

Proces návrhu • Proces návrhu se vždy skládá ze dvou podprocesů: – funkčního návrhu – konstrukčního návrhu.

• Výsledkem funkčního návrhu je stanovení zamýšlených funkce (funkcí) artefaktu. • Protože může existovat mnoho zainteresovaných osob, výsledné funkce jsou většinou kompromis. 50

Konstrukční, funkční pohled • To platí o šálku, mobilu i autě. • Nicméně na konci je souhlas (dohoda), co budou funkce, což je dokumentované ve funkční specifikaci. • Výsledkem konstrukčního návrhu je koncepce nějaké konstrukce, která je schopná přivodit (zapříčinit) zamýšlené funkce, jednou když to bude implementované. • Je to dokumentované v konstrukčních specifikacích. 51

Konstrukční, funkční pohled • Konstrukce může obsloužit všechny dodatečné záměry (důvody) se kterými mohou přijít zainteresované osoby. • Dělení procesu návrhu na dva podprocesy neznamená, že se vykonávají za sebou (následně). • Oba podprocesy jsou propletené do vysokého stupně, nebo alespoň existuje nějaká iterace mezi nimi, protože výsledná konstrukce je vyvážený kompromis mezi rozumnou funkční specifikací a proveditelnou konstrukční specifikací. 52

Konstrukční, funkční pohled • Přesto schopnost návrháře udělat jasné rozdělení mezi záležitostí funkční a záležitostí konstrukční je zásadní pro dobrý návrh. • Ideálně konstrukční návrh předchází ve dvou po sobě jsoucích fázích: – v první se zpracuje ontologický model artefaktu, (pod ontologickým se myslí, že nebude obsahovat jakékoli známky implementace).

53

Konstrukční, funkční pohled – ve druhé fázi je provedena zpodrobnění do takového stupně, že konečný model může být implementován s dostupnými technologiemi.

• Aktuálně se zřídka kdy setkáme s ontologickým návrhem. • Většinou konstrukční modely vyšší úrovně jsou implementovány (jako modely UML). • Podniky jsou stejnými artefakty jako např. šálky, nebo mobily. 54

Konstrukční, funkční pohled • Jsou cílevědomě navržené a implementované systémy, která následně mohou být re-designed nebo re-implemented. • Stejně jako funkční (byznys) perspektiva, tak i konstrukční (organizační) perspektiva je nezbytné vzít do úvahy a řídit se jimi. • Podniková ontologie zahrnuje více než „technickou“ definici. • Stimuluje k hlubokému pochopení organizace. 55

Autorizace • Příkladem může být pojem autorizace. • Počáteční bod je, že subjekt je zmocněn (autorizován) vykonávat roli aktora. • Avšak autorizace sama za sebe je produkt, tedy výsledek nějaké transakce. • Např. tenisový klub chce omezit přístup na tenisové kurty pro vybranou skupinu lidí. • Udělá to zavedením pojmu členství. 56

Autorizace • Pouze členům je dovoleno hrát roli iniciátora „tenisové transakce“. • V jádru se to neliší od autorizace. • Např. Eva plní roli aktéra A1, včetně práva delegovat některé úlohy na Adama. • Např. koupení lístku do divadla není ničím jiným, než získání autorizace. (Pouze držitelům lístků je umožněn vstup do divadla). 57

Autorizace • Autorizační mechanismus také může představovat outsourcing transakcí v B- nebo I- nebo Dorganizacích. • Předpokládejme, že v tenisovém klubu budeme outsource výpočet prvního poplatku za členství. • Tato transakce je informační transakce v Iorganizaci. • Outsource narození. 58

Tenisová klub

59

Obsah přednášky. Půjčovna aut pokračování Model akcí půjčovny aut Model faktů půjčovny aut Konstrukční a funkční model

Recommend Documents