Hauptseite: Unterschied zwischen den Versionen

Aus Wiki openKONSEQUENZ
Wechseln zu: Navigation, Suche
(File system conventions)
(Styleguide)
 
(12 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
{{DISPLAYTITLE:<span style="display:none">{{FULLPAGENAME}}</span>}}
 
{{DISPLAYTITLE:<span style="display:none">{{FULLPAGENAME}}</span>}}
 +
 +
Öffentliche Arbeitsunterlagen und Dokumentation von Meetings der Architecture und Quality Committees finden Sie hier [[OrgaUndMeetings|Organisatorisches und Meetings]].
 +
 
=Plattform=
 
=Plattform=
 
===Architektur===
 
===Architektur===
Zeile 72: Zeile 75:
 
Gemäß den Ansprüchen von openKONSEQUENZ enthält die Referenzumgebung keine intransparenten Bestandteile. Die Installation und Konfiguration aller Bestandteile der Referenzumgebung wird auf der Seite [[Installation]] erläutert.
 
Gemäß den Ansprüchen von openKONSEQUENZ enthält die Referenzumgebung keine intransparenten Bestandteile. Die Installation und Konfiguration aller Bestandteile der Referenzumgebung wird auf der Seite [[Installation]] erläutert.
  
==Demonstrationsumgebung==
+
== Demonstrationsumgebung ==
 
Die fertige Installation des ersten Moduls Einspeisemanagement (EISMAN) kann unter der URL [http://demo.openkonsequenz.de demo.openkonsequenz.de] angesehen werden.
 
Die fertige Installation des ersten Moduls Einspeisemanagement (EISMAN) kann unter der URL [http://demo.openkonsequenz.de demo.openkonsequenz.de] angesehen werden.
 +
 +
Die Hotline zur Demo-Umgebung bei Mettenmeier ist unter Tel. 05251 150 357 zu erreichen.
  
 
=Styleguide=
 
=Styleguide=
===allgemeine Festlegungen===
+
Im Bereich [[Styleguide]] werden Erfahrungen aus laufenden Projekte als Vorgaben für neue Projekte geteilt.
*[[Styleguide Design|Design]]
+
[[Styleguide (in Bearbeitung)]]
*[[Styleguide Komponenten|Komponenten]]
 
*[[Styleguide Layout|Layout]]
 
*[[Styleguide Barrierefreiheit|Barrierefreiheit]]
 
*[[Styleguide Internationalisierung|Internationalisierung]]
 
*[[Styleguide Usability|allg. Usability-Richtlinien]]
 
  
 
=Best Practises=
 
=Best Practises=
 
Im Bereich [[Best Practises]] werden Erfahrungen aus laufenden Projekte als Empfehlungen für neue Projekte geteilt.
 
Im Bereich [[Best Practises]] werden Erfahrungen aus laufenden Projekte als Empfehlungen für neue Projekte geteilt.
 
===Architecture Commitee===
 
 
===Quality Commitee===
 
 
====Quality Rules and Guidelines====
 
 
=====File system conventions=====
 
Es muss durch das AC festgelegt werden, ob eine maximale relative Pfadlänge definiert werden sollte, da unter Windows einige Programme (inkl. git) Probleme mit einer absoluten Pfadlänge > 256 Zeichen haben. Dies kann notwendig sein, da die zu erstellende Software auch auf älteren Systemen lauffähig sein muss. Zumindest sollte dieser Punkt im Rahmen zukünftiger Beauftragungen dediziert im jeweiligen Projektkontext betrachtet und ggf. auf Grundlage der Beauftragung bewertet werden.
 
 
=====Unit Tests & Code Coverage=====
 
Im Rahmen der Best Practices werden zur Durchführung von Unit-Tests entwicklungsspezifische Werkzeuge wie z.B. „JUnit“ empfohlen. Die damit generierten Testfälle sind selbst überprüfend und damit wiederholbar. Eine gute Test-Unit zeichnet sich dadurch aus, dass sie möglichst wenige Abhängigkeiten zum Rest des Systems hat und damit für sich genommen gut und einfach testbar ist.
 
 
Zum Test komplexerer Zusammenhänge sollte zusätzlich ein Mocking-Framework wie z.B.  „Mockito“ zur Abbildung weiterer Abhängigkeiten außerhalb des eigentlichen Unit-Kontextes verwendet werden. Ein derartiges Mocking-Framework bietet dem Entwickler die Möglichkeit, das Verhalten des zu testenden Systems verifizieren können, ohne im Vorfeld Annahmen treffen zu müssen. Nebenwirkungen von anderen Klassen und/oder Systemen werden weitestgehend eliminiert und die oft kritisierte enge Kopplung von Unit-Tests an den getesteten Code reduziert.
 
 
Für die Überprüfung der Code Coverage wird basierend auf den bestehenden Erfahrungen im Java-Umfeld aktuell „JaCoCo“ empfohlen. „JaCoCo“ ist ein Open-Source-Toolkit, mit dem die Qualität des Java-Codes bewertet und das Ergebnis publiziert werden kann. „JaCoCo“ wird unter den Bedingungen der „Eclipse Public License“ vertrieben und kann zudem in SonarQube eingebunden werden.
 
  
 
=Glossar=
 
=Glossar=
 
Das [[Glossar]] beinhaltet alle im openKONSEQUENZ definierten und zu verwendenden Begriffe.
 
Das [[Glossar]] beinhaltet alle im openKONSEQUENZ definierten und zu verwendenden Begriffe.
 
===Architecture Commitee===
 
 
===Quality Commitee===
 
  
 
=Dieses Wiki=
 
=Dieses Wiki=

Aktuelle Version vom 16. Mai 2019, 11:27 Uhr


Öffentliche Arbeitsunterlagen und Dokumentation von Meetings der Architecture und Quality Committees finden Sie hier Organisatorisches und Meetings.

Plattform

Architektur

Datenbereitstellung/Datenaustausch

oK-Module

Quellsystem-Mock-Ups

Nutzermodule (User Modules)

Domänenmodule (Domain Modules)

Monitoring und Logging

Die Begriffe Monitoring und Logging werden wie folgt bei openKONSEQUENZ verwendet:

Fachliches Monitoring und fachliches Logging
  • Als Fachliches Monitoring wird die Überwachung von fachlichen Funktionen wie z.B. "Einspeiser abregeln", "Topologie abfragen (getTopology)" verstanden.
  • Fachliches Logging adressiert das Aufzeichnen von fachlichen Benutzeraktionen oder Service-Aufrufen auf Funktionaler Sicht (2018-01-17 16:34 Start Absenkung Einspeiser 45 auf 30% durch Benutzer XZY ) und auch von Fachlichen Fehlern (z.B. Störung im Netzbetrieb, oder "Aufgrund von Verriegelung konnte nicht geschaltet werden", oder "Anmeldefehler durch Benutzer xxx von IP xxx". Fachliche Logs sind von Nicht-IT-Experten verständlich auch wenn sie schon sehr feingranular sind und eigentlich nicht die Standard-Interaktion mit dem Benutzer sind. Fachliche Logs könnten relevant für die Klärung von Streitigkeiten mit Netzkunden, falls z.B. nachgewiesen werden muss, dass man zügig oder diskriminierungsfrei gehandelt hat.
Technisches Monitoring und Logging
  • Technisches Monitoring bezeichnet das überwachen von eher IT-Parametern wie z.B. ob ein Service gestartet ist, was die uptime ist, was die Versionsnummer eines Services ist.
  • Technisches Logging ist das erstellen von Logs (insb. Log-Dateien) die Einträge wie z.B. Kompilier- und Start-Meldungen vom Server, Exceptions, Technische Fehler (z.B. Service Time Out) enthält. Technische Logs sind eher nur für IT-Experten relevant.
  • Performance Monitoring ist ein Spezialfall vom technischen Monitoring. Hier werden insb. Kennzahlen wie Durchsatz oder Antwortzeit für Services oder Prozessdurchläufe ermittelt.

Querschnittsmodule (Core Modules)

Installation & Betrieb

Entwicklung

Umgebungen

Referenzumgebung

Bereitstellung

Gemäß dem openKONSEQUENZ Architecture Committee Handbook (Kapitel: Deployment View) verantwortet das Konsortium neben der Demonstrationsumgebung (Demo Environment) und den Abnahmeplattformen (QA Environment) auch die Bereitstellung einer Referenzumgebung (Reference Environment).
Diese Referenzumgebung wird als direkt verwendbares Image (siehe: openKONSEQUENZ Quailty Comittee Handbook) über die IBM Softlayer Cloud angeboten. Notwendige Voraussetzung ist ein Account bei Softlayer! Über das Softlayer-Kundenportal kann unter Imagevorlagen nach öffentlichen Images gesucht werden, welche direkt als Virtueller Server (kostenpflichtig) instanziiert werden können. Die Detailbeschreibungen des jeweiligen Inhaltes dieser Images sind in der Imageliste.
Ein direkter Download der Images als Datei im VHD-Format zur lokalen Instanziierung ist angedacht. Leider sind vorher noch Fragen zur Haftung und zu einigen Nutzungs-Lizenzen zu klären.

Komponenten

Gemäß dem openKONSEQUENZ Architecture Committee Handbook (Kapitel: Technical Constraints) enthält die Referenzumgebung derzeit folgende Softwarekomponenten, welche durch openKONSEQUENZ zur Referenzumgebung zusammengestellt wurden:

Installation und Konfiguration

Gemäß den Ansprüchen von openKONSEQUENZ enthält die Referenzumgebung keine intransparenten Bestandteile. Die Installation und Konfiguration aller Bestandteile der Referenzumgebung wird auf der Seite Installation erläutert.

Demonstrationsumgebung

Die fertige Installation des ersten Moduls Einspeisemanagement (EISMAN) kann unter der URL demo.openkonsequenz.de angesehen werden.

Die Hotline zur Demo-Umgebung bei Mettenmeier ist unter Tel. 05251 150 357 zu erreichen.

Styleguide

Im Bereich Styleguide werden Erfahrungen aus laufenden Projekte als Vorgaben für neue Projekte geteilt. Styleguide (in Bearbeitung)

Best Practises

Im Bereich Best Practises werden Erfahrungen aus laufenden Projekte als Empfehlungen für neue Projekte geteilt.

Glossar

Das Glossar beinhaltet alle im openKONSEQUENZ definierten und zu verwendenden Begriffe.

Dieses Wiki

Dies ist das öffentliche openKONSEQUENZ-Wiki (frei im Internet)! Schreibberechtigung haben Mitglieder des openKONSEQUENZ ACQC (Architecture- and Quality-Committee).