Verteilte Systeme und Komponenten

Version ist erneuerbar und noch nicht stabil

--> wir bei jedem Build wieder vom Repo aufgelöst und aktualisert

--> sind mit einem Timestamp versehen

Betriebssystemkonfig und Netzwerkkonfiguration

• Übersicht gewinnen, welche Versionen von welchen Configuration Items (Software) wo im Einstatz sind
  • Nachvollziehbarkeit von Problemen
  • Nicht mehr verwendetet Versionen müssen nicht weiter unterstützt werden
• Ermitteln welche Konfiguration lauffähig ist
• Ermöglichen kontrollierte Durchführung von Konfigurationsänderungen unter Sicherstellung von Integrität und Rückverfolgung

Java Interface: Anzahl Methodne (und Länge der Parameterliste)

• Wichtig ist, dass man Zeit für Reviews von anfang an einplant.
• Versch. Reviewarten (Management, Technische-Reviews und Sprint Reviews)

• Maven definiert einen generalisierten Ablauf eines Buildprozesses –den so genannten «lifecycle» (Auszug, Vereinfacht):
  • validate – Validiert die Projektdefinition.
  • compile – Kompilation der Quellen.
  • test – Ausführen der Unit-Tests.
  • package – Packen der Distribution (JAR, EAR etc.)
  • verify – Ausführen der Integrations-Tests.
  • install – Deployment im lokalen Repository.
  • deploy – Deployment im zentralen Repository.
• allgemein: der Weg von Quellartefakten zu Zielartefakten

• automatisierter Ablauf sorgt für reproduzierbare Ergebnisse (Artefakt X kann aus einem bestimmten Stand erstellt werden, auch später noch)
• funktionieren plattformübergreifend, indem plattformspezifische Eigenheiten abstrahiert werden (z.B. Dateipfade)
• automatische Auflösung von Abhängigkeiten
• Wiederverwendung von bereits erstellten Zielartefakten (wurde nichts am Code verändert, muss das Modul nicht neu gebaut werden)

• Serversoftware, welche einen automatisierten Build eines SWProjektes ausführt und die Resultate allen EntwicklerInnen im Team zur Verfügung stellt.
• Integriert Buildautomation, Versionskontrolle, Issue-Tracking, Projektmanagement-Tools, Kommunikationswerkzeuge, Statistiken und Visualisierungen etc.

• Werkzeuge, die das Erstellen von (Binär-)Artefakten aufgrund von (Code-)Artefakten ermöglichen und erleichtern.
• dem Compiler (javac, gcc) übergeordnete Werkzeuge (ant/Maven, make)
• erlauben die Definition von Abhängigkeiten (Maven-Dependencies, Make-Targets)
• übernehmen Zusatzfunktionen wie Deployment, Testausführung, Validierung
• geben dem Anwender Feedback über Korrektheit, Probleme, Warnungen etc.

• Code muss von hoher Qualität sein, damit auch das Produkt längerfristig von hoher Qualität ist.
• Code, den man sich nicht zu ändern getraut, ist eine tickende Zeitbombe.
• Aspekte: Aussagekräftige Namen, sinnvolle Kommentare, sinnvolle Aufteilung in Funktionen/Methoden, saubere Fehlerbehandlung, Unit-Tests etc.

5S:

Organisation, Ordenlichkeit, Sauberkeit, Standardisierung, Disziplin

• Man kann beim Testing feststellen, wie viele Fälle man abdeckt und sogar Fehler finden (wurde eine Bedingung geprüft, ein Branch betreten etc.)
• Man kann mit der zeitlichen Veränderung der Coverage beispielsweise feststellen, ob sich ungetesteter Code anhäuft.
• Herausfinden, wie man mit möglichst wenig Testcode möglichst viel Produktivcode testet.

Unittest, Integrationstest, Systemtest, Akzeptanztest

Reggresionstest --> werden immer wieder ausgeführt, egal welcher Typ

manuell oder automatisiert

• Feststellen potentieller Fehler
  • Verwendung uninitialisierter Variablen
  • Mögliche Race-Conditions/inkonsistente Verwendung von synchronized
  • Hinweise auf deprecated-Konstrukte
• Erteilen von Verbesserungsvorschlägen
  • Vereinfachung logischer Ausdrücke
  • Überführung von Codeabschnitten in Lambda-Expressions
• Hinweise auf Codestyle
  • Gross- und Kleinschreibung von Bezeichnern
  • Überprüfung des Codes gegen Formatting-Guidelines (Einrückung, Zeilenumbrüche)
  • konsistente Verwendung von Tabs/Spaces
• Festhalten von Statistiken: Verbesserungen/Verschlechterungen verfolgen

• Checkstyle
• Classycle
• Findbugs
• PMD

Sehr kleine Arbeitsschritte sodass der Code immer lauffähig ist --> und immer getestet werden kann

• schnelleres Feedback bei Fehlern
• minimiert den Integrrationsaufwand bei der Entwicklung im Team
• man ist immer auf dem laufenden bei der Entwicklung im Team
• immer lauffähgien Build vorhanden

Abhängkeiten zu anderen Modulen/Package/Library/Komponente (intern/extern)

werden in binärer Form aufgelöst (kompilierte Projekte) jar Dateien --> Binär Repositories

Im POM File mit den drei Koordinaten (groupID [ch.hslu.vsk], artifactID [Name], version)

im Pom File bei der Dependency ein Attribut <scope>

gitb an wo diese Dependency verwendet werden soll

compile -> Kompilation und Laufzeit

test -> Kompilation und tests

Runtime -> nur Laufzeit

Modul A ist von Modul B abhängig, Modul B von Modul C

Somit ist A von C transitiv abhängig

Dadurch können Versionskonflikte und Zyklen auftreten

Ortstransparenz: der Ort an dem sich der Dienst/Ressource befindet ist dem Benutzer unbekannt

Zugriffstransaprenz: immer gleicher Zugriff, egal von wo (lokal oder entfernt)

Nebenläufigkeitstransparenz: Benutzer können gleichzeitg auf Diesnte/Ressourcen zugreifen. Zugriffe werden synchronisiert und repliziert.

Remote Interface: definiert Dienste welche zur Verfügung stehen sollten

Server Klasse: implementiert Remote Interface und erzeugt 1 oder n Instanz (Remote Objekte)

Remote Objekte: registrieren sich bei Namensservice

Namensservice: wird von Clients abgefragt

Clients: beschaffen sich mit Hilfe des Namensservice die Remote Referenzen der gewünschten Objekte und rufen dann die Dienste (Methoden) auf

Client Stub: bietet gleiche Schnittstelle wie das Remote Objekt an, ist auf dem gleichen Rechner wie der Client

Server Stub: auf gleichem Rechner wie der Server, nimmt Anfragen des Clients entgegen

Client und Serverstub kommunizieren ind er RMI Transportschicht miteinander. Der Server Stub kennt das Applikationsobjekt (Remote Object) und leitet die Anfragen des Client Stub an dieses weiter und den gibt den Rückgabewert zurück. Diese Kommunikation ist transparent.

elementare Datentypen --> call by value

lokale Objekte --> serialisert (kopiert und somit auch als value)

verweise auf Remote Objekte --> Referenzcharakter

Der Client übergibt dem Remote Objekt eine Remote Callback Referenz auf sich selbst. Das Remote Callback Objekt muss für die RMI Middelware exportiert werden.

RMI Registry, RMI Server, RMI Client

- Wiederverwendbarkeit (reduziert die Lieferzeit, grössere Konsistenz)

- Schnittstellen Vorteile (höher Qualität, präzise Spezifizierung, geteset)

- Austauschbarkeit (parallele Entwicklung)

• Eigenständige, ausführbare SW-Einheiten(Laufzeit-Sicht), d.h.Subsysteme, Prozesse, Objekte
• Über ihre Schnittstellen austauschbar
• Lassen sich unabhängig voneinander entwickeln
• Kunden -/ anwendungsspezifische bzw. wiederverwendbare sowie COTS
• Können installiert/deployed werden

eindeutige Indentifkation, ansonsten aufwändige Fehlersuche und schwer nachvollziehbar

1. Versionierung im Dateinamen
   1. Vorteil:
      1. Artefakt kann sehr einfach identifiziert werden
      2. Eindeutige Referenz in Klassepfaden möglich
   2. Nachteil:
      1. Einfach manipulierbar
      2. Bei Bugfix à muss Klassenpfad angepasst werden
2. Versionierung im manifest
   1. Vorteile:
      1. Manipulation nur durch Änderung in der JAR Datei
      2. Spezifikationskonform
      3. Dateiname ohne Versions-Nummer möglich à konstante Klassenpfade
   2. Nachteile:
      1. Version nur durch Blick in das JAR sichtbar

VARIANTEN KÖNNEN KOMBINIERT WERDEN

• Zerlegbarkeit à Teilprobleme sind unabhängig voneinander realisierbar (oft rekursiv)
• Kombinierbarkeit à unabhängig voneinander (wieder)-verwendbar
• Verständlichkeit à unabhängig voneinander zu verstehen
• Stetigkeit à kleine Änderungen der Spezifikation führen nur zu kleinen Änderungen im Code

Minimal (wenige Methoden und Überschneidungen, geringe Anzahl Parameter)

einfach zu verstehen

gut dokumentiert

Precondition --> Zusicherungen die der Aufrufer einuhalten hat

Postconditon--> Nachbedingungen die das Aufgerufene garantiert

Invariaten --> Bedingungen die Instanzen ab der Erzeugung erfüllen müssen und währen der Ausführung einer Funktion

• Syntax (Rückgabewerte, Argumente, in/out, Typen) à in der verwendeten Programmiersprache
• Semantik (Was bewirkt die Methode) à keine Allgemeineform
• Protokoll (synchron oder asynchron)
• Nichtfunktionale Eigenschaften (Performance, Robustheit, Verfügbarkeit, bei Web-Anwendungen auch Kosten)

Operational Interface

• Gruppieren Operationen welche zusammen gehören (Bsp. Reservation)
• Normalerweise braucht der Client mehrere Methoden des Interface
• Operationen welche zusammen gehören haben einen Effekt auf den Status des Komponenten Objekt

Signal Interface

• Komponente kann Signale erhalten oder schicken (Bsp. ErrorMessage)

Stream Interface

• Collections von Data-Streams welche von Komponenten benutzt/erstellt werden können. (Bsp.Videoimage)

objektorientierte API

REST API

Messaging API

Dateibasierte API

Validate: haben wir es das Richtige entwickelt

Verify: haben wir es richtig gemacht

Customer Requirments/PlanAcceptance Testing

Detailed Requirements/ Plan System Testing

System Design/ Plan Integartion Testing

Detailed Design/ Write Unit Testing/Run Unit Tests (IMPLEMENT AND REFACTOR)

Run Integration Tests --> verify system design

Run System Tests --> verify detailed Requirements

Run Acceptance Tests --> validate customer Requirments

• Im Backlog formulierten Anforderungen und Abnahmekriterien
• Den dazugehörigen detaillierten UseCase-Beschreibungen
• Der Defintion of Done
• Nicht funktionale Tests ( Last-/ Performance-/Security-/Robustness -Tests à ebenfalls wichtige Systemtests
• Formulieren der Systemtests fördert das Verständnis der Anforderungen im Backlog und bringt Unklarheiten und Inkonsistenzen frühzeitig zu Tage

• Feasibility Review (Systemabgrenzung und grober Projektplan)
• Requirments Review (Kundenanforderung und Abnahmeplanung)
• Preliminary Design Review (Systemarchitketur und Testkonzept)
• Critical Design Review (Dateailentwürfe und UnitTest Spezifkaitonen)