BackOffice v1.0
--------------------
Team:
Patrick Stapfer
Armin Mehryar

Benutzerhandbuch:
-------------------------
Das Programm besteht aus folgenden Reiter:
- Kontakt
- Kunden
- Projekte
- Angebote
- Ausgangsrechnungen
- Eingangsrechnungen
- Bankkonto
- Berichte

In jedem dieser Reiter gibt es die Buttons "Add", "Edit" und "Delete" zum Hinzufügen, Bearbeiten und Löschen von Einträgen.
Außerdem gibt es einen Filter, um gezielt nach bestimmten Einträgen zu Filtern.

Mit rechtem Mausklick auf die einzelnen Einträge, hat man die Möglichkeit diese zu Bearbeiten oder zu Löschen. 
Bei Ausgangsrechnungen und Eingangsrechnungen hat man außerdem die Möglichkeit, mit rechtem Mausklick Rechnungszeilen anzuzeigen/zu bearbeiten.

Das Drucken der Ausgangsrechnungen erfolgt ebenfalls mit rechtem Mausklick "Als PDF drucken".
Bei Eingangsrechnungen gibt es die Möglichkeit, mit rechtem Mausklick "Rechnung anzeigen", eingescannte Rechnungen anzuzeigen.

Im Reiter Bankkonto, hat man die Möglichkeit mit "Select Rechnung" einzelne Rechnungen mit einer Buchungszeile zu verknüpfen.

Berichte werden im Tab "Berichte" angezeigt und können mit dem Button "Als PDF speichern" gesichert werden.

Lösungsbeschreibung:
--------------------------
Project-Contents:
- bl:
Businesslayer: Contains all modelclasses for data-encapsulation in this application (POJOS)

- dal:
DataAccessLayer: Contains all database-related classes and the interface for the db-model-classes (DBEntity)

- databinding:
Databinding framework for validating GUI-input-data

- gui:
All classes related to the graphical user interface

- logging:
Loggingmodule, supports a central LoggerManager with multiple logging-adapters (similar to python logging)

- tests:
Contains all sorts of tests, most of them are unit-tests


What are we proud of?
----------------------
I think the whole DAL-system is pretty well designed, it has an simplistic ORM-Mapping, realized with a lot of reflection.
For performance, we implemented a reflection-caching-sytem, which provides our BL and DatabaseAdapter to reuse preloaded
class-data.
The ORM-Mapper is also capable of mapping inheritance-tables in it's database. That means, the business-objects can also
just inherit from their database-related business-object and the mapping happens automatically.
Because of this advanced system, we only had to implement methods for reading, updating, creating and deleting items.
For reading data, we implemented a Where-Chain-mechanism which enables us to construct filtered result-lists, this minimizes
the need for specialized methods in the database-adapter.
We have never used reflection before and are pretty proud of building such a complex system in an "somekind of" straight-forward
way.


What would we make better the next time?
----------------------------------------
Unfortunately, the MockAdapter for the database was one of the last classes we implemented, so we just used our finished
MysqlAdapter to test the software. Clearly, you have to install a database and you cannot test the system independently.
Also we would try to use less singleton-classes. We think that singleton-classes don't offer a lot of benefits and make
the code confusing.

In the Configuration-Module, there are some options missing, which would have been neat for the user, like individual
configuration of each Logger object (i.e. different Adapter,..), maybe that is one point we could have done better.