Examination bonus point projects
-
You are expected to work as a team of three partners.
-
Using the MI Gitlab SCM is a plus with respect to project evaluation. See table below.
-
Your team is expected to supply a Maven project based on the MI “Maven archetype quickstart” available from
https://maven.mi.hdm-stuttgart.de/nexus/repository/mi-maven/archetype-catalog.xml
. -
You are expected to provide good internal code documentation with respect both to method signatures (Javadoc™) and method implementation.
You are expected to provide good internal code documentation with respect both to method signatures (Javadoc™) and method implementation. Possible problems involve:
- Compile time warnings
-
Activate most compiler warnings at
--> . This will show potential compile time problems like dead / unnecessary / unreachable code, unused variable values, shadowing conflicts and so on.
Your method's formal parameters, their type and a method's return type must match your documentation.
You are expected to provide meaningful unit tests:
-
Try to cover all your implementation code and not just isolated modules / methods.
-
If methods allow for null values write suitable tests.
-
Test special cases: If a method expects i.e. an array of strings it may be allowed having zero length.
Your resulting project should be easily installable and runnable.
-
Maven is a good starting point with respect both to testing and cross platform (Unix / Windows / Apple) portability.
-
Avoid dependencies to local file system resources like
c:\users\xyz\testdata.txt
.
Tip
Test your application's deployability by installing it on an
untouched target platform (possibly of a different hard/software
architecture) and execute mvn test
(provided you do have written meaningful unit tests).
Criterion | Percentage |
---|---|
Overall code quality | 20% |
Code documentation | 20% |
Unit tests | 10% |
Deployment | 5% |
SCM usage | 5% |
Software functionality | 40% |
Some of these terms require further explanations:
- Overall code quality
-
Subject to personal preferences unfortunately.
- Code documentation
-
This involves writing Javadoc™ describing your classes. Furthermore you may want to add a project / architecture description. A
Readme.md
in your project's root is a good starting point. - Unit tests
-
Ideally your whole code could be covered by sensible unit tests. Albeit guaranteeing absence of errors it may help minimizing them.
- Deployment
-
How difficult is your software's deployment? Sample:
git clone git@gitlab.mi.hdm-stuttgart.de:.../yourProject.git cd yourProject mvn package # possible configuration according to documentation java -jar target/yourArchive.jar
- SCM usage
-
Using e.g. git supports team oriented project development. It also allows for tracing the participants individual contributions. For this reason your tutor is required to have read access to your project.
- Software functionality
-
-
Project specification met?
-
(User input) Error handling?
-
Stability
-
The following sections contain both current and archived project propositions.