Merge of simulator and main (#17)

* Fix so new connections are added as backend connections after they are 'ready' New connections are added to the backend connections here: https://github.com/Ecdar/Ecdar-GUI/blob/9ca653b7817706f132d88c8a773a0487e99c6038/src/main/java/ecdar/backend/BackendDriver.java#L153 But that is before the `updateComponents` query has completed, so a query can take the backend before it is ready. This results in a bunch of non-deterministic errors when executing queries, one being the `UNAVAILABLE: io exception` error. The backend should only be added on the `onCompleted` as is already done: https://github.com/Ecdar/Ecdar-GUI/blob/9ca653b7817706f132d88c8a773a0487e99c6038/src/main/java/ecdar/backend/BackendDriver.java#L171 After this small fix you can spam queries to your heart's content with no issues :) * Fix to prevent no default backend existing (Ecdar#130) * `README.md` Update (Ecdar#128) * WIP: ECDAR reference added, dependency section updated, and spelling fixed * WIP: Backend replaced with Engine to be consistent with naming * WIP: Engine Configuration enriched * Contributing section added and code snippets updated to be executable on Linux * Files reverted to main version * Added files removed (added through Ecdar#131) * WIP: Code Organization section added * Utility and Miscellaneous sub sections added to Code Organisation * Walkthrough changes * Component Refactor (Ecdar#126) * WIP: ComponentController/Presentation REFACTORED * Location placement logic extracted to separate class * Cleanup and minor refactoring * WIP: GlobalDeclarations refactored * Reachability analysis exception FIXED * WIP: Removed most of the static dependencies in component * LocationPlacer test failing * WIP: Component refactor (other elements have been refactored as a side-effect) * WIP: Verification aspects moved out of component into new class in mutation package * WIP: Location placement from dropdown FIXED * WIP: Refactoring and testing of ComponentVerificationTransformer started * WIP: LocationPlacer generalized and tested, and unnecessary initial and final location checks removed * WIP: LocationPlacer renamed to UnoccupiedSpaceFinder and offset add as parameter * Personal walkthrough changes * Universal and inconsistent location naming approach refactored * Color refactoring and initial location color fix * Walkthrough changes * Dangling engines FIX (Ecdar#140) * WIP: Potential fix for dangling engines by keeping track of started connections in one place and removing this responsibility from the QueryHandler * Method rename to better follow new logic * Add started backend connections immediately and use them to find used ports --------- Co-authored-by: Sebastian Lund <[email protected]> * Removed the contains deadlock option from the context menu in ComponentController (Ecdar#139) * Query types updated to follow theory (Ecdar#143) * Query types updated to follow theory * Updated bisim_minim name * Fix typo --------- Co-authored-by: Sebastian Lund <[email protected]> * Declaration alignment FIX (Ecdar#137) * Declaration resizing and alignment fixed for both single and split canvas (and minor refactoring) * Zoom keyboard shortcuts on split canvas FIXED * NullPointerException when opening existing project FIXED * WIP: Exceptions are thrown on project open and split canvas * WIP: Exceptions FIXED (Refactoring might be needed before merge) * Review suggestions * Dangling engines FIX (Ecdar#140) * WIP: Potential fix for dangling engines by keeping track of started connections in one place and removing this responsibility from the QueryHandler * Method rename to better follow new logic * Add started backend connections immediately and use them to find used ports --------- Co-authored-by: Sebastian Lund <[email protected]> * Declaration resizing and alignment fixed for both single and split canvas (and minor refactoring) * Zoom keyboard shortcuts on split canvas FIXED * NullPointerException when opening existing project FIXED * WIP: Exceptions are thrown on project open and split canvas * WIP: Exceptions FIXED (Refactoring might be needed before merge) * Review suggestions --------- Co-authored-by: Sebastian Lund <[email protected]> * Backend to engine (Ecdar#136) * WIP: ECDAR reference added, dependency section updated, and spelling fixed * WIP: Backend replaced with Engine to be consistent with naming * WIP: Engine Configuration enriched * Contributing section added and code snippets updated to be executable on Linux * Rename branched out from readme_update * File used on other branch * WIP: ECDAR reference added, dependency section updated, and spelling fixed * WIP: Backend replaced with Engine to be consistent with naming * Contributing section added and code snippets updated to be executable on Linux * File used on other branch * WIP: Backend replaced with Engine to be consistent with naming * WIP: Engine Configuration enriched * File used on other branch * Line about the deprecated mutation package added * Update src/main/java/ecdar/abstractions/Query.java Co-authored-by: Andreas K. Brandhøj <[email protected]> * WIP: Review changes (part 1/2) * Update src/main/java/ecdar/backend/BackendHelper.java Co-authored-by: Andreas K. Brandhøj <[email protected]> * WIP: Review changes (part 2/2) * startedEngineConnections filtering added to only account for ports of the related engine and comment updated * Found some more strings and vars to update * Review suggestions implemented --------- Co-authored-by: Andreas K. Brandhøj <[email protected]> * Backend refactor (Ecdar#147) * WIP: ECDAR reference added, dependency section updated, and spelling fixed * WIP: Backend replaced with Engine to be consistent with naming * WIP: Engine Configuration enriched * Contributing section added and code snippets updated to be executable on Linux * Rename branched out from readme_update * File used on other branch * WIP: ECDAR reference added, dependency section updated, and spelling fixed * WIP: Backend replaced with Engine to be consistent with naming * Contributing section added and code snippets updated to be executable on Linux * File used on other branch * WIP: Backend replaced with Engine to be consistent with naming * WIP: Engine Configuration enriched * File used on other branch * Line about the deprecated mutation package added * Update src/main/java/ecdar/abstractions/Query.java Co-authored-by: Andreas K. Brandhøj <[email protected]> * WIP: Review changes (part 1/2) * Update src/main/java/ecdar/backend/BackendHelper.java Co-authored-by: Andreas K. Brandhøj <[email protected]> * WIP: refactoring started * WIP: Review changes (part 2/2) * BackendDriver refactored to be more readable (method division) * More refactoring * WIP: Backend replaced with Engine to be consistent with naming * File used on other branch * WIP: Backend replaced with Engine to be consistent with naming * File used on other branch * BackendDriver refactored to be more readable (method division) * More refactoring * Ensure successful rebase and merge (#16) * Backend to engine (Ecdar#136) * WIP: ECDAR reference added, dependency section updated, and spelling fixed * WIP: Backend replaced with Engine to be consistent with naming * WIP: Engine Configuration enriched * Contributing section added and code snippets updated to be executable on Linux * Rename branched out from readme_update * File used on other branch * WIP: ECDAR reference added, dependency section updated, and spelling fixed * WIP: Backend replaced with Engine to be consistent with naming * Contributing section added and code snippets updated to be executable on Linux * File used on other branch * WIP: Backend replaced with Engine to be consistent with naming * WIP: Engine Configuration enriched * File used on other branch * Line about the deprecated mutation package added * Update src/main/java/ecdar/abstractions/Query.java Co-authored-by: Andreas K. Brandhøj <[email protected]> * WIP: Review changes (part 1/2) * Update src/main/java/ecdar/backend/BackendHelper.java Co-authored-by: Andreas K. Brandhøj <[email protected]> * WIP: Review changes (part 2/2) * startedEngineConnections filtering added to only account for ports of the related engine and comment updated * Found some more strings and vars to update * Review suggestions implemented --------- Co-authored-by: Andreas K. Brandhøj <[email protected]> * WIP: Backend replaced with Engine to be consistent with naming * File used on other branch * WIP: Backend replaced with Engine to be consistent with naming * File used on other branch * BackendDriver refactored to be more readable (method division) * More refactoring --------- Co-authored-by: Andreas K. Brandhøj <[email protected]> * Minor naming and comment errors fixed * WIP: Exception handling added (not done) to engine handling * WIP: Comment removed * Engine process and connection exception handling finished * Final backend refactor * Review renaming implemented * Get IP added to Engine for better interface * EngineConnection initialization moved to separate class * ToDo's removed and added as issues on the repo * ToDo's removed and added as issues on the repo v2 * Shutdown of the application updated for better handling --------- Co-authored-by: Andreas K. Brandhøj <[email protected]> * Community Standards (Ecdar#151) * Contributing file, issue templates added, and mistakenly removed image reintroduced * feature label replaced with enhancement * PR template added and CONTRIBUTING.md moved to hidden github directory * PR template reformattet * CODE_OF_CONDUCT.md added * PR template rewording * Bug report template updated and link to Contributing added to readme * Updated JDK example * WIP: Ongoing merge effort (not compiling) * WIP: Compiles (simulator not working) * WIP: Sketchy engine communication for simulation functionality to ensure compatibility (WORKING) * Red color on locations updated --------- Co-authored-by: Sebastian Lund <[email protected]> Co-authored-by: Morten Hartvigsen <[email protected]> Co-authored-by: Andreas K. Brandhøj <[email protected]>
Nielswps · Apr 15, 2023 · 8cb5296 · 8cb5296
1 parent 42329b7
commit 8cb5296
Show file tree

Hide file tree

Showing 154 changed files with 5,353 additions and 5,155 deletions.
diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md
@@ -0,0 +1,128 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+[email protected].
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct
+enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.
diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
@@ -0,0 +1,96 @@
+# Contributing
+When contributing to this repository, make your own fork and create pull requests to this repo from there.
+
+## Issues
+If you find a bug or a missing feature, feel free to create an issue. The system is continuously under development and suggestions are always welcome.
+
+### Bugs
+To increase the chances of the issue being resolved, please include the following (or use the `Bug Report` issue template):
+- Concise title that states the issue
+- An in-depth description of the issue
+  - What happened
+  - What was expected to happen
+  - Suggestion on possible cause [Not required]
+- Images (if relevant)
+
+### Feature
+To increase the chances of the issue being resolved, please include the following (or use the `Feature Request` issue template):
+- Concise title that describes the feature
+- An in-depth description of the feature
+  - What is the feature
+  - Use case
+  - How should it work for the user
+  - Suggestions for implementation [Not required]
+- Reasoning behind the request
+  - Added value
+  - Improved user experience
+
+> :information_source: To help organising the issue, please attach relevant tags (eg. `bug`, `feature`, etc.).
+
+## Pull Requests
+Pull requests are continuously being reviewed and merged. In order to ease this process, please open a pull request as draft, as long as it is under development, to notify anyone else that a given feature/issue is being worked on.
+
+Additionally, please add `Closes #{ISSUE_ID}` if the pull request is linked to a specific issue. If a PR addresses multiple pull requests, please add `Closes #{ISSUE_ID}` for each one.
+
+A CI workflow is executed against all pull requests and must succeed before the pull request can be merged, so please make sure that you check the workflow status and potential error messages.
+
+## Tests
+All non-UI tests are executed as part of the CI workflow and hence must succeed before merging. The tests are written with JUnit and relevant tests should be added when new code is added. If you are new to JUnit, you can check out syntax and structure [here](https://junit.org/junit5/docs/current/user-guide/).
+
+The test suite can be executed locally by running:
+```shell
+./gradlew test
+```
+
+> :information_source: Currently, the codebase has high coupling, which has made testing difficult and the test suite very small.
+
+### UI Tests
+For features that are highly coupled with the interface, a second test suite has been added under `src/test/java/ecdar/ui`. These tests are excluded from the `test` task are can be executed by running:
+```shell
+./gradlew uiTest
+```
+These tests are more intensive to run and utilizes a robot for interacting with a running process of the GUI. The tests are implemented using [TestFX](https://github.com/TestFX/TestFX). As these tests are more intensive, they are not run as part of the standard CI workflow.
+
+You should prefer writing non-UI tests, as they are less demanding and are part of the CI workflow.
+
+## Code Organisation
+The code within the project is structure based on the Model-View-ViewModel (**MVVM**) architectural pattern. However, the terms _Abstraction_, _Presentation_, and _Controller_ are used instead of _Model_, _View_, and _View-Model_ respectively.
+This means that each element in the system consists of:
+- An _Abstraction_ (located in `abstractions` package).
+- A _Controller_ (located in `controllers` package).
+- A _Presentation_ (located in `presentations` package).
+    - Most of the presentations are related to an `FXML` markup file that specifies the look of the presentation. These files are located in `src/main/resources/ecdar/presentations`.
+
+In addition to these, a `utility` package is used for additional business logic to improve separation of concern and enhance the testability of the system.
+
+### Abstractions
+The abstractions are used to represent logical elements, such as `components`, `locations`, and `edges`. These classes should mostly be pure data objects. They are used to save and load data to and from existing project files.
+
+### Controllers
+The controllers contain the business logic of the system. They function as the link between the UI and the abstractions.
+This is implemented such that an action performed to an element in the UI triggers a method inside the controller, which then alters the state of the related abstraction.
+
+They implement the `Initializable` interface and are initialized through their associated presentation when an instance of that is instantiated. Hierarchically, a presentation therefore contains a controller.
+
+Each controller controls an instance of its related abstraction. If an action to one element should affect another element, this effect is enforced through the controller.
+
+### Presentations
+As mentioned above, most of the presentations are split into a Java class and an FXML markup file. The Java class can be seen as a shell to initialize the FXML element from inside the business logic. It initializes the related controller and ensures that any needed elements are set within it. This allows the controllers to be initialized without any UI elements, which is very useful for testing, while ensuring that they are correctly connected while the UI is running.
+
+The FXML files are markup specifying how the elements should look in the UI and have a reference to the related controller. Each element that should be addressable or changeable from the controller has an `fx:id` that is directly referenced as a member inside the controller. The direct connection to a controller allows events, such as `onPressed`, to trigger the correct methods in the controller and also helps IDEs identified any potentially missing methods or members.
+
+> :question: **Why use both a controller and a presentation Java file?**\
+> The advantage of during this is that the `controller` can contain all the business logic and bindings to the FXML elements, while the `presentation` can be used to instantiate and reference the UI elements inside the Java code. The `controller` should contain the logic and is bound within the FXML file, so the `presentation` Java file should be seen as a shell.
+
+### Utility
+To increase the testability and separation of concern further, the `utility` package is introduced. This package includes useful functionality that is either used in multiple unrelated classes or outside the responsibility of the given class.
+
+An example of one of the classes located in this package is the `UndoRedoStack` used to keep track of actions performed by the user.
+
+### Miscellaneous
+Besides the packages mentioned above, some larger functionalities are located in their own packages. Here is a small description of each:
+- `backend`: Responsible for the communication with the engines and model checking.
+- `code_analysis`: Responsible for analysing the elements of the current project and construct messages if errors or warnings are encountered.
+- `issues`: Classes for representing `Errors`, `Issues`, and `Warnings`.
+- `model_canvas.arrow_heads`: Arrowheads used in the UI to visualize the direction of edges.
+- `mutation [Deprecrated]`: Functionality for supporting mutation testing of components. **This feature is currently not implemented in the engines and is therefore currently not supported**.
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -0,0 +1,44 @@
+---
+name: Bug
+about: File a bug report
+title: '[BUG] <title>'
+labels: bug
+assignees: ''
+---
+
+<!--
+Note: Please search to see if an issue already exists for the bug you encountered.
+-->
+
+### Description
+<!--
+Should include:
+1. What happened
+2. What was expected to happen
+3. Suggestion on possible cause [Not required]
+-->
+#### Where was the error encountered
+- [ ] Using a distribution from the main ECDAR repository
+
+
+- [ ] Using a local JDK 
+  - **Used JDK** (ex. Zulu 11.62.17 JDK FX 11.0.18):
+  - **Operating System**:
+    - [ ] Linux
+    - [ ] MacOS Arm
+    - [ ] MacOS Intel
+    - [ ] Windows
+
+### Steps To Reproduce
+<!--
+Example: steps to reproduce the behavior:
+1. In this environment...
+2. With this config...
+3. Run '...'
+4. See error...
+-->
+
+### Images
+<!--
+Links? References? Anything that will give us more context about the issue that you are encountering!
+-->
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -0,0 +1,25 @@
+---
+name: Feature
+about: Suggest a new feature
+title: '[Feature] <title>'
+labels: enhancement
+assignees: ''
+---
+
+<!--
+Note: Please search to see if an issue already exists for the feature you request.
+-->
+
+### Description
+<!--
+Should include:
+1. What is the feature
+2. Use case
+2. How should it work for the user
+3. Suggestions for implementation [Not required]
+-->
+
+### Reason For Request
+<!--
+Explanation for the request and how it will improve the system/user experience
+-->
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
@@ -0,0 +1,4 @@
+Closes #{ISSUE_ID}
+
+### Changes/Additions:
+-