Hauptseite

Aus Wiki openKONSEQUENZ
Version vom 6. Dezember 2018, 12:18 Uhr von JMeister (Diskussion | Beiträge) (Architecture Commitee)

Wechseln zu: Navigation, Suche

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.

Styleguide

allgemeine Festlegungen

Best Practises

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

Unit-Tests oder Komponententests werden verwendet um die funktionalen Einzelteile (Units) von Computerprogrammen zu testen, d. h. sie auf korrekte Funktionalität zu prüfen. Da Algorithmen auf Unit-Ebene meist nur eine begrenzte Komplexität aufweisen und über klar definierte Schnittstellen aktiviert werden, können sie mit relativ wenigen Testfällen weitgehend vollständig getestet werden. Dies gilt als Voraussetzung für die anschließende Teststufe „Integrationstest“. Dort werden die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausgerichtet. Damit lassen sich die modulspezifischen Detailkonstellationen auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle drastisch reduziert.

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.

Statement Coverage – Anweisungsabdeckung Die „Statement Coverage“ entspricht den beim Test durchlaufenden Anweisungen im Verhältnis zu allen Anweisungen. Beispiele für Anweisungen wären Wertezuweisungen bei Variablen, Fallunterscheidungen, Schleifen und Methodenaufrufe.

Branch Coverage – Zweigabdeckung Ein stärkerer Abdeckungsgrad ist die „Branch Coverage“. Sie entspricht dem Verhältnis der beim Test durchlaufenen Zweige (auch Kanten genannt).

Condition Coverage – Bedingungsabdeckung Die „Branch Coverage“ unterscheidet nicht, aufgrund welche Teilbedingungen eine Bedingung als wahr oder falsch ausgewertet wird. Dies erreicht die „Condition Coverage“. Man unterscheidet dabei zwischen der Einfach- und der Mehrfachbedingungsabdeckung.

Loop Coverage – Schleifenabdeckung

Path Coverage – Pfadabdeckung

Glossar

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

Architecture Commitee

AC Web Meetings

Quality Commitee

Dieses Wiki

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