VSK

• Client-Server 
• Peer-to-Peer
• Fat-Client
• Thin-Client
• 2 Tier: Client-Server
• 3 Tier: Client-AppServer-DBServer
• n Tier: Weitere Layers (z.B. Web-Server)

Unterteilung RMI Server, RMI Client und RMI Registry

RMI Server implementiert ein Remote-Interface und erzeugt Remote-Objekte, welche über die RMI Registry (Namens-Service) publiziert werden.

Clients können über Registry die Remote-Objekte Abfragen

Die Kommunikation zwischen Client und Server erfolgt mittels TCP.

Kommunikation zwischen Client und Server ist transparent.

Falls ein Objekt als Parameter angegeben wird, muss dieses serialisierbar sein.

• Remote Interface definiert eine Registrierungsmethode
• RMI Client erzeugt einen Remote Push Receiver, exportiert diesen in die RMI Runtime
• Client registriert sich bei Server
• Server ruft beim Remote Push Receiver die push Methode auf.

Wenn der Client und der Server nicht auf die gleichen Ressourcen (Remote-Interfaces und Objekte) zugreifen können.

Wird z.B. über einen HTTP-Server realisiert.

Sobald eine Codebase vorhanden ist, wird ein Security Manager benötigt.

Java unterscheidet zwischen lokalem Code und Code aus dem Netz:
Lokaler Code hat Zugriff auf alle Ressourcen

Für Code aus dem Netz ist der Zugriff stark eingeschränkt (kein Zugriff auf lokale Daten, keine TCP/IP-Verbindungen, laden von System-Libraries, ..)

Security Manager hat eine Security Policy (in einem File ausgelagert), welche definiert, was gemacht werden darf. Anhand der Codebase, der Signierung und des Principals können die Rechte eingeschränkt werden.

1. Zerlegbarkeit: Teilprobleme sind unabhängig voneinander entwerfbar.
2. Kombinierbarkeit: Module sind unabhängig voneinander wiederverwendbar.
3. Verständlichkeit: Module sind unabhängig voneinander zu verstehen.
4. Stetigkeit: Kleine Spezifikationsänderungen führen zu kleinen Code-Änderungen.

• Lose Kopplung
• Hohe Kohäsion
• Information Hiding
• wenige & exakte Schnittstellen

• Validierung: Abnahme des Kunden (kann ich das Tool brauchen?)
• Verifizierung: Entwickler prüft, ob die Umsetzung dem Konzept entspricht

• Tests, welche die Schnittstellen und das Zusammenspiel der Systemkomponenten testen.
• Erfordern, dass die einzelnen Komponenten bereits getestet sind (Unit-Tests)

Interfaces:

• Objekt Kompatibilität (Typen und Wertebereich)
• Aufruf-Sequenzen
• Wer validiert Inputs? Aufrufer oder Aufgerufener?

Datenabhängigkeit:

• Die Datenabhängigkeiten für alle Komponenten ermitteln und testen

CallGraph Abdeckung:

• Für Komponenten, welche von verschiedenen Aufrufern genutzt werden, müssen alle Aufrufvarianten getestet werden.

• Bottom-Up the Small: Kleinere Teilsysteme "von unten auf" integrieren
• Top-Down the Controls: Fehlende Komponenten mit Stubs ersetzen
• Big-Bang the Backbone: Alle nötigen Komponeten auf einen Schlag integrieren
• Continuous Integration: Neue Komponenten laufend integrieren und testen.

• Prüfen die gesamte Wirkungskette im Softwareprodukt --> alles was nicht mit Unit- und Integrationstests abgedeckt werden kann.
• Potentiell lieferbares Produkt:
  • Muss ausserhalb der IDE lauffähig sein
  • muss über eine Bedienschnittstelle verfügen
  • muss mit anderen Applikationen und Systemen interagieren
• Systemtests testen die möglichen Kombinationen, welche im Konfigurationsmanagement definiert worden sind.
• Auch nicht funktionale Anforderungen werden abgedeckt: Last-, Performance-, Stress-, Security-Tests
• Werden aus Backlog, UseCase-Beschreibungen und der Definition of Done abgeleitet.

• Tests, welche nach jeder Änderung des Systems erneut ausgeführt werden.
• Dadurch können Race-Conditions erkannt werden.
• Integrations- und Systemtests werden als Regressionstests wieder ausgeführt.

• Review: Überprüfung eines Artefakts (Dokumentation, Code, ..) --> Produkt Qualität
• Audit: Beweis, dass ein Prozess besteht (z.B. Dokumentierung) --> Prozess Qualität
• Akzeptanztest: Black-Box Testing --> Validierung (in Scrum als Review referenziert)

"Ein geplanter Punkt im Projektablauf an dem vorher festgelegte (Zwischen-)Ergebnisse vorliegen, die es erlauben den Projektfortschritt zu messen."

• Jeder Meilenstein hat Artefakte (Dokumente, SW-Komponenten, ..)
• Meilenstein ist erreicht, wenn Artefakte vorliegen und die Überprüfung (Review / Test) erfolgreich war.

Sortiert nach Formalität und Struktur:

1. Inspection (streng, wohldefiniert)
2. Team Review (geplant und strukturiert, etwas weniger formal)
3. Walkthrough (Author stellt Werk einer Gruppe vor)
4. Pair Programming (zwei Entwickler arbeiten zusammen am selben Projekt)
5. Peer Deskcheck (eine Person prüfe das Arbeitsergebnis)
6. Passaround (Kopien werden an div. Personen versandt und derren Feedback eingeholt)
7. Ad Hoc Review (normaler Bestandteil der Teamarbeit)

Konfigurations-Management definiert die kompatiblen Konfigurationen (Hardware, Software, Einstellungen, Firmware, Doku) um Änderungen an der Konfiguration kontrolliert durchführen zu können.

Eine Aggregierung von Software, welche als einzelnes SCI behandelt wird. Dieses SCI beinhaltet:

• Code
• Pläne
• Spezifikationen
• Code Library
• Daten und Daten-Verzeichnisse
• Installations-, Wartungs- und Betriebsanleitungen

• Version: spezifisches, identifizierbares Artefakt auf einem bestimmten Entwicklungsstand
• Revision: Neue Version eines Artefakts, welches eine alte Version ablöst.
• Baseline: Satz von Revisionen --> Snapshot der Konfiguration
• Release: Getestete und freigegebene Baseline

1. Wiederverwendung
   1. Divide and Conquer
   2. Wiederverwendung ist schneller als neu erstellen
   3. Weniger Testing notwendig
   4. Bessere konsistenz, da "standard" Komponenten
2. Interface
   1. Präzise Spezifikationen
   2. Bereits getestet
3. Ersetzen
   1. Programmierung der einzelnen Komponenten unabhängig voneinander.
   2. Komponenten sind austauschbar
   3. Änderung haben kleinere Auswirkungen auf das Gesamtsystem.
4. Wirtschaftlichkeit
   1. Bereits programmierte Komponenten müssen nicht neu erstellt werden

• Export: Interfaces, welche die Komponente zur Verfügung stellt.
• Import: Benötigte / benutze Interfaces von anderen Komponenten (Imports)
• Verhalten: Verhalten der Komponente
• Kontext: Rahmenbedingungen im Betrieb der Komponente

1. Schnittstellen machen Software leichter verständlich, da Implementierung irrelevant.
2. Schnittstellen helfen bei der Reduktion von Abhängigkeiten (verglichen mit der gleichen Software ohne Schnittstellen aber trotzdem mehrere Komponenten)
3. Erleichtern die Wiederverwendung

1. Schnittstellen sollen minimal sein
   1. wenige Methoden
   2. wenige Parameter
2. Schnittstellen sollen einfach zu verstehen sein
3. Schnittstellen sollen gut dokumentiert sein

• Alles was für die Benutzung der Komponente wichtig ist
• Alles was der Programmierer verstehen und beachten muss
• Definition der Methoden
  • Syntax (Rückgabewerte, Argumente, Typen)
  • Semantik (Was bewirkt die Methode?)
  • Protokoll (z.B. synchron, asynchron)
  • Nichtfunktionale Eigenschaften (Performance, Robustheit, Verfügbarkeit, allenfalls Kosten)

"Eine Komponente stellt Services zur Verfügung, welche vom Caller abgerufen werden können"

• Gruppiert zusammengehörige Operationen
• Wenn ein Client eine Operation verwendet, ist es gut möglich, dass auch eine andere Operation benötigt wird (Reservation tätigen, freie Plätze abfragen)

z.B. Reservationssystem:
"MakeReservation": Verändert den Zustand des Reservationssystems
"TakeUpReservation": Enthält Methode "beginStay()" --> Ist abhängig vom Zustand des Reservationssystems

Spezifikation:

• Name
• In- und Output Parameter
• Änderungen, welche am System getätigt werden durch die Operationen
• Spezifikation, wie die In-, Outputs und Zustände voneinander abhängig sind.

• Stream Interface:
  • the name of the interface
  • produced streams (outgoing)
  • consumed streams (ingoing)
  • quality of services (e.g. max. dataflow)
• Signal Interface:
  • the name of the interface
  • outgoing signals
  • ingoing signals

1. Socket erzeugen (IP und Port)
2. Socket an einen lokalen Port binden (Server-seitig)
3. Daten über Socket lesen/schreiben
4. Socket schliessen

1. Server-Socket erzeugen (Server hört auf diesen Port)
2. Mit accept-Methode auf eine Verbindung warten
3. In- und Output-Stream erstelln und mit dem Socket verknüpfen
4. Daten über die Sreams lesen und schreiben (gemäss dem vereinbarten Protokoll)
5. Stream von Client und Socket schliessen
6. Wieder zu Schritt 2 oder Socket schliessen

• Verbindung zwischen einem Computer und einem privaten oder öffentlichen Netzwerk
• Generell ein Netzwerk Adapter (NIC)
  • Kann auch Software sein (Loopback Interface)
• NIC muss beim erstellen des ServerSockets angegeben werden
• In Java: Klasse NetworkInterface
  • new ServerSocket(13, 10, inet) --> Socket hört auf Port 13, akzeptiert 10 Clients und hört auf die IP definiert in der Variable inet.

• Zeitliche Entwicklung von Artefakten festhalten.
• Erlaubt Rückgriff auf alte Änderungstände (Revisionen).
• Für Arbeiten im Team ausgelegt
• Keine Backupsysteme
• Fokus: Nachvollziehbarkeit von Änderungen
• Änderungen werden als "Changesets" innerhalb einer Transaktion gespeichert.

Es wird eine lokale Kopie des Repos angelegt. Änderungen werden zuerst nur lokal gemacht, mit einem push dann auch auf dem Remote Repo.

CVS:

• Alt, sehr robust, zentraler Server
• einfache Anwendung, gut überschaubar
• Nur dateibasierend (Verzeichnisstruktur nicht versioniert)
• Ablage von Binärdateien ineffizient
• Keine Transaktionen möglich

Subversion:

• Nachfolger von CVS, zentraler Server
• Transaktionsorientiert (Commit in Transaktion)
• Versioniert gesamte Verzeichnisstruktur
• optimierte/effiziente Speicherung und Übertragung
• Integration in Webserver möglich

git:

• Verteiltes System, flexibles Konzept
• Ausgelegt für massives, billiges Branching
• Operationen primär lokal
• Skaliert (Funktionsumfang, Verteilung, Grösse)
• Integration in Web-Apps
• Erfordert ein solides Konzept bei verteiltem Einsatz

Vorteile:

• Automatischer Ablauf, keine Interaktion nötig
• reproduzierbare Ergebnisse
• Lange Builds automatisch über Nacht laufen lassen
• unabhängig von IDE

Nachteile:

• eher sturer, unflexibler Ablauf
• Abhängigkeit von Shell und Plattform (OS)
• aufwändige Wartung und Erweiterung

Typische Aktionen während Programmierung:

• Binaries erstellen für Deployment.
• Testfälle ausführen, Test-Report erstellen.
• Qualitätssicherung (Codeanalyse, Metriken etc.).
• Distributionen zusammenstellen und Deployment etc.

make:

• für C/C++ Projekte
• hohe Flexibilität

Ant (alt und bewährt, Java mit XML)
Maven (populär, etabliert, Java mit XML)
Buildr (neu, Ruby-Script)
Gradle (poluär, neu, Groovy-Script mit DSL)
Bazel (von Google, Java mit Python-like Scripts)

Maven selbst definiert nur die POM-Struktur und die LIfecycle Phasen
Rest wird von dynamisch geladenen Plugins erledigt --> flexibel und erweiterbar.

Lifecycle phases:

• validate (Validiert die Projektdefinition)
• compile (kompiliert die Quellen)
• test (Ausführen der Unit Tests)
• package (erstellen von JAR, EAR, etc.)
• verify (Integrations-Tests ausführen)
• install (Deployment im lokalen Repo)
• deploy (Deployment im zentralen Repo)

• Beschreibt die Organisation udn die Techniken für den Umgang mit Abhängigkeiten zu anderen Modulen (Package, Library, Bundle, Komponente)
• Interne (eigenes Projekt) und externe Abhängigkeiten möglich
• Es gibt öffentliche Repositories für das Hosting
  • Firmen haben oft eigene Repos (als lokaler Spiecher und Mirror von öffentlichen Repos) --> performanter

"maven coordinates" beschreiben die Abhängigkeiten, sind im POM hinterlegt:

• GroupId: Reverse Domain Name + Zusätz (ähnlich Java Package Name), bsp. ch.hslu.vsk
• ArtifactId: Entspricht häufig dem Namen des Projektes bzw. den darin enthaltenen Modulen, bsp. stringpersistor-api
• Version: Version der dependency

Zusätzlich wird beim einbinden der Dependency die "scope" angegeben (compile, test, runtime, ..).