Kartenstapel

• Keine explizite Dokumentation und Reviews

• Paar-Programmierung zur Qualitätssicherung

• Code wird permanent lauffähig gehalten

• „Test-First“-Ansatz

--> nur für kleinere Projekte geeignet

a. Hohe Kohäsion: Eine Einheit sollte möglichst einen in sich geschlossenen Aufgabenkomplex abdecken. Siehe Kapselung: Attribute und Methoden, die eng zusammengehören, sollten eine gemeinsame Klasse bilden.

b. Lose Kopplung: Gegenseitige Abhängigkeiten zwischen verschiedenen Einheiten sollten möglichst gering sein.

Eine Komponente ist eine Einheit, die unabhängig auslieferbar und versioniert ist, explizite Schnittstellen hat, weitgehend von ihrer Umgebung unabhängig und mit anderen Komponenten kombinierbar ist. Sie ist mehrfach verwendbar und hat keinen nach Außen beobachtbaren Zustand.

• UML Zustandsdiagramme

o Zustände, in denen sich das System befinden kann

o Zustandsübergange, deren Auslösebedingungen und durchzuführende Aktionen

• UML Sequenzdiagramme

o Nachrichten- und Ereignisfluss

o Darstellung eines möglichen Use Cases

• Semantischer Unterschied: Statechart: "vollständige" Verhaltensbeschreibung vs.

Sequenzdiagramm: beispielhafter, konkreter Ablauf

• Inkrementell und iterativ

• 3 Rollen: Product Owner, Entwicklungsteam, Scrum Master

a. Guter Programmierstil:

i. Variablen klein und Klassennamen großschreiben

ii. Einheitliche Formatierung, z. B. einheitliche Einrückung von Codeblöcken (bspw. Schleifen) mit 2 Leerzeichen (keine Tabulatoren!)

iii. Kommentare verwenden

b. Coding-Guidlines sind generell sinnvoll, weil sie die Lesbarkeit des Codes erhöhen. Insbesondere wenn mehrere Personen an einem Projekt arbeiten, erleichter dies das Verständnis und die Wartung des Codes

Test/Integration: Im Gegensatz zu agilen Methoden erfolgt die Ermittlung der Testdaten im Wasserfallmodell erst in der Testphase.

Prototyping ist die Erstellung eines ersten Exemplars eines Produkts, das noch nicht voll funktionsfähig ist, aber preisgünstig und mit kurzer Entwicklungszeit erstellt werden kann. Es dient der frühen Einbindung von Anwendern in die Entwicklung, um frühzeitig mögliche Risiken erkennen und die Realisierbarkeit abschätzen zu können

Eine Komponente ist ein modularer Systembestandteil, der nach Außen nur durch seine Schnittstellen bekannt ist und die eigentliche Funktionsweise kapselt. Durch die definierte Schnittstelle ist die Komponente in ihrer Umgebung austauschbar und wiederverwendbar. Dies steigert die Produktivität, senkt die Kosten und vereinfacht die Wartung.

Es lassen sich im Wasserfallmodell nicht alle Tätigkeiten eindeutig einer Phase zuordnen, da sich die Phasen überschneiden und Tätigkeiten sich wiederholen können.

Um die Komponenten miteinander zu verbinden und zu einem Gesamtsystem zu verknüpfen ist zusätzlich sogenannter „Glue Code“ erforderlich.

Funktionale Anforderung:

•Beschreibung dessen, was das System tun soll

•Bsp.: "Das System soll einen Mechanismus zur Identifizierung von Benutzern vorsehen."

Nicht-funktionale Anforderung:

•Einschränkende Bedingung, wie die funktionalen Anforderungen zu realisieren sind

•Bsp.: "Der Identifizierungsvorgang muss in höchstens 5 Sekunden abgeschlossen sein."

• Domänen Engineering: Das Domänen Engineering umfasst die Erfassung aller relevanter Konzepte in der entsprechenden Domäne unabhängig von einem konkreten Anwendungsfall. Ziel ist die Realisierung einer wiederverwendbaren Plattform, die dann für die konkrete Anwendungsentwicklung genutzt werden kann.

• Applikation Engineering: Das Applikation Engineering befasst sich mit der Ableitung konkreter Produkte aus der durch das Domänen Engineering erarbeiteten Plattform.

a. Logische Sicht: Die logische Sicht beinhaltet das Klassenmodell und eine Verfeinerung des Analysemodells. Sie dient der vereinfachten Darstellung zur Kommunikation mit dem Endanwender.

b. Struktursicht: In der Struktursicht werden Subsysteme und deren Schnittstellen dargestellt. Sie kann dazu dienen, den Programmieraufwand aufzuteilen und die Wartung zu planen.

c. Ablaufsicht: Die Ablaufsicht beschreibt Prozesse und deren Koordination. Sie hilft Systemintegratoren.

d. Physikalische Sicht: Zur physikalischen Sicht gehören Komponenten, Hardware und Netze. Sie erklärt dem Nutzer den physikalischen Aufbau des Systems und hilft bei der Installation.

Der Zweck von Code-Generierung ist Qualität zu erhöhen und die Entwicklungszeit zu senken.

Zustandsdiagramme beschreiben das Verhalten von einzelnen Objekten durch endliche Zustandsübergangsdiagramme, die ähnlich wie endliche Automaten funktionieren. Der Fokus liegt hier auf möglichen Abläufen und der Verbindung dieser Abläufe zum aktuellen Zustand des Objekts (man kann bspw. Keine Tür schließen, die bereits geschlossen ist).

UML Sequenzdiagramme können die Interaktion zwischen Objekten sehr gut modellieren. Hierbei werden jedem Akteur verschiedene Aktivitäten zugeordnet, die eventuell voneinander abhängig sein können (zB Postbote kann Brief erst an Haushalt A verteilen, sobald er den Brief aus dem Verteilerzentrum erhalten hat), was durch diverse Pfeile gekennzeichnet wird. Der Fokus liegt auf dem Informationsfluss zwischen Objekten, die Zeit fließt nach unten.

Der wesentliche semantische Unterschied liegt in der Lese- und Schreibrichtung: UML Sequenzdiagramme werden von oben nach unten und von links nach rechts gelesen, UML Aktivitätsdiagramme und Aktivitätsdiagramme von links nach rechts. Jedes Diagramm hat leicht andere Symbole und beschreibt andere Teilaspekte eines Programms, der Fokus liegt auf anderen Aspekten

git --version: Zum Überprüfen, ob git installiert ist, kann man eine Konsole öffnen und folgenden Befehl eingeben

git clone # Hier der Link: Nun wollen wir das Projekt bei uns lokal auf dem Rechner haben. Hierfür müssen wir das Projekt klonen. Dafür auf den "Clone"-Button clickenHier kopieren wir uns den HTTPS-Link und geben in der Console den folgenden Befehl ein

git config --global user.email # Meine Email-Adresse: Weiter sollte man, wenn man Git zum ersten Mal installiert hat, in der Git Config zumindest seine Email-Adresse hinterlassen, damit der Commit jemandem zugeordnet werden kann. Hierfür reicht der folgende Befehl.

git add README.md: Dafür ist es zuerst wichtig, Git nur die Dateien hochladen zu lassen, welche wir auch hochladen wollen. Hier nutzen wir den git add Befehl, welcher in unserem Fall nur die Readme versionieren soll.

git commit -m # Unsere Nachricht: Dies bedeutet, dass wir sowohl den Änderungen eine Nachricht zuordnen, um im besten Fall präzise zu beschreiben, was wir da eigentlich gemacht haben, als auch die Dateien zu bestätigen (Näheres dazu in Remote). Dieses tun wir mit.

git fetch # Holt nur die neuen Änderungen

git pull # Versucht die neuen Änderungen bereits zu integrieren: Zu aller erst wollen wir sicher gehen, dass wir mit dem aktuellsten Stand des Repositories arbeiten. Neue Änderungen in dem Projekt in GitLab, welche sich noch nicht in unserem lokalen Repository befinden, können wir auf zwei Arten übertragen.

git checkout -b # Branchname: Um nun allerdings selbst mal mit Branches zu arbeiten, können wir uns erstmal einen neuen Branch erstellen. Wenn wir uns also in unserer CLI befinden, können wir einen neuen Branch mit dem folgenden Befehl erzeugen.

git push --set-upstream origin # Branchname: Weiter sehen wir auch den Zustand der Dateien. Sollten wir also beispielsweise auf dem zweiten Branch eine Änderung in der Readme vorgenommen haben, kann man folgendes sehen.

git rebase # Branchname: Nun wollen wir dafür sorgen, dass beide Branches in einen zusammengeführt werden und auf der anderen Seite auch erreichen, dass dabei die Änderungen aus den einzelnen Branches erhalten bleiben. Wir nutzen dafür den Rebase-Command.

mkdir # Ordnername

cd # Ordnername

git init --bare:Um nun zu verstehen, wie Git genau funktioniert, können wir uns einen eigenes Remote-Repository erstellen. Hierfür erstellen wir uns einen Ordner und initialisieren das Repository.