GoalSPEC : a Goal Specification Language supporting Adaptivity and Evolution

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 ProposedApproach • A Goal Specification Language: GoalSPEC • Examples EMAS'13 - GoalSPEC - M. Cossentino

3. Motivation • Introducingadaptation in workflowdesignedusing BPMN • Conventional (rigid) workflowdoesnotsatisfy the needs in manyscenarios • Whatchanges • Scenarioschangecontinously • Way people work changes • People change • Workloadisoftenunpredictable • Whatisconstant • Skills • The business analysistknows BPMN and doesnotwant to study a new language/paradigm (agents) • Eachworkerisable to perform some duties and not some others EMAS'13 - GoalSPEC - M. Cossentino

4. The ProposedApproach EMAS'13 - GoalSPEC - M. Cossentino

5. The proposedapproach • 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

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

7. Impact: Revisiting the lifecycle of Business Process Evolution models revises Business Expert Business Analyst automatic translates into GoalSPEC injection injection worker interacts commits to analyzes analyzes commits to analyzes analyzes Running MAS EMAS'13 - GoalSPEC - M. Cossentino

8. The Adopted Agent Architecture Goal 3 Goal 2 Goal 1 Goal n GOALS (design time and runtime) Agents Agent2 Agent2 Agent1 (GUI) (GUI) Business Analyst Resources (databases, …) Web Service Web Service Workflow User Environment

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

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

12. Anatomy of a Goal in GoalSPEC • The goal specification sentence in GoalSPEC: WHEN <something happens> <actor>SHALL ADDRESS <a desired state> When: Triggering Condition Who: the actor e.g. The System, agentA,… 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

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

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

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 weekTHE 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

16. Examples

17. Example: BPMN EMAS'13 - GoalSPEC - M. Cossentino

18. BPMN  XML  GoalSPEC <serviceTaskcompletionQuantity="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 classified(Doc) EMAS'13 - GoalSPEC - M. Cossentino

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

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

21. Thanks for yourattention Anyquestion? cossentino@pa.icar.cnr.it