i*/TROPOS

1. i*/TROPOS Jan Smolík

2. Charakteristika • Agentový přístup • Využívá agenty pro popis firmy • Vede k agentovým informačním systémům • Ale nemusí • Důraz na cíle • Založen na modelování vztahů mezi jednotlivými aktory

3. Agenti • Softwarový koncept • Vlastnosti agenta • Persistence • Autonomie • Sociální schopnosti • Reaktivita • Vnímá (percive) své okolí a reaguje na něj

4. BDI • Belief • To co agent ví o svém okolí • Nemusí být pravdivá • Desire • Něco, čeho agent chce dosáhnout • Intention • Něco, čeho agent chce dosáhnout a podnikne bezprostřední kroky k dosažení

5. BDI - Implementace • Často implementováno pomocí jiných pojmů • Belief • Goal • Něco, čeho agent může chtít dosáhnout • Plan • Způsob (kroky, akce) dosažení cíle

6. Agent – Ukázka v jazyce Jason

7. i* a TROPOS • i* - původně vyvinut na University of Toronto na přelomu století • TROPOS – projekt vedený University of Trento • Staví na rámci i* • Rozšiřuje jej o metodologii • Občas nepatrně odlišná terminologie • Oba projekty se velmi prolínají

8. Dva základní diagramy • StrategicDependency (Actor Diagram) • Popisuje vzájemné závislosti jednotlivých aktorů • Ve spolupráci mohou aktoři dosáhnout cílů, které by jinak nedosáhli • Záviset je možné na: cíli (tvrdém a měkkém), plánu (vykonání činnosti) a dodání zdroje • StrategicRationale (GoalDecomposition) • Převádí vstupní závislosti na výstupní • Zaměřuje se na možnosti jednoho agenta jak dosáhnout cíle • Rozpadá cíle na podcíle

9. StrategicDependency - ukázka

10. StrategicDependency - koncepty • Uzly • Aktor – entita, která má strategické cíle a intencionalitu v rámci systému • Představuje fyzického nebo softwarového agenta • Hrany – Závislosti • Tvrdý cíl • Měkký cíl • Plán • Zdroj

11. Rozdíl mezi cílem a plánem • Cíl • Popisuje stav věcí, kterých chce aktor dosáhnout • Jedná se o tvrzení, které aktor uvede do stavu pravdivé • Způsob dosažení cíle je na aktorovi • Plán • Reprezentuje postup, jak něco dělat • Vykonání plánu může být prostředkem k dosažení cíle • Závislost na cíli • Dává aktorovi volnost v konání • Závislost na plánu • Aktor vykoná činnosti bez možnosti rozhodnout se

12. Měkký cíl a tvrdý cíl • (Tvrdý) cíl • Jasně stanovuje podmínky světa, které musí nastat, aby byl splněn • Měkký cíl • Podmínky nejsou jasně stanoveny • Typicky představuje nefunkční požadavky

13. StrategicDependency - Ukázka

14. StrategicDependency – ukázka 2

15. StrategicRationale - Ukázka

16. StrategicRationale - koncepty • Uzly • Cíl • Plán • Zdroj • Měkký cíl • Hrany • Dekompozice • Means-end (způsob dosažení) • Příspěvek k měkkému cíli

17. SR - Dekompozice • Rozpadá cíl do dílčích podcílů, jejichž splnění je nutné k dosažení cíle • Cíl se může rozpadat na podcíl, plán, nebo zdroj, nebo softgoal • Rozpadat se mohou i další typy uzlů

18. SR – MeansEnd • Ukazuje alternativní cesty, jak dosáhnout daného cíle • Umožňuje analyzovat alternativní cesty • Umožňuje najít řešení v případě, že něco nefunguje optimálně

19. SR – SoftgoalContribution • U měkkého cíle nemůžeme říct, zda byl naplněn (je naplňován) • Jednotlivé cíle, zdroje a cíle a měkké cíle mohou přispívat k jeho naplnění jak pozitivně, tak negativně

20. SR – SoftgoalContribution - Ukázka

21. StrategicRationale - Ukázka

22. StrategicRationale – ukázka 2

23. Metodologie TROPOS • Návrh informačního systému • Předpokládá se agentový systém, ale nemusí být • Fáze • Early Requirements • Late Requirements • Architectural Design • Detailed Design • Implementation

24. EarlyRequirements • Smyslem je pochopení problému studiem existujícího organizačního zasazení • Monitoruje stakeholdery a jejich záměry • Cíle, rozpad do dílčích cílů • podpora vyhodnocení alternativ • Identifikace plánů • Může vést k identifikaci dalších závislostí • Měkké cíle (kvalitativní) vedou v dalších fázích k definici nefunkčních požadavků

25. EarlyRequirements

26. EarlyRequirements – GoalDecomposition

27. LateRequirements • Specifikuje pozici navrhovaného systému v operačním prostředí • Spefikuje jeho funkce a kvality • Systém je reprezentován jako aktor • Modelují se závislosti mezi systémem a existujícími aktory z Early Requirements

28. LateRequirements

29. Architectural Design • Cílem je definovat globální architekturu systému • Rozpad na dílčí subsystémy (aktory) • Subsystémy propojeny datovými a kontrolními toky – závislosti • Tři kroky • Refinováníaktorového diagramu vytvořením podaktorů na základě funkčních i nefunkčních požadavků • Zachycení schopností aktorů na základě toho, jaké funkční požadavky musí aktoři a podaktoři plnit • Definice sady agentových typů (komponent) a přiřazení schopností těmto komponentám

30. Architectural Design

31. Detailed Design • Již byla vybrána platforma pro implementaci • Design bude přímo mapován na kód • Může být vybráno například prostředí BDI – pak budeme definovat jednotlivé cíle a plány • Je možné vybrat i neagentové prostředí

32. Implementace • Vlastní napsání kódů ve vybraném prostředí

33. Využití i* pro reengieering • Pochopení současného procesu • Strategic Dependency • Generování alternativ • Strategic Rationale • Vyhodnocení alternativ

34. Pochopení současného stavu • SD • model umožňuje pochopit intencionállní závislosti mezi aktory • Nad rámec toku fyzických a informačních entit a aktivit, které je zpracovávájí • Umožňuje pochopit, co je předmětem zájmu, čího a co se stane, když závislost selže • Umožňuje identifikovat účastníky a stakeholdery a vymezit tak rozsah reingineeringového úsilí • SR • Umožňuje zodpovědět otázky • Proč • Řetěz od výstupních závislostí pomocí means-end • Jak • Řetězec od vstupních událostí

35. Generování nových alternativ • Means ends v SR umožňuje analyzovat různé cesty dosažení cíle • Když rozumíme současnému stavu, můžeme systematicky hledat další alternativy • Nové altarnativy mohou zrušit zaběhnuté předpoklady • SR umožňuje najít dopady nových alternativ • Means-ends mohou být použity od prostředků k dopadům

36. Vyhodnocení alternativ • Vodítka • Funguje to? • Jaké jsou příspěvky k měkkým cílům?