[[section-design-decisions]]

== Design Decisions

All architecture decisions based on the Architecture Committee Handbook. There are no other deviations then the following.

=== BDEW Whitepaper "Anforderungen an sichere Steuerungs- und Telekommunikationssysteme "

During the development of this module the whitepaper of the BDWE will be used as basis concept, but only for the given four aspects with the here given exclusions.

.aspects from BDWE whitepaper
[cols="4", options="header"]
|========================================================
|aspect|german|priority|description
|integrity|Integrität|high|- Integrity testing of module specific configuration files will be checked on DEV and TEST system manualy before they will be deployed to PROD.

- A crypted checksum for system-, config- and application files will not be implemented.

- user information will be handled with the 'Auth & Auth' core module. Therefore there are no real user data sended in the module. Just the crypted bearer value.  
|availability|Verfügbarkeit|normal|In the document the aspect availability is mostly described as a hardware based topic and has not really much to do with development of this module. The only point that fits is the patching situation. (p.12) But because of the normal priority a short downtime should be acceptable. A server start is recommended but not necessary. But the application contexts need to be undployed and deployed. Therefore a short downtime is needed.
|intimacy|Vertraulichkeit|normal|At the moment there is no intimacy classifaction defined. The Standby Planning module uses user data for generation standby plans. All the data are stored in a local database with restricted access. The Module uses HTTP-Rest requests for getting the data to UI. Therefore restrictions can be set that only users with special roles can be granted access.
|maintainability |Wartbarkeit|normal|- There is no defined maintainability contract at the moment.

- The Standby Planning module is currently splittet into three components. Backend, Frontend and database. It uses moduls from openK like 'Auth & Auth' but has not other interaction to the module. So far there are no interfaces that should be called from other modules. 
|========================================================

.timetable of decisons
[options="header"]
|========================================================
|Date|Short|Description
|2018-05-29|Fontend Framework|We chose to use the current version of Angular (6.1.0) in order to have a stable environment. An older version like Angular 4 was no option since the newer version has several bugfixes and optimizations. Angular JS was no alternative for us.
|2018-05-29|Fontend Buildmechanism|We decided to stay as close to the native and recommended build mechanism as possible. Therefore we are using Angular CLI as our build- and testtool. We opposed to use Maven for Frontendbuild as this brings additional complexity into the build process and is far away from the recommended and accepted way in the community.
|2018-05-29|Fontend - Backend - DB|At this point the module is splitted in 3 different projects. 
- Frontend: Angular with cli build
- Backend: Java with Maven build
- Database
Frontend and Backend have different components but at this point it would not make much sense to modulize them. (Diffenrent .jars, for example, would be more effort than benefit.) 
|2018-05-29|Camunda BPM|Camunda BPM is used as BPMN engine to route processes.
|2018-05-29|Tools and APIs|The technical constraints are documented in the 02_architecture_constraints.adoc and defined in the backend (spbe) pom.xml
|2018-05-29|ng2-daterangepicker|The source code of the date picker openK prefered is not maintained since 10 month. The last change was an ugrade to angular 4. Because the Standby Planning module uses angular 6 we decide not to use this date picker. Instead we chose to use the datepicker from ng-bootstrap (https://ng-bootstrap.github.io) which is well maintained.
|2018-06-14|AG-Grid for tables|The Product Owner preferred the usage of AG-Grid in this Project. As we did not see any disadvantages we agreed and used AG-Grid from now on. The alternative standard HTML-Tables were therefore obsolete.
|2018-06-29|no use of bom.xml|A bom.xml is not needed as long no further modularization is needed for the backend modul. The pom.xml file is enough to describe the external used .jars.
|2018-10-23|Standard HTML Tables for View "Abfrage aktuelle Bereitschaft"|For the View "Abfrage aktuelle Bereitschaft" it was required that it is responsive in order to use it on mobile devices and on Computers. We couldn´t get the AG-Grid responsive and therefore asked the Product Owner to use Standard HTML Tables. He agreed - (https://openkonsequenz.atlassian.net/browse/BP-187?focusedCommentId=10277&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-10277).
|========================================================