goalspec : a goal specification language supporting adaptivity and evolution

GoalSPEC: a Goal Specification

Language supporting Adaptivity and Evolution

L. Sabatucci, P. Ribino, C. Lodato, S. Lopes, and M. Cossentino

EMAS'13 - GoalSPEC - M. Cossentino 2

OutlineMotivationThe Proposed ApproachA Goal Specification Language: GoalSPECExamples


Motivation Introducing adaptation in workflow designed using BPMNConventional (rigid) workflow does not satisfy the needs

in many scenarios What changes

Scenarios change continously Way people work changesPeople changeWorkload is often unpredictable

What is constantSkills

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


The Proposed Approach


The proposed approachFocussing 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 goalEach 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


Self-Adapting Workflows: our Receipt

Distributed system with decentralized controlSoftware Agents

able to reason on the expected behavioraware of their capacities and consequencesdynamic 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


Impact: Revisiting the lifecycle of Business Process Evolution

Running MAS

GoalSPEC

Business Analyst

Business

Expert

models revises

automatic translates into

injectioninjection

analyzes

analyzes

commits tocommits to

analyzes

analyzes

worker

interacts

8

The Adopted Agent Architecture

Goal n

Resources(databases, …) Web

Service

Agents

EnvironmentWeb Service

GOALS(design time

and runtime)

Business Analyst

Workflow User

(GUI)

(GUI)

Agent1 Agent2 Agent2

Goal 3

Goal 2

Goal 1

GoalSPEC


GoalSPECMany Human-Oriented Languages exist to specify

Goals (i*, Tropos, Kaos)Responding to the need for “modeling” goals at design

timeKAOS may also support runtime interpretation of goals

but it is too complex for non-skilled workflow analystsGoalSPEC is a communication language between

humans and agents:Can be automatically generated from a BPMN workflow

representationBut also manually revised by business experts It can be automatically interpreted by Software Agents


Key Features of GoalSPECIt 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 goalIt allows to introduce points of flexibility in the

specification of goals


Anatomy of a Goal in GoalSPEC

The goal specification sentence in GoalSPEC:

WHEN <something happens> <actor>SHALL ADDRESS <a desired state>

When: Triggering Condition

What: Desired

State

Who: the actore.g. The System,

agentA,…

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


WHEN <something happens> THE SYSTEM SHALL ADDRESS <a desired state>

This Goal is assigned to the software systemThe clause ‘WHEN <something happens>’ requires

the candidate agent will activate some perceptionsThe 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 stateThe 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 satisfactionorAutonomously monitoring satisfaction


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)


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 facingGoalSPEC proposes FUZZY modifiers to relax requirements

constraintsWHEN 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”

Examples


Example: BPMN


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 classified(Doc)


A more sophisticated example

WHEN refined(Doc) THE SYSTEM SHALL

ADDRESS

( accepted(Doc) and approved(Doc) )

or rejected(Doc)

or incomplete(Doc)


ConclusionsGoalSPEC 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 systemagents 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.

Thanks for your attention

Any question?

[email protected]

goalspec : a goal specification language supporting adaptivity and evolution

Documents