This commit is contained in:
2024-12-08 18:18:11 +01:00
parent 27b50b6b08
commit eeb8580a31
13 changed files with 833 additions and 58 deletions

3
.obsidian/app.json vendored
View File

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

View File

@@ -1,21 +1,31 @@
[
"file-explorer",
"global-search",
"switcher",
"graph",
"backlink",
"canvas",
"outgoing-link",
"tag-pane",
"properties",
"page-preview",
"daily-notes",
"templates",
"note-composer",
"command-palette",
"editor-status",
"bookmarks",
"outline",
"word-count",
"file-recovery"
]
{
"file-explorer": true,
"global-search": true,
"switcher": true,
"graph": true,
"backlink": true,
"canvas": true,
"outgoing-link": true,
"tag-pane": true,
"page-preview": true,
"daily-notes": true,
"templates": true,
"note-composer": true,
"command-palette": true,
"slash-command": false,
"editor-status": true,
"starred": true,
"markdown-importer": false,
"zk-prefixer": false,
"random-note": false,
"outline": true,
"word-count": true,
"slides": false,
"audio-recorder": false,
"workspaces": false,
"file-recovery": true,
"publish": false,
"sync": false,
"bookmarks": true,
"properties": true
}

View File

@@ -5725,6 +5725,11 @@ Projektdokumentation
Projektstatus
Protokolldateien
Projektteam
Pseudonymized
Proportion
Pfade
Projekten
ParentTree
obj
oV
oYj
@@ -11360,6 +11365,8 @@ oraI
ofRs
oOfh
offene
overweight
ofSd
Length
LCw
LN
@@ -16950,6 +16957,9 @@ Layer
LeJv
Leistungsfähigkeit
Logs
Less
Laden
Logik
Filter
FlateDecode
Ff
@@ -22743,6 +22753,12 @@ Fehlerbehebung
FRUu
Fehlerberichte
Fortschritt
Franz
Frequencies
Funktionalitäten
Fehlende
Fazit
Folgendes
stream
se
sH
@@ -28793,6 +28809,24 @@ spzO
sinnvoll
starts
string
steps
salt
secure
shows
strukturieren
schwache
steuern
signifikante
standardmäßige
serielle
starke
separat
spezialisiert
stärkere
saH
setzt
sichtbare
schwebt
ZKs
ZN
Zf
@@ -34667,6 +34701,11 @@ Zugriffsrechte
Zentrales
Zusammenfassung
Zwecks
Ziffer
Ziffern
Zusammenhalt
Zweite
Zusammengefasst
Who
We
WE
@@ -40814,6 +40853,15 @@ WebExplorer
Werkzeug
Wartungsphase
Wann
Wortes
Weight
Weights
Wiederverwendbarkeit
Während
WzoS
WEuWU
WbIS
Wirkung
KI
Kt
KF
@@ -46986,6 +47034,11 @@ Konfigurationsinformationen
Kommunikationsstrategie
Kollaborationsplattformen
Kurze
Kleinbuchstaben
Kopplung
Kriterium
Kontexten
KNSwG
bq
bQ
bG
@@ -52816,6 +52869,17 @@ besprochen
bereitstellen
bPds
bekannten
bewerten
beachtet
besser
bezogene
bessere
bhOelC
bYF
bme
blau
blauem
beginnt
iZ
ig
iA
@@ -58842,6 +58906,14 @@ iioT
inklusive
integrieren
iPOqgn
implementation
identical
interne
isoliert
integriert
interfaces
internen
ihnen
GJe
GAG
GJ
@@ -64626,6 +64698,14 @@ GHhv
GLFLB
GeFH
Gruppierung
Großbuchstaben
Gültige
Given
Grundzügen
Getter
Grad
Geschäftslogik
GAAAAA
AO
Aw
Az
@@ -70839,6 +70919,15 @@ Artefakttypen
Artefakt
Autor
Archiviert
Ausdruck
Antje
Alex
Absolute
Attribute
Außenwelt
AEBP
Attribut
Abschnitte
QV
Qom
QJ
@@ -76919,6 +77008,9 @@ QnpY
Qualitätsziele
Quellcode
Qualität
Question
Qualitätskriterien
QBzH
nQC
nq
nR
@@ -82747,6 +82839,11 @@ nPqE
notwendig
nachvollziehbar
namespace
names
nacheinander
nachteilig
node
nAml
YJ
Yb
YwM
@@ -88632,6 +88729,9 @@ YmzL
YvA
YsKc
YYQX
YsBb
YSVV
YGKj
UIQ
Ue
UH
@@ -95140,6 +95240,12 @@ UvSWM
UBqu
Unerfahrener
Umwandeln
Ungültige
Umgebungen
Unabhängigkeit
Unit
Ungetestete
UPVd
TZ
TF
TP
@@ -101167,6 +101273,12 @@ Testberichte
Testphase
Teammitglieder
Tags
Testbarkeit
Teilen
TvDz
Textfarbe
Textinhalt
Texte
gO
gHoVo
gD
@@ -106957,6 +107069,21 @@ geschriebene
gruppiert
gearbeitet
gute
gültigen
generate
genannten
gekoppelt
gewissen
gekoppelte
generische
generischere
gering
gnXa
gnkkk
gelb
gelbem
grün
grünem
DMg
Dv
DLg
@@ -112700,6 +112827,23 @@ Doxygen
Darstellungen
Designphase
Dokumentenverwaltung
Danach
Dataset
Distribution
Derzeit
Datenpersistenz
Datenverarbeitung
Datenverwaltung
Datenbankverwaltung
Dennoch
Dateispeicherung
Datei
Dateipfade
Datenverwaltungslösungen
Designentscheidungen
Definitionen
Deklarationen
Divs
xU
xM
xK
@@ -118312,6 +118456,8 @@ xMwx
xtEt
xTG
xEe
xlBj
xRIG
Hx
HV
HdH
@@ -123739,6 +123885,14 @@ Hälfte
Hna
Handbücher
Historie
Histogram
Hierarchisierung
Hiding
Hauptklasse
HUzW
HJXV
Hierarchie
Hover
zo
zL
zE
@@ -135325,6 +135479,19 @@ hAsj
hYfA
hmik
hierarchically
handeln
histogram
http
html
hierarchische
helfen
hohen
harte
hindert
hFzD
hrRc
hellblau
hellblauen
pt
ps
pao
@@ -141017,6 +141184,17 @@ physische
pIqp
paoz
prüfen
pseudonymize
position
positions
pseudonymization
processed
pseudonymized
proportion
provided
prinzipiell
plattformabhängig
plattformunabhängigen
Ic
IT
Ir
@@ -146857,6 +147035,13 @@ Installationsanweisungen
Implementierungsphase
Interne
Inhalts
Implementierung
Interfaces
Implementierungsdetails
Insgesamt
IRAHuGP
IDTree
Inline
ap
aE
at
@@ -152604,6 +152789,19 @@ accessible
autonomous
attribute
after
abdeckt
alphabetic
adding
added
approx
arrange
absolute
across
ausschließlich
anpassen
anstelle
awht
aqbo
fb
fVVvD
fh
@@ -158440,6 +158638,18 @@ fdEM
formuliert
funktionalen
früheren
function
follow
finalize
fall
frequency
frac
full
frequencies
flach
flexiblere
fehlen
fNiKo
Bs
ByJ
BF
@@ -163902,6 +164112,16 @@ Budgetpläne
Bearbeitung
Bezeichner
Beziehung
Buchverwaltung
BuchV
Beziehungen
Buch
Buchlogik
Benutzeroberfläche
Benutzerinteraktionen
BvWK
Bps
BNyuu
ek
eP
eVPm
@@ -170136,6 +170356,22 @@ elhL
effektiv
element
elements
erfassen
exercise
empirical
expressed
equiv
erreicht
erhebliche
einzeln
erläutern
einschränken
erheblich
erweitern
einschränkt
eingebunden
erscheint
erscheinen
tj
tg
tt
@@ -176199,6 +176435,10 @@ tFogT
theoretischer
tragen
tatsächlich
transportieren
tBZGu
tPk
tAlT
JFRO
JG
JL
@@ -181908,6 +182148,8 @@ JaYK
Jenkins
JIRA
JUnit
JEux
JHV
kXW
kW
kp
@@ -188010,6 +188252,14 @@ kemX
kCrY
kyCh
klare
klarere
klar
khze
kfKn
kUiV
kWjW
komplett
kursiv
EU
Evq
Er
@@ -194060,6 +194310,18 @@ Entwicklungsphase
Erstellungsdatum
Entwurf
Each
Erklärungen
Empirical
Erweiterbarkeit
Environment
Engpass
EUNa
EOXt
EAAAAA
Erste
Elements
Einleitung
Elementen
lX
ll
lC
@@ -200017,6 +200279,9 @@ lOcG
lfaA
lhDU
least
luggage
light
lJE
wG
wd
ws
@@ -206237,6 +206502,14 @@ wALzE
whC
wAUF
whose
weights
weight
weitgehend
würde
wiederverwendet
wiederverwendbar
weiß
weißem
RmZh
Rp
RJ
@@ -212106,6 +212379,11 @@ Relic
Rollen
Repository
Rückverfolgung
Regulärer
Relative
Runtime
ReyZ
Regel
vJ
vS
vKDF
@@ -218131,6 +218409,13 @@ versioniert
vermeiden
vorgenommen
versionierende
vorkommen
visualizations
verbessert
verbessern
verborgen
verwoben
versucht
XE
Xd
XRb
@@ -223581,6 +223866,7 @@ XfcL
XBXOGW
Xlja
XJEEQ
XkJU
NW
Ni
Nj
@@ -229530,6 +229816,9 @@ Nachvollziehen
Nagios
NLaH
NbAG
NCj
NnA
NonStruct
jhpK
jb
jl
@@ -235768,6 +236057,9 @@ jzcB
jxjO
jdDYv
jBMt
jedem
jDWD
jiii
My
Mm
MO
@@ -241888,6 +242180,14 @@ Modulen
Missverständnisse
Manuell
Maschinell
Modularisierung
Modularität
Mangel
Mock
MZyu
MvHi
MmKC
Mauszeiger
qO
qj
qG
@@ -247743,6 +248043,7 @@ qCalL
qfgAd
qblx
qRzb
qAfbW
yB
yyNs
yQU
@@ -253530,6 +253831,9 @@ yNpJ
yNSA
ylWH
yQOA
yrZvH
yCRk
yDCq
ulC
uk
un
@@ -259608,6 +259912,14 @@ uSNU
unterschiedlicher
unbefugte
untersuchen
ungültige
ungültigen
understanding
unterteilt
unklaren
unterstützt
ungewollte
urmc
ma
ml
mB
@@ -265812,6 +266124,12 @@ mhhp
mrFW
mitgeteilt
must
möglicher
markieren
mention
müssten
mangelnde
mmoQ
dg
dw
de
@@ -271846,6 +272164,13 @@ dokumentiert
detaillierte
durchgeführten
dokumentieren
dataset
distribution
displays
defined
distributed
durchgehen
dlwm
VV
VA
Vsm
@@ -277919,6 +278244,12 @@ Versionierung
Vergleich
Verlaufsprotokoll
Versionsnummer
Values
Visualization
Vererbung
Verantwortlichkeiten
Verbesserungspotenziale
VomR
SGN
Sg
SrEHO
@@ -283994,6 +284325,17 @@ Softwareversion
Sinn
Stände
Status
Step
Shoe
Speichern
Starker
Setter
Schreiben
SSSK
SBTg
Styling
Setzt
Schriftfarbe
rn
rE
rD
@@ -290093,6 +290435,15 @@ rAyj
regelt
relevanten
reibungslosen
regulären
regulärer
random
real
represents
rgEw
rpgq
rUhH
rqQc
Cu
CL
Ch
@@ -295413,6 +295764,14 @@ COjh
Compiler
Confluence
CfgS
Convert
Compute
Calculation
Categories
Categorize
Category
Calculate
Cascading
OM
OWR
Os
@@ -301307,6 +301666,11 @@ ONGSU
Oqfn
OnnPQA
Operationsarten
Optional
Original
Overweight
Obwohl
OFWv
cgl
cj
content
@@ -307338,6 +307702,17 @@ cZNs
curl
custom
contains
combined
calculated
count
category
cumulative
create
chart
categories
charts
charset
cwdg
öUS
öG
öd
@@ -307557,6 +307932,9 @@ contains
Übersetzt
Überwachen
Überarbeitung
Überlastung
Überschriften
Überschrift
Äd
ÄY
Äquivalenz
@@ -307852,6 +308230,8 @@ contains
ühv
üCb
üd
übernimmt
überschreibt
ßc
ßI
ßVq

View File

@@ -4,22 +4,39 @@
"type": "split",
"children": [
{
"id": "49c46697a3151f3b",
"id": "1242ce1fca3b04dc",
"type": "tabs",
"children": [
{
"id": "8f0d65f1974eff73",
"id": "7d80a0ab440bdac7",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "WS2425/Web Tech/Übung/3/ü3.md",
"file": "WS2425/Data Science/4/4.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "4"
}
},
{
"id": "f8485cde20c4a56c",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "WS2425/SWT D/Ue6.md",
"mode": "preview",
"source": false
}
},
"icon": "lucide-file",
"title": "Ue6"
}
}
]
],
"currentTab": 1
}
],
"direction": "vertical"
@@ -39,7 +56,9 @@
"type": "file-explorer",
"state": {
"sortOrder": "alphabetical"
}
},
"icon": "lucide-folder-closed",
"title": "Files"
}
},
{
@@ -54,7 +73,9 @@
"collapseAll": false,
"extraContext": false,
"sortOrder": "alphabetical"
}
},
"icon": "lucide-search",
"title": "Search"
}
},
{
@@ -62,7 +83,9 @@
"type": "leaf",
"state": {
"type": "starred",
"state": {}
"state": {},
"icon": "lucide-file",
"title": "Plugin no longer active"
}
},
{
@@ -70,7 +93,9 @@
"type": "leaf",
"state": {
"type": "bookmarks",
"state": {}
"state": {},
"icon": "lucide-bookmark",
"title": "Bookmarks"
}
}
]
@@ -93,7 +118,7 @@
"state": {
"type": "backlink",
"state": {
"file": "WS2425/Web Tech/Übung/3/ü3.md",
"file": "WS2425/Web Tech/Übung/4/uebung04.pdf",
"collapseAll": false,
"extraContext": false,
"sortOrder": "alphabetical",
@@ -101,7 +126,9 @@
"searchQuery": "",
"backlinkCollapsed": false,
"unlinkedCollapsed": true
}
},
"icon": "links-coming-in",
"title": "Backlinks for uebung04"
}
},
{
@@ -110,10 +137,12 @@
"state": {
"type": "outgoing-link",
"state": {
"file": "WS2425/Web Tech/Übung/3/ü3.md",
"file": "WS2425/Web Tech/Übung/4/uebung04.pdf",
"linksCollapsed": false,
"unlinkedCollapsed": true
}
},
"icon": "links-going-out",
"title": "Outgoing links from uebung04"
}
},
{
@@ -124,7 +153,9 @@
"state": {
"sortOrder": "frequency",
"useHierarchy": true
}
},
"icon": "lucide-tags",
"title": "Tags"
}
},
{
@@ -133,8 +164,10 @@
"state": {
"type": "outline",
"state": {
"file": "WS2425/Web Tech/Übung/3/ü3.md"
}
"file": "WS2425/Web Tech/Übung/4/uebung04.pdf"
},
"icon": "lucide-list",
"title": "Outline of uebung04"
}
},
{
@@ -142,7 +175,9 @@
"type": "leaf",
"state": {
"type": "advanced-tables-toolbar",
"state": {}
"state": {},
"icon": "spreadsheet",
"title": "Advanced Tables"
}
},
{
@@ -154,7 +189,9 @@
"sortOrder": "frequency",
"showSearch": false,
"searchQuery": ""
}
},
"icon": "lucide-archive",
"title": "All properties"
}
},
{
@@ -162,7 +199,9 @@
"type": "leaf",
"state": {
"type": "calendar",
"state": {}
"state": {},
"icon": "calendar-with-checkmark",
"title": "Calendar"
}
},
{
@@ -170,7 +209,9 @@
"type": "leaf",
"state": {
"type": "juggl_nodes",
"state": {}
"state": {},
"icon": "ag-node-list",
"title": "Juggl nodes"
}
},
{
@@ -178,7 +219,9 @@
"type": "leaf",
"state": {
"type": "juggl_style",
"state": {}
"state": {},
"icon": "ag-style",
"title": "Juggl style"
}
}
]
@@ -204,10 +247,22 @@
"obsidian-livesync:Show log": false
}
},
"active": "8f0d65f1974eff73",
"active": "f8485cde20c4a56c",
"lastOpenFiles": [
"WS2425/Web Tech/Übung/2/Ü2.md",
"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",
@@ -218,10 +273,6 @@
"WS2425/Web Tech/Übung/1/uebung01.pdf",
"WS2425/Web Tech/Praktikum",
"WS2425/Web Tech/Übung/1/Ü1.md",
"SS24/SWT2/KW19/03_SWT2_Architekturstile_I.pdf",
"WS2425/Web Tech/Übung/1",
"WS2425/Web Tech/Übung",
"WS2425/Theoretische Informatik/Blatt0-Einfuehrung (1).pdf",
"SS24/TdS/Canvas.canvas",
"SS24/SWT2/KW19/KW19.md",
"SS24/SWT2/SWT2.canvas",
@@ -239,20 +290,12 @@
"Untitled.md",
"IHK/Probeklausur/Klausur Winter 2020-2021.md",
"IHK/Rechenaufgaben/Rechenaufgaben.md",
"IHK/Selbsttest/Selbsttest Teil 2.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",
"IHK/Probeklausur/blobid1673285754812.png",
"IHK/Probeklausur/blobid1673284745609.png",
"IHK/Probeklausur/blobid1673284486298.png",
"IHK/Selbsttest/Selbsttest Teil 1.md",
"WS2324/Untitled.md",
"WS2324/Datenbank/Unterricht/13 Tutorium/Aufgaben.md",
"WS2324/Datenbank/Unterricht/08. Datenbankanfragen (Teil 2) (28.11.2023)/Praktikum/Aufgaben.md"
"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