Modern, collaborative software development projects are highly supported by a variety of tools. Aside from the pure code development that is nowadays well supported by integrated development environments (IDEs) such as Eclipse, also other activities receive increasing attention in the matter of tool support. Recent improvements in tool support for source code management (SCM), process management and documentation management are driven by the changing demands of increasing distribution and agility of development projects. Moreover, the integration of tool support systems into integrated project management environments (IPMEs) increase the usefulness of each emerging tool support, especially for agile approaches. The Petri net-based agent-oriented software engineering (Paose) is highly influenced by agile methods and combines the agile concepts with aspects from model driven development. We have achieved increased efficiency by the adoption of IPMEs into the Paose development approach. However, the introduced tool set integration lacks in support for the model driven part of Paose, i.e. the tool integration for graphical (model-based) source code i s missing. In this work we present an approach for an appropriate tool support of agile methods and model driven development. As a prototypical implementation of the concepts we present a Web service-based fra mework and plugin-based extension for Redmine as representative o f open source IPMEs, which is currently in use in the context of the Paose approach.
development, today’s modern development requires more flexible ap proaches to manage the given circumstances. In fact, project managers have to deal with distributed teams and software systems, concurrently working developers and fast and sporadic changes of demands.
Therefore we need even more adequate tools in order to keep the development process under control and to handle the different requirements in a satisfyingly and efficient manner. In the usual software development process, there are a lot of well-established tools in use, such as integrated development env ironments (IDEs) to support technical aspects of programming and project management tools, assisting developers and mainly superintendents in organizational matters. The centralized or distributed storage of source code is also well supported by various source code management (SCM) tools such as Subversion1 or Git2.
In contrast to the classical software development, the agent-o riented software
development faces developers and project managers with some new aspects of
tasks and therefore with some new fields to support, possibly even with an
extended tool chain. One main reason for this is the self-organized an d autonomous
character of agents, which we also adopted into the organization of the
development team [
With this work we present an approach to improve the developers tool chain in context of the Petri net-based agent-oriented software dev elopment. For that reason, we advance the development process through adjusted and new tools, which fill the gap of partially unsupported tasks. Additionally, our focus lies on the adequate integration of these tools in our existent tool chain to advance the integrated project management environment (IPME). In Section 2 we investigate the developers’ tasks, especially in context of the agent-or iented and agile procedure of development. Furthermore, we point out the deficits of the existent tool chain and additionally work out some possible supporting measures. We decided to primarily improve the topic of source code management within the Petri net-based development through an extended tool set . Section 3 describes these tools with regard to the architecture, realization and integration. We also present our prototypical implementation, which allows to include visual representations of any diagram type / net, available in the Renew tool set (see http://www.renew.de), in an IPME. This includes the simple displaying of diagrams / nets as well as the presentation of visual differences between versions available in the SCM. 1 Apache Subversion, Enterprise-class centralized version control for the masses (http://subversion.apache.org) 2 Git, distributed version control system (http://git-scm. com)
In the final conclusion we summarize our results of investigation and discuss the achieved benefits through our enhancement in the development tool chain. 2
The process of software development consists of many different activities and
phases we traverse during the specification, implementation, verification and
deployment of software artifacts [
While communication is a prerequisite for the proper planning and
coordination inside the development team3, this activity gets more relevant within
distributed teams and concurrently working developers. The terms self-organization
and responsibility are outstanding in agent-oriented development [
Furthermore, the source code management plays a significant role sharing
resources within the development team. Regarding textually represented source
code, a wide variety of tools exists to support the developer [
Documentation is another task a developer is faced with. In agile approaches
this task is less expensive, because running software has a higher value as
comprehensive documentation if we follow the agile manifest [
Finally, developers make use of a lot of tools. We aim at the integration of all used tools in the existent and usual tool chain and further connect these tools together. This means that developers are able to link the various contents and results of the tools’ usages. More precisely, we target the link ing of source code with task definitions, documentation and discussed topics relevant to the concrete realization. Additionally, the exchange of information between the tools should be realized as an automatic process embedded into the usual workflow. The result of this is an integrated project management environment, being able to handle many tasks belonging to different phases and areas of the complete development process and finally to make this information available through a single interface. 4 Note that in Paose the agent-oriented paradigm is also applied to the developm ent team and to the development process.
The free available open source project management tools Redmine5 and Trac6 support many of these needs out of the box and also provide a notification system via e-mail transparently embedded in the usual workflow. One missin g feature, the possibility to view and compare graphical source code in a visual manner inside the IPME, is realized through our extension of the tool chain and will be presented in the following section. 3
In the previous section, we pointed out the requirement of a tool to visualize and compare graphical source code, particularly in context of Petri net-based development. This section deals with the architecture, implementation and integration of the outlined draft for such a tool, that fits perfectly into the distributed nature of agent-oriented software development, our existing tool chain and development workflow. 3.1
Due to the plugin-based design of the most project management to ols, in our case Redmine, it is possible to improve the functionality of the IPME with respect to the integration of Petri nets and also other models such as sequence diagrams, class diagrams, etc. For this purpose, we provide an extension, which enables the IPME to (1) render net files in a graphical manner instead of showing the corresponding text representation and (2) compare two revisions of the same net file by highlighting their differences. The implementation of this extension is divided into two functional components. The first is designed as a Web service, which offers the capability to compute images of submitted nets that depict the requested functionality of the extension (detailed description in Section 3.3). The second component is located in the IPME as a plugin called Redmine Renew Plugin and integrates the functionality offered by the Web service into the webbased user interface (as described in Section 3.5). This is realized by extending the existing code view mechanisms so that net files supported by Renew (*.rnw, *.aip, *.draw, *.pnml, etc.) will be forwarded and handled by the corresponding Web service.
Each component of the tool chain can be assembled and hosted in a completely distributed environment, as depicted in Figure 2, or centralized on one host. The IPME is hosted on a web server that offers developers, managers and designers an easy access using a simple Web browser. Source code repositories are located on file servers and will be integrated into the environment with the help of the build-in source code management (SCM) connectors. Th e major workload of the net integration is done by the export server, which hosts the two Web services (Image Net Export and Image Net Diff). 5 Redmine, A flexible project management web application (http://www.redmine.org) 6 Trac, Integrated SCM & Project Management (http://trac.edgewall.org) Conversion of diagram / net representation into image representations is provided by two plugins available for Renew. The Export plugin is part of the distribution of Renew and makes use of the powerful Freehep libraries (see http://www.freehep.org/). It was first included in version 2.1 of Renew. The Export agent makes use of the PNG (Portable Network Graphics) export format, which is displayed directly in a Web browser.
The ImageNetDiff plugin for Renew is available as on optional plugin and
allows producing a visual diff of two diagrams or nets. As the name suggests, the
visual diff is represented as an image (compare with [
Both services (Image Net Export Service and Image Net Diff Service) used in
the Redmine Renew Plugin are realized as RESTful Web services [
To fulfill the desired behavior of the export agent services (Image Net Export Service and Image Net Diff Service), the implementation makes use of the Renew Export and ImageNetDiff plugins (mentioned in Section 3.2), which are available due to the fact that the Mulan multi-agent framework uses Renew as a runtime engine. 3.4
The current prototype of the Redmine Renew Plugin implements two different features, export and diff, which both work with source code files from the connected repository, as described in Section 3.1.
The visualization of a single net file is a relatively simple task and thus fairly simple to implement. The plugin has to fetch the net file from the repository and post the content of this file to the Web service to get a visual representation 7 FIPA ACL: http://fipa.org/specs/fipa00061/SC00061G.html 8 Jetty Web server: http://www.eclipse.org/jetty/ 9 W3C WebSocket API: http://dev.w3.org/html5/websockets/ 10 Java Server Page (JSP): http://www.oracle.com/technetwork/java/javaee/jsp/ WS Client
HTTP/WebSocket
Inform/Request
Response
Register
Response Inform/Request
WebGateway Web Service Registry
Agent Service Web Service
FIPA-ACL Inform/Request
Response Register
Agent
Response
Inform/Request of the net as result. This result, the received PNG image, will be shown to the user, embedded inside the repository view of Redmine (compare with Figure 4, in which a diff image is shown, which is explained in Section 3.5). The comparison of two revisions of the same net file from the repository does not make a big effort, too. In this case, the plugin has to fetch the two different revisions of the net file and post its contents to the Web service to receive the image with the highlighted differences.
However, the case of comparing two complete changesets11 is a complex task with regard to the technical aspect. This is firstly, because a changeset might contain graphical and textual source code changes, therefore the plugin has to decide for every file separately, if it will use the image net diff algorithm or the build-in textual one 12. Secondly, the type of change can be one of the following for every single file in the changeset: addition, modification, deletion, duplication, moving or renaming. As a consequence, there are a lot of possible cases to take into account e.g. if we add a net file in one changeset, remove this file in the next one and after that we add a file with the same name but different contents again. Then, the complete history of changes made to this file name has to receive attention in order to decide which revisions should be compared. Another complex sequence of operations arises, when a file becomes renamed or moved. In this case the plugin has to fetch the previously named file and the current one in order to compare the changes, what results in a supplementary request to the repository. 11 A changeset contains all changes, which were made in an atomic commit and contains multiple files in the majority of cases. 12 The repository itself (i.e. Subversion) does not make any difference between file types and returns a single unified diff file for all changes made in a changeset. Therefore the Redmine Renew Plugin has to split this unified diff into separate parts, whereby every part contains the changes made to a single file.
In the Paose approach we use project management tools that are already wellestablished in agile development approaches. By their usage, we directly apply the advantages of these tools to the agent-oriented developmen t and benefit from the tight linking of source code with developer tasks and documentation, as requested within Section 2. Beyond that, we extend these tools with plugins according to the needs of the Petri net-based agent-oriented sof tware development, which result from the model-driven nature of the Petri net-based development, as described in Section 3.1.
Figure 4 shows a screenshot of the web-based IPME Redmine. The im age
shows the repository view extended by the Redmine Renew Plugin in diff mode.
Inside the content area in the center, it shows the differences of two revisions
(i.e. revisions 9296 and 9538) of a Petri net from the connected Subversion
repository. The colored areas describe changed parts of the Petri net, whereby
green13 signifies added parts and red deleted parts, while the light-gray are as
signify unchanged parts. The plugin integrates into the IMPE in a transparent
way, without the need of changing anything in the general workflow.
Additionally, the presentation of both, textual and graphical source code, is embedded
into our IMPE homogeneously. The just described screenshot shows only one
possible use of the plugin. There is also the ability to compare other graphical
resources, such as use case diagrams or agent interaction protocols, which both
were introduced to the Paose approach [
A demonstration of the new tool integrated into the IMPE Redmine is accessible under https://paose.informatik.uni-hamburg.de/redmine/ . The connected Subversion repository contains some examples, which were developed in the context of the P*AOSE student project at the University of Hamburg. The presented IPME allows public users to access the source code, to visualize and to compare different versions.14
In Section 2 we described the developer tasks and discussed the need for tool support for the comparison of graphical source code (i.e. in our case Petri nets) and other diagrams in a visual way. The possibilities offered by our presented extensions especially support the developers in communication aspects and the exchange of information. Furthermore, reviewing and refactoring of code, for instance in order to discover and eliminate some bugs, are simplified, because the simple access to a visualization of the graphical source code is integrated into the applied IPME. Besides that, project leaders and other participants can inform themselves straightforwardly about the progress of development without the need of an IDE and thus also derive benefits from the integrated tool set.
A typical use case for the net diff inside the IPME is a session of finding the differences during a debugging session. However, one very useful simple use case is examining, whether changes were made in a model. For instance marginal changes in the layout (e.g. changing the z-order of elements) can r esult in repository check-ins. Also if changes from for example version A to versio n B are reverted in version C the control of absence of differences between version A and C and the easy access to this information is of great advantage. 4
In this work we investigated the development process in Petri net- based agentoriented software development concerning the improvements of tool support. After outlining developer tasks and gaps in tool support, we introduced an extension to the tool set to accommodate the source code management of graphically represented source code, embedded into the widely used open source project management tool Redmine. 13 A black and white print shows only light-gray parts and black net elements and inscriptions. With the exception of the comments (in square brackets) only additions have been made in the presented diff. 14 Additionally the Web service-based functionality of diagr am export and diagram image diff can be accessed manually via an included Web interface.
With the introduction of our extended tool chain in the context of the P*AOSE projects at the University of Hamburg, which follow the Paose approach, we improved various aspects of the developers’ tasks. F irst of all, of course we supported the possibility to observe graphical source code and compare it concerning its different versions. Supplementary, we improved the speed of development through this feature, in respect of the possibility to visually compare model-based source code (i.e. in our case Petri nets) and oth er diagrams directly and effortlessly in an integrated environment for the project management and planning (IPME), which is closely linked to the SCM. Furthermore the presented tool integration supports the communication of the developers. Information exchange through source code changes between the developers gets easier than before and performs thereby the requirements delineated in Section 2. Finally, we come to the conclusion that our presented extended tool chain is one substantial step to improve the development of Petri net-based agent-oriented software. The gap between text-based and model-based source code – as well as other design models – is thus further closed in regard to the handling of these documents during development, reviewing, documentation and refactoring. The presented approach could easily be adapted to support other development approaches that make use of graphical representations (e.g. UML diagrams) during development.