i*/TROPOS Jan Smolík

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

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

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í

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

Agent – Ukázka v jazyce Jason

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í

Dva základní diagramy Strategic Dependency (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 Strategic Rationale (Goal Decomposition) ◦ 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

Strategic Dependency - ukázka

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

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

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

Strategic Dependency - Ukázka

Strategic Dependency – ukázka 2

Strategic Rationale - Ukázka

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

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ů

SR – Means End 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ě

SR – Softgoal Contribution 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ě

SR – Softgoal Contribution - Ukázka

Strategic Rationale - Ukázka

Strategic Rationale – ukázka 2

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

Early Requirements 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ů

Early Requirements

Early Requirements – Goal Decomposition

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

Late Requirements

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 1.Refinování aktorového diagramu vytvořením podaktorů na základě funkčních i nefunkčních požadavků 2.Zachycení schopností aktorů na základě toho, jaké funkční požadavky musí aktoři a podaktoři plnit 3.Definice sady agentových typů (komponent) a přiřazení schopností těmto komponentám

Architectural Design

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í

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

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

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í

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

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