a

WS2425/SWT D/P3.md

@@ -0,0 +1,60 @@
+Um die Implementierung der Buchverwaltung in der Version 1.0 (BuchV1) gemäß den genannten Architekturprinzipien zu bewerten, werde ich die Prinzipien nacheinander durchgehen und eine Bewertung sowie eine Begründung für jede geben.
+
+### 1. Modularisierung
+**Bewertung: 3 (in Grundzügen umgesetzt)**  
+**Begründung:** Die Buchverwaltung ist in mehrere Klassen unterteilt (z.B. `Buch` und `Buchverwaltung`), was eine gewisse Modularität aufweist. Allerdings könnte die Modularisierung weiter verbessert werden, indem zusätzliche Klassen für spezifische Aufgaben wie das Speichern und Laden von Daten oder die GUI-Logik erstellt werden. Derzeit sind alle Funktionalitäten in der `Buchverwaltung`-Klasse zusammengefasst, was zu einer Überlastung dieser Klasse führt.
+
+### 2. Hierarchisierung
+**Bewertung: 2 (kaum beachtet)**  
+**Begründung:** In der aktuellen Implementierung gibt es keine klare Hierarchisierung. Die Klassen sind weitgehend flach, und es gibt keine Nutzung von Vererbung oder Interfaces, um verschiedene Typen von Objekten oder Funktionen zu strukturieren. Eine hierarchische Struktur könnte helfen, die Beziehungen zwischen verschiedenen Klassen besser zu verdeutlichen und die Wartbarkeit zu verbessern.
+
+### 3. Starker Zusammenhalt und schwache Kopplung
+**Bewertung: 3 (in Grundzügen umgesetzt)**  
+**Begründung:** Die Klasse `Buch` hat einen hohen Zusammenhalt, da sie ausschließlich Buch-bezogene Daten und Methoden enthält. Allerdings ist die `Buchverwaltung`-Klasse stark gekoppelt an die GUI-Logik und die Datenpersistenz. Eine bessere Trennung der Verantwortlichkeiten (z.B. durch separate Klassen für die Datenverarbeitung und GUI) könnte die Kopplung reduzieren und die Wiederverwendbarkeit erhöhen.
+
+### 4. Trennung von Zuständigkeiten
+**Bewertung: 2 (kaum beachtet)**  
+**Begründung:** Die `Buchverwaltung`-Klasse übernimmt mehrere Verantwortlichkeiten, einschließlich der GUI-Interaktion und der Datenverwaltung. Dies führt zu einer unklaren Trennung von Zuständigkeiten. Eine klarere Trennung könnte erreicht werden, indem man spezifische Klassen für die GUI, die Datenbankverwaltung und die Buchlogik erstellt. Dies würde die Wartbarkeit und Testbarkeit des Codes verbessern.
+
+### 5. Information Hiding
+**Bewertung: 4 (in wesentlichen Teilen umgesetzt)**  
+**Begründung:** Die Implementierung nutzt private Attribute in der Klasse `Buch`, was dem Prinzip des Information Hiding entspricht. Die Methoden, die den Zugriff auf diese Attribute steuern (z.B. Getter und Setter), sind klar definiert. Allerdings könnten einige Implementierungsdetails der `Buchverwaltung`-Klasse, wie die Datenpersistenz, besser verborgen werden, um die interne Logik vor der Außenwelt zu schützen.
+
+### Zusammenfassung
+Insgesamt zeigt die Implementierung einige positive Aspekte, wie z.B. das Information Hiding und einen gewissen Grad an Modularisierung. Dennoch gibt es signifikante Verbesserungspotenziale, insbesondere hinsichtlich der Hierarchisierung und der Trennung von Zuständigkeiten. Eine Überarbeitung der Architektur könnte dazu beitragen, die Wartbarkeit, Erweiterbarkeit und Testbarkeit des Systems zu verbessern.
+
+
+Die Architektur der Buchverwaltung in Version 1.0 (BuchV1) hat erhebliche Auswirkungen auf die folgenden Qualitätskriterien: Portabilität, Testbarkeit und Wiederverwendbarkeit. Ich werde jedes Kriterium einzeln betrachten und die Auswirkungen der aktuellen Architektur erläutern.
+
+### 1. Portabilität
+**Auswirkungen:**  
+Die Portabilität bezieht sich darauf, wie leicht eine Anwendung auf verschiedenen Plattformen und Umgebungen eingesetzt werden kann. In der aktuellen Implementierung gibt es einige positive Aspekte:
+
+- **Unabhängigkeit von spezifischen Bibliotheken:** Die Buchverwaltung verwendet standardmäßige Java-Klassen (z.B. AWT für die GUI), die auf verschiedenen Plattformen verfügbar sind. Dadurch kann die Anwendung prinzipiell auf jedem System, das die Java Runtime Environment (JRE) unterstützt, betrieben werden.
+- **Dateispeicherung:** Die Anwendung speichert Daten in einer serielle Datei, was einfach zu transportieren ist. Allerdings ist der harte Pfad zur Datei (`/Users/dwiesmann/IO/buchliste.ser`) eine Einschränkung, da er plattformabhängig ist. Dies könnte die Portabilität einschränken, da Benutzer die Pfade manuell anpassen müssten.
+
+**Bewertung:** Die Portabilität ist gegeben, könnte aber durch flexiblere Dateipfade und die Verwendung von plattformunabhängigen Bibliotheken verbessert werden.
+
+### 2. Testbarkeit
+**Auswirkungen:**  
+Die Testbarkeit bezieht sich darauf, wie einfach es ist, die Software zu testen, insbesondere automatisierte Tests.
+
+- **Eng gekoppelte Klassen:** Die starke Kopplung zwischen GUI-Logik und Datenverwaltung in der `Buchverwaltung`-Klasse erschwert Unit-Tests. Es ist schwierig, Teile der Logik isoliert zu testen, da die Benutzeroberfläche und die Geschäftslogik eng miteinander verwoben sind.
+- **Mangel an Schnittstellen:** Die Verwendung von konkreten Klassen anstelle von Interfaces reduziert die Möglichkeit, Mock-Objekte für Tests zu verwenden. Dies erschwert das Testen von Abhängigkeiten und das Schreiben von Unit-Tests.
+- **Ungetestete Benutzerinteraktionen:** Da die GUI-Logik direkt in die Hauptklasse integriert ist, fehlen Mechanismen, um Benutzerinteraktionen separat zu testen.
+
+**Bewertung:** Die Testbarkeit ist eingeschränkt. Eine bessere Trennung der Zuständigkeiten und die Verwendung von Interfaces würden die Testbarkeit erheblich verbessern.
+
+### 3. Wiederverwendbarkeit
+**Auswirkungen:**  
+Die Wiederverwendbarkeit bezieht sich darauf, wie gut Teile der Software in anderen Kontexten oder Projekten wiederverwendet werden können.
+
+- **Modularität:** Obwohl die `Buch`-Klasse wiederverwendbar ist, ist die `Buchverwaltung`-Klasse zu stark spezialisiert, um leicht in anderen Projekten eingesetzt zu werden. Die Kombination von GUI-Logik und Datenverwaltung in einer einzigen Klasse hindert die Wiederverwendbarkeit.
+- **Fehlende generische Lösungen:** Es gibt keine allgemeinen Datenverwaltungslösungen oder -interfaces, die in anderen Anwendungen verwendet werden könnten. Eine generischere Architektur würde die Wiederverwendbarkeit erhöhen.
+- **Engpass in der Erweiterbarkeit:** Die aktuelle Architektur lässt sich nur schwer anpassen oder erweitern, was die Wiederverwendbarkeit der Komponenten einschränkt. Änderungen an einer Funktionalität könnten ungewollte Auswirkungen auf andere Teile der Anwendung haben.
+
+**Bewertung:** Die Wiederverwendbarkeit ist gering. Eine stärkere Modularität und die Trennung von Funktionalitäten könnten die Wiederverwendbarkeit der Komponenten erheblich verbessern.
+
+### Fazit
+Die Architektur der Buchverwaltung in Version 1.0 hat signifikante Auswirkungen auf die Portabilität, Testbarkeit und Wiederverwendbarkeit. Während es einige positive Aspekte gibt, wie die Verwendung von Standard-Java-Klassen, sind viele Designentscheidungen (wie starke Kopplung und mangelnde Modularität) nachteilig und könnten durch eine Überarbeitung der Architektur erheblich verbessert werden.
+