DECIDE

Repo for the DECIDE task in DD2480. This project works as part of a hypothetical anti-ballistic missile system, which would provide a function to decide whether the missile should be launched.

Requirements

The requirements can be downloaded here. According to that, this repo is composed by the following part:

• IO Operation : Read inputs fron JSON file and output the decision.
• LIC functions : 15 different functions that decide whether a condition is met.
• Final Decision : Calculate PUM & FUV and decide whether to launch according to the results.
• Tests : Unit tests and integration tests to ensure code is functioning well.

The program would take the following as input.

• NUMPOINTS : The number of planar data points.
• POINTS : Array containing the coordinates of data points.
• PARAMETERS : Struct holding parameters for LICs.
• LCM : Logical Connector Matrix.
• PUV : Preliminary Unlocking Vector.

And calculate the following values for decision.

• CMV : Conditions Met Vector.
• PUM : Preliminary Unlocking Matrix.
• FUV : Final Unlocking Vector.

Then a final decision is made based on FUV.

Usage

We use maven as the package manager for our project, which can be installed with the following commands.

$ sudo apt update
$ sudo apt install maven

Then the following commands can be run:

$ mvn package # Build the project and run unit tests
$ mvn test # Only run the tests without rebuild
$ mvn exec:java # Run the main function
$ mvn javadoc:javadoc # Generate documentation

Dependencies

• Maven 3.6+ requires JDK 8 or above to execute.
• Additional Maven dependencies are configured in pom.xml

Coding Standard

We follow Sun's Java Style and enforce the standard via CheckStyle.

API Documentation

API Documentation is automated generated by JavaDoc and is deployed on Github Pages.

Way of Working

Principles Established

• Principles and constraints are committed to by the team.
• Principles and constraints are agreed to by the stakeholders.
• The tool needs of the work and its stakeholders are agreed.
• A recommendation for the approach to be taken is available.
• The context within which the team will operate is understood.
• The constraints that apply to the selection, acquisition, and use of practices and tools are known.

Foundation Established

• The key practices and tools that form the foundation of the way-of-working are selected.
• Enough practices for work to start are agreed to by the team.
• All non-negotiable practices and tools have been identified.
• The gaps that exist between the practices and tools that are needed and the practices and tools that are available have been analyzed and understood.
• The capability gaps that exist between what is needed to execute the desired way of working and the capability levels of the team have been analyzed and understood.
• The selected practices and tools have been integrated to form a usable way-of-working.

In Use

• The practices and tools are being used to do real work.
• The use of the practices and tools selected are regularly inspected.
• The practices and tools are being adapted to the team’s context.
• The use of the practices and tools is supported by the team.
• Procedures are in place to handle feedback on the team’s way of working.
• The practices and tools support team communication and collaboration.

In Place

• The practices and tools are being used by the whole team to perform their work.
• All team members have access to the practices and tools required to do their work.
• The whole team is involved in the inspection and adaptation of the way-of-working.

Working well

• Team members are making progress as planned by using and adapting the way-of-
• working to suit their current context.
• [] The team naturally applies the practices without thinking about them.
• The tools naturally support the way that the team works.
• The team continually tunes their use of the practices and tools.

Retired

• The team's way of working is no longer being used.
• Lessons learned are shared for future use.

Contributions

Contributions to the projected is stated below.

Angelica Engström

• Implement LIC 4 & Related unit tests
• Implement LIC 11 & Related unit tests
• Implement LIC 14 & Related unit tests
• Implement LIC 15 & Related unit tests
• Fix code skeleton style
• Implement input reader

Celina Tjärnström

• Implement LIC 3 & Related unit tests
• Implement LIC 9 & Related unit tests
• Implement LIC 10 & Related unit tests
• Implement LIC 13 & Related unit tests

Tobias Hansson

• Implement LIC 1 & Related unit tests
• Implement LIC 2 & Related unit tests
• Implement LIC 5 & Related unit tests
• Implement LIC 12 & Related unit tests

John Söderholm

• Set up Code skeleton
• Set up OpenRewrite for auto fixing coding style
• Implement LIC 6 & Related unit tests
• Implement LIC 7 & Related unit tests
• Implement LIC 8 & Related unit tests

Tianxing Wu

• Set up CI for unit tests, coding style check and build documents
• Implement Parameters class
• Implement calculation for PUM & FUV & final decision functionalities
• Implement tests for the above functions
• Help to fix coding styles, documentations and other minor issues