[[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 - 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 much sencse 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-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.
|========================================================