diff --git a/Documentation/cli-parameter-mapping.org b/Documentation/cli-parameter-mapping.org new file mode 100644 index 0000000..630de97 --- /dev/null +++ b/Documentation/cli-parameter-mapping.org @@ -0,0 +1,11 @@ + + +Jede action ist eine Klasse, die einen String und eine action function hat +Beim Start der Anwendung wird eine Map aufgebaut, die den String der Klasse auf die Klasse mappt. +So wird dann nur + + + + +Repo ist für ein Agregat verantwortlich +Repository enthält teilrepositories diff --git a/Documentation/programmEntwurf.org b/Documentation/programmEntwurf.org new file mode 100644 index 0000000..07dad67 --- /dev/null +++ b/Documentation/programmEntwurf.org @@ -0,0 +1,371 @@ +Programmentwurf + +[Bezeichung] + +Name: [Name, Vorname]\\ +Martrikelnummer: [MNR] + +Abgabedatum: [DATUM] + +* + :PROPERTIES: + :CUSTOM_ID: section + :END: +Allgemeine Anmerkungen: + +- es darf nicht auf andere Kapitel als Leistungsnachweis verwiesen + werden (z.B. in der Form “XY wurde schon in Kapitel 2 behandelt, daher + hier keine Ausführung”) + +- alles muss in UTF-8 codiert sein (Text und Code) + +- sollten mündliche Aussagen den schriftlichen Aufgaben widersprechen, + gelten die schriftlichen Aufgaben (ggf. an Anpassung der schriftlichen + Aufgaben erinnern!) + +- alles muss ins Repository (Code, Ausarbeitung und alles was damit + zusammenhängt) + +- die Beispiele sollten wenn möglich vom aktuellen Stand genommen werden + + - finden sich dort keine entsprechenden Beispiele, dürfen auch ältere + Commits unter Verweis auf den Commit verwendet werden + - Ausnahme: beim Kapitel “Refactoring” darf von vorne herein aus allen + Ständen frei gewählt werden (mit Verweis auf den entsprechenden + Commit) + +- falls verlangte Negativ-Beispiele nicht vorhanden sind, müssen + entsprechend mehr Positiv-Beispiele gebracht werden + + - Achtung: werden im Code entsprechende Negativ-Beispiele gefunden, + gibt es keine Punkte für die zusätzlichen Positiv-Beispiele + + - Beispiele + + - “Nennen Sie jeweils eine Klasse, die das SRP einhält bzw. + verletzt.” + + - Antwort: Es gibt keine Klasse, die SRP verletzt, daher hier 2 + Klassen, die SRP einhalten: [Klasse 1], [Klasse 2] + - Bewertung: falls im Code tatsächlich keine Klasse das SRP + verletzt: volle Punktzahl ODER falls im Code mind. eine Klasse + SRP verletzt: halbe Punktzahl + +- verlangte Positiv-Beispiele müssen gebracht werden + +- Code-Beispiel = Code in das Dokument kopieren + +* Kapitel 1: *Einführung* + :PROPERTIES: + :CUSTOM_ID: kapitel-1-einführung + :END: +*** Übersicht über die Applikation + :PROPERTIES: + :CUSTOM_ID: übersicht-über-die-applikation + :END: +[Was macht die Applikation? Wie funktioniert sie? Welches Problem löst +sie/welchen Zweck hat sie?] + +*** Wie startet man die Applikation? + :PROPERTIES: + :CUSTOM_ID: wie-startet-man-die-applikation + :END: +[Wie startet man die Applikation? Welche Voraussetzungen werden +benötigt? Schritt-für-Schritt-Anleitung] + +*** Wie testet man die Applikation? + :PROPERTIES: + :CUSTOM_ID: wie-testet-man-die-applikation + :END: +[Wie testet man die Applikation? Welche Voraussetzungen werden benötigt? +Schritt-für-Schritt-Anleitung] + +* Kapitel 2: Clean Architecture + :PROPERTIES: + :CUSTOM_ID: kapitel-2-clean-architecture + :END: +*** Was ist Clean Architecture? + :PROPERTIES: + :CUSTOM_ID: was-ist-clean-architecture + :END: +[allgemeine Beschreibung der Clean Architecture in eigenen Worten] + +*** Analyse der Dependency Rule + :PROPERTIES: + :CUSTOM_ID: analyse-der-dependency-rule + :END: +[(1 Klasse, die die Dependency Rule einhält und eine Klasse, die die +Dependency Rule verletzt); jeweils UML der Klasse und Analyse der +Abhängigkeiten in beide Richtungen (d.h., von wem hängt die Klasse ab +und wer hängt von der Klasse ab) in Bezug auf die Dependency Rule] + +**** Positiv-Beispiel: Dependency Rule + :PROPERTIES: + :CUSTOM_ID: positiv-beispiel-dependency-rule + :END: +**** Negativ-Beispiel: Dependency Rule + :PROPERTIES: + :CUSTOM_ID: negativ-beispiel-dependency-rule + :END: +*** *Analyse der Schichten* + :PROPERTIES: + :CUSTOM_ID: analyse-der-schichten + :END: +[jeweils 1 Klasse zu 2 unterschiedlichen Schichten der +Clean-Architecture: jeweils UML der Klasse (ggf. auch zusammenspielenden +Klassen), Beschreibung der Aufgabe, Einordnung mit Begründung in die +Clean-Architecture] + +**** Schicht: [Name] + :PROPERTIES: + :CUSTOM_ID: schicht-name + :END: +**** Schicht: [Name] + :PROPERTIES: + :CUSTOM_ID: schicht-name-1 + :END: + +* Kapitel 3: SOLID + :PROPERTIES: + :CUSTOM_ID: kapitel-3-solid + :END: +*** Analyse Single-Responsibility-Principle (*SRP)* + :PROPERTIES: + :CUSTOM_ID: analyse-single-responsibility-principle-srp + :END: +[jeweils eine Klasse als positives und negatives Beispiel für SRP; +jeweils UML der Klasse und Beschreibung der Aufgabe bzw. der Aufgaben +und möglicher Lösungsweg des Negativ-Beispiels (inkl. UML)] + +**** Positiv-Beispiel + :PROPERTIES: + :CUSTOM_ID: positiv-beispiel + :END: +**** Negativ-Beispiel + :PROPERTIES: + :CUSTOM_ID: negativ-beispiel + :END: + +*** Analyse Open-Closed-Principle (OCP) + :PROPERTIES: + :CUSTOM_ID: analyse-open-closed-principle-ocp + :END: +[jeweils eine Klasse als positives und negatives Beispiel für OCP; +jeweils UML der Klasse und Analyse mit Begründung, warum das OCP +erfüllt/nicht erfüllt wurde -- falls erfüllt: warum hier +sinnvoll/welches Problem gab es? Falls nicht erfüllt: wie könnte man es +lösen (inkl. UML)?] + +**** Positiv-Beispiel + :PROPERTIES: + :CUSTOM_ID: positiv-beispiel-1 + :END: +**** Negativ-Beispiel + :PROPERTIES: + :CUSTOM_ID: negativ-beispiel-1 + :END: + +*** Analyse Liskov-Substitution- (LSP), Interface-Segreggation- (ISP), Dependency-Inversion-Principle (DIP) + :PROPERTIES: + :CUSTOM_ID: analyse-liskov-substitution--lsp-interface-segreggation--isp-dependency-inversion-principle-dip + :END: +[jeweils eine Klasse als positives und negatives Beispiel für entweder +LSP oder ISP oder DIP); jeweils UML der Klasse und Begründung, warum man +hier das Prinzip erfüllt/nicht erfüllt wird] + +[Anm.: es darf nur ein Prinzip ausgewählt werden; es darf NICHT z.B. ein +positives Beispiel für LSP und ein negatives Beispiel für ISP genommen +werden] + +**** Positiv-Beispiel + :PROPERTIES: + :CUSTOM_ID: positiv-beispiel-2 + :END: +**** Negativ-Beispiel + :PROPERTIES: + :CUSTOM_ID: negativ-beispiel-2 + :END: + +* Kapitel 4: Weitere Prinzipien + :PROPERTIES: + :CUSTOM_ID: kapitel-4-weitere-prinzipien + :END: +*** Analyse GRASP: Geringe Kopplung + :PROPERTIES: + :CUSTOM_ID: analyse-grasp-geringe-kopplung + :END: +[jeweils eine bis jetzt noch nicht behandelte Klasse als positives und +negatives Beispiel geringer Kopplung; jeweils UML Diagramm mit +zusammenspielenden Klassen, Aufgabenbeschreibung und Begründung für die +Umsetzung der geringen Kopplung bzw. Beschreibung, wie die Kopplung +aufgelöst werden kann] + +**** Positiv-Beispiel + :PROPERTIES: + :CUSTOM_ID: positiv-beispiel-3 + :END: +**** Negativ-Beispiel + :PROPERTIES: + :CUSTOM_ID: negativ-beispiel-3 + :END: + +*** Analyse GRASP: Hohe *Kohäsion* + :PROPERTIES: + :CUSTOM_ID: analyse-grasp-hohe-kohäsion + :END: +[eine Klasse als positives Beispiel hoher Kohäsion; UML Diagramm und +Begründung, warum die Kohäsion hoch ist] + +*** *Don't Repeat Yourself (DRY)* + :PROPERTIES: + :CUSTOM_ID: dont-repeat-yourself-dry + :END: +[ein Commit angeben, bei dem duplizierter Code/duplizierte Logik +aufgelöst wurde; Code-Beispiele (vorher/nachher); begründen und +Auswirkung beschreiben] + +* + :PROPERTIES: + :CUSTOM_ID: section-1 + :END: +* Kapitel 5: *Unit Tests* + :PROPERTIES: + :CUSTOM_ID: kapitel-5-unit-tests + :END: +*** 10 Unit Tests + :PROPERTIES: + :CUSTOM_ID: unit-tests + :END: +[Nennung von 10 Unit-Tests und Beschreibung, was getestet wird] + +| Unit Test | Beschreibung | +| Klasse#Methode | | +| | | +| | | +| | | +| | | +| | | +| | | +| | | +| | | +| | | + +*** ATRIP: Automatic + :PROPERTIES: + :CUSTOM_ID: atrip-automatic + :END: +[Begründung/Erläuterung, wie ‘Automatic' realisiert wurde] + +*** ATRIP: Thorough + :PROPERTIES: + :CUSTOM_ID: atrip-thorough + :END: +[jeweils 1 positives und negatives Beispiel zu ‘Thorough'; jeweils +Code-Beispiel, Analyse und Begründung, was professionell/nicht +professionell ist] + +*** ATRIP: Professional + :PROPERTIES: + :CUSTOM_ID: atrip-professional + :END: +[jeweils 1 positives und negatives Beispiel zu ‘Professional'; jeweils +Code-Beispiel, Analyse und Begründung, was professionell/nicht +professionell ist] + +*** Code Coverage + :PROPERTIES: + :CUSTOM_ID: code-coverage + :END: +[Code Coverage im Projekt analysieren und begründen] + +*** Fakes und Mocks + :PROPERTIES: + :CUSTOM_ID: fakes-und-mocks + :END: +[Analyse und Begründung des Einsatzes von 2 Fake/Mock-Objekten; +zusätzlich jeweils UML Diagramm der Klasse] + +* Kapitel 6: Domain Driven Design + :PROPERTIES: + :CUSTOM_ID: kapitel-6-domain-driven-design + :END: +*** Ubiquitous Language + :PROPERTIES: + :CUSTOM_ID: ubiquitous-language + :END: +[4 Beispiele für die Ubiquitous Language; jeweils Bezeichung, Bedeutung +und kurze Begründung, warum es zur Ubiquitous Language gehört] + +| Bezeichung | Bedeutung | Begründung | +| Link | | | +| Category | | | +| | | | +| | | | + +*** Entities + :PROPERTIES: + :CUSTOM_ID: entities + :END: +[UML, Beschreibung und Begründung des Einsatzes einer Entity; falls +keine Entity vorhanden: ausführliche Begründung, warum es keines geben +kann/hier nicht sinnvoll ist] + +*** Value Objects + :PROPERTIES: + :CUSTOM_ID: value-objects + :END: +/[UML, Beschreibung und Begründung des Einsatzes eines Value Objects; +falls kein Value Object vorhanden: ausführliche Begründung, warum es +keines geben kann/hier nicht sinnvoll ist]/ + +*** Repositories + :PROPERTIES: + :CUSTOM_ID: repositories + :END: +[UML, Beschreibung und Begründung des Einsatzes eines Repositories; +falls kein Repository vorhanden: ausführliche Begründung, warum es +keines geben kann/hier nicht sinnvoll ist] + +*** Aggregates + :PROPERTIES: + :CUSTOM_ID: aggregates + :END: +[UML, Beschreibung und Begründung des Einsatzes eines Aggregates; falls +kein Aggregate vorhanden: ausführliche Begründung, warum es keines geben +kann/hier nicht sinnvoll ist] + +* Kapitel 7: Refactoring + :PROPERTIES: + :CUSTOM_ID: kapitel-7-refactoring + :END: +*** Code Smells + :PROPERTIES: + :CUSTOM_ID: code-smells + :END: +/[jeweils 1 Code-Beispiel zu 2 Code Smells aus der Vorlesung; jeweils +Code-Beispiel und einen möglichen Lösungsweg bzw. den genommen +Lösungsweg beschreiben (inkl./ /(Pseudo-)Code)]/ + +*** 2 Refactorings + :PROPERTIES: + :CUSTOM_ID: refactorings + :END: +[2 unterschiedliche Refactorings aus der Vorlesung anwenden, begründen, +sowie UML vorher/nachher liefern; jeweils auf die Commits verweisen] + +* Kapitel 8: Entwurfsmuster + :PROPERTIES: + :CUSTOM_ID: kapitel-8-entwurfsmuster + :END: +/[2 unterschiedliche Entwurfsmuster aus der Vorlesung (oder nach +Absprache auch andere) jeweils sinnvoll einsetzen, begründen und +UML-Diagramm]/ + +*** Entwurfsmuster: [Name] + :PROPERTIES: + :CUSTOM_ID: entwurfsmuster-name + :END: +*** Entwurfsmuster: [Name] + :PROPERTIES: + :CUSTOM_ID: entwurfsmuster-name-1 + :END: