GoalSPEC - An Introduction
Download as PPTX, PDF0 likes365 views
The document introduces GoalSPEC, a goal specification language to support adaptivity and evolution in workflows. It aims to translate workflow specifications into goal-oriented specifications that software agents can use to dynamically commit to goals and find ways to achieve them as changes occur. GoalSPEC allows expressing functional requirements using ontology elements and introduces degrees of freedom to relax constraints. It supports adaptation by defining only desired states for agents to achieve flexibly based on context. It also supports evolution by defining goals at design and runtime that agents can use to reorganize behavior.
GoalSPEC - An Introduction
- 1. GoalSPEC: a Goal Specification Language supporting Adaptivity and Evolution L. Sabatucci, P. Ribino, C. Lodato, S. Lopes, and M. Cossentino
- 2. Outline Motivation The Proposed Approach A Goal Specification Language: GoalSPEC Examples EMAS'13 - GoalSPEC - M. Cossentino 2
- 3. Motivation Introducing adaptation in workflow designed using BPMN Conventional (rigid) workflow does not satisfy the needs in many scenarios What changes Scenarios change continously Way people work changes People change Workload is often unpredictable What is constant Skills The business analysist knows BPMN and does not want to study a new language/paradigm (agents) Each worker is able to perform some duties and not some others EMAS'13 - GoalSPEC - M. Cossentino 3
- 4. The Proposed Approach EMAS'13 - GoalSPEC - M. Cossentino 4
- 5. The proposed approach Focussing on goals pursued by the workflow The workflow specification in BPMN has to be translated into a goal oriented specification Assumptions: Each workflow pursues a goal Each task in the workflow pursues a subgoal of the workflow goal Letting agents find the best way to achieve goals when changes occur Agents are someway generic They have some capacities the knowledge they can achieve some state of the world by using capacity implementations available in the execution environment They are able to access and control available implementations of their capacities They commit to goal of the workflow (that means they carry on related tasks) if the goal outcome correspond to the state of the world achieved by one of the capacities owned by the agent EMAS'13 - GoalSPEC - M. Cossentino 5
- 6. Self-Adapting Workflows: our Receipt Distributed system with decentralized control Software Agents able to reason on the expected behavior aware of their capacities and consequences dynamic commitment to system goals Business Goals and Rules may be injected into the system at run-time The system (re-)organizes itself according to the published business goals For these aims, we NEED a goal specification language EMAS'13 - GoalSPEC - M. Cossentino 6
- 7. Impact: Revisiting the lifecycle of Business Process Evolution models revises Business Analyst Busine ss Expert automatic translates into GoalSPEC injection worker injection interacts commits to analyzes Running MAS EMAS'13 - GoalSPEC - M. Cossentino analyzes analyzes commits to analyzes 7
- 8. The Adopted Agent Architecture GOALS Goal 3 Goal 2 Goal 1 Goal n (design time and runtime) Agents Agent1 Agent2 Agent2 (GUI) (GUI) Environment Resources (databases, …) Web Service Web Service Business Analyst Workflow User 8
- 9. GoalSPEC
- 10. GoalSPEC Many Human-Oriented Languages exist to specify Goals (i*, Tropos, Kaos) Responding to the need for “modeling” goals at design time KAOS may also support runtime interpretation of goals but it is too complex for non-skilled workflow analysts GoalSPEC is a communication language between humans and agents: Can be automatically generated from a BPMN workflow representation But also manually revised by business experts It can be automatically interpreted by Software Agents EMAS'13 - GoalSPEC - M. Cossentino 10
- 11. Key Features of GoalSPEC It allows to express functional requirements It is grounded on an ontological description of the problem domain Ontology elements are used to specify the expected results of a goal It allows to introduce points of flexibility in the specification of goals EMAS'13 - GoalSPEC - M. Cossentino 11
- 12. Anatomy of a Goal in GoalSPEC The goal specification sentence in GoalSPEC: When: Triggering Condition Who: the actor e.g. The System, agentA,… WHEN <something happens> <actor> SHALL ADDRESS <a desired state> What: Desired State GoalSPEC considers two categories of actors: The SYSTEM considered as a whole (the goal will be pursued by an agent or a group of agents) Human ROLES that participate to the workflow EMAS'13 - GoalSPEC - M. Cossentino 12
- 13. WHEN <something happens> THE SYSTEM SHALL ADDRESS <a desired state> This Goal is assigned to the software system The clause „WHEN <something happens>‟ requires the candidate agent will activate some perceptions The clause „ADDRESS <a desired state>‟ requires the candidate agent will (generally speaking) need both actuators and monitors (perception capabilities) The Actuator to achieve the desired state The Monitor to check if actuator has been successful Otherwise, when a goal is assigned to a human role, system is only responsible for: Interacting with the human to verify goal satisfaction or Autonomously monitoring satisfaction EMAS'13 - GoalSPEC - M. Cossentino 13
- 14. WHEN available(document) THE SYSTEM SHALL ADDRESS classified(document,Category) We use descriptive logics for triggering conditions and desired states. The agent can commit to a specific goal only if It owns a capacity to check if the belief is true: “is available(document) true?” It owns the capacity to lead the world to the desired state: “classified(document,Category)” where Category is grounded (for instance Category==invoice) EMAS'13 - GoalSPEC - M. Cossentino 14
- 15. Work in Progress: Degrees of freedom Adaptation demands some degree of freedom Agents can exploit this degree of freedom in their decision process, according to the current context they are facing GoalSPEC proposes FUZZY modifiers to relax requirements constraints WHEN available(document) THE SYSTEM SHALL ADDRESS classified(document,Category) AS SOON AS POSSIBLE WHEN cassified(document,invoice) and delay(document,Delay) and Delay IS CLOSE TO 1 week THE SYSTEM SHALL ADDRESS *In place of “IS CLOSE TO 1 week” it is also possible to use “AFTER/BEFORE 1 week” EMAS'13 - GoalSPEC - M. Cossentino 15
- 16. Examples
- 17. Example: BPMN EMAS'13 - GoalSPEC - M. Cossentino 17
- 18. BPMN XML GoalSPEC <serviceTask completionQuantity="1" id="_9” name="Classify”> <incoming>_10</incoming> <outgoing>_17</outgoing> <ioSpecification> <dataInput id="Din_9_7" isCollection="false"/> <dataOutput id="Dout_9_12" isCollection="false"/> <inputSet> <dataInputRefs>Din_9_7</dataInputRefs> </inputSet> <outputSet> <dataOutputRefs>Dout_9_12</dataOutputRefs> </outputSet> </ioSpecification> <dataInputAssociation id="_14"> <sourceRef>_7</sourceRef> <targetRef>Din_9_7</targetRef> </dataInputAssociation> <dataOutputAssociation id="_4"> <sourceRef>Dout_9_12</sourceRef> <targetRef>_12</targetRef> </dataOutputAssociation> </serviceTask> WHEN received(Doc) and WHEN unclassified(Doc) THE SYSTEM SHALL ADDRESS clas EMAS'13 - GoalSPEC - M. Cossentino 18
- 19. A more sophisticated example WHEN refined(Doc) THE SYSTEM SHALL ADDRESS ( accepted(Doc) and approved(Doc) ) or rejected(Doc) or incomplete(Doc) EMAS'13 - GoalSPEC - M. Cossentino 19
- 20. Conclusions GoalSPEC supports adaptation GoalSPEC syntax aims at increasing the agent freedom of degree in choosing how/when to address the desired state GOALs defines only the desired state, it is up to the agent intelligence to find the best plan to achieve the desired state, according to the current execution context GoalSPEC supports evolution GOALs are defined at design time but also at run-time and then injected into the system agents will change their behavior according to the current set of available goals This mechanism makes the whole system highly configurable and able to follow evolving users‟ needs. EMAS'13 - GoalSPEC - M. Cossentino 20
- 21. Thanks for your attention Any question? cossentino@pa.icar.cnr.it
Editor's Notes
- #18: NOTE LUCA:BPMN èunanotazionegrafica per la definizione di flussi di lavoro. OMG ha definito un meta-modello per la sintassi del linguaggio e di conseguenzauno schema XML per la rappresentazionesia del modellochedeidettagligrafici.In questoesempioabbiamo TASK (in verde e contrassegnati da unostereotipografico: bustabianca = task per la ricezione di messaggi, Bustanera = task per l’invio dimessaggi,ingranaggi = task per attivare un Service, tabella = task che segue delleregole definite dall’utenteomino = task eseguitomanualmentePoi ci sonoi DATAOBJECT (con ilsimbolo del documento, cherappresentanooggetti con unostatomessotraparentesiquadre)
- #19: La porzione di XML riportatamostra la descrizione di un TASK<incoming> e <outcoming> contengono un riferimentoai “sequence-flow” (freccie) in ingresso e in uscita<ioSpecificaion> eplicitaidatichevengonoconsumati e prodotti dal task<dataInputAssociation> definiscequaliDATAOBJECT sonoassociati al task