1. L. Sabatucci, P. Ribino, C. Lodato, S. Lopes, and M. Cossentino
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

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

4. The Proposed Approach
EMAS'13 - GoalSPEC - M. Cossentino

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

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 Analyst
Business Expert
GoalSPEC
automatic translates into
worker
injection
injection
interacts
commits to
analyzes
analyzes
commits to
analyzes
analyzes
Running MAS
EMAS'13 - GoalSPEC - M. Cossentino

8. The Adopted Agent Architecture
Goal 2
Goal 3
Goal 1
Goal n
GOALS
(design time
and
runtime)
Agent1
Agent2
Agent2
Agents
(GUI)
(GUI)
Resources
(databases, …)
Business Analyst
Web Service
Workflow User
Web Service
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. This Goal is assigned to the software system
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. The agent can commit to a specific goal only if
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 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

16. Examples

17. Example: BPMN NOTE LUCA:
BPMN è una notazione grafica per la definizione di flussi di lavoro. OMG ha definito un meta-modello per la sintassi del linguaggio e di conseguenza uno schema XML per la rappresentazione sia del modello che dei dettagli grafici.
In questo esempio abbiamo TASK (in verde e contrassegnati da uno stereotipo grafico:
busta bianca = task per la ricezione di messaggi,
Busta nera = task per l’invio di messaggi,
ingranaggi = task per attivare un Service,
tabella = task che segue delle regole definite dall’utente
omino = task eseguito manualmente
Poi ci sono i DATAOBJECT (con il simbolo del documento, che rappresentano oggetti con uno stato messo tra parentesi quadre)
EMAS'13 - GoalSPEC - M. Cossentino

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>
La porzione di XML riportata mostra la descrizione di un TASK
<incoming> e <outcoming> contengono un riferimento ai “sequence-flow” (freccie) in ingresso e in uscita
<ioSpecificaion> eplicita i dati che vengono consumati e prodotti dal task
<dataInputAssociation> definisce quali DATAOBJECT sono associati al task
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 supports evolution
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 your attention
Any question?