1. 1
Towards Interoperable Service-Oriented Tools for
Reasoning about Goal Models
Mohammed Ali Khan
Graduate Programme in Computer Science and Engineering
York University
Toronto, Ontario
October 2014

2. 2
Abstract
In the goal modeling and reasoning research community, a wealth of tools exist for developing and
reasoning with goal models. Often, there is a need to conserve time spent setting up one’s development
environment in order to execute a third party tool. However,although there are numerous tools available
to aid researchers,since they are mainly developed in an academic setting by Professors and Graduate
students, a large number of these tools become difficult to use in few years after their release. This is due
to newer version of operating systems and compilers which requires the user to retrofit their development
environment or modify the source code of the tools in order to use them. In other cases,users often have
to download and setup pre-requisite software packages before attempting to install and execute the tool
itself. Most importantly, tools handle all functionality in one installation, preventing users from easily
creating their own modular solutions (i.e. use one tool’s drawing widgets and another’s reasoning
mechanisms). Such activities add a considerable overhead to the researcher’s project timelines.
In this project we propose a service-oriented reference architecture for goal modeling and analysis tools.
We first discuss the use of goal modeling markup language, iStarML, as means for achieving
interoperability amongst tools. We present the extension, iStarML+P, which illustrates how we can
extend the core goal modelling constructs with other elements particularly preferences. Having
established the extensibility of iStarML, we then propose a reference architecture to develop service-
oriented reasoning solutions for goal modeling based on iStarML. We also present our own
implementation of the reference architecture, Y-Reason,which is a service-oriented reasoning solution for
performing planner-based analysis to i* models.

3. 3
Acknowledgements
Foremost, I would like to express my sincerest gratitude to my advisor Prof. Sotirios Liaskos for his
guidance, patience, and encouragement. I would also like to thank Prof. Vassilios Tzerpos who was part
of the project committee as a second reader.
I would also like to thank my wife and my parents for their continuous support throughout my studies.

4. 4
TABLE OF CONTENTS
CHAPTER 1 6
INTRODUCTION 6
1.1 Motivation 6
1.2 Project Objectives 8
1.3 Project Contributions 8
1.4 Report Outline 8
CHAPTER 2 10
BACKGROUND 10
2.1 Goal Modeling and i* 10
2.2 Reasoning about Goal Modeling 11
2.3 Tool Support for Reasoning about Goals 12
2.4 iStarML 12
2.5 Hierarchical Task networks and DT-Golog 14
CHAPTER 3 16
EXTENDING ISTARML: ISTARML+P 16
3.1 Overview of Extensions 16
3.2 Adding Temporal Constraints 16
3.3 Modeling Effects and Utilities 17
3.4 Summary and Future Work 20
CHAPTER 4 21

5. 5
A SERVICE-ORIENTED APPROACH TO REQUIREMENTS REASONING SYSTEMS 21
4.1 Context and Design Goals 21
4.2 ARCHITECTURAL APPROACH 23
4.2.1 Reference Architectures 23
4.2.2 A Reference Architecture for Requirements Models Reasoning Systems. 24
CHAPTER 5 28
CASE STUDY: Y-REASON: TRANSLATING FROM ISTARML+P TO SHOP2 28
5.1 Introduction 28
5.2 Architectural Design 28
5.3 Core Translator Design 30
5.4 Performance Evaluation 31
CHAPTER 6 33
CONCLUSIONS AND FUTURE WORK 33
6.1 Service-based tools for software engineering research: benefits and challenges 33
6.2 Future Work on the Y-Reason suite (Y-Reason v2) 34
REFERNCES 35
APPENDIX 37
A. Design Documentation 37
A.1 Translating goal model to HTN planner: Algorithm 37
A.2 Y-Reason Screenshots 40
B. Examples 43
B.1 Sample Goal Model 43
B.2 SHOP2: sample inputand output 44

6. 6
Chapter1
Introduction
During the requirements gathering phase of a project, there is a crucial need to capture the requirements
concisely and to ensure no requirements or facts which may influence the system implementation are
missed. In order to capture requirements with accuracy and completeness the use of goal models has been
proposed. Goal models capture in a semi-formal diagrammatic fashion the intentions of stakeholders and
how these intentions relate to each other, allowing thereby analysts study the reasons why certain
functionality might be required by stakeholders. This way, the resulting functional specifications have
both a sound justification and a completeness criterion.
In goal models the main goal (root goal) is decomposed into sub-goals and tasks until no further
decompositions are possible. This allows the parties involved in requirements gathering to visualize and
therefore to understand the tasks and goals which are needed to be accomplished in order to achieve the
main goal and to explore any alternatives in the design of the system as well as any complexities such as
pre-requisites and anti-requisites among sub goals and tasks. Goal models can be further extended to
include additional information to further aid in system designing and to ensure successfulend product.
Currently, there are numerous frameworks available for developing goal models. Examples of popular
goal modeling frameworks include i* [4], Tropos [3], and KAOS[3]. While there may be overlap in the
functionality they provide, each framework has its own unique advantages and supports an ecosystem of
tools for modeling with the framework and doing useful analysis with the models.
For example, in order to model with i*, one may use either OpenOME [11] or iStarTool [24] among other
tools. As with the different competing modeling frameworks, while these tools may overlap in the
functionality they provide (i.e. developing i* goal models), each tool offers unique advantage(s) and thus
provide a critical service to the end user. For example, OpenOME and the iStarTool are applications
which provide a graphical editor for creating and analyzing i* goal. Other tools, such as the T-Tool, focus
on integrating other formal reasoning frameworks to allow for advanced analysis over goal models.
Nevertheless,since these tools are needed to perform goal modeling, often the user becomes reliant on
one or more of them. However,with passage of time, some of the tools which haven’t been updated
become difficult to use because of incompatibility issues with newer versions of technology used by the
user’s host environment (e.g. operating system versions and compilers). Other times, whenever software-
level integration with the tool is needed, the user needs to learn and use a specific method (e.g. API calls)
in order to interact with the tool from his/her software program. This leads to interoperability issues
whenever the user wants to user part of the functionality of another goal modeling/reasoning tool.
1.1 Motivation
We illustrate the difficulty with the current tool development approach in the community using an
example. Liaskos and his colleagues have developed a number of techniques for performing reasoning
with i* based goal models using different third party AI reasoning tools [5]. Such tools include a Lisp
based planner, SHOP2 [18], various Prolog based tools, such as Golog [28], DT-Golog [14], PPlan [29],

7. 7
each requiring their own implementation of Prolog, as well as planners that come as simple Unix-based
executables. The research team wished to develop tools in order to demonstrate the techniques and allow
others to benefit from them. They needed a visual editor, in which graphical models can be efficiently
developed, a set of procedures to translate the goal models into the formal specifications (i.e. the
implementation of the proposed technique), and a component which would allow integration with the
third party tools.
Since the researchers are mostly motivated towards publishing rather than tool development, tool qualities
other than correctly implementing and demonstrating the technique are often of low priority. In the
particular case,the researchers wanted a quick way to generate formal specifications from goal models
and run them in their custom platform installations. Thus, MS Visio was used for model development and
VBA scripts were written to translate from the graphical models to text files containing the AI formalism.
The text files are manually (or with partial automation from tools) inputted to the AI planner. The solution
served the purpose of the team and can be potentially posted for sharing. In general, such tool sharing
does not involve any kind of support and is often very limited in terms of instructions and documentation.
To see the issues with this approach consider that another research team,say Skosail and her colleagues,
wants to extend and reuse aspects so the Liaskos et al. tool, particularly the translators which are the core
of their contribution. Firstly, she would have to adopt MS Visio, a proprietary software system,in order to
develop her models; disregarding her own editor and all associated processing capabilities (we assume
she also studies reasoning with goal models). Secondly, she would have to copiously find and install the
appropriate versions of the third party reasoning tools, and the corresponding platforms (LISP, Prolog,
etc.). Should she further want to extend and redistribute the tool suite, it would result in even more third
party dependencies and installation procedures. In any case,substantial reverse engineering effort would
be required to understand what the other group has done and how to make it work. Rather than risking
that, Soksail and her colleagues would rather just re-implement things that Liaskos et al. has already
implemented, creating, as such, an overlap between the tools. Note that even if Liaskos at al. had de-
coupled editor and translator somehow, the installation effort as well as the platform and language
compatibility problem remains.
What could Liaskos et al. do in order to maximize utility for the community? It is our view in this project
that researchers should adopt a service oriented approach to tool development. In particular they can
isolate their particular contribution, implement it the way they can, then hide it behind an accessible web
service. This way,researchers who just want to use the particular contribution in their tool, they simply
need to implement a call to an on-line web service.
Following this approach has the following potential benefits:
1. Allows individual researchers to share software implementing their contribution, without being
concerned with installation instruction and documentation.
2. Allows other researchers to use and integrate in their own tools the functionality they exactly need,
without making language, platform or architectural commitments.
3. Reduces the amount of functional overlaps across tools produced in a given research community.

8. 8
4. Allows code produced to remain in working state for a longer time by controlling the host environment
(in terms of operating system version and software package versions).
5. By allowing tool developers to avoid worrying about user issues related to install and setup, more time
can be invested in further improving the tool itself and its documentation.
These benefits are exhibited under the assumption that: (a) a managed server infrastructure is available,
(b) tool use implies internet connectivity, (c) time lag due to using remote services is not disruptive, (d) a
data interchange language is developed and available. We show later how these are actually not strong
assumptions today.
1.2 Project Objectives
In this project, we aim at showing how an individual researcher within the goal modeling community can
develop a tool utilizing the benefits of service-orientation discussed above. We do this via introducing a
simple reference architecture to be instantiated for developing research tools.
Our reference architecture is based on an interchange language that allows for modularizing individual
contribution with the least possible coupling. To demonstrate the relevance of such a language, we first
define extensions to an XML-based language, called iStarML, for representing interchangeable goal
models within a popular framework (i*). Our iStarML extension, iStarML+ P,incorporates preferences
and other elements introduced by a series of publications [2][26]. Our purpose is to show that it is
possible to introduce extensions to such core XML languages and use them to integrate tools.
We then specify the elements of our reference architecture which researchers can instantiate in order to
develop service-oriented tools. As a case study, we present an implementation of our reference
architecture by developing a web service which allows users to submit appropriately extended i* models
and allow the service to calculate plans within the goal model, using a Hierarchical Task Network (HTN)
reasoning tool called SHOP2.
1.3 Project Contributions
In this project:
 We explore extensions to iStarML which can allow the development of interoperable tools that
implement a series of research contributions on reasoning with requirements goal models.
 We propose a service-oriented reference architecture for such tools.
 As an application, we develop a tool that translates one such iStarML extension into SHOP2 and
describe the tool in detail.
1.4 Report Outline
Background information relating to goal modeling and i*, iStarML, hierarchical task networks and
SHOP2,reasoning about goal modeling, and tool support for reasoning about goals is presented in chapter
2. Chapter 3 provides details about our extension to iStarML, iStarML+ P, which enables i* preference
based goal modeling. Meanwhile chapter 4 describes the need for and details about reference architecture
for service oriented goal modeling reasoning solutions. Finally, we end our report in chapter 5 by

9. 9
presenting a case study (Y-Reason) which utilizes iStarML+ P and implements the reference architecture
for service-oriented goal modeling reasoning solutions presented in chapter 4 before presenting our
conclusions.

10. 10
Chapter2
Background
2.1 Goal Modeling and i*
When designing a software system,there are different groups/teams of people working with a very
different set of goals/expectations. In order to ensure these differing set of goals/expectations are
captured, requirements engineering is utilized. The traditional approach to requirements engineering was
to simply describe functionalities of the system-to-be while leaving the goals of these various
stakeholders implicit or even unknown. This practice, however, of ignoring the reasons why requirements
are required, may lead to systems that are not complete (i.e. do not fulfill all stakeholder needs) or have
irrelevant features (i.e. functions that are unnecessary). Thus explicit capture and representation of
stakeholder goals has been recognized to be essential during requirements engineering. Goal modeling
languages (e.g. [4][24]) fulfill exactly this purpose, i.e. to explicitly represent stakeholder goals and
alternative ways to solve them.
A given goal model, primarily consists of goals and tasks. Goals are used to describe conditions or states
of affairs which one or more actors of interest wishes to achieve [2] whereas tasks describe specific
activities an actor needs to perform in order to fulfill its goals [2]. The goals and tasks in the model are
connected using links such as AND/OR decomposition to provide logical modeling and may include
other such relationship links. A sample goal model is presented in Appendix B (B.1 “Sample Goal
Model”).
The i*framework (pronounced i-star) is one of the most established requirements modeling frameworks.
The primary objective of i* framework is to allow modeling and reasoning of the organizational
environments and their information systems. The framework itself is built on the concept of ‘influential
actor’. These actors are organizational actors and have properties such as goals, beliefs, abilities, and
commitments. Actors are often dependent on other actors to accomplish tasks/goals and for efficient
usage of resources [3].
For goal modeling, i* framework consists of two main modeling components: strategic dependency (SD)
model and the strategic rationale (SR) model. The SD model describes the dependency relationships
between various actors in an organizational context [3] whereas the SR model describes the interests and
concerns of stakeholders, and how they can be resolved by various combinations of systems and
environment [3].
A variety of other goal modeling languages have also been introduced, either independently or as dialects
of i*. KAOS for example ([33][34]) is a goal modeling language that emerged around the same time as i*
did but with the focus rather on formal specification and verification of goals rather than high-level
qualitative analysis thereof. The i* framework itself was elaborated into a language called GRL [35]
which was then adopted by the User Requirements Notation (URN) [36], which combines i* with use
case maps for offering both an intentional and a behavioural view of the early requirements. The
framework Tropos [37],while very similar to i*, is often considered to be a separate dialect thereof. In

11. 11
addition, individual researchers introduce their own extensions to the core modeling languages in order to
model concepts that concern them, such as for example adding commitments [38].
In this project, we primarily focus on i* and the very essential features thereof which are the basic types
of goals and their decompositions.
2.2 ReasoningaboutGoal Modeling
In goal modeling, any requirements gathering effort utilizes the fact that there is a root goal to be
achieved for the system being designed, and that the root goal should be decomposed (typically using
AND/OR decomposition) into sub-goals and tasks (tasks can also be decomposed into sub-tasks) until we
reach leaf-level tasks (tasks which are primitive operations and can no longer be decomposed further). By
using goal modeling for requirements gathering, we are able to get a fresh perspective on system
designing where we not only take into account the main goal to achieve, but we also explore complex
relationships between various sub-goals and tasks. By using goal modeling, we are also able to define and
capture soft goals and other relationship links between goals/tasks such as pre-requisites and anti-
requisites.
For realistic system modeling, there is a need to validate the goal models created against defined set of
rules/constraints in order to create domain specific goal models. In order to do so (goal model validation)
we need to obtain feedback in terms of an output plan (which provides the user with feedback in terms of
what order the sub goals must be achieved in order to meet the root goal). Therefore,beyond system
modeling, we can utilize goal models for tasks such as executing goal models against SHOP2 reasoning
and analysis systems, such as AI planners, and to obtain the planner system’s output. This involves
translating a given goal model to low-level language syntax which can then be interpreted and executed
by the planning system.
For example, Giorgini et al. in [39] describe how traditional goal modeling can be extended to account for
various real-world factors (such as inflation and product pricing) to create a realistic goal-modeling for
car manufacturers looking to increase their product sales and profitability. Giorgini et al. in [39] also
describe algorithms which can parse and analyze the extended goal models to produce statistical output
thus helping the car manufacturers to model and view the impact of their strategies. Similarly, Asnar et al.
in [40] also extend traditional goal modeling to allow accounting for various real-world factors (in the air
traffic management domain) and they too describe how to convert goal model into a specification which
can then be executed against an AI planner called LPG-td.
In a similar vein, Liaskos et al. in [10] describe an algorithm to convert goal model into HTN
specification (which can then be used by HTN planners such as SHOP2 as input). In another paper [2]
they explore converting goal models to DT-Golog (which is a “formal specification language that
combines idea from dynamic domain specification languages and Markov Decision Processes (MDPs)”
[2]). Meanwhile [25] defines conversion of goal models to a STRIPS-based planning language (for
PPlan). We return to these conversions below as they relate to our iStarML extensions and our application
case.

12. 12
2.3 Tool SupportforReasoningaboutGoals
There are many different tools available online for modeling goals and performing reasoning as discussed
earlier. They include (among others) OpenOME, jUCMNav, and iStarTool. Almost all these tools require
user to download and install the tool before they can be used.
OpenOME (Open Organization Modelling Environment) is a general purpose goal modeling and analysis
tool. It provides users with a graphical interface for developing models, and it supports access to a
knowledge base that allows for computer-aided analysis [11]. Meanwhile jUCMNav, like OpenOME, is
also a graphical editor and analysis tool. It is also a transformation tool for the User Requirements
Notation (URN) [12]. The iStarTool is also a graphical editor but unlike jUCMNav which allows
modeling with URN,it supports system modeling using the i* framework [13]. Besides providing goal
modeling capability, OpenOME supports goal model reasoning in terms of validation of goal models
created as well as analysis of the goal model itself whereas jUCMNav supports execution and reasoning
of goal models and allows sophisticated goal model analysis by utilizing timers, events, and switches.
While these tools effectively fulfil the need for goal modeling as well as in some cases reasoning about
goal modeling, extending the tools with third party modules and making the tools work together remains a
challenge. As such, researchers have acknowledged the need for interoperability amongst i* tools. At the
center of the discussion are developing core i* ontologies [30] and, more relevant to our work,
introducing XML based languages for representing goal models. The canonical one is iStarML which we
present in the next section.
Taking these limitations into account, in this paper we define a web service based reference architecture
for such goal modeling tools. We also provide a case study which utilizes the i* framework and
transforms i* goal models to SHOP2 syntax and executes the model against the SHOP2 planner (the case
study demonstrates the applicability of the reference architecture). This allows the researchers to develop
reasoning tools by providing access to their tools in a service-oriented manner and thus eliminating the
need for the end user to download and install the reasoner tool on his/her environment.
In business terms, our approach provides cost benefits by realizing time savings required for often
complicated process of getting the reasoner(s) to properly setup and execute on the host machine. This
also allows the researchers to avoid upgrading their reasoning tool frequently due to changes in compilers
and general environmental changes such as operating system versions.
2.4 iStarML
At the time i* was introduced, it was presented as a diagram-based modeling tool (similar to other
graphical modeling tools) and for many years since, the i* models were developed using such tools. As
we saw,however, performing interesting analysis is an integral part of goal modeling and, in this aspect,
there was a great variety of techniques each coming from different research groups. This in turn gave rise
to the need for software integration where integration between a graphical tool (e.g. visual i* goal
modeller) and another software program is required. Such an integration may be achieved by use of
Application Programming Interfaces (APIs) or by using a common ‘language’ which can be created by

13. 13
the client (either user supplied or programmatically) and can then be parsed/consumed by the graphical
tool (e.g. i* goal modeller).
While APIs may be used for software integration, they present yet another limitation: the API method
defines integration very specifically – it is application specific and future integration with another tool
will likely involve set of vastly different APIs (and thus additional tool specific coding) in order to
integrate with the tool. A better strategy for software integration should involve a solution which is both
tool independent and technology independent at its core.
One such solution (using a common language independent of technology) involves using industry-
standard language such as Xtensible Markup Language (XML) which was introduced in 1996 (modeled
after HTML) to aid in software development. “XML allows Computer Programmers to model data
descriptively using HTML-like tags (e.g. <car><type>sedan</type></car>) which in turn allow seamless
collaboration between different software programs (independent of environment/technology)” [6]. Since
introduction of XML and its mass adoption across many industries and domains, many XML-based
technologies (e.g. XSD, RelaxNG, and Schematron) have been introduced to provide validation for XML
documents being prepared.
Using the comprehensive validation techniques provided by Schematron, in 2006 Carlos Cares created
istarML (i* Markup Language) that defines i* in terms of XML (Figure 1) allowing creation of XML
based i* documents [7] while making sure that the istarML models adhere to the specifications set by the
i* framework. Since istarML is a XML based language, like XML, it too can be utilized for information
interchange between distributed systems. And since istarML’s validation rules are defined using
Schematron, one can extend these rules as well as create new ones to create an extension to istarML itself.

14. 14
Figure 1. Sample i* diagram and its istarML representation.
The aim of istarML is to provide a language for representing the core istarML elements that are used
across different dialects and tools. However,to perform interesting analysis researchers often need to
extend the notation with their own constructs (e.g. [31]), which in turn need their own XML-based
representation. Thus, istarML alone might not be entirely useful without allowing researchers to extend it
in order to model their own constructs.
2.5 HierarchicalTasknetworks andDT-Golog
As our example istarML extension in this project concerns two specific types of reasoning languages,
Hierarchical Task Networks, and DT-Golog, we offer here an overview of these systems. Hierarchical
Task network (HTN) planning is an approach for domain-specific planning. The core concept of HTN is
to compute a plan for the given problem by decomposing goals and tasks into sub goals and sub tasks
until they can no longer be decomposed. A HTN planning problem consists of an initial state (state of
world at beginning of the problem), initial task network (set of tasks to be executed along with their
constraints) and the domain description. The domain description consists of: a set of ‘planning operators’
which define the actions needed to be done to perform a task, a set of ‘methods’ which define all possible

15. 15
decomposition of tasks into subtasks (if decomposition is possible), and optional information such as
helper functions and axioms [8].
The Simple Hierarchical Ordered Planner 2 (SHOP2) is a planning tool which provides domain-
independent planning based on “ordered task decomposition – a modified version of HTN planning that
involves planning for tasks in the same order that they will later be executed” [9]. As input, SHOP2
requires a planning domain and either a single planning problem or a set of planning problems. Planning
domains consist of logical atoms (initial state) as well as task lists. All components of a planning domain
(i.e. operators, methods and axioms) involve logical expressions. Logical expressions combine logical
atoms (predicate symbols and terms) using conjunction and disjunction. The lists of tasks in planning
problems are composed of task atoms. The components of domains and problems are all ultimately
defined by various symbols [9]. A sample SHOP2 input program and its output can be found under
Appendix B (B.2 “SHOP2: sample input and output”). While there are other planning systems such as
DT-Golog (Decision-Theoretic goal modeling planner) and PPLAN (preference based best-first search
planner), in this report we focus on SHOP2 and HTN planning.
Another formal language of interest is DT-Golog [14], a decision theoretic dialect of the Golog family
[14]. As with planners, in Golog [28] actions are first class citizens, with preconditions and effects
capture through precondition and successor state axioms, respectively. What makes Golog different from
planners is the fact that it combines the planning specification with an imperative language for writing
complex programs, which makes for a more powerful language. Decision Theoretic Golog, DT-Golog in
short, is an extension of Golog, which allows for decision theoretic analysis. DT-Golog assume
uncertainity in action execution: an action may succeed or fail or otherwise bring about different
outcomes with different probability. As such Golog includes stochastic actions, which are actions that
connect actions with a probability distribution over possible outcomes. In addition it allows representation
of utility: each action or state is assigned a value expressing the desirability of that particular state or
action. DT-Golog’s reasoner computes plans based on maximization of accumulated expected utility,
found by progressively calculating the product of probability of being in a given state to the utility of the
same state.

16. 16
Chapter3
ExtendingiStarML:iStarML+P
3.1 Overview ofExtensions
As we saw,automated reasoning with goal models rarely uses “vanilla” i* models. Rather, researchers
add their own extensions that are pertinent to the kind of reasoning they want to perform. The resulting
augmented models are then typically translated into a specification language that can be read by an
external reasoning tool. For example, [2] explores converting goal models to DT-Golog and in order to do
so with i*, we must first extend i* to allow us to define items such as effect table.
But how can those extensions be modeled in iStarML to allow for interoperability? In this chapter,we
describe a few extensions we introduced to iStarML in order to support reasoning tasks prescribed in
various works by Liaskos et al. in [10]. The result shows that extending iStarML to accommodate such
extensions is possible and paves the way for further work on the matter.
In classic i* framework,concepts such as goals, tasks, and actors along with logical AND/OR
decompositions are used to create goal models. In [10], Liaskos et al. describe “the need-for and how-to
incorporate probability into conventional goal modeling techniques (such as those offered by i*). These
extensions in turn allow for more accurate goalplanning as the enhanced model acknowledges and
accounts for less-than-ideal situations” [6]. Therefore,to aid this concept, Liaskos et al. in their paper [10]
introduced the concept of ‘effect table’, ‘utility table’, ‘priority table’ and ‘precedence links’. Our
extension to iStarML (iStarML+P) consists of defining these extensions to the base iStarML’s
Schematron file (effect table, utility table, priority table, and precedence link). Over the next two sections
of this chapter,we further introduce these modeling concepts and describe how we represent them in
iStarML.
3.2 AddingTemporalConstraints
The first extension introduced by Liaskos et al. [2] is the precedence constraints. Through precedence
constraints we are able to specify constraints on the orderings by which goals of a goal model can be
fulfilled. Precedence links allow two new types of relationships to be defined between two i* intentional
elements (e.g. tasks,goal, soft goal). The precedence link may have one of two possible values: ‘pre’ and
‘npr’.
As per [2], ‘pre’ indicates that the ‘source’ element (i.e. goal or task) must be completed before the
‘destination’ element can be attempted. On the other hand, ‘npr’ means that if the source element has
been completed, then the destination element cannot be attempted.
In order to model precedence links in iStarML, we work as follows: The precedence link has been
modeled after the already existing ‘contribution’ link of istarML which allows the user to define
contribution in terms of positive or negative. Since the precedence link is defined under the ‘ielement’
context (to allow precedence as a type of link between two ‘ielement’ tags/objects), it must be placed
within the ‘ielement’ start/end tags. For example representing precedence links in terms of iStarML from
goal model diagram in (see Appendix B.1),

17. 17
Figure 3. Sample i* illustration of precedence link
<ielement id=”91” type=”task” name=”ParticipantsAttendMeeting”>
<ielementLink type=”precedence” value=”pre”>
<ielement iref=”81”/>
</ielementLink>
</ielement>
This example illustrates the ‘precedence’ link with the value of ‘pre’ between two ‘ielements’ (goal
‘meeting announced [source] and task ‘Participants Attend Meeting’ [destination]) which states that the
task of having participants attend a meeting can only be accomplished if the meeting was announced.
Figure 3 shows a sample i* illustration of the precedence link (the ‘id’ has been added to goal and task to
aid user understanding of iStarML).
3.3 Modeling Effects and Utilities
While precedence constraints suffice for translation to SHOP2, translations to DT-Golog require more
extensions. In the DT-Golog work, the effects of tasks are considered to be non-deterministic and as such
they are associated with a probability distribution of possible outcomes. Such distribution is described in
form of a table. Furthermore, in order to model effects,utility, and priorities, in iStarML+P we introduce
the concept of effect table, utility table, and the priority table.
As per [2], the effect table is used for modeling the effects of tasks and their probabilities. This table
includes attainment formula (“signifies what effects must be brought about to consider a goal or task
satisfied or performed” [2]) and domain predicates (“which model the state features of the domain” [2]).
Utility table is used for connecting the state of domain with the achievement of goals and soft goals.
Similar to the effect table,utility table also contains domain predicates and condition variables whereas
the priority table is a table prioritizing goals in terms of probability (to a maximum probability of 1.0).
In order to model effect table in iStarML, we work as follows: since the effect table consists of decision
variables, condition variables, domain predicates, and attainment formula; we must encapsulate all these
elements in an encompassing effect table element. For example representing an effect table (Figure 4a –
reproduced below) in terms of iStarML,

18. 18
Figure 4a. Sample Effect Table [2].
<effectTable iref="121">
<decisionVariables>
<decisionVariable id="121a" name="excellentResponsesReceived"/>
<decisionVariable id="121b" name="adequateResponsesReceived"/>
<decisionVariable id="121c" name="toofewResponsesReceived"/>
</decisionVariables>
<conditionVariables>
<conditionVariable id="121x" name="waited1Day"/>
<conditionVariable id="121y" name="wated3Days"/>
<conditionVariable id="121z" name="waited1Week"/>
</conditionVariables>
<domainPredicatesET>
<predicate cref="121x" dref="121a" probability="0.0"/>
<predicate cref="121x" dref="121b" probability="0.33"/>
<predicate cref="121x" dref="121c" probability="0.67"/>
<predicate cref="121y" dref="121a" probability="0.17"/>
<predicate cref="121y" dref="121b" probability="0.5"/>
<predicate cref="121y" dref="121c" probability="0.33"/>
<predicate cref="121z" dref="121a" probability="0.83"/>
<predicate cref="121z" dref="121b" probability="0.17"/>
<predicate cref="121z" dref="121c" probability="0.0"/>
</domainPredicatesET>
<attainmentFormula>
<attainFormula decomposition="or">
<afElement dref="121b"/>
<afElement dref="121a"/>
</attainFormula>
</attainmentFormula>

19. 19
</effectTable>
Here we specify our decision variables and assign each an ID. We take advantage of the XML rule that all
ids assigned inside of a XML document must be unique to make sure all decision variables can be
referenced without ambiguity when needed. For each decision variable, we utilize the ‘name’ attribute to
set the name of decision variable.
We then specify the condition variables where similar to the case with decision variables, we set an
element ID for each condition variable and set its name. Following this, we define the domain predicates
– here we utilize the element IDs of the condition and decision variables to define each predicate and then
use the attribute ‘probability’ to assign it a probability. In order to keep in line with the istarML standard,
we call the condition variable id ‘cref’ when referencing it and call the decision variable id ‘dref’ when
referencing it. Finally we define the attainment formula for the task where the attainment formula is
specified in terms of conjunction/disjunction and references the decision variables.
In order to model utility table in iStarML, we work as follows: similar to the effect table, since the utility
table is composed of defined dependencies as well as domain predicates, we must encapsulate all these
elements in an encompassing utility table element. For example representing a utility table (Figure 4b –
reproduced below) in terms of iStarML, we can work as follows:
Figure 4b. Sample Utility Table [2].
<utilityTable iref="131">
<dependsOn>
<dependOn id="131a" name="calledEverybody"/>
<dependOn id="131b" name="reminderArrived"/>
</dependsOn>
<domainPredicatesUT>
<predicateUT isFpNOT="no" fpref="131a" stref="131b" isStNOT="no" utility="0.0"/>
<predicateUT isFpNOT="no" fpref="131a" stref="131b" isStNOT="yes" utility="0.3"/>
<predicateUT isFpNOT="yes" fpref="131a" stref="131b" isStNOT="no" utility="0.7"/>
<predicateUT isFpNOT="yes" fpref="131a" stref="131b" isStNOT="yes" utility="1.0"/>
</domainPredicatesUT>
</utilityTable>
Here the domain predicates represent the effect a goal (such as calledEverybody) may have on a softgoal
(such as ‘Avoid Annoying the Participants’) if the specified goal in the utility table is actioned upon by
taking a particular strategy (e.g. in the case of calledEverybody,we can take two different strategies:

20. 20
reminderArrived or notreminderArrived). Therefore in iStarML, we capture the domain predicates in
terms of goals and strategies and we also capture the value of utility each goal/strategy.
Finally in order to model priority table in iStarML, we work as follows: similar to the effect table and the
utility table, since the priority table is composed of defined goal probabilities, we must encapsulate all
these elements in an encompassing priority table element. For example representing a priority table
(Figure 4c – reproduced below) in terms of iStarML,
Figure 4c. Sample Priority Table [2].
<priorityTable>
<goalPriority iref="131" priority="0.1"/>
<goalPriority iref="141" priority="0.2"/>
<goalPriority iref="151" priority="0.7"/>
</priorityTable>
Being a relatively simpler table (as opposed to effect and utility tables), it only contains ‘goalPriority’ as
the child elements where the ‘iref’ refers to the ids of either goals or soft goals and priorities must be
greater than equal to 0 and less than or equal to 1.
3.4 Summary and FutureWork
In this chapter we presented an extension to istarML (iStarML+P), by using the concepts presented in [2],
we introduce concepts such as precedence links, effect table, utility table, and priority table. Our
extensions are not exhaustive: for example preference formulae [10] can be introduced through XML
representations of logical and temporal formulae and combined with our representation of priorities. Our
goal here is to show that such extensions are relatively straightforward.
Our future work will include extensions to the iStarML+P Schematron file in order to allow us to create
decision-theoretic goal models that can then be transformed using our reference architecture to DT-
GoLog syntax and be executed against it to produce a plan. In order to do so, we will have to define the
new istarML syntax and validation rules in iStarML+P to allow various XML tags in order to define the
Markov Decision Processes (MDP) and the related situation calculus required for DT-GoLog input files
[14].

21. 21
Chapter4
A Service-oriented ApproachtoRequirements ReasoningSystems
4.1 Context and DesignGoals
In this chapter,we present a reference architecture for tools that allow reasoning about goal models. The
use of such a reference architecture is to sketch how tool developers can servicize the reasoning aspects of
their tools decoupling them from other functional aspects of goal modeling such as the user interface for
drawing such models or other analysis components.
To appreciate the need for service-oriented architectures one must first understand the development
practices and artefacts in the goal oriented requirements engineering community. While our description is
based on rather anecdotal observations, the characteristics of the available tools seem to support our
understanding. The tools that we discuss here are open-source or freeware systems (i.e. often without any
license attached to them) developed within academic or research institutions. A list of such tools can be
found in [13]. They are not commercial, i.e. no-one generates revenue from them, and the development
effect is the by-product (less often: the main product) of the research effort of a graduate student or
temporary research staff. The tools are available to download as part of the research dissemination
process and to enhance the profile of the researchers and impact of the research. While the ambition
seems to be that such tools are embraced by the community of practitioners, they are often used by other
research students and staff in order for the latter to introduce their contributions through extending and
using the original tool
Research students,the primary developers of the tools we consider here, are motivated towards publishing
and finishing their degree. During development, quality aspects of the tool and the development are not
necessarily rewarded by the community. Thus, aspects such as proper quality assurance,usability,
architecture, documentation and extensibility remain a lower priority for the graduate developer who is
primarily interested in quickly producing an adequate result. After graduation, unless their new
appointment and research necessitates this,they may lack resources and motivation to further support and
extend the tool. Hence,given that most of the tools are not commercial, ongoing support is non-existent
or limited to the availability of the primary developer. Sessional developers, on the other hand, who are
sometimes hired to perform specific development work, often using a research grant, may have more
opportunity and skill to develop robust and good quality software. However,this happens only as long as
their contract lasts and naturally without assuming any responsibility after the end of their contract.
The effects of these development practices are that:
1. The produced code may lack proper documentation and architectural clarity to allow for other users to
reverse engineer and extend it without communicating with the original developer, who in turn is
probably unavailable.
2. Design decisions are not made with extensibility, interoperability or ease of use in mind but rather the
urge to quickly produce research output. As such, the result requires substantial investment for a third
party to expand or interoperate with.

22. 22
3. Given the resource limitations, and the innovative nature of their contributions, the tool developers
integrate software found on-line, in an ad-hoc manner. Such software utilizes a diversity of environments
and operating systems. The end-result is a complex web of platform, tool and version dependencies that
are difficult to reproduce.
4. Given the above, third parties who would wish to reuse and extend existing tools, consider the cost of
reverse engineering and adapting them against the cost of re-developing functionalities from scratch.
Often the latter is chosen leading to many competing implementations of the same functions in the
community; particular case in point being goal diagram editors.
How could research developers produce software that alleviates these problems? That is, how can
research tools within the goal modeling community allow for:
1. Quick and easy access to the offered functionality, with minimum learning curve.
2. Quick and easy reuse of specific functions of the tool from within other tools.
3. Independence of the above interoperability from platform or language choices.
4. Maintain reasonable overhead for the primary developer in ensuring the above.
Our reference architecture proposes service-orientation to address those goals in the particular case of
goal reasoners. Such are tools that take as input a requirements specification (e.g. a goal model) and
produce as output the result of some kind of analysis over the specification (e.g. validation, planning,
search,slicing) to be presented to the user,further analyzed or otherwise utilized.
By servicizing the core functions of a research contribution of this kind, the community is able to (1)
access the functionality without installation of any component and its dependencies (2) reuse the
functionality within other tools through simple web-service calls, (3) ignore any platform or language
commitments made by the tool developer. The overhead for the primary developer of the tool is to simply
define the appropriate web-service interfaces,and install the tool in a server,reducing the problem of
providing installation and integration support to one of maintaining and running server on in the internet.
The advantage of the latter responsibility is that it can be taken over by IT personnel (e.g. at an academic
institution) without specific domain expertise.
In a well-designed requirements reasoner system, integration with a new reasoner tool may be provided
by embracing the concept of software modularity. This means that in order for a requirements reasoner to
provide service oriented access to a reasoning tool, translation logic (to convert a requirements model to
reasoner’s native syntax and then to execute it) can be created as self-contained executable modules.
Also, by using a requirements reasoner system, instead of requiring the end user to download the reasoner
tool and setup the tool themselves, the requirements reasoner system provides remote access to the tool.
Keeping in mind the advantages of this approach as discussed above, this has some important advantages
for requirements reasoners:

23. 23
1. The software developer may focus on providing a better front-end/user guide for the end user instead of
constantly worrying about updating/developing the tool to provide compatibility with newer compilers
and different operating systems
2. In terms of economics, it provides benefit to the end user because as mentioned above, a potential large
time savings is observed since there is no need for the end user to spend time downloading and setting up
the host environment in order to use the reasoner tool.
3. While developmental/maintenance neglect may be inevitable given the academic nature of such
systems, if the system is designed to provide service using industry standard protocols (i.e. SOAP or
REST), we can be reasonably confident that the requirements reasoner system developed will remain in
working order long after development and maintenance has subsided.
The reference architecture defined in this report is designed to help the requirements modeling research
community increase collaboration by creating web-based tools that are readily available for consumption
by other researchers in the community. It also serves the purpose of providing a blue print for future tool
enhancements/development in the requirements modeling tool development domain.
4.2 ArchitecturalApproach
4.2.1 Reference Architectures
Reference architecture represents a set of rules and constraints which can be for designing individual
architectures in a certain domain (e.g. designing goal modeling software, compilers, on-line shopping
systems, etc.). They provide guidelines for the software architects to enable them to model a software
system for the domain’s problem space by utilizing a working model [15]. A reference architecture draws
knowledge from the experience from previous architectural and design patterns across various domains.
This is an important factor as it provides assurance that the reference architecture takes into account
various accounts of successes and failures documented (and perhaps publicized) over the years [16].
As an example, consider a popular SQL DBMS PostgreSQL’s Windows OS implementation [19] and a
popular C++ compiler called Visual C++ [20]. In both cases, it is safe to assume that there is a reference
architecture the authors of both products must have consulted in order to ensure that they make use of all
the architectural wisdom that exists in the field on how to optimally design such products: in case of
PostgreSQL,the reference architecture would have been for DBMSs such as [26] while in the case of
Visual C++, the reference architecture would have been for compilers such as [27]. Once that process was
completed, the authors would have referred to and studied the reference architectures (PostgreSQL
architecture and C++ compiler architecture) to design and produce their specific implementations.
For example, in the case of C++ compiler design, the reference architecture would represent following
sequence of steps [32]:
1. Lexical Analyzing: scan the incoming stream of characters (source code).

24. 24
2. Syntax Analyzing: parse the source code using lexical tokens.
3. Semantic Analyzing: resolve semantic information and consult tree nodes for errors.
4. Intermediate Code Generation: generates a semantic graph which contains a syntax tree with added
properties and resolved references.
5. Machine Independent Code Improvement: optimizes the source code by performing operations such as
eliminating redundancies and simplifying computations.
6. Producing machine language: Translates the optimized source code into optimized machine language
(assembly language) for the target environment.
It is really through architecting experience embodied within a reference architecture that designers of a
C++ or other compiler are able to design their products without having to reinvent the wheel. Our here is
very similar: our reference architecture is a proposal for structuring the embodiment of architectural
experience in the particular field of goal reasonsers. We present our result in the following section.
4.2.2 A Reference ArchitectureforRequirements Models ReasoningSystems.
The high-level overview of the reference architecture is showcased in Figure 5. The overview shows that
the system is made of two components:
1. The server-side which encapsulates the actual reasoning tool (such as SHOP2) along with the
underlying classes which holds the business rules for processing the provided services (e.g. reasoning
system execution, user account management, authentication management, transaction management, etc.).
The services in turn are defined through an interface (web services / WSDL) which itself forms part of the
server-side subsystem.
2. The client-side which is responsible for submitting requests along with required information and for
providing the end user with the response returned from the server-side – the client interacts with the
server by utilizing the WSDL published by the server-side.

25. 25
Figure 5. Static Structure of the Reference Architecture.
By utilizing these architectural designs, we provide basis for a system where the client is actually an
editor which allows creation and display of requirements models and the generated solution(s), while the
server is comprised of the backend hosted on a computer with powerful specifications for performing the
automated reasoning task at hand.
Looking at Figure 5, the server side consists of a variety of modules, including: the service control
responsible for orchestrating the necessary activities, user management for validating the user ID,
validation module for validating the job request itself, a transaction management module which simply
queues and executes requests sequentially or in parallel based on system constraints and user privileges, a
translator for translating the job from the interoperable format (e.g. iStarML) to the native one as well as
the reasoner (interface),which wraps the reasoning tool, which, in turn, is a native executable (including
Prolog, Lisp or other interpreter).

26. 26
Figure 6. Behavioural View of the Reference Architecture.
The corresponding behavioural view can be seen in Figure 6. Jobs in the interoperable format propagate
from the web service interface towards the interface. Eventually they are translated to the language of the
reasoner (mentioned as “syntax” in the diagram), which in turn returns the response to the web interface
for SOAP wrapping and sending back to the client.
It is worth pointing that, apart from using the ‘client-server’ architectural pattern, as it became obvious
above, the ‘pipe-and-filter’ pattern is also utilized [16]. The filters in our design are:
1. SOAP parser:This filter performs the role of parsing the incoming SOAP message. In the case of
incoming SOAP envelope, the content is iStarML+P representation of the goal model.
2. Transform to Reasoner syntax: This filter performs the role of transforming the iStarML+P
representation of the goal model to reasoner specific syntax (e.g. iStarML+P to SHOP2).
3. Execute Reasoner:This filter performs the role of executing the reasoner.
4. Reasoner Response syntax: This filter performs the role of placing the reasoner output within the
SOAP envelope and sending it back to the client.
The pipes on the other hand are representative of the various classes of business logic within the software
system which invoke the filters in an orderly manner while passing along information required by the next
step. Thus, a (rather static) pipeline is formed whereby the SOAP representation is gradually translated
into a formal representation and finally into a reasoning result, which is again translated into a SOAP
message to be sent back to the client. The way these are implemented is up to the users of the reference
architecture.

27. 27
For our reference architecture,we don’t provide any details regarding the client-side as the only
requirement for the client-side is to be able to communicate with the server-side via web services (i.e.
SOAP or REST) and to provide handling for user input and responses returned by the server-side.
Therefore,focusing on the server-side, in Figure 6 we provide the pipe-and-filter view of the server-side
reference architecture.
Figure 7. Pipe-and-Filter view of the server-side reference architecture
The reference architecture provided in Figures 5 and 6 is intentionally kept simple by eliminating from
view any solution specific details (such as the database layer and interface details) both for sake of brevity
and to produce an architectural statement that would be applicable for the target domain (requirement
modeling).
All these components allow the authors to create a fully functional and robust service-oriented application
and helps standardize the usage of XML as the data interchange language between the client and server
for goal models. It also allows future introduction of additional reasoning tools in an organized fashion
which is highly modularized thus requiring no updates to the core application (i.e. the web service). The
database can be seamlessly introduced to this architecture by using technologies such as JDBC/Hibernate
(in case of java) or Active Records (in case of Ruby-on-Rails) whereas the various components of the
application communicate with each other by utilizing interfaces,native calls, and through the use objects.

28. 28
Chapter5
CaseStudy:Y-Reason:TranslatingfromiStarML+PtoSHOP2
5.1 Overview
We now provide an implementation of the reference architecture proposed to deliver a requirements
modeling software system called Y-Reason. The software system implemented, Y-Reason, is a web-based
system that utilizes XML and SOAP in order to allow researchers to submit their i* goal models in
iStarML+P which are then translated to goal modeling planner’s input files (such as for SHOP2 HTN
planner) before being executed with the target planner and the planner output being returned to the user.
The incentive behind the creation of Y-Reason is not only to allow access to an online tool to a researcher
so no setup is required, but to also provide a system which facilitates future additions (in the case of Y-
Reason,this entails addition of various other automated reasoning tools such as DT-Golog and PPLAN)
while maintaining a reasonable response time to service the end user in order to maximize user adoption
in the research community.
5.2 ArchitecturalDesign
Based on the reference architecture described in Figures 5, 6 and 7, we have implemented our software
system – Y-Reason. The high level Y-Reason architecture is provided in Figure 8. In the diagram, how
the archetype modules that appear in the reference architecture are implemented in Y-Reason is
represented through specialization relationships. Some examples of how the reference modules are
instantiated include:
1. The iStarML+P validation and DOM generation module in Figure 8 implements the “Validation”
component of Figure 6 and corresponds to the “XML Parser” filter of figure 7.
2. The LISP interface module is responsible for sending the native call to the LISP interpreted, which in
turn is appropriately loaded with the SHOP2. It implements the “Translator” reference module.
3. Both User Management and Log Management are implemented through a Data Layer module which
connects to a PostgresSQL DBMS.

29. 29
Figure 7. Y-Reason architecture
In Y-Reason,we provided integration with the SHOP2 planner tool from our Java-based (J2EE) web
service. We utilized the JAX-WS (Java API for XML – Web Services) library to define the Java interface
which is used to create the WSDL file while using JAX DOM (Document Object Model) class for XML
parsing.
The translation logic to convert XML to SHOP2 syntax was placed inside a Java class (this Java class is
our implementation of the reference architecture’s Transformto ReasonerSyntax filter as described in
Figure 6). This class also executes the SHOP2 planner – this translation logic utilizes the W3C DOM
library in Java to utilize APIs offered by the DOM library for browsing/traversing the XML document.
In order to provide iStarML validation, we used a freeware tool called Probatron4J [21] to validate the
iStarML document against the iStarML schematron document. This represents the XML Parser filter as
described in Figure 6.
Finally, to record various job statistics (job representing the user submitted request to execute the SHOP2
planner) as well as to identify the user (and to provide user authentication), we utilized the PostgreSQL
database [22] along with the Java Hibernate ORM (Object Relational Mapping) framework [23] to
integrate the database with our application. This data store component represents the optional components
we mentioned when defining our reference architecture in section 4.2.2 of the report.
Since our system is a web service application, the entry point to the system is the server-side interface
exposed to clients (WSDL). This allows the client-side applications to make SOAP based requests to the
server-side and to return responses – all in the standard data interchange model defined by SOAP and

30. 30
XML. As a result of this, the system allows seamless integration between the client and server sides
regardless of the technology stack used to develop them. The web service interface identifies the
operations (APIs) which we have made available for SOAP clients to consume – these include converting
the istarML document provided to target planner syntax, and executing the planner (which converts from
istarML to native planner syntax and then executes the planner with it).
On the server-side we implement this web service interface to provide logic to process the interface
operations. Since we have defined our istarML extensions using schematron, we utilize a third party
freeware library to allow validation of the istarML document provided by the user against our schematron
document. We also added a data store element to our software using a SQL database along with a
database logic layer (class) in order to provide CRUD operations for recording job statistics as well as to
provide a very basic user authentication mechanism.
In order to execute planners such as SHOP2,we have an accompanying logical layer (e.g. SHOP2 class)
which executes the planner and is also responsible for converting istarML to native SHOP2 syntax. Since
we would like to be able to extend our system’s functionality in the future by introducing integration with
new planners (e.g. PPLAN),instead of calling the planner’s logical layer directly, we utilize another
interface (planner interface) which allows us to utilize polymorphism from the class representing the web
service interface implementation to easily instantiate and call objects belonging to different planners.
For the client-side, we utilize the web service interface (WSDL) to establish a SOAP connection and to
make requests against the server-side while providing the required API parameter values. In addition to
making SOAP requests and getting back output from the server-side, the client allows user to select
istarML file to send and allows user to save output returned to their local file system.
5.3 Core TranslatorDesign
The core translator design is based on a paper by Liaskos et al. [10] in which they describe an algorithm
to convert input from a goal based model to HTN planner (the goal model being represented in terms of
goals and tasks using models similar to those produced with i* but extended with preferences and HTN
planner similar to SHOP2). The algorithm can be divided into three parts: eliminating optional subgoals,
constructing the HTN specification, and constructing the planning problem. The algorithm is best
understood through the use of pseudo code and this has been presented in Appendix A (A.1 “Translating
goal model to HTN planner: Algorithm”).
In the algorithm, eliminating optional subgoals involves first identifying all nodes in the model which are
optional subgoals and then for each such subgoal, replacing it by a new hard goal gp
and by introducing a
new dummy task td
(this task is removed from the plans which the planner returns) while maintaining the
precedence and non-precedence links at optional subgoal go
. Construction of HTN specification is the
most complex part of the algorithm which involves introducing HTN domain predicates and HTN
operators for the leaf-level tasks and, for each hard goal ‘g’, introduction of HTN tasks along with
attainment formula and HTN methods. The third part of the algorithm involves the creation of the HTN
planning problem which is accomplished by adding an empty set of initial conditions (I={}) and setting
the HTN goal to the root goal of the mandatory decomposition (G={agr} where ‘agr’ is the HTN task
representing the root goal ‘gr’).

31. 31
By implementing this algorithm, we are able to convert the user provided iStarML+P input to the target
HTN planner (in our case SHOP2) native syntax which can then execute in the backend from our system.
This allows users to utilize a high-level syntax offered by iStarML (along with extensions from
iStarML+P) to create goalmodels and to get planner output.
5.4 Preliminary PerformanceEvaluation
At the core of our architectural approach is the choice to use a client-server pattern in which the front-end
editor communicates with the reasoning procedure via a network and using a series of translations based
on W3C standards. While this approach has the benefits we have argued for above, the obvious cost is the
performance overhead from both the network traffic and the various conversions. But how disruptive is
this necessary overhead? To assess this, we conducted exploratory performance tests. In particular, we
used the system with input goal models of three different sizes and measured how long it took for a client
to get response back from the server (time taken to parse XML to SHOP2 + SHOP2 execution time).
We used three different istarML files for testing: istarML1, istarML2, and istarML3, taken from realgoal
model cases of three different domain. The models slightly differ in the number of goals and tasks that
make up the model (larger files have larger number of goals and tasks as well relationship links such as
precedence links). We ran 100 trials of the translation procedure for all three files. Results from the
testing are displayed on Table 1.
Goal Model # Goals # Tasks Min (s) Median (s) Max (s) Average (s)
iStarML1 18 3 2 2 14 2.95
iStarML2 6 8 2 2 15 3.07
iStarML3 8 12 2 3 66 3.90
Figure 1. Translation Time Statistics
The performance measures reported on the table include the time for translating the iStarML specification
of the corresponding goal model to the local SHOP2 specification. This, we claim, plus network delays
make for the most of the performance overhead for adopting a client-server solution. The results show
that an overhead of 2-3 seconds is expected for the particular translation. Assuming that for such sizes of
goal models, based on the size of the resulting XML message, network delay is similar to that of visiting
web pages, we can conclude that although the introduced overhead is definitely noticeable, it does not
necessarily make reasoning with goal models unusable. Further usability investigation with a finished
goal modeling and analysis system – in this work we focus mainly on the server side – would shed more
light as to how distracting the delays due to the client-serve architectural choice are.
Experimentation with models of larger size would probably be illumining as to how well the translation
procedure scales – and we expect it to scale linearly to the number of goal model elements. It is
furthermore important to add that as goal models increase in size, the reasoning task per se (e.g. SHOP2’s
reasoning work) becomes increasingly costly, often requiring many seconds, minutes or even hours of

32. 32
computation. In such cases, it is the reasoning per se that can potentially challenge usability of the end-
system and not the translation time, which is inconsiderably low comparatively.

33. 33
Chapter6
Conclusions and FutureWork
6.1 Service-based tools forsoftwareengineeringresearch:benefits and challenges
In this report, we looked at the challenges faced by the software tool developers in the requirements
engineering in terms of both development and maintenance of their tools. We also described reference
architecture for service-oriented tool development which utilizes an extended version of iStarML (these
extensions were also discussed in this report). Finally, we presented our implementation of the reference
architecture (Y-Reason) and we presented the advantages (as well as challenges) of developing service-
oriented software tools in the requirements engineering domain.
As with any architecture,there are benefits as well as challenges. In our case,since we are using a web
service model, our challenges include:
1. Availability of the internet. This may not be a concern to users in developed parts of the World
however in some parts where electricity outages are common, this approach can present challenges.
2. Lack of opportunities for tool customization by the client. This will be especially true for cases where
open-source projects usually have the tool’s source code available and users can modify the code to
accommodate any personal computation(s).
3. We have to factor in cyber security risks. We have to guard over software and hosting environment
against risks such as security over the network (network snooping/packet sniffing, denial of service
attack,SQL injection, cross-site scripting, etc.).
4. Application performance. Since instead of directly executing the planner we are calling it from our web
application, we introduce overhead in terms of logical layers which perform various data processing (e.g.
conversion to syntax and schematron validation) before calling the planner itself.
Meanwhile, the benefits of developing service-based tools include:
1. Drastically reduced time for setting up user’s work environment. Since we are providing online access
to planner software such as SHOP2,user no longer needs to download and setup these software
applications themselves.
2. Increased productivity for the software development team. Instead of providing time-consuming
support to users who have problems setting up the system on their environment, the developers can focus
their efforts on providing a robust online application for accessing their tool and can put emphasis on
thoroughly documenting their web service interface for SOAP clients.

34. 34
6.2 Future Workon the Reference Architectureand the Y-Reasonsuite(Y-Reasonv2)
The reference architecture that we have proposed is deliberately high level and abstract to allow
implementers use their own intuition as to how they can realize its various aspects. As such,our reference
architecture acts more as a starting point than as a complete template at this point. Nevertheless additional
components can be added to further guide realization of instances. Two aspects that we find particularly
worth future work are transaction management and security. Transaction management is currently viewed
as a module that simply queues and adds deadlines to jobs based on registration data (e.g. paid
registrations versus free ones). Given that the jobs are requests for heavy computation, it is expected that
performance-oriented management is also relevant. This may come in the form of managing threads,
assigning various priorities to jobs or working with complex server infrastructures such as clusters.
Security is also an aspect that is currently underserved in the reference architecture. More elaborate
authentication and encryption techniques would be a very useful addition to the reference architecture.
For next version of Y-Reason,we accordingly plan on consolidating our current code-base in order to
optimize runtime performance and to develop a job scheduler in order to control concurrent execution of
the planner systems as well as to allow queued/pending jobs to run to completion in event of a system
reboot or a crash. We also plan to develop a security mechanism to detect and thwart cyber security
attacks -- e.g. using HTTPS instead of HTTP,testing user input for SQL injection as well as planner
system injection such as using LISP for SHOP2 syntax, using PGP in order to encrypt response returned
to the user,etc.. Hopefully these enhancements will give inspiration for enriching the reference
architecture as well.
Finally, in terms of evaluation of the client-server idea for reasoning with goal models, we plan to run
more experiments using larger goal models, as well as run usability evaluations using end-to-end goal
modeling and analysis solutions, once the latter emerge.

35. 35
REFERNCES
[1] E. S. K. Yu and J. Mylopoulos. “Understanding “why” in software process modelling, analysis, and design.”
In Proceedings of the 16th international conference on Software engineering (ICSE '94). IEEE Computer
Society Press, pp. 159-168, 1994.
[2] S. Liaskos, S. Khan, M. Soutchanski, and J. Mylopoulos. “Modeling and Reasoning with Decision-Theoretic
Goals” Information Systems Engineering: Conceptual Modeling – Lecture Notes in Computer Science, Springer
Berlin Heidelberg, vol. 8217, pp. 19-32, 2013.
[3] M. Khan. Class Presentation, Topic: “Introduction to goal modeling frameworks and variability” York
Univerity. Toronto.Aug. 09, 2011.
[4] E. Yu. “Modelling Strategic Relationships for Process Reengineering” Ph.D. Thesis. Dept. of Computer
Science, University of Toronto, 1995.
[5] S. Liaskos. “Sotirios Liaskos” Internet: www.yorku.ca/liaskos, [Aug. 02, 2014].
[6] M. Khan “iStarML++ v1.0” Degree Project Paper, York University. Toronto.2013.
[7] A. Viklund. “iStarML resources” Internet: www.upc.edu/gessi/istar/tools/istarml/resources.html, [Aug. 02,
2014].
[8] D. Nau, T. C. Au, O. Ilghami, U. Kuter, D. Wu, F. Yaman, H. Munoz-Avil, J. W. Murdock. “Applications of
SHOP and SHOP2” Intelligent Systems, IEEE, vol. 20, no. 2, pp. 34,41, March-April 2005.
[9] D. Nau. R. P. Goldman, J. Maraist. “Documentation for SHOP2” Dept. of Computer Science, University of
Maryland, Minneapolis. 10 Sep. 2012.
[10] S. Liaskos, S. A. Mcllraith, S. Sohrabi, J. Mylopoulos. “Representing and reasnoning about preferences in
requirements engineering” Requirements Engineerin, Springer-Verlag, vol. 16, pp. 227-249, 2011.
[11] G. Lapouchnian. “OpenOME, an open-source requirements engineering tool” Internet:
www.cs.toronto.edu/km/openome, [Aug. 02, 2014].
[12] P. Boulet. “jUCMNav: Juice up your modelling!” Internet:
jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/WebHome , Jul. 27, 2014 [Aug. 02, 2014].
[13] Ruppert. “i* Tools” Internet: istar.rwth-aachen.de/tiki-index.php?page=i*+Tools, Apr. 06, 2014 [Aug. 02,
2014].
[14] C. Boutilier, R. Reiter, M. Soutchanski, S. Thrun. “Decision-Theoretic, High-Level Agent Programming in the
Situation Calculus” In Proceedingsof the Seventeenth National Conference on Artificial Intettligence and
Twelfth Conference on Innovative Applications ofArtificial Intelligence,AAAI Press. pp. 355-362.
[15] R.N. Taylor, N. Mdevidovic, E.M. Dashofy. Software Architecture:Foundations,Theory, and Practice. USA:
John Wiley & Sons, Inc. 2010.
[16] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, J. Stafford. Documenting Software
Architectures: Views and Beyond. USA: Addison-Wesley.2003.
[17] Y. Yasam. “SHOP2” Internet: yasamyang.blogspot.ca/2013/01/shop2.html, Jan. 15, 2013 [Aug. 02, 2014].
[18] “Simple Hierarchical Ordered Planner” Internet: www.cs.umd.edu/projects/shop, Jun. 2013 [Aug 02, 2014].
[19] “PostgreSQL” Internet: www.postgresql.org, [Oct. 06, 2014].
[20] “Visual C++ resources” Internet: msdn.microsoft.com/en-us/vstudio/hh386302.aspx, [Aug. 02, 2014].

36. 36
[21] “Probatron4J”Interet: www.probatron.org/probatron4j.html, [Aug. 02, 2014].
[22] “PostgreSQL” Internet: www.postgresql.org, Aug.02, 2014 [Aug. 02, 2014].
[23] “HIBERNATE” Internet: hibernate.org, [Aug. 02, 2014].
[24] A. Malta, M. Soares, E. Santos,J. Paes, F. Alencar, J. Castro. “iStarTool: Modeling requirements using the i*
framework” In Proceedingsof the Fifth International i* Workshop (iStar 2011).pp.163-165.
[25] S. Liaskos, S.A. McIlraith and J. Mylopoulos. “Towards Augmenting Requirements Models with Preferences.”
In Proceedings of the 24th IEEE/ACM Internaional Conference on Automated Software engineering (ASE '09).
IEEE Computer Society Press, pp. 565-569, 2009.
[26] “Database Management Systems” Internet: cs.oberlin.edu/~jdonalds/311/lecture01.html [Aug. 18, 2014].
[27] “Compiler Architecture” Internet: cs.lmu.edu/~ray/notes/compilerarchitecture [Aug. 18, 2014].
[28] “Congitive Robotics >> Systems” Internet: cs.toronto.edu/cogrobo/main/systems [Sep. 20, 2014].
[29] “PPLAN: A Best-First Search Planner for Preference-Based Planning” Internet: cs.toronto.edu/~sheila/PPLAN
[Sep. 20, 2014].
[30] X. Franch. “Xavier Franch” Internet: essi.upc.edu/~franch,[Sep. 20, 2014].
[31] “Secure Tropos | Secure Software Development Methodology” Internet: securetropos.org [Sep. 20, 2014].
[32] R. Toal. “Compiler Architecture” Internet: cs.lmu.edu/~ray/notes/compilerarchitecture [Oct. 06, 2014].
[33] A. Dardenne, A. Van Lamsweerde, S. Fickas. “Goal-directed requirements acquistion” Science of Computer
Programming, Elsevier, vol. 20, no. 1-2, pp. 3-50, April 1993.
[34] R. Darimont, E. Delor, P. Massonet,A.Van Lamsweerde. “GRAIL/KAOS: an environment for goal-driven
requirements engineering” In Proceedings of the 19th
international conference on Software engineering.ACM,
pp. 612-613, 1997.
[35] “GRL – Goal-oriented Requirement Language” Internet: www.cs.toronto.edu/km/GRL, [Oct. 06, 2014].
[36] “URN Focus Group” Internet: www.itu.int/ITU-T/studygroups/com17/urn/focusgroup.html, Jan. 18, 2007 [Oct.
06, 2014].
[37] “Tropos” Internet: www.troposproject.org, [Oct. 06, 2014].
[38] A. Van Lamsweerde. “Reasoning About Alternative Requirements Options” Conceptual Modeling:
Foundationsand Applications.Springer-Verlag, pp. 380-397, 2009.
[39] P. Giorgini, J. Mylopoulos,E. Nicchiarelli, R. Sebastiani. “Reasoning with Goal Models”. In Proceedingsof the
21st
International Conference on Conceptual Modeling.Springer-Verlag, pp. 167-181, 2002.
[40] Y. Asnar, V. Bryl, P. Giorgini. “Using risk analysis to evaluate design alternatives”. In Proceedings of the 7th
international conference on Agent-oriented software engineering VII (AOSE’06). Springer-Verlag, pp. 140-
155, 2006.

37. 37
APPENDIX
A. DesignDocumentation
A.1 Translatinggoalmodel to HTN planner:Algorithm
The pseudo code presented is based on paper by Dr. Liaskos et al. [10] and heavily borrows wording from
it.
// (1) Eliminate optional subgoals
For each subgoal go that is optional
-> Introduce one new goal gp
-> Introduce one new task td
-> OR-decompose gp into original go and td
-> gp takes the place of go in the original tree
-> change type of go from optional to hard goal
if 'pre' or 'npr' links were connected to 'go',
they remain as-is (connected to go).
fi
// td
is a "dummy" task that is removed from the plans that the planner returns.
end
// (2) Construct HTN specifications
For each leaf-level task 't'
-> Introduce a HTN domain predicate 'vt' // call this 'task performance
predicated'
-> Introduce an HTN operator 'ot'.
-> Set the effect of 'ot' to be 'eff-ot=vt'
-> Set the operator precondition pre-ot=get_precondition_formula(t)
end
/*
Intuitively the task performance predicate 'vt' represents the fact that the
task 't' has been performed, hence its position as an effect.
*/
For each hard goal 'g' of the goal model
-> Introduce an HTN task 'ag'.
-> Introduce the 'attainment formula' Φg as follows:
If 'g' is OR decomposed into mandatory subgoals then
replace Φg=g with Φg=(g1)v(g2)v...
else if 'g' is AND decomposed into mandatory subgoals then
replace Φg=g with Φg=(g1)^(g2)^...
fi
Φg=get_attainment_formula(Φg)

38. 38
end
For each hard goal 'g' of the goal model
-> Depending on g's decomposition type, introduce one or more HTN methods.
More specifically:
If 'g' is AND-decomposed into goals g1,g2,... and tasks t1,t2,... then
introduce one method 'mg' with:
. tsk-mg=ag
. pre-mg=get_precondition_formula(g)
. dec-mg={ag1, ag2,...,ot1,ot2,..} //agx is for goal, otx is for task
else if 'g' is OR-decomposed into 'n' goals or tasks h1,h2,...,hn then
introduce 'n' methods 'mg
i' each corresponding to each child 'hi' and
with:
. tsk-mi
g=ag
. pre-mi
g=get_precondition_formula(g)
if 'hi' is a goal then
. dec-mi
g=ahi
else
. dec-mi
g=ohi
fi
fi
end
function get_attainment_formula(NodeList g) {
-> Replace each 'gi' with the conjunction or disjunction of gi's children.
-> If a child of the goal in consideration is a task then
use the task performance predicate 'vt' in replacement
fi
if 'g' contains goal
g=get_attainment_formula(g)
fi
return g
}
function get_precondition_formula(Node h) {
N = set of all goals and tasks 'he' for which he -npr-> h
P = set of all goals and tasks 'hp' for which hp -pre-> h
Φpre
h = ΛhpϵP Φhp ^ (ΛhpϵN NOT(Φhe))
for each 'hp'
if 'hp' is a goal then
Φhp = attainment formula
else if 'hp' is a task then
Φhp = task performance

39. 39
fi
end
for each 'he'
if 'he' is a goal then
Φhe = attainment formula
else if 'he' is a task then
Φhe = task performance
fi
end
}
// (3) The Planning Problem
/*
last step of translation is identification of the planning problem.
HTN planning problem consists of a set 'I' of domain predicates in V
that are true in the initial state, as well as a list 'G' of high-level
tasks that need to be satisfied.
*/
I={} //set empty initial conditions
// HTN goal is set to the root goal of the mandatory decomposition
G={agr} // where agr is the HTN task representing the root goal gr

40. 40
A.2 Y-ReasonScreenshots
The Web Services Description Language (WSDL) file:

41. 41
The Y-Planner desktop client:
Selecting XML file from Y-Reason:

42. 42
Getting back Y-Reason output (Reasoner output):

43. 43
B. Examples
B.1 SampleGoal Model
Sample goal model for a meeting organizer system. Reproduced from [2]

44. 44
B.2 SHOP2:sampleinputand output
Sample SHOP2 input:
(asdf:oos 'asdf:load-op :shop2)
(in-package :shop2-user)
(defdomain shopdomain (
(:operator (!SendEmail) () () ((SendEmail_done)) )
(:operator (!WaitForAWeek) () () ((WaitForAWeek_done)) )
(:operator (!FindSuitableRoom) ((FindSuitableSlot_done)) () ((FindSuitableRoom_done))
)
(:operator (!FindSuitableSlot)
((or(or(CallEverybody_done)(and(SendInvitation_done)(and(or(WaitOneDay_done)(WaitThree
Days_done)(WaitForAWeek_done))(ReceiveResponses_done))))(Automatically_done))) ()
((FindSuitableSlot_done)) )
(:operator (!ParticipantsAttendMeeting) () () ((ParticipantsAttendMeeting_done)) )
(:operator (!SendAttendanceReminder) ((SendEmail_done)) ()
((SendAttendanceReminder_done)) )
(:operator (!ReceiveResponses) () () ((ReceiveResponses_done)) )
(:operator (!Automatically) () () ((Automatically_done)) )
(:operator (!WaitOneDay) () () ((WaitOneDay_done)) )
(:operator (!CallEverybody) () () ((CallEverybody_done)) )
(:operator (!WaitThreeDays) () () ((WaitThreeDays_done)) )
(:operator (!SendInvitation) () () ((SendInvitation_done)) )
(:method (WaitForResponsesToArrive)
()
((!WaitForAWeek))
)
(:method (ResponseReceived)
((SendInvitation_done))
(:unordered (WaitForResponsesToArrive)(!ReceiveResponses))
)
(:method (BookMeeting)
()
(:unordered (!FindSuitableSlot)(!FindSuitableRoom))
)
(:method (HaveMeetingScheduled)
()
(:unordered
(ContraintsGathered)(BookMeeting)(MeetingAnnounced)(!ParticipantsAttendMeeting))
)
(:method (RequestConstraintsByEmail)
()

45. 45
(:unordered (ResponseReceived)(!SendInvitation))
)
(:method (ContraintsGathered)
()
((RequestBased))
)
(:method (WaitForResponsesToArrive)
()
((!WaitOneDay))
)
(:method (RequestBased)
()
((!CallEverybody))
)
(:method (ContraintsGathered)
()
((!Automatically))
)
(:method (MeetingAnnounced)
((FindSuitableRoom_done))
(:unordered (!SendEmail)(!SendAttendanceReminder))
)
(:method (WaitForResponsesToArrive)
()
((!WaitThreeDays))
)
)
)
(defproblem problem1 shopdomain
()
((HaveMeetingScheduled))
)
(find-plans 'problem1 :which :all :verbose :plans)
Sample SHOP2output:
This is SBCL 1.0.58, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the

46. 46
distribution for more information.
*
("ASDF")
*
("/home/mokhan/project/shop2/")
*
SHOP2 version 2.9.0
Copyright (C) 2002 University of Maryland.
Modifications by SIFT, LLC personnel Copyright (C) 2004-2008 SIFT, LLC.
This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
KIND, either express or implied. This software is distributed under an
MPL/GPL/LGPL triple license. For details, see the software source file.
#<ASDF:LOAD-OP NIL {B208289}>
((#<ASDF:LOAD-OP NIL {BB2D991}>
. #<ASDF:CL-SOURCE-FILE "shop2-unifier" "package-unifier">)
(#<ASDF:LOAD-OP NIL {BB2D991}>
. #<ASDF:CL-SOURCE-FILE "shop2-unifier" "tracer">)
(#<ASDF:LOAD-OP NIL {BB2D991}>
. #<ASDF:CL-SOURCE-FILE "shop2-unifier" "unify">)
(#<ASDF:LOAD-OP NIL {BB2D991}> . #<ASDF:SYSTEM "shop2-unifier">)
(#<ASDF:LOAD-OP NIL {BBED719}>
. #<ASDF:CL-SOURCE-FILE "shop2-common" "package-common">)
(#<ASDF:LOAD-OP NIL {BBED719}>
. #<ASDF:CL-SOURCE-FILE "shop2-common" "common">)
(#<ASDF:LOAD-OP NIL {BBED719}>
. #<ASDF:CL-SOURCE-FILE "shop2-common" "state-decls">)
(#<ASDF:LOAD-OP NIL {BBED719}>
. #<ASDF:CL-SOURCE-FILE "shop2-common" "state-utils">)
(#<ASDF:LOAD-OP NIL {BBED719}> . #<ASDF:SYSTEM "shop2-common">)
(#<ASDF:LOAD-OP NIL {BB287A9}>
. #<ASDF:CL-SOURCE-FILE "shop2-theorem-prover" "package-thpr">)
(#<ASDF:LOAD-OP NIL {BB287A9}>
. #<ASDF:CL-SOURCE-FILE "shop2-theorem-prover" "decls">)
(#<ASDF:LOAD-OP NIL {BB287A9}>
. #<ASDF:CL-SOURCE-FILE "shop2-theorem-prover" "theorem-prover">)
(#<ASDF:LOAD-OP NIL {BB287A9}> . #<ASDF:SYSTEM "shop2-theorem-prover">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "package">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "decls">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "io" "input">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "io" "output">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "io" "debugging">)
(#<ASDF:LOAD-OP NIL {B208289}> . #<ASDF:MODULE "shop2" "io">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "pddl" "pddl">)
(#<ASDF:LOAD-OP NIL {B208289}> . #<ASDF:MODULE "shop2" "pddl">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "search" "protections">)

47. 47
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "search" "task-reductions">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "search" "search">)
(#<ASDF:LOAD-OP NIL {B208289}> . #<ASDF:MODULE "shop2" "search">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "tree" "tree-accessors">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "tree" "tree-reductions">)
(#<ASDF:LOAD-OP NIL {B208289}> . #<ASDF:MODULE "shop2" "tree">)
(#<ASDF:LOAD-OP NIL {B208289}>
. #<SHOP2-ASD::CL-FILE-WITH-DEFCONSTANTS "shop2" "shop2">)
(#<ASDF:LOAD-OP NIL {B208289}> . #<ASDF:SYSTEM "shop2">))
*
Defining domain SHOPDOMAIN...
Defining problem PROBLEM1 ...
---------------------------------------------------------------------------
Problem PROBLEM1 with :WHICH = :ALL, :VERBOSE = :PLANS
Totals: Plans Mincost Maxcost Expansions Inferences CPU time Real time
12 6.0 6.0 98 109 0.104 0.105
Plans:
(((!CALLEVERYBODY) (!FINDSUITABLESLOT) (!PARTICIPANTSATTENDMEETING)
(!FINDSUITABLEROOM) (!SENDEMAIL) (!SENDATTENDANCEREMINDER))
((!CALLEVERYBODY) (!FINDSUITABLESLOT) (!FINDSUITABLEROOM) (!SENDEMAIL)
(!PARTICIPANTSATTENDMEETING) (!SENDATTENDANCEREMINDER))
((!CALLEVERYBODY) (!FINDSUITABLESLOT) (!FINDSUITABLEROOM) (!SENDEMAIL)
(!SENDATTENDANCEREMINDER) (!PARTICIPANTSATTENDMEETING))
((!CALLEVERYBODY) (!FINDSUITABLESLOT) (!FINDSUITABLEROOM)
(!PARTICIPANTSATTENDMEETING) (!SENDEMAIL) (!SENDATTENDANCEREMINDER))
((!CALLEVERYBODY) (!PARTICIPANTSATTENDMEETING) (!FINDSUITABLESLOT)
(!FINDSUITABLEROOM) (!SENDEMAIL) (!SENDATTENDANCEREMINDER))
((!AUTOMATICALLY) (!FINDSUITABLESLOT) (!PARTICIPANTSATTENDMEETING)
(!FINDSUITABLEROOM) (!SENDEMAIL) (!SENDATTENDANCEREMINDER))
((!AUTOMATICALLY) (!FINDSUITABLESLOT) (!FINDSUITABLEROOM) (!SENDEMAIL)
(!PARTICIPANTSATTENDMEETING) (!SENDATTENDANCEREMINDER))
((!AUTOMATICALLY) (!FINDSUITABLESLOT) (!FINDSUITABLEROOM) (!SENDEMAIL)
(!SENDATTENDANCEREMINDER) (!PARTICIPANTSATTENDMEETING))
((!AUTOMATICALLY) (!FINDSUITABLESLOT) (!FINDSUITABLEROOM)
(!PARTICIPANTSATTENDMEETING) (!SENDEMAIL) (!SENDATTENDANCEREMINDER))
((!AUTOMATICALLY) (!PARTICIPANTSATTENDMEETING) (!FINDSUITABLESLOT)
(!FINDSUITABLEROOM) (!SENDEMAIL) (!SENDATTENDANCEREMINDER))
((!PARTICIPANTSATTENDMEETING) (!CALLEVERYBODY) (!FINDSUITABLESLOT)
(!FINDSUITABLEROOM) (!SENDEMAIL) (!SENDATTENDANCEREMINDER))
((!PARTICIPANTSATTENDMEETING) (!AUTOMATICALLY) (!FINDSUITABLESLOT)
(!FINDSUITABLEROOM) (!SENDEMAIL) (!SENDATTENDANCEREMINDER)))
T
*