Merge pull request #101 from szdan97/master

Grouping subprojects into directories

.github/workflows/docker-tools.yml

@@ -10,7 +10,7 @@ jobs:
     - name: Build CFA Docker image
       run: docker build -t theta-cfa-cli -f docker/theta-cfa-cli.Dockerfile .
     - name: Run CFA docker on example
-      run: ./docker/run-theta-cfa-cli.sh subprojects/cfa/src/test/resources/counter5_true.cfa
+      run: ./docker/run-theta-cfa-cli.sh subprojects/cfa/cfa/src/test/resources/counter5_true.cfa
 
   sts-cli-docker:
     runs-on: ubuntu-latest
@@ -19,7 +19,7 @@ jobs:
     - name: Build STS Docker image
       run: docker build -t theta-sts-cli -f docker/theta-sts-cli.Dockerfile .
     - name: Run STS docker on example
-      run: ./docker/run-theta-sts-cli.sh subprojects/sts/src/test/resources/simple1.system
+      run: ./docker/run-theta-sts-cli.sh subprojects/sts/sts/src/test/resources/simple1.system
 
   xsts-cli-docker:
     runs-on: ubuntu-latest
@@ -28,7 +28,7 @@ jobs:
     - name: Build XSTS Docker image
       run: docker build -t theta-xsts-cli -f docker/theta-xsts-cli.Dockerfile .
     - name: Run XSTS docker on example
-      run: ./docker/run-theta-xsts-cli.sh subprojects/xsts-analysis/src/test/resources/model/sequential.xsts --property "!(x==1)"
+      run: ./docker/run-theta-xsts-cli.sh subprojects/xsts/xsts-analysis/src/test/resources/model/sequential.xsts --property "!(x==1)"
 
   xta-cli-docker:
     runs-on: ubuntu-latest
@@ -37,4 +37,4 @@ jobs:
     - name: Build XTA Docker image
       run: docker build -t theta-xta-cli -f docker/theta-xta-cli.Dockerfile .
     - name: Run XTA docker on example
-      run: ./docker/run-theta-xta-cli.sh subprojects/xta/src/test/resources/csma-2.xta -c LU -s BFS
+      run: ./docker/run-theta-xta-cli.sh subprojects/xta/xta/src/test/resources/csma-2.xta -c LU -s BFS

README.md

@@ -19,13 +19,13 @@ Theta can both serve as a model checking backend, and also includes ready-to-use
 Tools are concrete instantiations of the framework to solve a certain problem using the built-in algorithms.
 Currently, the following tools are available (follow the links for more information).
 
-* [`theta-cfa-cli`](subprojects/cfa-cli): Reachability checking of error locations in Control Flow Automata (CFA) using CEGAR-based algorithms.
+* [`theta-cfa-cli`](subprojects/cfa/cfa-cli): Reachability checking of error locations in Control Flow Automata (CFA) using CEGAR-based algorithms.
   * [Gazer](https://github.com/ftsrg/gazer) is an [LLVM](https://llvm.org/)-based frontend to verify C programs using theta-cfa-cli, also giving support towards [SV-COMP](https://sv-comp.sosy-lab.org/2021/).
   * [PLCverif](https://cern.ch/plcverif) is a tool developed at CERN for the formal specification and verification of PLC (Programmable Logic Controller) programs, supporting theta-cfa-cli as one of its verification backends.
-* [`theta-sts-cli`](subprojects/sts-cli): Verification of safety properties in Symbolic Transition Systems (STS) using CEGAR-based algorithms.
+* [`theta-sts-cli`](subprojects/sts/sts-cli): Verification of safety properties in Symbolic Transition Systems (STS) using CEGAR-based algorithms.
   * theta-sts-cli natively supports the [AIGER format](http://fmv.jku.at/aiger/) of the [Hardware Model Checking Competition (HWMCC)](http://fmv.jku.at/hwmcc/).
-* [`theta-xta-cli`](subprojects/xta-cli): Verification of [Uppaal](http://www.uppaal.org/) timed automata (XTA).
-* [`theta-xsts-cli`](subprojects/xsts-cli): Verification of safety properties in eXtended Symbolic Transition Systems (XSTS) using CEGAR-based algorithms.
+* [`theta-xta-cli`](subprojects/xta/xta-cli): Verification of [Uppaal](http://www.uppaal.org/) timed automata (XTA).
+* [`theta-xsts-cli`](subprojects/xsts/xsts-cli): Verification of safety properties in eXtended Symbolic Transition Systems (XSTS) using CEGAR-based algorithms.
   * [Gamma](https://github.com/ftsrg/gamma) is a statechart composition framework, that supports theta-xsts-cli as a backend to verify collaborating state machines.
   * theta-xsts-cli natively supports Petri net models in the [PNML](http://www.pnml.org/) format (experimental).
 
@@ -36,17 +36,17 @@ Theta can be divided into the following four layers.
 * **Formalisms**: The core elements of Theta are the formalisms, which represent models of real life systems (e.g., software, hardware, protocols).
 Formalisms are usually low level, mathematical representations based on first order logic expressions and graph like structures.
 Formalisms can also support higher level languages that can be mapped to that particular formalism by a language front-end (consisting of a specific parser and possibly reductions for simplification of the model).
-The common features of the different formalisms reside in the [`core`](subprojects/core) project (e.g., expressions and statements) and each formalism has its own project.
-Currently, the following formalisms are supported: (extended) symbolic transition systems ([`sts`](subprojects/sts) / [`xsts`](subprojects/xsts)), control-flow automata ([`cfa`](subprojects/cfa)) and timed automata ([`xta`](subprojects/xta)).
+The common features of the different formalisms reside in the [`core`](subprojects/common/core) project (e.g., expressions and statements) and each formalism has its own project.
+Currently, the following formalisms are supported: (extended) symbolic transition systems ([`sts`](subprojects/sts/sts) / [`xsts`](subprojects/xsts/xsts)), control-flow automata ([`cfa`](subprojects/cfa/cfa)) and timed automata ([`xta`](subprojects/xta/xta)).
 * **Analysis back-end**: The analysis back-end provides the verification algorithms that can formally prove whether a model meets certain requirements.
 There is an interpreter for each formalism, providing a common interface towards the algorithms (e.g., calculating initial states and successors).
 This ensures that most components of the algorithms work for all formalisms (as long as they provide the interpreter).
 The verification algorithms are mostly based on abstraction.
 The analysis back-end defines various abstract domains (e.g., predicates, explicit values, zones), strategies for performing abstraction and refinement (e.g., interpolation), and algorithms built from these components.
-The common components reside in the [`analysis`](subprojects/analysis) project (e.g., CEGAR loop) and the formalism-specific modules (e.g., the interpreters) are implemented in separate analysis projects (with suffix `-analysis`) for each formalism.
+The common components reside in the [`analysis`](subprojects/common/analysis) project (e.g., CEGAR loop) and the formalism-specific modules (e.g., the interpreters) are implemented in separate analysis projects (with suffix `-analysis`) for each formalism.
 * **SMT solver interface and SMT solvers**: Many components of the algorithms rely on satisfiability modulo theories (SMT) solvers.
-The framework provides a general SMT solver interface in the project [`solver`](subprojects/solver) that supports incremental solving, unsat cores, and the generation of binary and sequence interpolants.
-Currently, the interface is implemented by the [Z3](https://github.com/Z3Prover/z3) SMT solver in the project [`solver-z3`](subprojects/solver-z3), but it can easily be extended with new solvers.
+The framework provides a general SMT solver interface in the project [`solver`](subprojects/common/solver) that supports incremental solving, unsat cores, and the generation of binary and sequence interpolants.
+Currently, the interface is implemented by the [Z3](https://github.com/Z3Prover/z3) SMT solver in the project [`solver-z3`](subprojects/common/solver-z3), but it can easily be extended with new solvers.
 * **Tools**: Tools are command line applications that can be compiled into a runnable jar file.
 Tools usually read some input and then instantiate and run the algorithms.
 Tools are implemented in separate projects, currently with the `-cli` suffix.
@@ -56,10 +56,10 @@ Each project contains a README.md in its root directory describing its purpose i
 
 |  | Common | CFA | STS | XTA | XSTS |
 |--|--|--|--|--|--|
-| **Tools** |  | [`cfa-cli`](subprojects/cfa-cli) | [`sts-cli`](subprojects/sts-cli) | [`xta-cli`](subprojects/xta-cli) | [`xsts-cli`](subprojects/xsts-cli) |
-| **Analyses** | [`analysis`](subprojects/analysis) | [`cfa-analysis`](subprojects/cfa-analysis) | [`sts-analysis`](subprojects/sts-analysis) | [`xta-analysis`](subprojects/xta-analysis) | [`xsts-analysis`](subprojects/xsts-analysis) |
-| **Formalisms** | [`core`](subprojects/core), [`common`](subprojects/common) | [`cfa`](subprojects/cfa) | [`sts`](subprojects/sts) | [`xta`](subprojects/xta) | [`xsts`](subprojects/xsts) |
-| **SMT solvers** | [`solver`](subprojects/solver), [`solver-z3`](subprojects/solver-z3) |
+| **Tools** |  | [`cfa-cli`](subprojects/cfa/cfa-cli) | [`sts-cli`](subprojects/sts/sts-cli) | [`xta-cli`](subprojects/xta/xta-cli) | [`xsts-cli`](subprojects/xsts/xsts-cli) |
+| **Analyses** | [`analysis`](subprojects/common/analysis) | [`cfa-analysis`](subprojects/cfa/cfa-analysis) | [`sts-analysis`](subprojects/sts/sts-analysis) | [`xta-analysis`](subprojects/xta/xta-analysis) | [`xsts-analysis`](subprojects/xsts/xsts-analysis) |
+| **Formalisms** | [`core`](subprojects/common/core), [`common`](subprojects/common/common) | [`cfa`](subprojects/cfa/cfa) | [`sts`](subprojects/sts/sts) | [`xta`](subprojects/xta/xta) | [`xsts`](subprojects/xsts/xsts) |
+| **SMT solvers** | [`solver`](subprojects/common/solver), [`solver-z3`](subprojects/common/solver-z3) |
 
 ## Extend Theta
 

build.gradle.kts

@@ -10,7 +10,7 @@ buildscript {
 
 allprojects {
     group = "hu.bme.mit.inf.theta"
-    version = "2.9.0"
+    version = "2.9.1"
 
     apply(from = rootDir.resolve("gradle/shared-with-buildSrc/mirrors.gradle.kts"))
 }

docker/theta-cfa-cli.Dockerfile

@@ -9,7 +9,7 @@ COPY . theta
 WORKDIR /theta
 RUN ./gradlew clean && \
     ./gradlew theta-cfa-cli:build && \
-    mv subprojects/cfa-cli/build/libs/theta-cfa-cli-*-all.jar /theta-cfa-cli.jar
+    mv subprojects/cfa/cfa-cli/build/libs/theta-cfa-cli-*-all.jar /theta-cfa-cli.jar
 WORKDIR /
 
 ENV LD_LIBRARY_PATH="$LD_LIBRARY_PATH:./theta/lib/"

docker/theta-sts-cli.Dockerfile

@@ -9,7 +9,7 @@ COPY . theta
 WORKDIR /theta
 RUN ./gradlew clean && \
     ./gradlew theta-sts-cli:build && \
-    mv subprojects/sts-cli/build/libs/theta-sts-cli-*-all.jar /theta-sts-cli.jar
+    mv subprojects/sts/sts-cli/build/libs/theta-sts-cli-*-all.jar /theta-sts-cli.jar
 WORKDIR /
 
 ENV LD_LIBRARY_PATH="$LD_LIBRARY_PATH:./theta/lib/"

docker/theta-xsts-cli.Dockerfile

@@ -9,7 +9,7 @@ COPY . theta
 WORKDIR /theta
 RUN ./gradlew clean && \
     ./gradlew theta-xsts-cli:build && \
-    mv subprojects/xsts-cli/build/libs/theta-xsts-cli-*-all.jar /theta-xsts-cli.jar
+    mv subprojects/xsts/xsts-cli/build/libs/theta-xsts-cli-*-all.jar /theta-xsts-cli.jar
 WORKDIR /
 
 ENV LD_LIBRARY_PATH="$LD_LIBRARY_PATH:./theta/lib/"

docker/theta-xta-cli.Dockerfile

@@ -9,7 +9,7 @@ COPY . theta
 WORKDIR /theta
 RUN ./gradlew clean && \
     ./gradlew theta-xta-cli:build && \
-    mv subprojects/xta-cli/build/libs/theta-xta-cli-*-all.jar /theta-xta-cli.jar
+    mv subprojects/xta/xta-cli/build/libs/theta-xta-cli-*-all.jar /theta-xta-cli.jar
 WORKDIR /
 
 ENV LD_LIBRARY_PATH="$LD_LIBRARY_PATH:./theta/lib/"

settings.gradle.kts

@@ -1,27 +1,32 @@
 rootProject.name = "theta"
 
 include(
-        "analysis",
-        "cfa",
-        "cfa-analysis",
-        "cfa-cli",
-        "common",
-        "core",
-        "solver",
-        "solver-z3",
-        "sts",
-        "sts-analysis",
-        "sts-cli",
-        "xta",
-        "xta-analysis",
-        "xta-cli",
-        "xsts",
-        "xsts-analysis",
-        "xsts-cli"
+        "common/analysis",
+        "common/common",
+        "common/core",
+        "common/solver",
+        "common/solver-z3",
+
+        "cfa/cfa",
+        "cfa/cfa-analysis",
+        "cfa/cfa-cli",
+
+        "sts/sts",
+        "sts/sts-analysis",
+        "sts/sts-cli",
+
+        "xta/xta",
+        "xta/xta-analysis",
+        "xta/xta-cli",
+
+        "xsts/xsts",
+        "xsts/xsts-analysis",
+        "xsts/xsts-cli"
 )
 
 for (project in rootProject.children) {
-    val projectName = project.name
-    project.projectDir = file("subprojects/$projectName")
+    val projectPath = project.name
+    val projectName = projectPath.split("/").last()
+    project.projectDir = file("subprojects/$projectPath")
     project.name = "${rootProject.name}-$projectName"
-}
+}

subprojects/cfa-analysis/README.md → subprojects/cfa/cfa-analysis/README.md

@@ -4,6 +4,6 @@ This project contains analysis modules related to the Control Flow Automata (CFA
 
 ### Related projects
 
-* [`analysis`](../analysis/README.md): Common analysis modules.
+* [`analysis`](../../common/analysis/README.md): Common analysis modules.
 * [`cfa`](../cfa/README.md): Classes to represent CFAs and a domain specific language (DSL) to parse CFAs from a textual representation.
 * [`cfa-cli`](../cfa-cli/README.md): An executable tool (command line) for running analyses on CFAs.

subprojects/cfa-cli/README.md → subprojects/cfa/cfa-cli/README.md

@@ -18,10 +18,10 @@ For more information about the CFA formalism and its supported language elements
 
 1. First, get the tool.
     * The easiest way is to download a [pre-built release](https://github.com/ftsrg/theta/releases).
-    * You can also [build](../../doc/Build.md) the tool yourself. The runnable jar file will appear under _build/libs/_ with the name _theta-cfa-cli-\<VERSION\>-all.jar_, you can simply rename it to _theta-cfa-cli.jar_.
+    * You can also [build](../../../doc/Build.md) the tool yourself. The runnable jar file will appear under _build/libs/_ with the name _theta-cfa-cli-\<VERSION\>-all.jar_, you can simply rename it to _theta-cfa-cli.jar_.
     * Alternatively, you can use our docker image (see below).
 2. Running the tool requires Java (JRE) 11.
-3. The tool also requires the [Z3 SMT solver libraries](../../doc/Build.md) to be available on `PATH`.
+3. The tool also requires the [Z3 SMT solver libraries](../../../doc/Build.md) to be available on `PATH`.
 4. The tool can be executed with `java -jar theta-cfa-cli.jar [ARGUMENTS]`.
     * If no arguments are given, a help screen is displayed about the arguments and their possible values.
     More information can also be found below.
@@ -52,12 +52,12 @@ All arguments are optional, except `--model`.
     * Possible values (from the least to the most detailed): `RESULT`, `MAINSTEP`, `SUBSTEP` (default), `INFO`, `DETAIL`, `VERBOSE`.
 * `--metrics`: Print metrics about the CFA without running the algorithm.
 * `--visualize`: Visualize the CFA without running the algorithm.
-If the extension of the output file is `pdf`, `png` or `svg` an automatic visualization is performed, for which [GraphViz](../../doc/Build.md) has to be available on `PATH`.
+If the extension of the output file is `pdf`, `png` or `svg` an automatic visualization is performed, for which [GraphViz](../../../doc/Build.md) has to be available on `PATH`.
 Otherwise, the output is simply in `dot` format.
-
-The arguments related to the algorithm are described in more detail (along with best practices) in [CEGAR-algorithms.md](../../doc/CEGAR-algorithms.md).
 * `--version`: Print version info (in this case `--model` is of course not required).
 
+The arguments related to the algorithm are described in more detail (along with best practices) in [CEGAR-algorithms.md](../../../doc/CEGAR-algorithms.md).
+
 ### For developer usage
 
 | Flag | Description |