Kernpunkte

• Eine Klasse ist Bauplan, ein Objekt ist eine konkrete Instanz mit eigenem Zustand.
• Attribute beschreiben Zustand, Methoden beschreiben Verhalten. Konstruktoren initialisieren ein neu erzeugtes Objekt.
• Kapselung: Attribute sind `private`, Zugriff erfolgt über öffentliche Getter/Setter — schützt Invarianten und entkoppelt API von Implementation.
• Java-Skelett: ```java public class Konto { private double saldo; public Konto(double start) { this.saldo = start; } public void einzahlen(double b) { this.saldo += b; } public double getSaldo() { return this.saldo; } } ```
• Statische Felder/Methoden gehören zur Klasse, nicht zum Objekt — Beispiel `Math.PI`.
• `this` referenziert das aktuelle Objekt; in Python heißt das Pendant `self` und ist erstes Methodenargument.

Kernpunkte

• Vererbung (`extends`) etabliert eine Ist-ein-Beziehung; Unterklasse erbt Attribute/Methoden der Oberklasse und kann sie überschreiben (`@Override`).
• Polymorphie: derselbe Methodenaufruf hat je nach dynamischem Typ unterschiedliches Verhalten — Grundlage des dynamischen Bindens zur Laufzeit.
• Abstrakte Klassen (Java `abstract`) können nicht instanziiert werden und enthalten oft abstrakte Methoden, die Unterklassen implementieren müssen.
• Interfaces (Java `interface`) definieren reine Verhaltensverträge ohne Zustand; eine Klasse kann mehrere Interfaces implementieren — pragmatische Mehrfachvererbung.
• Beispiel Polymorphie: ```java Tier t = new Hund("Rex"); System.out.println(t.lautGeben()); // ruft Hund#lautGeben → "Wuff" ```
• LSP (Liskov-Substitutionsprinzip): Unterklasse darf Vertrag der Oberklasse nicht verschärfen — sonst Polymorphie brüchig.

Kernpunkte

• UML 2 ist Standard-Notation; Klassendiagramme kapseln Klassen in Dreifach-Rechtecken: Name, Attribute, Methoden.
• Sichtbarkeit: `+` public, `-` private, `#` protected, `~` package.
• Beziehungen: Assoziation (Linie), Aggregation (offene Raute, Teil-Ganzes, schwach), Komposition (gefüllte Raute, starkes Teil-Ganzes), Vererbung (offene Pfeilspitze zur Oberklasse), Realisierung (gestrichelter Pfeil, Interface).
• Multiplizitäten an den Enden: `1`, `0..1`, ``, `1..` — beschreiben Kardinalität der Beziehung.
• CRC-Karten (Class-Responsibility-Collaboration) sind Vorstufe für Modellierung im Team; jede Karte trägt Klassenname, Verantwortlichkeiten, Kollaborateure.
• Sequenzdiagramme dokumentieren Nachrichtenfluss zwischen Objekten über die Zeitachse — ergänzen Klassendiagramme um dynamische Sicht.

Kernpunkte

• Entwurfsmuster (Gamma et al. 1994 — Gang of Four) lösen wiederkehrende Probleme strukturell und sind sprachunabhängig.
• Singleton: garantiert genau eine Instanz; kritisch wegen globalem Zustand und Testbarkeit.
• Observer: Subjekt benachrichtigt Beobachter über Zustandsänderungen — Grundlage für MVC, Event-Bus, reaktive UIs.
• Strategy: kapselt austauschbare Algorithmen hinter einer gemeinsamen Schnittstelle — Vergleich mit polymorpher Substitution.
• Factory Method: delegiert Objekterzeugung an Unterklassen; entkoppelt Client von konkreter Klasse.
• SOLID-Prinzipien (Single Responsibility, Open/Closed, Liskov, Interface Segregation, Dependency Inversion) sind Qualitätsleitlinien für OOP-Design.
• Querverweis: Das Strategy-Muster kapselt austauschbare Algorithmen aus dem Topic Algorithmen und Programmierung (z.B. Sortierverfahren) und verbindet so OOP-Struktur mit algorithmischer Variation.

Kernpunkte

• Klassische Phasenmodelle: Wasserfall (sequenziell, dokumentationsstark), V-Modell (jede Entwicklungsphase hat korrespondierende Teststufe).
• Agile Modelle: Scrum (Sprints, Product/Sprint Backlog, Daily Stand-up), Kanban (kontinuierlicher Fluss, Work-in-Progress-Limits).
• Versionierung mit Git: Commit, Branch, Merge, Pull-Request; verteiltes Modell ermöglicht parallel arbeitende Teams.
• Testarten: Unit-Tests (Methodenebene, JUnit/pytest), Integrationstests (Modulinteraktion), Systemtests (End-to-End), Abnahmetests (User).
• Testabdeckung: Anweisungs-, Zweig-, Pfadüberdeckung — höhere Abdeckung ≠ automatisch mehr Qualität.
• Continuous Integration: Tests laufen bei jedem Commit automatisch — Beispiel GitHub Actions, GitLab CI.

Kernpunkte

• Während ein Klassendiagramm die statische Struktur zeigt, beschreiben Objekt-, Sequenz- und Zustandsdiagramme das dynamische Verhalten zur Laufzeit.
• Ein Objektdiagramm ist eine Momentaufnahme: konkrete Instanzen (`k1:Kunde`) mit belegten Attributwerten und ihren aktuellen Verknüpfungen (Links).
• Ein Sequenzdiagramm stellt den Nachrichtenfluss zwischen Objekten über die Zeitachse dar: Lebenslinien, Aktivierungsbalken, synchrone (durchgezogen) und Rückgabe-Nachrichten (gestrichelt).
• Ein Zustandsdiagramm (Statechart) modelliert die Zustände eines Objekts und die durch Ereignisse ausgelösten Übergänge (z.B. Bestellung: offen → bezahlt → versandt → abgeschlossen).
• Übergänge tragen die Form `Ereignis [Bedingung] / Aktion`; Start- (gefüllter Kreis) und Endzustand (Ring um Kreis) rahmen das Diagramm.
• Die Diagrammtypen ergänzen sich: Klassendiagramm (Struktur), Sequenzdiagramm (Interaktion), Zustandsdiagramm (Lebenszyklus eines Objekts).