Compare commits

...

2 Commits

Author SHA1 Message Date
beefbfad29 a 2024-12-08 18:19:24 +01:00
eeb8580a31 a 2024-12-08 18:18:11 +01:00
12 changed files with 734 additions and 4982 deletions

3
.obsidian/app.json vendored
View File

@@ -6,5 +6,6 @@
"margin": "0",
"downscalePercent": 100
},
"alwaysUpdateLinks": true
"alwaysUpdateLinks": true,
"spellcheck": true
}

File diff suppressed because it is too large Load Diff

View File

@@ -4,42 +4,39 @@
"type": "split",
"children": [
{
"id": "49c46697a3151f3b",
"id": "1242ce1fca3b04dc",
"type": "tabs",
"children": [
{
"id": "8f0d65f1974eff73",
"id": "7d80a0ab440bdac7",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "WS2425/Data Science/VL/Zusammenfassung.md",
"file": "WS2425/Data Science/4/4.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "Zusammenfassung"
"title": "4"
}
}
]
},
{
"id": "575ada4754eaee23",
"type": "tabs",
"children": [
},
{
"id": "91af7024b9a5f7d4",
"id": "f8485cde20c4a56c",
"type": "leaf",
"state": {
"type": "pdf",
"type": "markdown",
"state": {
"file": "WS2425/Data Science/VL/lecture_09.pdf"
"file": "WS2425/SWT D/Ue6.md",
"mode": "preview",
"source": false
},
"icon": "lucide-file-text",
"title": "lecture_09"
"icon": "lucide-file",
"title": "Ue6"
}
}
]
],
"currentTab": 1
}
],
"direction": "vertical"
@@ -70,7 +67,7 @@
"state": {
"type": "search",
"state": {
"query": "path:\"WS2425/Data Science/\" ",
"query": "",
"matchingCase": false,
"explainSearch": false,
"collapseAll": false,
@@ -121,7 +118,7 @@
"state": {
"type": "backlink",
"state": {
"file": "WS2425/Data Science/VL/Zusammenfassung.md",
"file": "WS2425/Web Tech/Übung/4/uebung04.pdf",
"collapseAll": false,
"extraContext": false,
"sortOrder": "alphabetical",
@@ -131,7 +128,7 @@
"unlinkedCollapsed": true
},
"icon": "links-coming-in",
"title": "Backlinks for Zusammenfassung"
"title": "Backlinks for uebung04"
}
},
{
@@ -140,12 +137,12 @@
"state": {
"type": "outgoing-link",
"state": {
"file": "WS2425/Data Science/VL/Zusammenfassung.md",
"file": "WS2425/Web Tech/Übung/4/uebung04.pdf",
"linksCollapsed": false,
"unlinkedCollapsed": true
},
"icon": "links-going-out",
"title": "Outgoing links from Zusammenfassung"
"title": "Outgoing links from uebung04"
}
},
{
@@ -167,10 +164,10 @@
"state": {
"type": "outline",
"state": {
"file": "WS2425/Data Science/VL/Zusammenfassung.md"
"file": "WS2425/Web Tech/Übung/4/uebung04.pdf"
},
"icon": "lucide-list",
"title": "Outline of Zusammenfassung"
"title": "Outline of uebung04"
}
},
{
@@ -236,7 +233,6 @@
},
"left-ribbon": {
"hiddenItems": {
"omnisearch:Omnisearch": false,
"switcher:Open quick switcher": false,
"graph:Open graph view": false,
"canvas:Create new canvas": false,
@@ -251,37 +247,31 @@
"obsidian-livesync:Show log": false
}
},
"active": "8f0d65f1974eff73",
"active": "f8485cde20c4a56c",
"lastOpenFiles": [
"WS2425/Data Science/VL/lecture_09_notes.md",
"Pasted image 20241205235837.png",
"Pasted image 20241205235827.png",
"Pasted image 20241205235635.png",
"Pasted image 20241205235614.png",
"Pasted image 20241205235604.png",
"Pasted image 20241205235524.png",
"WS2425/Data Science/VL/lecture_09.pdf",
"WS2425/Data Science/VL/lecture_08_notes.md",
"WS2425/Data Science/VL/lecture_08_neu.pdf",
"Pasted image 20241205235403.png",
"Pasted image 20241205235347.png",
"Pasted image 20241205235322.png",
"Pasted image 20241205235306.png",
"WS2425/Data Science/VL/lecture_07.pdf",
"WS2425/Data Science/VL/lecture_07_notes.md",
"WS2425/Data Science/VL/lecture_08.pdf",
"WS2425/Data Science/VL/lecture_06.pdf",
"WS2425/Data Science/VL/Zusammenfassung.md",
"WS2425/Data Science/Ue_P/exercise_7/excercise_7.pdf",
"WS2425/Data Science/Ue_P/exercise_8/excercise_8.pdf",
"WS2425/Data Science/Ue_P/exercise_9/excercise_9.pdf",
"WS2425/Data Science/VL/lecture_02.pdf",
"WS2425/Data Science/VL/lecture_01.pdf",
"WS2425/SWT D/Ue6.md",
"WS2425/Web Tech/Übung/4/uebung04.pdf",
"WS2425/Web Tech/Übung/4/Ü4.md",
"Pasted image 20241029134825.png",
"Pasted image 20241029134619.png",
"Pasted image 20241029134346.png",
"WS2425/Web Tech/Übung/3/ü3.md",
"WS2425/Web Tech/Übung/4",
"WS2425/SWT D/P3.md",
"WS2425/SWT D/Ue3.md",
"WS2425/Data Science/4/4.md",
"WS2425/Data Science/4",
"WS2425/Data Science",
"WS2425/Web Tech/Übung/2/Ü2.md",
"WS2425/Web Tech/Übung/3",
"WS2425/SWT D/P2.md",
"WS2425/SWT D/swtd-p-02.pdf",
"WS2425/SWT D/swtd-ue-02.pdf",
"WS2425/SWT D/Ue 2.md",
"WS2425/Web Tech/Praktikum/Untitled.md",
"WS2425/SWT D",
"WS2425/Web Tech/Übung/1/uebung01.pdf",
"WS2425/Web Tech/Praktikum",
"WS2425/Web Tech/Übung/1/Ü1.md",
"SS24/TdS/Canvas.canvas",
"SS24/SWT2/KW19/KW19.md",
@@ -299,6 +289,13 @@
"README.md",
"Untitled.md",
"IHK/Probeklausur/Klausur Winter 2020-2021.md",
"IHK/Rechenaufgaben/Rechenaufgaben.md"
"IHK/Rechenaufgaben/Rechenaufgaben.md",
"IHK/Selbsttest/img/Element1.png",
"IHK/Probeklausur/blobid1673287222977.png",
"IHK/Probeklausur/blobid1673287138447.png",
"IHK/Probeklausur/blobid1673287064541.png",
"IHK/Probeklausur/blobid1673286850637.png",
"IHK/Probeklausur/blobid1673286771726.png",
"IHK/Probeklausur/blobid1673286238586.png"
]
}

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.6 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

117
WS2425/Data Science/4/4.md Normal file
View File

@@ -0,0 +1,117 @@
To pseudonymize the "name" values in the given dataset using the specified hash function, let's follow these steps:
1. **Convert each character in the name to its alphabetic position using the `alph` function**, where:
- `A = 1`, `B = 2`, `C = 3`, and so on, up to `Z = 26`.
2. **Compute the hash value** using the formula:
3. $$
h(s) = \sum_{i} \text{alph}(s_i) \mod 13
$$
where \( s_i \) is the \( i \)-th character in the string.
3. **Add a salt** to the hash value. The salt is a random value that is combined with the hash to make it more secure.
Let's apply these steps to each name in the dataset.
### Step-by-Step Calculation
For each name, we'll calculate the hash value before adding a salt.
#### 1. Name: Franz
- `F = 6`, `R = 18`, `A = 1`, `N = 14`, `Z = 26`
- Sum of positions: \( 6 + 18 + 1 + 14 + 26 = 65 \)
- Hash: \( 65 \mod 13 = 0 \)
#### 2. Name: Antje
- `A = 1`, `N = 14`, `T = 20`, `J = 10`, `E = 5`
- Sum of positions: \( 1 + 14 + 20 + 10 + 5 = 50 \)
- Hash: \( 50 \mod 13 = 11 \)
#### 3. Name: Alex
- `A = 1`, `L = 12`, `E = 5`, `X = 24`
- Sum of positions: \( 1 + 12 + 5 + 24 = 42 \)
- Hash: \( 42 \mod 13 = 3 \)
### Pseudonymized Dataset with Hash Values
We can now add the calculated hash values to the dataset. We'll also mention that a salt should be added to these hash values for increased security in a real implementation:
| Original Name | Height | Shoe Size | Hash Value (no salt) |
|---------------|--------|-----------|---------------------|
| Franz | 165 | 40 | 0 |
| Antje | 170 | 39 | 11 |
| Alex | 174 | 42 | 3 |
To finalize the pseudonymization process, a random salt should be combined with these hash values, ensuring that even if two identical names are processed, they won't result in the same pseudonymized value.
Let's go through the steps for this exercise.
### Given Data
The weights of the luggage are:
```
22, 44, 11, 19, 21, 17, 17, 11, 11, 19, 22, 17
```
### Categories:
- **Light**: less than 15 kg
- **Normal**: between 15 and 20 kg
- **Overweight**: more than 20 kg
### Part (a): Absolute and Relative Frequencies
#### Step 1: Categorize the weights
We will count how many weights fall into each category.
| Category | Weight Values | Frequency (Absolute) |
|------------|--------------------------------------------|---------------------|
| Light | 11, 11, 11 | 3 |
| Normal | 19, 17, 17, 17, 19 | 5 |
| Overweight | 22, 44, 21, 22 | 4 |
#### Step 2: Calculate Relative Frequencies
Relative frequency is calculated as:
$$
\text{Relative Frequency} = \frac{\text{Absolute Frequency}}{\text{Total Number of Weights}}
$$
Total number of weights = 12
| Category | Absolute Frequency | Relative Frequency |
|------------|--------------------|-------------------|
| Light | 3 | \( \frac{3}{12} = 0.25 \) or 25% |
| Normal | 5 | \( \frac{5}{12} \approx 0.42 \) or 42% |
| Overweight | 4 | \( \frac{4}{12} \approx 0.33 \) or 33% |
### Part (b): Empirical Distribution Function and Question
The empirical distribution function (EDF) represents the cumulative frequency of the dataset.
Let's arrange the weights in increasing order:
```
11, 11, 11, 17, 17, 17, 19, 19, 21, 22, 22, 44
```
The EDF for these weights can be expressed as:
- Less than or equal to 11 kg: 3/12 = 0.25
- Less than or equal to 17 kg: 6/12 = 0.5
- Less than or equal to 19 kg: 8/12 = 0.67
- Less than or equal to 21 kg: 9/12 = 0.75
- Less than or equal to 22 kg: 11/12 = 0.92
- Less than or equal to 44 kg: 12/12 = 1
#### Question: What is the proportion of weights that are less than 18 kg or more than 23 kg?
- **Weights less than 18 kg:** 6 out of 12 = \( \frac{6}{12} = 0.5 \) or 50%
- **Weights more than 23 kg:** 1 out of 12 = \( \frac{1}{12} \approx 0.08 \) or 8%
Proportion of weights that are less than 18 kg or more than 23 kg:
$$
0.5 + 0.08 = 0.58 \text{ or 58%}
$$
### Visualization: Bar Chart and Histogram
Now, let's create a bar chart and histogram for the weight categories. I will generate these charts using the data provided.
<meta http-equiv="content-type" content="text/html; charset=utf-8"><img class="my-1 max-h-full max-w-full" alt="Output image" src="https://files.oaiusercontent.com/file-1NLAbWjJbRoIpOpkPlGyFDgJ?se=2024-10-14T09%3A24%3A00Z&amp;sp=r&amp;sv=2024-08-04&amp;sr=b&amp;rscc=max-age%3D299%2C%20immutable%2C%20private&amp;rscd=attachment%3B%20filename%3Defbc9b60-7fa3-4779-8424-e1161ace057d&amp;sig=L/65MC847FN1r7DOH9Y4zLV9NIiqPFMxLg8iAfU3LGU%3D">
<meta http-equiv="content-type" content="text/html; charset=utf-8"><img class="my-1 max-h-full max-w-full" alt="Output image" src="https://files.oaiusercontent.com/file-X3OdJTHxHl2hGw2cSgzDuKum?se=2024-10-14T09%3A24%3A00Z&amp;sp=r&amp;sv=2024-08-04&amp;sr=b&amp;rscc=max-age%3D299%2C%20immutable%2C%20private&amp;rscd=attachment%3B%20filename%3Dcf1e314c-a836-410f-a4c0-5ff900ff9d6e&amp;sig=p6mA9gHjDbY2VcS/6nAqcBCs7BCJpJ93vcRs/1ryKVs%3D">
The bar chart displays the absolute frequencies of each weight category, while the histogram shows the distribution of luggage weights according to the defined categories (light, normal, and overweight).
These visualizations help in understanding how the weights are distributed across the categories.

60
WS2425/SWT D/P3.md Normal file
View File

@@ -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.

34
WS2425/SWT D/Ue3.md Normal file
View File

@@ -0,0 +1,34 @@
Die Wahl einer geeigneten Programmiersprache ist ein wichtiger Schritt zur Sicherstellung der Qualität eines Softwareprojekts. Im Folgenden werden die genannten Aspekte erläutert, die bei der Auswahl einer Programmiersprache berücksichtigt werden sollten:
### 1. **Strukturelemente zur Konstruktion modularer Programmeinheiten**
- **Einfluss auf die Wahl der Programmiersprache:** Die Möglichkeit, Programme in modularen Einheiten (wie Funktionen, Klassen oder Modulen) zu strukturieren, ist entscheidend für die Wartbarkeit und Wiederverwendbarkeit des Codes. Sprachen, die diese Modularität unterstützen, ermöglichen es Entwicklern, Code in kleinere, wiederverwendbare Bausteine zu zerlegen.
- **Einfluss auf die Qualität:** Modularer Code ist leichter zu verstehen, zu testen und zu warten. Er fördert auch eine saubere Trennung der Verantwortlichkeiten im Code.
- **Beispiele:** Programmiersprachen wie **Java** und **Python** unterstützen Konzepte wie Klassen, Module und Pakete, die zur modularen Strukturierung beitragen.
### 2. **Typsystem mit strenger Typprüfung**
- **Einfluss auf die Wahl der Programmiersprache:** Ein strenges Typsystem hilft dabei, Fehler frühzeitig während der Kompilierungsphase zu erkennen, bevor der Code ausgeführt wird. Sprachen mit statischer Typisierung ermöglichen es, viele Fehler zu verhindern, die sonst zur Laufzeit auftreten könnten.
- **Einfluss auf die Qualität:** Eine strenge Typprüfung erhöht die Zuverlässigkeit des Codes und reduziert das Risiko von Laufzeitfehlern. Sie verbessert auch die Lesbarkeit und Dokumentation des Codes, da der Datentyp explizit definiert ist.
- **Beispiele:** **C++** und **Java** sind Beispiele für Programmiersprachen mit einem starken, statischen Typsystem. Im Gegensatz dazu ist **Python** dynamisch typisiert, was flexibler ist, aber mehr Laufzeitfehler verursachen kann.
### 3. **Trennung von Schnittstelle und Implementierung**
- **Einfluss auf die Wahl der Programmiersprache:** Eine klare Trennung von Schnittstelle (was der Code tut) und Implementierung (wie er es tut) ermöglicht eine einfachere Wartung und Anpassung des Codes. Dies ist besonders wichtig bei der Entwicklung großer Softwaresysteme.
- **Einfluss auf die Qualität:** Durch diese Trennung können Entwickler Änderungen an der Implementierung vornehmen, ohne die Schnittstelle zu ändern, was die Kompatibilität mit anderen Modulen bewahrt.
- **Beispiele:** In **Java** können Interfaces verwendet werden, um Schnittstellen zu definieren, während die Implementierung in Klassen erfolgt. **C++** verwendet Header-Dateien für die Deklaration und Implementierungsdateien für die Definition.
### 4. **Syntax, die zur Lesbarkeit des Codes beiträgt**
- **Einfluss auf die Wahl der Programmiersprache:** Eine klare und einfache Syntax verbessert die Lesbarkeit des Codes, was wiederum die Fehleranfälligkeit reduziert und die Zusammenarbeit im Team erleichtert.
- **Einfluss auf die Qualität:** Gut lesbarer Code ist leichter zu verstehen und zu warten, insbesondere wenn mehrere Entwickler an einem Projekt arbeiten.
- **Beispiele:** **Python** ist für seine einfache und klare Syntax bekannt, die der Lesbarkeit sehr zugutekommt. Im Gegensatz dazu kann **Perl** durch seine flexiblere, aber auch komplexere Syntax schwerer lesbar sein.
### 5. **Automatische Zeigerverwaltung**
- **Einfluss auf die Wahl der Programmiersprache:** Die automatische Speicherverwaltung, wie sie durch Garbage Collection bereitgestellt wird, hilft, Speicherlecks und andere Speicherverwaltungsprobleme zu vermeiden.
- **Einfluss auf die Qualität:** Durch die automatische Verwaltung von Speicherressourcen wird die Anzahl der Speicherverwaltungsfehler reduziert, was die Zuverlässigkeit und Stabilität der Software erhöht.
- **Beispiele:** **Java** und **Python** haben automatische Garbage Collection, während **C++** eine manuelle Speicherverwaltung erfordert, was mehr Flexibilität bietet, aber auch fehleranfälliger ist.
### 6. **Gute Unterstützung durch Werkzeuge**
- **Einfluss auf die Wahl der Programmiersprache:** Eine breite Unterstützung durch Entwicklungswerkzeuge wie IDEs, Debugger, und statische Analysewerkzeuge erleichtert die Entwicklung und das Debugging des Codes.
- **Einfluss auf die Qualität:** Durch leistungsfähige Werkzeuge können Entwickler effizienter arbeiten, Fehler schneller finden und beheben sowie die Qualität des Codes durch automatisierte Tests und Code-Analysen verbessern.
- **Beispiele:** **Java** hat eine starke Unterstützung durch Entwicklungsumgebungen wie IntelliJ IDEA und Eclipse. Für **Python** gibt es ebenfalls viele Werkzeuge wie PyCharm und Visual Studio Code.
### Zusammenfassung
Die Wahl der Programmiersprache kann einen erheblichen Einfluss auf die Qualität der Software haben. Kriterien wie Modularität, Typprüfung, Trennung von Schnittstelle und Implementierung, lesbare Syntax, automatische Speicherverwaltung und Unterstützung durch Werkzeuge tragen zur Wartbarkeit, Erweiterbarkeit und Zuverlässigkeit des Codes bei. Durch die sorgfältige Berücksichtigung dieser Aspekte können Entwickler die Sprachwahl so treffen, dass sie die langfristige Qualität und Effizienz der Softwareentwicklung fördern.

63
WS2425/SWT D/Ue6.md Normal file
View File

@@ -0,0 +1,63 @@
Um die Queue zu testen, beschreiben wir verschiedene Testfälle. Bei einer Arraylänge von 3 können wir den Speicherplatz optimal nutzen, indem wir das Verhalten des Ringspeichers in verschiedenen Zuständen der Queue (voll, leer, teilweise gefüllt) prüfen. Wir definieren die Eingaben, die erwarteten Rückgabewerte sowie den logischen Zustand des Arrays für jeden Testfall.
### Testfälle
1. **Testfall 1: Enqueue in eine leere Queue**
- **Aktion:** `enqueue(1)`
- **Erwartetes Ergebnis:** Keine Rückgabe.
- **Array-Zustand:** `[1, -, -]`
2. **Testfall 2: Zweiter Wert wird hinzugefügt**
- **Aktion:** `enqueue(2)`
- **Erwartetes Ergebnis:** Keine Rückgabe.
- **Array-Zustand:** `[1, 2, -]`
3. **Testfall 3: Dritter Wert wird hinzugefügt (Queue voll)**
- **Aktion:** `enqueue(3)`
- **Erwartetes Ergebnis:** Keine Rückgabe.
- **Array-Zustand:** `[1, 2, 3]`
4. **Testfall 4: Dequeue von voller Queue**
- **Aktion:** `dequeue()`
- **Erwarteter Rückgabewert:** `1`
- **Array-Zustand:** `[-, 2, 3]`
5. **Testfall 5: Enqueue bei fast voller Queue**
- **Aktion:** `enqueue(4)`
- **Erwartetes Ergebnis:** Keine Rückgabe.
- **Array-Zustand:** `[4, 2, 3]` (da das Array als Ring organisiert ist, wird 4 am Anfang gespeichert)
6. **Testfall 6: Dequeue**
- **Aktion:** `dequeue()`
- **Erwarteter Rückgabewert:** `2`
- **Array-Zustand:** `[4, -, 3]`
7. **Testfall 7: Enqueue, um die Queue zu füllen**
- **Aktion:** `enqueue(5)`
- **Erwartetes Ergebnis:** Keine Rückgabe.
- **Array-Zustand:** `[4, 5, 3]`
8. **Testfall 8: Enqueue, das Überschreiben auslöst**
- **Aktion:** `enqueue(6)`
- **Erwartetes Ergebnis:** Keine Rückgabe.
- **Array-Zustand:** `[4, 5, 6]` (ältester Wert `3` wurde überschrieben)
9. **Testfall 9: Dequeue nach Überschreiben**
- **Aktion:** `dequeue()`
- **Erwarteter Rückgabewert:** `4`
- **Array-Zustand:** `[-, 5, 6]`
10. **Testfall 10: Weiteres Dequeue**
- **Aktion:** `dequeue()`
- **Erwarteter Rückgabewert:** `5`
- **Array-Zustand:** `[-, -, 6]`
11. **Testfall 11: Letztes Dequeue zum Leeren der Queue**
- **Aktion:** `dequeue()`
- **Erwarteter Rückgabewert:** `6`
- **Array-Zustand:** `[-, -, -]` (Queue ist jetzt leer)
12. **Testfall 12: Dequeue von leerer Queue**
- **Aktion:** `dequeue()`
- **Erwartetes Ergebnis:** Fehler wird signalisiert, da die Queue leer ist.

Binary file not shown.

View File

@@ -0,0 +1,67 @@
# 1
In diesem Beispiel wird die Darstellung im Browser durch verschiedene CSS-Definitionen beeinflusst, die für das `<h2>`-Element festgelegt sind.
### Analyse der Hierarchie:
1. **Externe CSS-Datei (`style.css`)**: Diese definiert `h2 { background-color: red; }`, was für alle `<h2>`-Überschriften den Hintergrund rot setzt.
2. **Interne CSS-Definition im `<style>`-Tag**: Die interne CSS-Regel `h2 { background-color: yellow; }` überschreibt die externe Definition, da sie im Dokument direkt eingebunden ist und eine höhere Priorität hat.
3. **Inline-Styling auf dem ersten `<h2>`-Tag**: Im `<h2>`-Tag für „Erste Überschrift“ wird direkt `style="background-color: blue;"` definiert. Da Inline-Styling die höchste Priorität besitzt, wird der Hintergrund dieses Elements blau.
### Darstellung im Browser:
- **Erste Überschrift** (`<h2 style="background-color: blue;">Erste Überschrift</h2>`): Der Hintergrund wird **blau** angezeigt, da das Inline-Styling die höchste Priorität hat.
- **Zweite Überschrift** (`<h2>Zweite Überschrift</h2>`): Der Hintergrund wird **gelb** angezeigt, da die Definition aus dem internen `<style>`-Tag (gelb) die externe CSS-Datei (`style.css`, rot) überschreibt.
### Ergebnis:
Die erste Überschrift erscheint mit blauem Hintergrund, und die zweite Überschrift erscheint mit gelbem Hintergrund.
![[Pasted image 20241029134346.png]]
# 2
Hier ist die Analyse des CSS- und HTML-Codes und wie sie sich auf die Darstellung der Seite im Browser auswirken:
### CSS-Regeln und ihre Auswirkungen
1. **Regel 1: `h1 { color: red; }`**
- Setzt die Textfarbe aller `<h1>`-Elemente auf **rot**.
- Im Browser wird der Text „Cascading Stylesheets“ in der `<h1>`-Überschrift rot dargestellt.
2. **Regel 2: `h1, h2 { text-transform: uppercase; }`**
- Setzt den Textinhalt aller `<h1>`- und `<h2>`-Elemente in **Großbuchstaben**.
- Im Browser erscheinen die Texte der `<h1>`- und `<h2>`-Elemente („Cascading Stylesheets“, „Einleitung“ und „Syntax“) komplett in Großbuchstaben.
3. **Regel 3: `h1 h2 { text-transform: lowercase; }`**
- Diese Regel versucht, `<h2>`-Elemente innerhalb von `<h1>`-Elementen in **Kleinbuchstaben** darzustellen. Da es jedoch kein `<h2>`-Element innerhalb eines `<h1>`-Elements gibt, hat diese Regel **keine sichtbare Wirkung**.
4. **Regel 4: `.hinweis { background-color: lightblue; }`**
- Setzt den Hintergrund aller Elemente mit der Klasse `.hinweis` auf **hellblau**.
- Im Browser erscheinen die `<div>`-Elemente mit der Klasse `hinweis` („Hinweis: Damit unterstützt CSS …“ und „Hinweis: Deklarationen …“) mit einem hellblauen Hintergrund.
5. **Regel 5: `#hinweis { background-color: red; }`**
- Setzt den Hintergrund des Elements mit der ID `hinweis` auf **rot**. Da es jedoch kein Element mit der ID `hinweis` gibt, hat diese Regel **keine sichtbare Wirkung**.
6. **Regel 6: `a[href^="#"] { color: green; }`**
- Setzt die Textfarbe von Links, deren `href`-Attribut mit `#` beginnt, auf **grün**.
- Die Links im `<nav>`-Element (mit `href="#einleitung"` und `href="#syntax"`) werden daher im Browser grün dargestellt.
7. **Regel 7: `nav a:hover { background-color: green; color: white; }`**
- Verändert die Darstellung von Links im `<nav>`-Element, wenn der Mauszeiger über ihnen schwebt. Der Hintergrund wird **grün** und die Schriftfarbe **weiß**.
- Im Browser werden die Links im `<nav>`-Element beim Hover grün mit weißem Text dargestellt.
8. **Regel 8: `*[id] { font-style: italic; }`**
- Setzt alle Elemente mit einem `id`-Attribut kursiv.
- Die `<section>`-Elemente mit den IDs `einleitung` und `syntax` sowie deren Inhalte werden daher **kursiv** dargestellt.
### Darstellung im Browser
Zusammengefasst wird Folgendes dargestellt:
- **"Cascading Stylesheets"** als `<h1>`-Überschrift in **rot** und **Großbuchstaben**.
- **"Einleitung"** und **"Syntax"** als `<h2>`-Überschriften in **Großbuchstaben**.
- **Links im `<nav>`-Element** in **grün** und bei Hover mit grünem Hintergrund und weißem Text.
- **Text innerhalb der `.hinweis`-Divs** in einem **hellblauen** Hintergrund.
- **Abschnitte mit IDs** (`einleitung`, `syntax`) sind kursiv aufgrund von Regel 8.
![[Pasted image 20241029134619.png]]
![[Pasted image 20241029134825.png]]
# 3