�ݺ�ߣ

GoalSPEC:
a Goal Specification Language
supporting
Adaptivity and Evolution
L. Sabatucci, P. Ribino, C. Lodato,
S. Lopes, and M. Cossentino

Outline
 Motivation
 The Proposed Approach
 A Goal Specification Language: GoalSPEC

 Examples

EMAS'13 - GoalSPEC - M. Cossentino

2

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


3

The Proposed Approach


4

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

5

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

6

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


analyzes

analyzes

commits to
analyzes

7

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

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

10

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


11

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

12

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

13

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)


14

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”

15

Example: BPMN


17

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

18

A more sophisticated example
WHEN refined(Doc) THE SYSTEM SHALL
ADDRESS
( accepted(Doc) and approved(Doc) )
or rejected(Doc)
or incomplete(Doc)


19

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.


20

Thanks for your
attention
Any question?

cossentino@pa.icar.cnr.it

�ݺ�ߣ

GoalSPEC - An Introduction

More Related Content

GoalSPEC - An Introduction

Editor's Notes