DECIDE is a program that simulates a hypothetical anti-ballistic missle system. The program is designed to generate a boolean signal which determines wheter an interceptor should be launched to intercept incoming missle. Depending on the input of this program and which combinations of the Launch Interceptor Conditions (LIC's) are relevant to the immediate situation, the progrma will output a boolean signal to determine if an interceptor should be launched.
This project requires:
- Maven (see Installing Apache Maven or use your package manager).
- Java 17 or later (refer to your package manager).
- JUnit 5 (included in the Maven dependencies).
- Git (refer to your package manager).
Clone the repository locally using git clone.
You can then use Maven to compile, test and package the project. The Maven project is located in the decide subfolder, so navigate to that folder before running any Maven commands (cd decide).
To compile the project, run:
mvn compileTo run the tests, run:
mvn testTo package the project, run:
mvn packagemvn package will compile and run the tests before packaging the project.
Once compiled, there will be a .jar file in the target folder. You can run the program using:
java -jar target/decide-1.0-SNAPSHOT.jarEach person has contributed to the project by creating issues, particpating in assigning issues among the group, writing code and creating pull requests, and reviewing other group members' pull requests. Reviews have been divided among the group members in a way that everyone has reviewed a fair share of the PRs and in a way that all group members have a solid knowledge of the codebase.
- #28: fix: update .gitignore for Maven as well
- #40: feat: add method for LIC 1 along with tests
- #41: ci: add initial GitHub actions config for maven
- #50: style: add vscode settings that force auto format
- #56: feat: implement LIC 4 and corresponding tests
- #63: feat: implement LIC 8 and tests for it
- #65: refactor: restructure project to adhere to naming conventions better
- #67: docs: update README, initial structure
- #68: refactor: reorder the LIC methods in LaunchInterceptor class
- #69: test: remove unnecessary System.out.println statements
- #71: fix: add maven-jar-plugin to our pom.xml to make jar exec
- #84: docs: add javadoc comments to all methods
- #93: docs: update statement of contributions in README
- #48: feat: implement LIC5 along with their tests
- #53: feat: implement lic11
- #55: bug: Added plugin to pom file
- #78: feat: Added function for FUV and tests
- #85: feat: Add decide function, corresponding tests and main entry point
- #88: docs: removed redundant comment in testFUV_true()
- #18: feat: Create files
- #25: Feat: Update gitignore
- #32: feat: implement lic2 and some tests for it
- #42: feat: implement lic6
- #49: feat: Implement lic12
- #52: feat: Implement lic14
- #58: fix: Fix the lic-methods that handles "intervening points" incorrectly
- #59: feat: Implement lic13
- #66: feat: add and fix comments for tests
- #73: fix: fix how lic7 handles intervening points
- #74: feat: add test case for lic7
- #79: feat: add exceptions for all lic-methods
- #82: feat: add a test for lic5
- #94: docs: remove duplicate comment and add missing javadoc comments
- #20: fix: Change test file name
- #24: feat: Add global variables
- #26: feat: Add LIC0 method and added maven project for tests.
- #29: feat: Add lic3() method
- #30: feat: Add method lic7()
- #39: feat: Add lic9()
- #60: feat: Add lic10()
- #81: fix: Implement CMV & PUM tests
- #92: fix: Implement all CMV tests
Our way of working, according to the Essence standard, is in the "in place" state. The tools we use are Java, Maven, Git and GitHub issues. The practices we use are for example the standardized way of writing commit messages (see this), and the use of pull requests for code reviews. All team members use these practices and tools and have access to them to perform their work. New changes to the way we work have been discussed and agreed upon by the team, meaning that the whole team is involved in the adaption and inspection of our way-of-working.
The obstacles for us to get to the next state is for the team members to be more comfortable with the practices so that we apply them natually without thinking about it. We also would have to continually tune our use of our practices and tools.
We believe that the group has fulfilled the requirements for P+.
- Nearly all commits are linked to an issue that describes the feature / commit.
- The group has worked well togehter in a proactive and creative way. Each group member is proud of the work that has been done.