This commit is contained in:
parent
07f0e11428
commit
c1852b8bac
11
Documentation/cli-parameter-mapping.org
Normal file
11
Documentation/cli-parameter-mapping.org
Normal file
|
@ -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
|
371
Documentation/programmEntwurf.org
Normal file
371
Documentation/programmEntwurf.org
Normal file
|
@ -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:
|
Reference in a new issue