Software Traceability for Multi-Agent Systems Implemented Using BDI Architecture (vol. 1) E-Book

Gilberto Cysneiros Filho

• Herausgeber: GRIN Verlag
• Sprache: Englisch

Veröffentlichungsjahr: 2014

Beschreibung

Doctoral Thesis / Dissertation from the year 2011 in the subject Computer Science - Software, City University London, course: Computer Science, language: English, abstract: The development of multi-agent software systems is considered a complex task due to (a) the large number and heterogeneity of documents generated during the development of these systems, (b) the lack of support for the whole development life-cycle by existing agent-oriented methodologies requiring the use of different methodologies, and (c) the possible incompleteness of the documents and models generated during the development of the systems. In order to alleviate the above problems, in this thesis, a traceability framework is described to support the development of multi-agent systems. The framework supports automatic generation of traceability relations and identification of missing elements (i.e., completeness checking) in the models created during the development life-cycle of multi-agent systems using the Belief-Desire-Intention (BDI) architecture. Traceability has been recognized as an important activity in the software development process. Traceability relations can guarantee and improve software quality and can help with several tasks such as the evolution of software systems, reuse of parts of the system, validation that a system meets its requirements, understanding of the rationale for certain design decisions, identification of common aspects of the system, and analysis of implications of changes in the system. The traceability framework presented in this thesis concentrates on multi-agent software systems developed using i* framework, Prometheus methodology, and JACK language. Here, a traceability reference model is presented for software artefacts generated when using i* framework, Prometheus methodology, and JACK language. Different types of relations between the artefacts are identified. The framework is based on a rule-based approach to support automatic identification of traceability relations and missing elements between the generated artefacts. Software models represented in XML were used to support the heterogeneity of models and tools used during the software development life-cycle. In the framework, the rules are specified in an extension of XQuery to support (i) representation of the consequence part of the rules, i.e. the actions to be taken when the conditions are satisfied, and (ii) extra functions to cover some of the traceability relations being proposed and completeness checking of the models. A prototype tool has been developed to illustrate and evaluate the work.

Leseprobe

Impressum:

Copyright (c) 2015 GRIN Verlag / Open Publishing GmbH, alle Inhalte urheberrechtlich geschützt. Kopieren und verbreiten nur mit Genehmigung des Verlags.

Bei GRIN macht sich Ihr Wissen bezahlt! Wir veröffentlichen kostenlos Ihre Haus-, Bachelor- und Masterarbeiten.

Jetzt beiwww.grin.com

Contents

Figures

Tables

Acknowledgements

Declaration

Abstract

Chapter 1 - Introduction

1.2 Hypotheses

1.3 Objectives

1.4 Contributions

1.5 Thesis Outline

Chapter 2 - Literature Survey on Traceability

2.1 Traceability Reference Models and Meta-Models

2.2 Traceability Approaches to Capture Trace Relations

2.2.1 Formal Approaches

2.2.2 Process Oriented Approaches

2.2.3 Information Retrieval Approaches

2.2.4 String Matching Approaches

2.2.5 Rule Based Approaches

2.2.6 Run-time approaches

2.2.7 Hypermedia and Information Integration approaches

2.3 Representation, Recording and Maintenance of Traceability Relations

2.4 Visualisation of Traceability Relations

2.5 Use of Traceability Relations

2.6 Traceability Approaches for Multi-Agent Systems

2.7 Performance Measures

2.8 Implication of tools that infer trace relations

2.9 Summary

Chapter 3 - Traceability Reference Model

3.1 Overview of the Reference Model

3.2 Multi-agent Oriented Artefacts

3.2.1 i* Framework

3.2.2 Prometheus

3.2.3 JACK

3.3 Traceability Relations

3.3.1 Traceability Relations between i* and Prometheus

3.2.2 Traceability Relations between Prometheus and JACK

3.4 Summary

Chapter 4 - Traceability Framework

4.1. Overview of the Framework

4.2 Traceability and Completeness Checking Rules

4.3 Extended Functions

4.3.1 Completeness checking functions

4.3.2 XQuery functions

4.3.3 XQueryJACKFunctions

4.3.4 XQueryPDTFunctions

4.3.5 XQuerySimilarityFunctions

4.3.6 XQuerySynonymsFunctions

4.3.7 XQueryTAOMFunctions

4.4 Retratos Tool

4.5 Discussion

4.6 Summary

Chapter 5 - Evaluation and Results

5.1 Criteria for Evaluation

5.2 Automatic Teller Machine

5.2.1 Overview of the Case Study

5.2.2 Artefacts

5.2.3 Evaluation

5.3 Air Traffic Control Environment

5.3.1 Overview of the Case Study

5.3.2 Artefacts

5.3.3 Evaluation

5.4 Electronic Bookstore

5.4.1 Overview of the Case Study

5.4.2 Artefacts

5.4.3 Evaluation

5.5 Discussion

5.6 Threats of Validity

5.7 Summary

Chapter 6 - Conclusion and Future Works

6.1 Overall Conclusions

6.2 Hypotheses

6.3 Objectives

6.4 Contributions

6.5 Future Work

6.5 Final Remarks

Bibliography

Figures

Figure 3.1 SD model

Figure 3.2 Strategic Dependency Diagram for the Electronic Bookstore

Figure 3.3 Strategic Rationale Diagram for the Electronic Bookstore actor

Figure 3.4 Prometheus methodology phases

Figure 3.5 Goal diagram for the Electronic Bookstore

Figure 3.6 Role Diagram for the Electronic Bookstore

Figure 3.7 Order Book Scenario

Figure 3.8 System Overview Diagram

Figure 3.9 Find BestSellers Capability

Figure 3.10 Security Manager Agent Overview Diagram

Figure 3.11 Airport Agent in JACK

Figure 3.12 BankAgent agent in JACK

Figure 3.13 ArrivalSequencing Capability

Figure 3.14 WithdrawRequest event

Figure 3.15 WithdrawCash plan

Figure 3.16 Accounts beliefSet

Figure 3.17 Prometheus Goal vs. SD Goal overlaps traceability relation

Figure 3.18 Prometheus Data vs. SR Resource overlaps traceability relation

Figure 3.19 Prometheus Data vs. SD Goal contributes traceability relation

Figure 3.20 Prometheus Data vs. SD Task contributes traceability relation

Figure 3.21 Prometheus Plan vs. SD Resource uses traceability relation

Figure 3.22 Prometheus Plan vs. SR Resource uses traceability relation

Figure 3.23 Prometheus Plan vs. SR Resource creates traceability relation

Figure 3.24 Prometheus Scenario vs. SR Resource creates traceability relation

Figure 3.25 Prometheus Agent vs. SD Goal achieves traceability relation

Figure 3.26 Prometheus Plan vs. SR Task achieves traceability relation

Figure 3.27 Prometheus Goal vs. Actor depends on traceability relation

Figure 3.28 Prometheus Scenario vs. SR Goal compose traceability relation

Figure 3.29 Prometheus Scenario vs. SR Task composed traceability relation

Figure 3.30 JACK BeliefSet vs. Prometheus Data overlaps traceability relation

Figure 3.31 JACK Agent vs. Prometheus Agent overlaps traceability relation

Figure 3.32 JACK Agent vs. Prometheus Plan uses traceability relation

Figure 3.33 JACK Plan vs. Prometheus Data uses traceability relation

Figure 3.34 JACK Plan vs. Prometheus Data creates traceability relation

Figure 3.35 JACK BeliefSet vs. Prometheus Plan creates traceability relation

Figure 3.36 JACK Agent vs. Prometheus Goal achieves traceability relation

Figure 3.37 JACK Plan vs. Prometheus Goal achieves traceability relation

Figure 3.38 JACK Agent vs. Prometheus Message sends traceability relation

Figure 3.39 JACK Plan vs. Prometheus Message sends traceability relation

Figure 3.40 JACK Plan vs. Prometheus Message receives traceability relation

Figure 3.41 JACK Plan vs. Prometheus Message sends traceability relation

Figure 4.1: Overview of traceability framework

Figure 4.2 Example of the use of rule in our approach

Figure 4.3 Rule Template

Figure 4.4 Rule4

Figure 4.5 Rule4 Header

Figure 4.6 Namespace declarations

Figure 4.7 Variable declarations

Figure 4.8 Condition part

Figure 4.9 Traceability Relation Creation

Figure 4.10 Traceability Relation between Arrange delivery and Organize delivery

Figure 4.11 Generation of Missing Element

Figure 4.12 Log Outgoing Delivery Missing Element

Figure 4.13 Rule49

Figure 4.14 Iteration part of the Rule15

Figure 4.15 Airport agent in Prometheus and Airport actor in i*

Figure 4.16 Traceability relation between Airport agent and Airport actor

Figure 4.17 Rule4cc

Figure 4.18 Iteration part of the Rule4cc

Figure 4.19 Airport SR model and ATCE Prometheus Goal

Figure 4.20 Request Runway goal missing in Prometheus

Figure 4.21 Calling getPDTFileName extended function in Java

Figure 4.22 List of strings

Figure 4.23 Arrival Sequencing Capability and ATL SD Resource

Figure 4.24 capabilityUsesSDResource function example

Figure 4.25 getBeliefSetFields function example

Figure 4.26 getIncludesFields function example

Figure 4.27 isSimilar function example

Figure 4.29 contains function example

Figure 4.28 isSynonyms function example

Figure 4.30 getSubGoalsAndTask function example

Figure 4.31 Retratos main menu

Figure 4.32 Creating a New Project

Figure 4.33 New Project window

Figure 4.34 Creating traceability relations and identifying missing elements

Figure 4.35 output.xml file

Figure 4.36 – HTML Generator sub-menu item

Figure 4.37 Simple HTML Report

Figure 4.38 HTML Template

Figure 4.39 – retratos.css file

Figure 4.40 HTML Report using HTML template and retratos.css file

Figure 4.41 HTMLGeneratorWith Types menu item

Figure 4.42 HTML Report with Types

Figure 4.43 HTML Report with types using HTML template and retratos.css file

Figure 4.44 IstarPrometheusRule menu item

Figure 4.45 IstarPrometheus rule editor

Figure 4.46 PrometheusJACKRule menu item

Figure 4.47 PrometheusJACK rule editor

Figure 4.48 Show Rules menu item

Figure 4.49 Rule Viewer

Figure 5.1 Fields of the Accounts beliefSetAccounts Descriptor

Figure 5.2 Accounts Descriptor

Figure 5.3 Balances beliefSet

Figure 5.4 Balances descriptor

Figure 5.5 ProcessWithdraw plan

Figure 5.6 Process Withdraw descriptor

Figure 5.7 WithdrawApproved plan

Figure 5.8 Withdraw Approved descriptor

Figure 5.9 WithdrawCash plan

Figure 5.10 Withdraw Cash descriptor

Figure 5.11 WithdrawRejected plan

Figure 5.12 Withdraw Rejected descriptor

Tables

Table 3.1 Relations between Prometheus and i* SD

Table 3.2 Relations between Prometheus and i*SR elements

Table 3.3 Traceability Relations Types between Prometheus and JACK Artefacts

Table 3.4 Traceability Relations Types between Prometheus and JACK Artefacts

Table 5.1 ATM elements in Prometheus

Table 5.2 ATM elements in JACK

Table 5.3 Results of experiments for the ATM case study

Table 5.4 Missing Information

Table 5.5 Results of the experiments for the new models of the ATM case study

Table 5.6 ATCE elements in Prometheus

Table 5.7 ATCE elements in i*

Table 5.8 ATCE elements in JACK

Table 5.9 Results of the experiments between Prometheus model and JACK code

Table 5.10 Results of the experiments between i* model and Prometheus model

Table 5.11 Missing relations between JACK code and Prometheus model

Table 5.12 Results of the experiments for the new models of the ATCE case study

Table 5.13 Missing relations between i* and Prometheus model

Table 5.14 Results of the experiments for the new models of the ATCE case study

Table 5.15 EB elements in i*

Table 5.16 EB elements in Prometheus

Table 5.17 EB elements in Prometheus

Table 5.18 Evaluation Results

Table 5.19 Evaluation Results

Table 6.1 – Results of the experiments

Table 6.2 Results of the experiments

Table 6.3 – Results of LEDA case study using threshold

Table 6.4 Results of the experiments

Table 6.5 Number of traceability relations identified for the ATM case study

Table 6.6 Number of traceability relations identified for ATCE case study

Table 6.7 Number of traceability relations identified for the ATCE case study

Acknowledgements

I would like to thank the examiners Peter Sawyer and Bill Karakostas for having so kindly accepted to take part of my viva voice examination and for the comments and suggestions. The quality of thesis would have suffered without their contribution.

Andre Zisman has been principal motivator actor of my work giving helpful feedback during the period of her supervision. It was also great value have written papers with her and with my co-supervisor George Spanoudakis.

Thank you to all colleagues from Department of Computing who I have had the good fortune to share a room with or work together with as visiting tutor. Especially, I would like to thank Michael Iossif, Mark Firman, Shant Narcessian, Waraporn Jirapathong, Khaled Mahub, Marcus Andrews, Olga Castilho, Thsiamo, Theoharris, Ricardo Contreras, and George Lekeas.

I would also like to thank the support and administrative team for all their help during all this period.

Thank you especially to my friends from London for the support and attention that made life easier and happier.

My greatest gratitude goes to my family that had suffered from my absence and for the support that they always gave in my life.

Declaration

I grant powers of discretion to the University Librarian to allow the thesis to be copied in whole or in part without further reference to the author. This permission covers only single copies made for study purposes, subject to normal conditions of acknowledgment.

Abstract

The development of multi-agent software systems is considered a complex task due to (a) the large number and heterogeneity of documents generated during the development of these systems, (b) the lack of support for the whole development life-cycle by existing agent-oriented methodologies requiring the use of different methodologies, and (c) the possible incompleteness of the documents and models generated during the development of the systems.

In order to alleviate the above problems, in this thesis, a traceability framework is described to support the development of multi-agent systems. The framework supports automatic generation of traceability relations and identification of missing elements (i.e., completeness checking) in the models created during the development life-cycle of multi-agent systems using the Belief-Desire-Intention (BDI) architecture.

Traceability has been recognized as an important activity in the software development process. Traceability relations can guarantee and improve software quality and can help with several tasks such as the evolution of software systems, reuse of parts of the system, validation that a system meets its requirements, understanding of the rationale for certain design decisions, identification of common aspects of the system, and analysis of implications of changes in the system.

The traceability framework presented in this thesis concentrates on multi-agent software systems developed using i* framework, Prometheus methodology, and JACK language. Here, a traceability reference model is presented for software artefacts generated when using i* framework, Prometheus methodology, and JACK language. Different types of relations between the artefacts are identified. The framework is based on a rule-based approach to support automatic identification of traceability relations and missing elements between the generated artefacts. Software models represented in XML were used to support the heterogeneity of models and tools used during the software development life-cycle. In the framework, the rules are specified in an extension of XQuery to support (i) representation of the consequence part of the rules, i.e. the actions to be taken when the conditions are satisfied, and (ii) extra functions to cover some of the traceability relations being proposed and completeness checking of the models.

A prototype tool has been developed to illustrate and evaluate the work. The work has been evaluated in terms of recall and precision measurements in three different case studies. One small case study of an Automatic Teller Machine application, one medium case study of an Air Traffic Control Environment application, and one large case study of an Electronic Bookstore application.

Chapter 1 - Introduction

A multi-agent system consists of a system composed of several agents that are situated in an environment and that interact with each other and with their environment. Multi-agent systems have been proposed as a solution to implement complex systems that need to run in an environment that is open, distributed and highly interactive. An agent is defined by Wooldridge in (Wooldridge, et al., 1995), (Wooldridge, 2002) as a software component that is “situated in some environment and that is capable of autonomous action in this environment in order to meet its design objectives”. Several types of software components fulfil this definition varying from daemons process in UNIX (Frisch, 2002) to complex decision making systems that control unmanned autonomous vehicles (Agent Oriented Software Limited, 2010).

An intelligent agent is an autonomous software component that is categorised to be pro-active, reactive, and social (Wooldridge, 2002). Pro-activeness means that the agent takes initiative in order to achieve its goals. Reactivity means that the agent perceives its environment and responds to its stimulus according to its goals. Social ability means that the agent will be able to communicate with other agents and have abilities such as co-operation, co-ordination, and negotiation.

Several architectures have been proposed to build multi-agent systems such as Jadex (Pokahr, et al., 2005), Jason (Bordini, et al., 2005), and JACK (Busetta, et al., 1999), (Howden, et al., 2001). Agent architectures can be classified in three categories: deliberative architectures, reactive architectures, hybrid architectures.

Reactive architectures do not maintain a symbolic representation of the environment and actions are performed using rules. Agents are situated in the environment and perceive the environment. Depending on the event that occurs in the environment a rule is executed and actions are performed.

In the deliberative architecture, a symbolic representation of the environment is created and the agent performs actions to manipulate these symbols. The actions performed are based on logical reasoning using theorem provers (Genesereth, et al., 1987). The drawback of this architecture is that it is difficult to represent the real world using a symbolic representation. Moreover, the use of logic reasoning to determine what action to perform is a very resource and time consuming task. Several multi-agent systems use a deliberative architecture to support reasoning and some of them are based on the BDI (Belief Desire Intention) architecture (Bratman, et al., 1988). Hybrid architectures combine deliberative and reactive behaviour. Examples of hybrid architectures are: TouringMachines, and INTERRRAP (Luck, et al., 2004).

BDI architectures have been proposed to address the problem of resource boundedness. The BDI architecture (Rao, et al., 1992) is one of the most successful architectures. The BDI architecture is founded on the philosophy theory of Bratman (Bratman, 1999) to explain human rationale action and it has been formalised by logic theory called LORA (Wooldridge, 2000) and BDI logic (Rao, et al., 1998). The BDI architecture has been implemented several times. Examples of implementation are: IRMA (Bratman, et al., 1988), PRS (Ingrand, et al., 1992), Jadex (Pokahr, et al., 2005), Jason (Bordini, et al., 2005) and JACK (Howden, et al., 2001), (Agent Oriented Software Limited, 2010).

Bratman et al. describe the Intelligent Resource-Bounded Machine Architecture (IRMA) that is the first implementation of BDI architecture (Luck, et al., 2004). The IRMA architecture addresses the problem of how an agent can select the best set of actions to carry out in order to achieve a goal when limited by resources such as the amount of time to take the decision.

The Procedural Reasoning System (PRS) is one of the most successful implementation of BDI architecture. The PRS architecture was used to build several applications such as a prototype system to manage the air traffic control of Sydney airport (Ljungberg, et al., 1992), (Rao, et al., 1995). The PRS system has been re-implemented and extended several times. The most known implementations are dMARS (d'Inverno, et al., 2004), JAM (Huber, 1999), JACK (Howden, et al., 2001), (Agent Oriented Software Limited, 2010), and Jadex (Pokahr, et al., 2005).

To support the development of multi-agent systems various methodologies have been proposed such as Prometheus (Padgham, et al., 2004), Tropos (Castro, et al., 2002), MaSE (DeLoach, 2001), and Gaia (Wooldridge, et al., 2000). These methodologies can be classified based on their origins. For instance, Tropos is based on requirements oriented methodologies and has its origins on i* framework. Prometheus is based on object-oriented methodologies and its design phase is influenced by JACK. Luck et al. (Luck, et al., 2004) and Sudeikat et al. (Sudeikat, et al., 2004) classify agent oriented methodologies origins as object-oriented, knowledge engineering oriented, requirement engineering oriented, and of general category.

Despite advances in the area, the development of multi-agent systems is a complex task. As outlined in (Luck, et al., 2004), the difficulty to develop multi-agent systems are due to the (a) design of software systems that maintain a balance between proactive and reactive behaviour present in agents, (b) understanding of when agent approaches are appropriate, and (c) use of informal development techniques. In addition, (i) the large number and heterogeneity of documents generated during the development of multi-agent systems, (ii) the lack of support for the whole development life-cycle by existing agent-oriented methodologies requiring the use of different methodologies, and (iii) the possible incompleteness of the documents and models generated during the development of multi-agent systems contribute to the difficulties of developing such systems.

Moreover, the development of multi-agent systems produces a huge number of artefacts. Each artefact created can be related to several other artefacts. The relations between artefacts can be explicit or implicit. Explicit relations are concerned with the direct relation between two artefacts. For instance, artefact B depends on artefact A. Therefore, there is an explicit relation between the artefacts A and B. Implicit relations are concerned with indirect relations between two artefacts. For instance, artefact B depends on artefact A and artefact C depends on artefact B. Therefore there is an implicit relation between artefacts A and C.

Explicit relations are easier to maintain while implicit relations are difficult to maintain and to be found. Furthermore, multi-agents systems are normally developed by teams of analysts, developers, and programmers that are often distributed in different locations and use different tools, notations, and methodologies. The heterogeneity of people, tools, notations, and methodologies makes difficult to identify and understand the relations between the artefacts. In addition, it is not possible to guarantee completeness of the generated artefacts.

The need to understand the relations between the artefacts created during the development of software system is essential to several activities of software development such as impact analysis, software maintenance and evolution, component reuse, verification and validation. It is difficult or even impossible to indentify manually these relations in complex systems (e.g. multi-agent systems).

The difficult to indentify traceability relations in multi-agent systems are due to (a) the large number and heterogeneity of documents generated during the development of these systems, (b) the lack of support for the whole development life-cycle by existing agent-oriented methodologies requiring the use of different methodologies, and (c) the possible incompleteness of the documents and models generated during the development of the systems.

We recognize that the above problems can occur in other types of complex systems, but in this thesis we focus on multi-agent systems developed using BDI architecture. In particular, the main differences are the types of the elements and documents that are used when developing a multi-agent system. The development of multi-agent systems involves a new set of elements such as goals, percepts, beliefs, capabilities, agents, roles, actions, events, messages, and plans. To utilize and understand the traceability relations, it is necessary to define the semantics of the relations between these elements. To address this problem we define a traceability reference model to represent the semantic of traceability relations. The semantic of traceability relation gives the ability to carry out richer kind of analysis (e.g. impact analysis).

Another difference is that in some of methodologies such as Troops and Prometheus the definition of requirements is based on goal oriented techniques instead of textual descriptions that allow the development of multi-agent using a model driven development since the requirement definition phase.

Multi-agent systems are distributed and concurrent, and the agents that make up a multi-agent system are able to exhibit complex flexible behaviour in order to achieve its objectives in the face of a dynamic and uncertain environment. This flexible behaviour is key in making agent technology useful, but it makes it difficult to trace agent systems. Tracing is an essential part of the process of developing software, and important to support verification, validation and debugging.

In order to alleviate the above problems, in this thesis we propose the use of software traceability and identification of missing elements between artefacts produced during the whole life cycle of a multi-agent system.

Software traceability has been defined as “the ability to describe and follow the life of a requirement, in both a forward and backward direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases)” (Gotel, et al., 1994). Traceability relations can help to assist with several activities during the life cycle of software development such as impact analysis, verification and validation, reuse, and maintenance.

The identification of traceability relations manually is a labour intensive and an error prone task (Spanoudakis, et al., 2005). Several approaches have been proposed to recover traceability relations automatically. The approaches can be classified as (i) formal approaches (Pinheiro, et al., 1996), (ii) process oriented approaches (Castro-Herrera, et al., 2007), (Ravichandar, et al., 2007), (Pohl, 1996), (iii) information retrieval approaches (Zou, et al., 2007), (Poshyvanyk, et al., 2007), (Duan, et al., 2007), (Kritzinger, et al., 2008), (Antoniol, et al., 2002), (Marcus, et al., 2003), (Zou, et al., 2006), (De Lucia, et al., 2007), (De Lucia, et al., 2008), (Lormans, et al., 2006), (Hayes, et al., 2007), (iv) string matching approaches (Fiutem, et al., 1998), (Antoniol, et al., 2001), v) rule base approaches (Spanoudakis, et al., 2004), (Jirapanthong, et al., 2005), (Jirapanthong, et al., 2009), (Cysneiros, et al., 2003), (Cysneiros, et al., 2007a), (Cysneiros, et al., 2007b), (Cysneiros, et al., 2008) (Spanoudakis, et al., 2003), (Spanoudakis, et al., 2004), (Dagenais, et al., 2007), (Reiss, 2006), (Fletcher, et al., 2007), (Rilling, et al., 2007), (Kagdi, et al., 2007), (Alves-Foss, et al., 2002), (vi) run-time approaches (Liu, et al., 2007), (Egyed, 2003), (Egyed, et al., 2005), (Grechanik, et al., 2007), and (vii) hypermedia and information integration approaches (Sherba, et al., 2003), (Sherba, 2005).

The approaches above address different aspects of the traceability problem. For instance, i) formal approaches can be used when it is possible to define the software project using a formal language and then traceability relations are derived automatically using axioms; ii) process oriented approaches can be used when a unified software process development is used to develop software; iii) information retrieval techniques have been used successful to identify traceability relations between textual documentation of software artefacts; iv) string matching approaches can be used when naming of elements are used consistently to define elements of a software project; v) rule-based approaches can be used when it is easy to identify and define rules between relations of elements created during the development of a software; vi) run-time approaches can be used when code of the system is available.

In this thesis a rule-based framework is described to support automatic generation of traceability relations and identification of missing elements in artefacts created during the development of multi-agent systems. The identification of missing elements is called completeness checking in this thesis report. This work provides support for artefacts created during different phases of the software development life-cycle. More specifically, the approach supports artefacts created during early and late requirements elicitation, analysis and design, and implementation phases of the development of multi-agent systems.

The framework concentrates on early requirements represented using i* framework (Yu, 1995), late requirements, analysis and design specification created using the Prometheus methodology (Padgham, et al., 2004), and code implemented with JACK (Agent Oriented Software Limited, 2010).

Prometheus methodology was chosen because it has been largely used in academic and industrial settings; it covers the whole life cycle of development; and there are a large number of documentation, examples, and tools support available. Moreover, the detailed design phase of Prometheus covers the concepts necessary to model multi-agent systems implemented using the BDI architecture.

The reason for using i* framework to represent the early phase of the requirement specification is due to the fact that Prometheus methodology only supports a specification of goals of the system in terms of a hierarchical diagram. The i* framework provides a richer modelling technique to represent organizational process. The i* framework represents relations between actors that depend of each other to have its goals accomplished. The rationale behind the dependencies can also be represented in i*.

The adoption of JACK is due to its use in several academic and commercial applications and in diverse areas such as unmanned aerial vehicles, surveillance, air traffic management, real-time scheduling, and virtual actors (Agent Oriented Software Limited, 2010). Moreover, a large number of documentation is available and the detailed phase of Prometheus describes the elements of the JACK.

In order to support the heterogeneity of models and tools covered in this work, the models are represented in XML (XML, 2010). XML was chosen as the basis of our approach due to several reasons: (a) XML has become the de facto language to support data interchange among heterogeneous tools and applications, (b) the existence of large number of applications that use XML to represent information internally or as a standard export format, and (c) to allow the use of XQuery (XQuery, 2010) as a standard way of expressing traceability rules.

We propose to use an extended version of XQuery to represent the rules in our framework. XQuery is an XML-based query language that has been widely used for manipulating, retrieving, and interpreting information from XML documents. Apart from the embedded functions offered by XQuery, it is possible to add new functions. We have extended XQuery (a) to support representation of the consequence part of the rules, i.e. the actions to be taken when the conditions are satisfied, and (b) to support extra functions to cover (i) some of the traceability relations being proposed and (ii) completeness checking of the models.

A prototype tool has been implemented to demonstrate and evaluate the work. The evaluation of the work has been performed in three case studies, namely: (i) automatic teller machine, (ii) electronic bookstore, and (iii) air traffic control environment. The automatic teller machine is a small size application that allows a customer to withdraw cash and print statements. The air traffic environment is a medium size application that simulates the landing sequencing of an aircraft. The electronic bookstore application is a large size application that implements the main functionalities of an electronic bookstore such as browsing catalogue, search books by keyword and buy a book.

The remainder of this chapter describes the hypotheses, problem definition, objectives, contributions, and thesis outline.

1.2 Hypotheses

The hypothesis of our framework consists on the identification of traceability relations between software artefacts created during the development of multi-agent systems using a model driven approach. This hypothesis is broken into the following:

 It is possible to use rules to identify traceability relations between software artefacts created during the development of multi-agent systems using a model driven approach;

 It is possible to use rules to identify missing elements between software artefacts created during the development of multi-agent systems using a model driven approach;

 It is possible to use the information about missing elements to fix discrepancies between names given to elements in the different documentation and to improve completeness between software artefacts created during the development of multi-agent systems using a model driven approach;

 It is possible to use the information about missing elements to improve the number of traceability relations identified by our framework.

To evaluate this hypothesis, a prototype tool was built and assessed in three case studies. In chapter 5 these experiments are described and the results of the evaluation presented.

1.3 Objectives

The overall aim of this research is to develop an approach to support traceability between artefacts created during the entire life cycle of the development of a multi-agent system. In particular, the main interest was in supporting the identification of missing elements and automatic generation of traceability relations between software elements in i* organisational models (Yu, 1995), Prometheus models (Padgham, et al., 2004), and JACK code (Agent Oriented Software Limited, 2010).

The main aim was broken down into the following objectives:

 To define different types of traceability relations;

 To create a reference model that defines traceability relations between artefacts in i* and Prometheus and between artefacts in Prometheus and JACK code;

 To create a set of rules to identify missing elements and traceability relations between i* and Prometheus artefacts;

 To create a set of rules to identify missing elements and traceability relations between Prometheus and JACK code elements;

 To develop a prototype tool to identify missing elements and to automatically generate traceability relations between i* and Prometheus models and between Prometheus models and JACK code;

 To evaluate the work in several case studies.

1.4 Contributions

This research contributes to the Agent Oriented Software Engineering area and addresses the problems discussed in Section 1.1. The main contributions can be summarised as:

 Automatically recovery of traceability relations - A rule-based approach was proposed to support automatic generation of traceability relations between heterogeneous software models created during the development of multi-agent systems. This alleviates the problems of creating traceability relations manually;

 Support for completeness checking - A rule-based approach was proposed to support the identification of missing elements in various software models. This facilitates fixing inconsistencies among the models;