SWEN2

Alle Daten immer verfügbar. Für die Applikation soll es egal sein ob die Daten im Cache oder in der DB sind.

Beim Entity Mapping geht es darum, einem Objekt aus dem System eine ID aus der Datenbank zuzuweisen. So weiss das System, welche ID im zugrundeliegenden RDBMS zu einem Objekt gehört. Dies mittels Annotations passiert wie folgt:

Dependencies werden zur Runtimes injected und nicht von den Objekten selber initialisiert. Dies erlaubt bessere Testbarkeit und einfache Austauschbarkeit einzelner Komponenten wie DB, Logger etc

Java Spring ist ein Beispiel.

1. Single responsibility
2. Open closed principle
3. Liskovsche Substitution
4. Interface Segregation Principle
5. Dependency Inversion

Jede Klasse und Methode sollte nur eine einzige Verantwortung haben. Eine Klasse / Methode sollte sich in einem Satz ohne "und" beschreiben lassen.

Errorhandling und Logging sind auch verantwortlichkeiten!

Eine Modul sollte offen für Erweiterungen und geschlossen für Veränderungen sein.

Einfaches Beispiel: Eine Methode die immer "Hello World" printet. Will man diese Nachricht nun ändern, muss man das direkt im Code machen. Übergibt man die Message hingegen als Argument erfüllt diese Methode das OC Prinzip

Falls S ein Subtyp von T ist, dann sollten alle Objekte vom Typ T mit dem Typ S ersetzt werden können.

Dieses Prinzip kann leicht verletzt werden. Daher sollte komposition statt vererbung bevorzugt werden.

Dient dazu grosse Interfaces aufzuteilen. Klassen sollten nur die Interfaces implementieren die sie auch wirklich benötigen. Damit wird die Software stärker entkoppelt und besser refaktorisierbar.

Soll die Kopplung reduzieren. Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Abstraktionen abhängen.

Business Logik sollte z.B: nicht abhängig von der Datenbank sein.

Limit Work in Progress. Maximalanzahl von erlaubten Tasks pro Spalte des Kanbanboards.

Kanban Board wie Trello. Tasks in verschiedene Aufgaben wie Todo, Dev, Testing etc unterteilen

Visualisiert die stabilität des Prozesses über Zeit. 

Lead time startet wenn ein Request gemacht wurde und endet wenn dieses Feature ausgeliefert wurde. Lead Time ist das, was der Kunde sieht.

Durchschnittliche Zeit um ein Item fertigzustellen.

Drei Arten von Waste:

1. Waste in code development (defekter code, keine tests suites)
2. Waste in project management (unnötige dokumentation, sitzungen etc)
3. Waste in workforce potential (multitasking, entwickler können nicht arbeiten weil sie auf infos warten etc.)

Das Ziel ist es möglichst alles zu entfernen was kein Business Value bringt.

Unabhängig ablaufende Elemente, welche über Nachrichten miteinander agieren.

Communication Processes und Event Systems.

Wasserfall:

• Lineares Modell welches in aufeinanderfolgende Projektphasen organisiert ist: 
  • Anforderungen
  • Entwurf
  • Implementation
  • Überprüfung
  • Wartung
• Vorteile:
  • Einfach verständlich
  • Bei soliden Anforderungen einigermasse gute Abschätzung von kosten und Umfang möglich
• Nachteile:
  • Unflexibel
  • Softwareprojekte laufen häufig nichtlinear ab
  • Anforderungen sind im voraus so gut wie nie 100% bekannt
  • Es wird häufig am User vorbeientwickelt (Nur 20% der Features werden wirklich gebraucht)

Unified Process

• Iterativ und inkremental
• Use case driven
• Risk first => d.H. kritische Use Cases zuerst entwickeln
• Vier Phasen:
  • Inception (Risiken identifizieren sowie provisrische Architektur)
  • Elaboration (Architekturprototyp und detaillierte Beschreibung von 80% der Use Cases)
  • Construction (Entwickeln und testen des Produkts)
  • Transition (Übergabe und Auslieferung der Software)
• Vorteile:
  • Skalierbarkeit auf grosse und kleine Projekte
  • Bekanntes Verfahren (d.H: es gibt Standards für Sachen wie UML)
  • Klare Struktur
• Nachteile:
  • Sehr Dokumentationslastig (mit teilweise wenig Businessvalue)
  • Schwierige Einführung von neuen Entwicklern welche das System nicht kennen

Fixer Kommunikations-Mechanismus zwischen aufrufendem Element und aufgerufenen Element

Main Program & Subroutine / Object Oriented / Layered

Brooks unterscheidet zwischen ungewollter (accidental) und notwendiger (essential) komplexität. Ungewollte komplexität sind Probleme welche gelöst werden können. Notwendige Komplexität kann nicht umgangen werden. Wenn ein User 30 Sachen von einer Software will, muss diese Software diese 30 Sachen unterstützen. Ungewollte Komplexität geht immer mehr zurück, durch bessere Programmiersprachen und Tools und Programmierer können sich auf die notwendige Komplexität fokussieren.

Brooks empfiehlt Software inkrementell und anhand von Prototypen zusammen mit dem Kunden zu entwickeln. Ausserdem sagt er, dass der Fokus bei der Bildung von Programmieren auf der Softwaredesignebene liegen sollte. "Starsoftwaredesigner" sollten zudem gleich behandelt werden wie Starmanager.,

 Erlaubt die Realisierung portabler und interpretierbarer Systeme

Interpreter und Rule-Based Systems

Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.

System ist eine Abfolge von Datenbezogenen Transformationen

Batch Sequential und Pipes and Filters

1. Kunden zufriedenstellen durch kontinuierliche Auslieferung funktionierender Software
2. Veränderung sind in jeder Phase des Projekts willkommen
3. Funktionierende Software alle paar Wochen / Monate liefern (kürzere Zeitspanne besser)
4. Kunde und Entwicklern sollten täglich zusammenarbeiten.
5. Entwickeln mit motivierten Teams, diesen Vertrauen und ein gutes Umfeld schaffen.
6. Persönliche Kommunikation bevorzugen
7. Funktionierende Software als wichtigstes Fortschrittsmass
8. Nachhaltige Entwickelung => Kunde und Entwickler sollen das Tempo halten können
9. Ständiges Augenmerk auf teschnische Exzellenz und gutes Design
10. Einfachheit statt unnötiger Komplexität
11. Selbstorganisierte Teams
12. Regelmässige Reflektion

Kontinuierliche Auslieferung

Änderungen sind jederzeit willkommen und möglich

Kunde und Entwickler arbeiten täglich zusammen

Regelmässige Reflektion

Zentrale Aufgabe ist Zugriff und Aktualisierung von Daten eines Repositories

Repository / Blackboard

Definition: Besteht aus einer beliebigen Anzahl miteinander kommunizierender Elemente. Die Synchronisation erfolgt ausschliesslich über die Kommunikationskanäle zwischen den Elementen und kann sowohl synchron als auch asynchron erfolgen.

Stil: Independent Components

Anwendung: Parallelverarbeitung. 

Beispiel: Springer Problem. Lösung durch Backtracking

+ Einfache Modellierung, Skalierbarkeit

- Komplexität der einzelnen Elemente

Robert C. Martin

Autor mehrerer Bücher zum Thema XP und Agiler Entwicklung. Gibt Vorträge und schreibt Artikel auf verschiedenen Plattformen. Seine Firma berät Firmen zu den Themen XP und agile.

Dave Thomas

War Mitautor von "The Pragmatic Programmer". Glaubt, dass das Herzen eines Projekts die Personen sind und nicht die Methode.

Alistair Cockburn

Bekannt für seine Interviews von Projektteams. Arbeitet an Empfehlungen für Agile Softwareentwicklung.

Martin Fowler

Chefwissenschaftler von Thoughtswork. Eine Firma für Softwareentwicklung und Beratung. Autor von mehreren Büchern über XP, Refactoring und UML

Ron Jeffries:

Autor von XP Büchern und gibt regelmässig Vorträge über XP. Ausserdem sehr aktiv in Online Foren.

                            Agile Values

                            ----------

                          Prinzipien / Managment Practices!

             --------------------------------------------

                     Engineering Practices

--------------------------------------------------------------------------

Values:

Kommunikation, Funktionierende Software, Zusammenarbeit und Flexibilität

Prinzipien:

Die 12 Agile Prinzipien

Definition: Dieser Ereignisgesteuerte Architektur Stil definiert Architekturen, deren Prozesse über Events miteinander kommunizieren.

Stil: Independent Components

Anwendung: GUI, Real-time Systeme 

Beispiel: React, MVC

+ Unabhängigkeit der Elemente, Einfach zu ändern

- Non-Deterministisches Verhalten der Elemente

Risk:

Project cancelledSystem does not evolve gracefully (defect rate increases)Defect rateBusines misunderstoodBusiness changesFalse feature richStaff turnoverXP gibt uns Prinzipien und How-Tos, um mit diesen Risiken umzugehen

4 variables in Agile Development:

Zeit, Ressourcen, Qualit�t, Scope. Die ersten drei sind meistens fix. Daher sollte Scope flexibel sein!

Cost of Change:

Dir kosten kos änderungen sollen nur minimal steigern. Z.b. durch automatisierte tests.