I maintain quite a bit of software. A month ago or so, Wil asked me to give an overview of the software for some exciting ((Not exciting.)) mid-term evaluation report. As such, I decided to make a simple architecture diagram, and even simplified it turned to not be so simple.
Today, I was to give a presentation at a staff meeting, so I decided to explain the architecture as the rest of the group may be able to use some of the code. I was asked to make a clickable version with links to relevant documentation, so here goes.
The software falls into 3 groups: CPN Tools stuff, Declare stuff, and ProM stuff. Let’s go thru them in that order. Afterwards I’ll explain how (some of) the tools can exchange data via files. Some of the components also exchange data via various network protocols, but let’s save those for another day ((Never.)).
CPN Tools
The CPN Tools suite consists of three tools: CPN Tools itself, Grade/CPN and Access/CPN.
CPN Tools is the tool everybody knows and loves. CPN Tools consists of a GUI written in Beta and a simulator written in SML. I’ve written a modified version of the ProM CPN library called XES/CPN, which serves the same purpose, except it generates a special kind of XES logs that can directly be imported in ProM 6.
As the simulator is a separate component (it is even a separate program ((There’s even more to the story, but let’s not worry about that here…)) ), it is possible to use it in other programs as well. To do that in a uniform way, I wrote the Access/CPN library. Access/CPN is implemented in Java and makes it easy to load, simulate, and save CPN models compatible with CPN Tools. Originally, the library was part of the BRITNeY Suite written by yours truly, it was later cleaned up and integrated into ASAP (which I was also responsible for), and finally got a life on its own as a separate library.
On top of Access/CPN I built Grade/CPN, which is a completely new tool for automatically grading CPN assignments.
Declare
Here, we consider the three tools of Declare as just one tool. Declare really comprises three tools, but for the sake of simplicity let’s consider them as one. Declare has a couple of components that are exported and usable without Declare, ltl2aut and the Module Library, and uses an external module, the Operational Support Client.
The ltl2aut library implements a translation from (finite trace) LTL to automata and contains a super-efficient automaton implementation with many useful operations. The library is not documented on its own but ships with a bunch of examples for illustration.
The Module Library implements modular Declare in a manner that allows foreign modules to be embedded as well. This also has no documentation available, but ships with test code as well. The library is currently only implemented in Declare (and a compatible version is implemented in iTasks), but one could easily envision compatible versions in, e.g., YAWL, CPN Tools, or even ProM itself.
Declare can use operational support as implemented in ProM (see below). It uses a pure-Java implementation of the client protocol.
ProM Plug-ins
Some of my ProM packages are related, some are not. I also add new ones all the time, so chances are this chart is outdated even before I write this sentence (it is).
Let’s start from the left. The Declare package embeds the ltl2aut library and (parts of) the Declare tool as a model package in ProM. This makes it possible to load and (crudely) draw Declare models in ProM. It is also possible to make rudimentary translations of Declare models to various representations of LTL formulae and automata (and on to transition systems).
The Declare package, like all other of my packages and many packages in general, depends on my Widgets package, which implements ProM versions of more widgets than are available in SlickerBox. The library has been extended since the documentation was written, and also contains comprehensive support for logging and other things. See the test plug-included in the package for a (near-complete) overview of widgets and how to use them. Most important is the ProMPropertyPanel, which makes it super-easy to get settings for ProM plug-ins. All my plug-ins use that.
The New Aligner is a completely new implementation of a rethinking of alignments. It is currently only available in my test-package, MichaelWestergaard. It is currently very experimental and is only in the figure (with a dashed outline) for completion’s sake. The arrow means that even though the package is not visibly above the ltl2aut library, it still builds upon it.
The KeyValue package makes it possible to represent, load, modify, and structure unstructured log data. It can be used directly, but also as framework for making log transformations or loading log data from other formats. It can also load CSV-data. The package is very interesting for developers and end-users alike. Read the documentation; that’s what it is there for!
Next up is the operational support universe. The main package reimplements operational support in ProM to fix various race conditions and to add support for sessions and looser coupling. The package contains a client library, which can be used from pure Java applications as well (e.g., Declare; see above). The package relies on 3rd (or 1st) party packages implementing actual operational support algorithms. One such is the XQuery Provider. When the documentation was written, it only supported simple queries, but it has subsequently been extended with real prediction and recommendation based on a log and even on a model in the form of a transition system or a Petri net (see more at my discussion about NAWL; NAWL should also be in the figure above somewhere).
Let’s do the operational support test suite from the bottom. First, the (or CPNet) package basically embeds the Access/CPN library as a model package in ProM. It is possible to load CPN models, either from a .cpn file or directly from CPN Tools. This is used by the Cosimulation package, which makes it possible to run ProM plug-ins together with CPN models. This includes using CPN models for implementation as part of Java code, using Java code as sub-pages in CPN models, and invoking Java code when certain transitions occur or certain places are marked. The package a.o. includes the super-cool ProM orchestration functionality. The cosimulation feature is used to implement interfaces between CPN models and operational support and Declare. The Declare Embedder builds upon the cosimulation functionality and the Declare package (indicated by the arrow) to make it possible to list, request, and complete work items from a running Declare Server. The OS Embedder makes it possible to query the operational support service in ProM from CPN models and also to make a CPN model to implement an operational support provider which can run entirely inside ProM and be available to all clients, e.g., the Declare Client.
Data
Finally, we are at the interchanges of data between my code. Most of the interesting stuff is getting data from CPN Tools into ProM, but there are a couple of ways to do that and a couple other interesting connections, so I made this figure showing the interactions possible:
We have 3 kinds of data. CPN model files (usually with the suffix .cpn) and two kinds of logs. Naturally, CPN Tools can read and write model files and can produce the two kinds of logs.
The CPN Tools Simulation Log is the native log file of CPN Tools. See more about how to generate such at look here. The KeyValue package can immediately read such files as KeyValue sets and they can then be translated to real logs. Often, it is a good idea to provide extra information when importing this way.
The XES/CPN logs are generated by my modified XES/CPN library. They are valid XES logs but contain only one case and each event has an explicit case id. If saved as a .cpnxes file, they can be loaded directly in ProM as a regular log, otherwise, you have to remove the log structure manually, translating it to a KeyValue set and then translate it back to a log.
Access/CPN can also both read and write CPN model files, and can generate standard CPN Tools simulation logs. As ProM/CPN builds on top of Access/CPN, it in principle inherits these features, but only loading of models is exposed.
Declare can generate .cpn model files for analysis. The functionality is not complete, but expected to be expanded. This makes it possible to speed up the testing done using the operational support test suite and also to use the power of CPN Tools (for nefarious and other purposes).
Ending Words
So, that’s the code I’m currently responsible for. For the data-freaks, I’ve added a table of lines of code. Weee. The data is old and outdated, and I’ve added a couple thousand lines and may not have included everything. For some components, I’ve mentioned the size of significant sub-components. I have not tallied my ProM packages individually. Interestingly, CPN Tools comprises roughly 230k lines of code, Access/CPN 170k lines of code, Grade/CPN 180k lines of code, and Declare 70k lines of code.
Lines of code
| Component | kLoC |
|---|---|
| CPN Tools GUI | 135 |
| > GUI framework | 55 |
| > glue to Simulate/CPN | 5 |
| Simulate/CPN | 95 |
| > old state-space tool | 15 |
| > new state-space tool | 20 |
| Access/CPN | 70 |
| Grade/CPN | 10 |
| ltl2aut | 15 |
| Declare | 50 |
| ProM/CPN | 3 |
| ProM/Declare | 2.5 |
| Other ProM plug-ins | ~20-25 |
| Total | ~400 |
I also have a couple ideas for plug-ins for ProM that would be neat, but for which I currently don’t have time (and probably never will). I typically add a blog post about such ideas; check this search to find them.
This morning, Wil was joking I couldn’t do a presentation or write anything without mentioning Britney, but just lookie–loo… Damn! Almost managed 😉
