Architektur-Diagramme

KAPITEL · PREMIUM EDITION

Architektur-Diagramme

Die umfassende Sammlung aller wichtigen Architektur-Diagramme – von Netzwerk-Topologien über CPU-Architekturen, Virtualisierung, Speicher-Hierarchien bis hin zu Betriebssystem-Architekturen. Alles visuell aufbereitet und praxisnah erklärt.

Netzwerk CPU Betriebssysteme Speicher Enterprise

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite finden Sie alle Architektur-Diagramme in 8 Hauptkategorien:

Kategorien im Überblick

Netzwerk-Topologien

Stern, Bus, Ring, Mesh, Baum

Heimnetzwerk

OPNsense mit DMZ

3-Tier Enterprise

Core, Distribution, Access

Von-Neumann

CPU-Architektur

Betriebssysteme

Schichtenmodell

CPU-Typen

5 Architekturen

Speicher-Hierarchie

Register bis Cloud

Virtualisierung

Type-1 & Type-2 Hypervisor

Cloud-Architektur

IaaS, PaaS, SaaS, Serverless

Docker & Container

Container-Technologie

1. Definition

Was sind Architektur-Diagramme?

Architektur-Diagramme sind visuelle Darstellungen von Systemstrukturen, die die Anordnung, Verbindung und Interaktion von Komponenten zeigen. Sie dienen der Planung, Dokumentation und Kommunikation von technischen Designs – sowohl für kleine Heimnetzwerke als auch für komplexe Enterprise-Infrastrukturen.

Ein gutes Architektur-Diagramm zeigt Topologie, Datenflüsse, Sicherheitszonen und die logischen Verbindungen zwischen Komponenten. Es hilft Administratoren, Fehler zu identifizieren, Änderungen zu planen und komplexe Systeme verständlich darzustellen.

In der IT unterscheidet man zwischen physischen Diagrammen (wie sind Geräte verkabelt?) und logischen Diagrammen (wie fließen Daten?). Beide Perspektiven sind für ein vollständiges Verständnis notwendig.

Warum sind Architektur-Diagramme wichtig?

  • Dokumentation: Neue Mitarbeiter verstehen das Netzwerk schneller
  • Fehlersuche: Probleme lassen sich visuell schneller lokalisieren
  • Planung: Erweiterungen und Migrationen werden kalkulierbar
  • Compliance: Viele Standards (ISO 27001, BSI) verlangen Netzpläne
  • Kommunikation: Technische Konzepte werden für Management verständlich

2. Netzwerk-Topologien

Die 5 wichtigsten Netzwerk-Topologien

Die Topologie beschreibt die physische oder logische Struktur eines Netzwerks – wie Geräte miteinander verbunden sind. Jede Topologie hat spezifische Vor- und Nachteile.

Stern-Topologie

Zentraler Switch/Hub

Alle Geräte sind mit einem zentralen Knoten (Switch/Hub) verbunden. Die häufigste Topologie in LANs.

Vorteile
  • Einfache Fehlersuche
  • Ausfall eines Geräts beeinflusst andere nicht
  • Leicht erweiterbar
Nachteile
  • Switch = Single Point of Failure
  • Mehr Kabelbedarf
  • Switch-Kosten

Bus-Topologie

Gemeinsames Kabel

Alle Geräte hängen an einem gemeinsamen Kabel (Bus). Ältere Topologie, heute selten.

Vorteile
  • Wenig Kabel
  • Einfach aufzubauen
  • Günstig
Nachteile
  • Bus-Ausfall = Komplettausfall
  • Schlechte Performance
  • Schwer zu troubleshooten

Ring-Topologie

Geschlossener Kreis

Geräte sind in einem Ring verbunden. Daten wandern von Gerät zu Gerät. Heute selten (Token Ring).

Vorteile
  • Geordneter Datenverkehr
  • Keine Kollisionen
  • Gleichberechtigung
Nachteile
  • Ein Ausfall unterbricht Ring
  • Schwer erweiterbar
  • Langsam bei vielen Geräten

Mesh-Topologie

Vermaschtes Netz

Jedes Gerät ist mit jedem anderen verbunden. Maximale Redundanz, aber hoher Verkabelungsaufwand.

Vorteile
  • Maximale Ausfallsicherheit
  • Mehrere Pfade möglich
  • Kein Single Point of Failure
Nachteile
  • Sehr hoher Kabelbedarf
  • Teuer
  • Komplex zu verwalten

Baum-Topologie

Hierarchische Struktur

Hierarchische Struktur mit Wurzel und Ästen. Kombination aus Stern und Bus. Typisch für große Netzwerke.

Vorteile
  • Gut skalierbar
  • Strukturierte Verwaltung
  • Segmentierung möglich
Nachteile
  • Wurzel = Single Point of Failure
  • Komplex
  • Teuer bei großen Netzen

Praxis-Tipp

In modernen Enterprise-Netzwerken wird häufig eine hybride Topologie eingesetzt: Baum-Struktur auf oberster Ebene, Stern-Topologie in den einzelnen Segmenten. Dies kombiniert die Vorteile beider Ansätze und ermöglicht einfache Verwaltung bei hoher Ausfallsicherheit.

3. Heimnetzwerk mit OPNsense und DMZ

Heimnetzwerk-Architektur

Ein praxisnahes Beispiel für ein sicheres Heimnetzwerk mit OPNsense-Firewall, DMZ für öffentliche Dienste und zwei internen LANs. Ideal für VMware-Projekte und fortgeschrittene Heimnetzwerke.

Die DMZ (Demilitarized Zone) isoliert öffentlich erreichbare Dienste (Webserver, VPN, DNS) vom internen LAN. Selbst wenn ein Dienst kompromittiert wird, hat der Angreifer keinen direkten Zugriff auf private Geräte.

Heimnetzwerk · OPNsense mit DMZ
Internet
Öffentliche Dienste
SSH(Port 22)
FTP(Port 21)
Google DNS8.8.8.8
Cloudflare DNS1.1.1.1
Mail(SMTP / IMAP)
Minecraft VPS185.42.12.34
WAN
Fritzbox(WAN-Router / Modem)192.168.0.1
DMZ
LAN 3 · DMZ (10.0.3.0/24)
OPNsense(Firewall / Router) WAN: 192.168.0.2 LAN1: 10.0.1.1 LAN2: 10.0.2.1 DMZ: 10.0.3.1
AdGuard DNS(Ad-Blocker / DNS)10.0.3.10
Homeserver(Dienste / Storage)10.0.3.20
LAN 1
LAN 2
LANs
LAN 1 (10.0.1.0/24)
PC(Windows / Linux)10.0.1.100
LAN 2 (10.0.2.0/24)
Notebook(Windows / Linux)10.0.2.100
Routing
LAN 1 (10.0.1.0/24) ↔ DMZ (10.0.3.0/24) LAN 2 (10.0.2.0/24) ↔ DMZ (10.0.3.0/24) DMZ ↔ Internet (via Fritzbox)
Fritzbox: 192.168.0.1 OPNsense WAN: 192.168.0.2 OPNsense LAN1: 10.0.1.1 OPNsense LAN2: 10.0.2.1 OPNsense DMZ: 10.0.3.1 AdGuard DNS: 10.0.3.10 Homeserver: 10.0.3.20 PC (LAN1): 10.0.1.100 Notebook (LAN2): 10.0.2.100

Geplante Routing-Regeln

  • LAN 1 ↔ DMZ: Erlaubt (Zugriff auf Homeserver)
  • LAN 2 ↔ DMZ: Erlaubt (Zugriff auf Homeserver)
  • DMZ ↔ LAN 1/2: Blockiert (DMZ darf nicht auf LAN zugreifen)
  • Alle → Internet: Via OPNsense → Fritzbox

4. 3-Tier Enterprise-Netzwerk-Architektur

Moderne Enterprise-Architektur (3-Tier + DMZ)

Das hierarchische 3-Tier-Design (Core, Distribution, Access) ist der Standard für Enterprise-Netzwerke. Es bietet Skalierbarkeit, Fehlerisolierung und klare Struktur. Jede Ebene hat eine spezifische Aufgabe.

In professionellen Netzwerken wird die DMZ von zwei Firewalls geschützt: Perimeter-Firewall (zwischen Internet und DMZ) und Interne Firewall (zwischen DMZ und Core-Layer). Dieses Design wird als „Dual-Homed DMZ" bezeichnet und gilt als Best Practice.

Moderne Enterprise-Netzwerk-Architektur (3-Tier + DMZ)
Internet
Internet
Perimeter-Firewall(externe FW)
DMZ
Pufferzone
Web-Server
Mail-Server
VPN-Gateway
DMZ → Core
Interne Firewall(Core-FW)
Core Layer
Kern
Core-Switch(Redundant)
Core-Switch(Redundant)
Distribution
Verteilung
Distri-Switch
Router
Distri-Switch
Access Layer
Zugang
Access-Switch
Access PointWiFi 6
Access-Switch
Endgeräte
Clients
PC
Laptop
Drucker
Server(File/AD)
Smartphone

Core – Distribution – Access

Core Layer (Kern)

Das Rückgrat des Netzwerks. Extrem schnelle Weiterleitung von Daten zwischen den Distribution-Layern. Hohe Redundanz und Verfügbarkeit.

10–100 Gbit/s Layer 3 Switching Redundanz High Availability
Distribution Layer (Verteilung)

Aggregiert den Traffic der Access-Layer und leitet ihn zum Core weiter. Hier finden Routing, Policy-Definition und Security-Filterung statt.

Routing VLANs ACLs QoS
Access Layer (Zugang)

Hier werden Endgeräte (PCs, Drucker, APs) an das Netzwerk angeschlossen. Port-Security, VLAN-Zuweisung und PoE finden hier statt.

1 Gbit/s Ports PoE Port-Security 802.1X

Zwei-Firewall-Architektur (DMZ)

In einer professionellen Netzwerk-Architektur wird die DMZ von zwei Firewalls geschützt:

  • Perimeter-Firewall (externe FW): Zwischen Internet und DMZ. Schützt die DMZ-Server vor Angriffen aus dem Internet.
  • Interne Firewall (Core-FW): Zwischen DMZ und Core-Layer. Verhindert, dass ein kompromittierter DMZ-Server Zugriff auf das interne LAN bekommt.

Dieses Design wird auch als „Dual-Homed DMZ" oder „Dual-Firewall-Architektur" bezeichnet und gilt als Best Practice.

5. Von-Neumann-Architektur (CPU)

Von-Neumann-Architektur

Das Von-Neumann-Modell (1945 von John von Neumann beschrieben) ist das grundlegende Architekturmodell fast aller modernen Computer. Kernprinzip: Programm und Daten werden im gleichen Speicher abgelegt und über einen gemeinsamen Bus übertragen.

Von-Neumann-Architektur

Eingabe

Tastatur, Maus, Scanner

Zentraleinheit (CPU)

Rechenwerk + Steuerwerk

Rechenwerk (ALU)
Steuerwerk (Control Unit)
Register
Speicher

RAM (Daten + Programme)

Ausgabe

Monitor, Drucker

Von-Neumann-Flaschenhals

Da Daten und Programme denselben Speicher teilen und über denselben Bus übertragen werden, kann die CPU nie gleichzeitig einen Befehl holen und Daten lesen/schreiben. Das begrenzt den Durchsatz und wird als Von-Neumann-Flaschenhals bezeichnet. Moderne CPUs verwenden Caches (Harvard-Architektur auf Cache-Ebene), um dieses Problem zu mildern.

6. Betriebssystem-Architektur

Schichtenmodell eines Betriebssystems

Moderne Betriebssysteme sind in Schichten (Layers) aufgebaut. Jede Schicht bietet Dienste für die nächsthöhere an und kapselt die Komplexität der darunterliegenden Schicht.


Betriebssystem-Schichten


User Space · Anwendungen

Browser, Office, Spiele, Shell, GUI

Layer 5
System Call Interface (API)

Schnittstelle zwischen Anwendungen und Kernel (z.B. POSIX, Win32 API)

Layer 4
Kernel · Kern des Betriebssystems

Prozessmanagement, Speicherverwaltung, Dateisystem, Scheduling, Security

Layer 3
Device Drivers · Gerätetreiber

Treiber für Hardware-Komponenten (GPU, NIC, Storage, USB, etc.)

Layer 2
Hardware · Physische Komponenten

CPU, RAM, Storage, Netzwerk, Peripherie

Layer 1

Kernel-Arten

  • Monolithischer Kernel: Alles in einem Adressraum (Linux, Windows) – schnell, aber komplex
  • Mikrokernel: Nur minimale Funktionen im Kernel, Rest in User Space (MINIX, QNX) – sicherer, aber langsamer
  • Hybrid-Kernel: Kombination beider Ansätze (macOS XNU, Windows NT)

7. CPU-Typen

Instruction Set Architectures (ISA) im Vergleich

Unterschiedliche CPU-Architekturen verwenden verschiedene Befehlssätze (ISA). Betriebssysteme und Software müssen für jede Architektur separat kompiliert werden.

Die wichtigsten CPU-Architekturen und ihre typischen Einsatzgebiete.

amd64 / x86_64

64-Bit-Erweiterung von x86
  • Hersteller: AMD, Intel
  • Architektur: CISC (Complex Instruction Set)
  • Register: 16 × 64-Bit General Purpose
  • Backward Compatible: Ja, zu 32-Bit x86
  • Leistung: Sehr hoch, für Desktop/Server
Einsatz: Desktop-PCs, Laptops, Server, Workstations

arm64 / AArch64

64-Bit ARM-Architektur
  • Hersteller: ARM Ltd. (Apple, Qualcomm, Samsung)
  • Architektur: RISC (Reduced Instruction Set)
  • Register: 31 × 64-Bit General Purpose
  • Energieeffizienz: Sehr hoch
  • Lizenz: ARM-Design, von Herstellern implementiert
Einsatz: Smartphones, Tablets, Apple Silicon (M1/M2/M3), Embedded, Server (AWS Graviton)

ppc64el

PowerPC 64-Bit Little Endian
  • Hersteller: IBM (Power), OpenPOWER
  • Architektur: RISC
  • Endian: Little Endian (el)
  • Leistung: Hoch, für Enterprise-Server
  • Open Standard: OpenPOWER Foundation
Einsatz: IBM Power Systems, Supercomputer, Enterprise-Server

s390x

IBM Z (Mainframe)
  • Hersteller: IBM
  • Architektur: CISC (spezialisiert)
  • Virtualisierung: Hardware-seitig (z/VM)
  • Zuverlässigkeit: Extrem hoch (99.9999%)
  • Skalierung: Bis 240 Kerne, 10+ TB RAM
Einsatz: IBM Mainframes, Bankensysteme, Versicherungen, große Transaktionssysteme

riscv64

RISC-V Open Source ISA
  • Hersteller: Open Source (verschiedene)
  • Architektur: RISC
  • Lizenz: Komplett offen, keine Lizenzgebühren
  • Modular: Erweiterbar (RV64IMAFDC)
  • Wachstum: Schnell wachsendes Ökosystem
Einsatz: Embedded, Mikrocontroller, Forschung, Custom Silicon, IoT

CISC vs. RISC

  • CISC (Complex Instruction Set): Viele komplexe Befehle, variable Länge – z.B. x86, s390x
  • RISC (Reduced Instruction Set): Wenige einfache Befehle, feste Länge – z.B. ARM, RISC-V, PowerPC
  • Moderne CPUs: Hybride Ansätze – x86-CPUs übersetzen CISC-Befehle intern in RISC-ähnliche Mikro-Operationen

8. Speicher-Hierarchie

Speicherhierarchie (schnell → groß)

Die Speicher-Hierarchie organisiert Speichermedien nach Geschwindigkeit, Größe und Kosten. Je näher an der CPU, desto schneller, kleiner und teurer pro Byte. Je weiter weg, desto langsamer, größer und günstiger.

Speicherhierarchie (schnell → groß)

Register

Direkt in der CPU, extrem schnell

< 1 ns
~1 KB
L1-Cache

Pro Kern, aufgeteilt in Daten + Befehle

~1 ns
32-64 KB
L2-Cache

Pro Kern, größer als L1

~3-4 ns
256-512 KB
L3-Cache

Geteilt zwischen allen Kernen

~10-15 ns
8-128 MB
Arbeitsspeicher (RAM)

DDR4/DDR5, flüchtig

~50-80 ns
8-128 GB
SSD / NVMe

Nicht-flüchtig, sehr schnell

~0,1 ms
250 GB - 8 TB
HDD / Cloud / Band

Mechanisch oder remote, große Kapazität

~5-10 ms
500 GB - 20 TB+

Prinzip der Lokalität

  • Zeitliche Lokalität: Auf dieselben Daten wird bald wieder zugegriffen (z.B. Schleifenvariablen)
  • Örtliche Lokalität: Auf benachbarte Daten wird bald zugegriffen (z.B. Arrays)
  • Cache-Strategie: Der Cache nutzt diese Prinzipien, um die häufigsten Daten bereitzuhalten

9. Virtualisierungs-Architektur

Virtualisierung ermöglicht es, mehrere virtuelle Maschinen auf einem physischen Server zu betreiben. Es gibt zwei Haupttypen von Hypervisoren.

Type 1 Hypervisor

Bare-Metal / Native

Virtuelle Maschinen

VM 1, VM 2, VM 3, ...

Hypervisor

VMware ESXi, Microsoft Hyper-V, Proxmox, KVM

Hardware

CPU, RAM, Storage, Netzwerk

Vorteile
  • Bessere Performance (kein Host-OS)
  • Höhere Sicherheit
  • Enterprise-Standard

Type 2 Hypervisor

Hosted

Virtuelle Maschinen

VM 1, VM 2, VM 3, ...

Hypervisor

VMware Workstation, VirtualBox, Parallels

Host-Betriebssystem

Windows, macOS, Linux

Hardware

CPU, RAM, Storage, Netzwerk

Einsatz
  • Entwicklung & Testing
  • Schulungen & Demos
  • Private Nutzung
Container vs. Virtualisierung

Container (Docker, Podman) virtualisieren nicht die Hardware, sondern das Betriebssystem. Sie teilen sich den Host-Kernel und sind daher leichter und schneller als VMs, bieten aber weniger Isolation. Ideal für Microservices und CI/CD.

10. Cloud-Architektur

Cloud-Dienste im Überblick

Die Cloud bietet verschiedene Dienstmodelle – vom Server über Plattformen bis hin zu fertigen Anwendungen. Hier die wichtigsten Arten einfach erklärt.

Infrastructure as a Service

IaaS stellt virtuelle Server, Speicher und Netzwerke zur Verfügung. Du bekommst einen "Server in der Cloud" – musst dich aber selbst um Betriebssystem, Updates und Sicherheit kümmern.

AWS EC2 Azure VMs Google Compute Engine DigitalOcean Droplets
🎯 Wofür?
  • Server für Webseiten
  • Datenbanken
  • Entwicklungsumgebungen
  • Spiele-Server (z.B. Minecraft)

Welche Cloud für welchen Zweck?

Spiele-Server

IaaS
AWS EC2, DigitalOcean

Web-Apps

PaaS
Heroku, AWS Beanstalk

E-Mail & Office

SaaS
Google Workspace, M365

Bildverarbeitung

Serverless
AWS Lambda, Cloudflare

Datenbank

IaaS / PaaS
AWS RDS, Azure SQL

Zusammenfassung

  • IaaS: Du bekommst einen Server – du machst alles selbst (z.B. AWS EC2)
  • PaaS: Du bekommst eine Plattform – du deployst nur Code (z.B. Heroku)
  • SaaS: Du bekommst eine fertige App – einfach nutzen (z.B. Google Workspace)
  • Serverless: Du schreibst Funktionen – der Rest ist automatisch (z.B. AWS Lambda)

11. Docker & Container

Container-Technologie einfach erklärt

Container sind leichtgewichtige, isolierte Umgebungen für Anwendungen. Anders als virtuelle Maschinen teilen sie sich den Host-Kernel und starten in Sekunden. Docker ist der De-facto-Standard für Container-Technologie.

Container

Leicht & schnell

Anwendung + Abhängigkeiten

App, Bibliotheken, Konfiguration

Container-Engine

Docker, Podman, containerd

Host-Betriebssystem

Linux, Windows, macOS

Vorteile
  • Start in Sekunden
  • Geringer Ressourcenverbrauch
  • Einfache Skalierung

Virtuelle Maschine

Schwer & vollständig

Anwendung + Bibliotheken

App, Bibliotheken, Konfiguration

Gast-Betriebssystem

Eigenes OS (z.B. Ubuntu, Windows)

Hypervisor

VMware ESXi, Proxmox, KVM

Hardware

CPU, RAM, Storage, Netzwerk

Vorteile
  • Vollständige Isolation
  • Verschiedene Betriebssysteme
  • Production-Standard

Docker-Architektur

Container

Laufende Instanz eines Images

Runtime
Docker Engine

Daemon + API + CLI – Verwaltung von Containern

Engine
Images

Vorlagen für Container – z.B. nginx, ubuntu, mysql

Template
Dockerfile

Bauanleitung für Images – FROM, RUN, COPY, EXPOSE

Build
Container Registry

Docker Hub, Google Container Registry, private Registry

Storage

Wichtige Docker-Kommandos

RUN docker run nginx

Container aus Image starten

BUILD docker build -t myapp .

Image aus Dockerfile bauen

PULL docker pull ubuntu

Image aus Registry herunterladen

PS docker ps -a

Alle Container anzeigen

STOP docker stop container

Container stoppen

Beispiel: Dockerfile für eine Node.js-App 
	FROM node:18-alpine
	WORKDIR /app
	COPY package*.json ./
	RUN npm install --production
	COPY . .
	EXPOSE 3000
	CMD ["node", "server.js"]
FROM – Basis-Image WORKDIR – Arbeitsverzeichnis COPY – Dateien kopieren RUN – Befehle ausführen EXPOSE – Port freigeben CMD – Startbefehl
Vorteile von Containern
  • Leicht: Kein eigenes Betriebssystem
  • Schnell: Start in Sekunden
  • Portabel: Überall gleich – dev, test, prod
  • Skalierbar: Einfach replizieren
  • Isoliert: Abhängigkeiten pro Container
Nachteile von Containern
  • Weniger Isolation: Teilt Host-Kernel
  • Persistenz: Volumes für Daten nötig
  • Komplexität: Orchestrierung (Kubernetes)
  • Windows-Container: Nur unter Windows
  • Lernkurve: Neue Konzepte

Zusammenfassung

  • Container: Leichte, isolierte Umgebungen für Anwendungen
  • Docker: De-facto-Standard für Container-Technologie
  • Dockerfile: Bauanleitung für Images (FROM, RUN, COPY, CMD)
  • Images: Vorlagen für Container – einmal gebaut, überall lauffähig
  • Registry: Speicherort für Images (Docker Hub, private Registry)
  • Container vs. VM: Container sind leichter und schneller, VMs bieten mehr Isolation

12. Programmablaufplan (PAP)

Der Programmablaufplan visualisiert den Ablauf eines Algorithmus mit standardisierten Symbolen nach DIN 66001.

PAP – Beispiel: Summe prüfen

Der Programmablaufplan (PAP) verwendet genormte Symbole nach DIN 66001: Oval für Start/Ende, Rechteck für Verarbeitung, Parallelogramm für Ein-/Ausgabe und Raute für Entscheidungen.

START
Eingabe: Zahl a, Zahl b
summe = a + b
Ja ↓ Nein ↓
summe > 100?
Ausgabe: "Groß"
Ausgabe: "Klein"
STOP

PAP-Symbole nach DIN 66001

  • Oval: Start / Ende
  • Rechteck: Verarbeitung / Prozess
  • Parallelogramm: Ein- / Ausgabe
  • Raute: Entscheidung (Ja/Nein)
  • Pfeile: Kontrollfluss

13. Struktogramm (Nassi-Shneiderman)

Das Struktogramm stellt Algorithmen als verschachtelte Blöcke dar und erzwingt strukturierte Programmierung.

Struktogramm – Beispiel

Das Struktogramm (auch Nassi-Shneiderman-Diagramm) verwendet verschachtelte Blöcke anstelle von Pfeilen. Es erzwingt strukturierte Programmierung ohne Sprünge (kein GOTO) und ist ideal für komplexe verschachtelte Bedingungen.

START
Eingabe: a, b
summe = a + b
summe > 100?
Wahr Ausgabe: "Groß"
Falsch Ausgabe: "Klein"
ENDE

Vorteile des Struktogramms

  • Erzwingt strukturierte Programmierung
  • Keine unübersichtlichen Sprünge
  • Gut für komplexe verschachtelte Bedingungen
  • Leicht in Code umzusetzen

14. UML-Klassendiagramm

UML-Klassendiagramme zeigen die statische Struktur eines objektorientierten Systems.

UML-Klassendiagramm – Beispiel

UML-Klassendiagramme visualisieren Klassen, Attribute, Methoden und Beziehungen. Sie sind das zentrale Werkzeug für objektorientierte Softwareentwicklung und werden in der Design-Phase sowie für die Dokumentation eingesetzt.

Person
- name: String
- alter: Int
- email: String
+ getName(): String
+ setAlter(a: Int): void
+ sendeEmail(msg: String): void
Mitarbeiter (erbt von Person)
- mitarbeiterId: Int
- gehalt: Double
- abteilung: String
+ berechneBonus(): Double
+ befoerdern(): void
+ getGehalt(): Double

Sichtbarkeits-Symbole

  • + public – von überall sichtbar
  • - private – nur in der Klasse sichtbar
  • # protected – in Klasse und Subklassen sichtbar
  • ~ package – im gleichen Paket sichtbar

15. UML-Sequenzdiagramm

Sequenzdiagramme zeigen die dynamische Interaktion zwischen Objekten über die Zeit.

UML-Sequenzdiagramm – Beispiel

Sequenzdiagramme zeigen den zeitlichen Ablauf von Nachrichten zwischen Objekten. Sie sind ideal für Use Cases, API-Design und die Dokumentation von Microservices-Kommunikation.

Benutzer
Browser
Webserver
Datenbank
Login anfordern →
POST /login →
← HTML Response
SELECT user →
← User-Daten

Anwendungsfälle

  • Visualisierung von User-Stories
  • Dokumentation von API-Workflows
  • Microservice-Kommunikation
  • Protokoll-Abläufe (z.B. OAuth2, TLS-Handshake)

16. Flussdiagramm (Flowchart)

Ein Flussdiagramm ist ein allgemeines Diagramm zur Visualisierung von Prozessen und Workflows.

Flussdiagramm – Beispiel

Ein Flussdiagramm ist weniger formal als ein PAP und wird in vielen Bereichen eingesetzt: Geschäftsprozess-Modellierung, IT-Workflows, Entscheidungsprozesse und Dokumentation von SOPs.

START
Benutzer-Login
Passwort korrekt?
Nein ←
→ Ja
Fehler anzeigen
Dashboard laden
ENDE

Einsatzgebiete von Flussdiagrammen

  • Geschäftsprozess-Modellierung (BPMN)
  • IT-Workflows (Incident Response, Deployment)
  • Entscheidungsprozesse
  • Dokumentation von Standard Operating Procedures (SOPs)

17. Entity-Relationship-Diagramm (ERD)

ER-Diagramme visualisieren Datenmodelle in Datenbanken mit Entities, Attributen und Beziehungen.

ERD – Beispiel

ER-Diagramme zeigen Entities (Tabellen), Attribute (Spalten) und Relationships (Beziehungen) zwischen Entities. Sie sind das Standard-Werkzeug für Datenbank-Design und Datenmodellierung.

👤 Kunde
PK kunden_id
name
email
adresse
registriert_am
tätigt
1 : n
📦 Bestellung
PK bestell_id
FK kunden_id
bestell_datum
status
gesamt_summe
🛍️ Produkt
PK produkt_id
name
preis
bestand
enthält
n : m
📋 Bestellposition
PK position_id
FK bestell_id
FK produkt_id
menge
einzelpreis

ERD-Symbole

  • PK (Primary Key): Eindeutiger Identifikator einer Entität
  • FK (Foreign Key): Verweis auf den Primary Key einer anderen Entität
  • 1:1 – Eins-zu-Eins-Beziehung
  • 1:n – Eins-zu-Viele-Beziehung
  • n:m – Viele-zu-Viele-Beziehung (erfordert Zwischentabelle)

FAQ – Häufige Fragen & Antworten

Häufige Fragen zu Architektur-Diagrammen

Was ist der Unterschied zwischen Von-Neumann- und Harvard-Architektur?

Von-Neumann: Programme und Daten werden im gleichen Speicher abgelegt und über einen gemeinsamen Bus übertragen. Dies führt zum Von-Neumann-Flaschenhals – der Bus limitiert die Geschwindigkeit.

Harvard: Programme und Daten werden in getrennten Speichern mit eigenen Bussen abgelegt. Dies ermöglicht parallele Zugriffe und höhere Geschwindigkeit.

In der Praxis: Moderne CPUs verwenden eine Modified Harvard Architecture – getrennte L1-Caches für Daten und Instruktionen, aber gemeinsamer RAM.

Warum gibt es eine Speicher-Hierarchie und nicht nur einen einzigen schnellen Speicher?

Das ist eine Frage der Kosten und Physik:

  • SRAM (für Cache): Extrem schnell, aber teuer (~1000× teurer als DRAM pro GB)
  • DRAM (für RAM): Schnell und günstig, aber flüchtig
  • NAND Flash (für SSD): Nicht-flüchtig, aber langsamer
  • Magnetisch (HDD): Sehr günstig, aber langsam

Durch die Hierarchie und das Lokalitätsprinzip erreichen wir fast die Geschwindigkeit von SRAM zu den Kosten von HDDs – weil ~90% der Zugriffe auf ~10% der Daten erfolgen.

Wann sollte ich Type-1 vs. Type-2 Hypervisor einsetzen?

Type-1 (Bare Metal) – z.B. VMware ESXi, KVM, Proxmox:

  • Produktivumgebungen, Rechenzentren
  • Hohe Performance-Anforderungen
  • 24/7-Betrieb erforderlich
  • Maximale Stabilität und Sicherheit

Type-2 (Hosted) – z.B. VirtualBox, VMware Workstation:

  • Entwicklung und Testing
  • Lernumgebungen
  • Desktop-Nutzung
  • Schnelle Einrichtung ohne spezielle Hardware
Was ist der Unterschied zwischen einem PAP und einem Struktogramm?

PAP (Programmablaufplan):

  • Verwendet Symbole nach DIN 66001 (Ovale, Rechtecke, Rauten)
  • Erlaubt Sprünge (Pfeile in beliebige Richtungen)
  • Kann unstrukturierten Code darstellen (auch mit GOTO)
  • Gut für einfache Algorithmen

Struktogramm (Nassi-Shneiderman):

  • Verwendet verschachtelte Blöcke
  • Erzwingt strukturierte Programmierung (kein GOTO möglich)
  • Besser für komplexe, verschachtelte Logik
  • Leichter in Code zu übersetzen
Wann verwende ich UML-Klassendiagramme vs. Sequenzdiagramme?

Klassendiagramm (statisch):

  • Zeigt die Struktur des Systems
  • Klassen, Attribute, Methoden, Beziehungen
  • Wann? Beim Design der Datenmodelle und Architektur
  • Beispiel: Welche Klassen hat mein System? Wie sind sie verknüpft?

Sequenzdiagramm (dynamisch):

  • Zeigt die Interaktion über die Zeit
  • Nachrichtenfluss zwischen Objekten
  • Wann? Bei der Dokumentation von Use Cases und Workflows
  • Beispiel: Wie läuft ein Login-Prozess ab? Wie kommunizieren Microservices?
Welches Diagramm nutze ich für Datenbank-Design?

Entity-Relationship-Diagramm (ERD) ist der Standard für Datenbank-Design:

  • Zeigt Tabellen (Entities), Spalten (Attribute) und Beziehungen
  • Definiert Primary Keys, Foreign Keys
  • Visualisiert Kardinalitäten (1:1, 1:n, n:m)

ERD-Notationen:

  • Chen-Notation: Klassisch, mit Rauten für Relationships
  • Crow's-Foot-Notation: Modern, verwendet "Krallen" für Kardinalitäten
  • UML-Klassendiagramm: Wird oft auch für Datenmodelle verwendet

Tools: MySQL Workbench, pgModeler, dbdiagram.io, draw.io

Was ist eine DMZ und warum brauche ich sie?

DMZ (Demilitarized Zone) ist ein isoliertes Netzwerksegment zwischen Internet und internem LAN:

  • Beherbergt öffentlich erreichbare Dienste (Web-Server, Mail, VPN)
  • Schützt das interne Netzwerk vor direkten Angriffen aus dem Internet
  • Bei Kompromittierung eines DMZ-Servers bleibt das LAN geschützt

Best Practice: Dual-Homed DMZ

  • Externe Firewall: Zwischen Internet und DMZ
  • Interne Firewall: Zwischen DMZ und LAN
  • Keine direkte Verbindung Internet ↔ LAN (nur über DMZ)

Auch im Heimnetzwerk sinnvoll: Z.B. mit OPNsense für Homeserver, Nextcloud, VPN.

Was bedeutet amd64 vs. arm64 in der Praxis?

amd64 / x86_64:

  • Standard in Desktops, Laptops, Servern
  • Hohe Single-Core-Performance
  • Breite Software-Unterstützung
  • Höherer Stromverbrauch

arm64 / AArch64:

  • Standard in Smartphones, Tablets, Apple M-Serie
  • Sehr energieeffizient
  • Wachsende Server-Präsenz (AWS Graviton, Ampere)
  • Software muss oft separat kompiliert werden

Praxis-Tipp: Bei Docker-Images auf platform achten: docker buildx build --platform linux/amd64,linux/arm64

Warum hat die 3-Tier Enterprise-Architektur drei Ebenen?

Die 3-Tier-Architektur (Core – Distribution – Access) folgt dem Prinzip der Aufgabentrennung:

  • Core Layer: Hochgeschwindigkeit (10-100 Gbit/s), nur Paket-Weiterleitung
  • Distribution Layer: Routing, Policies, Security (ACLs, QoS)
  • Access Layer: Endgeräte-Anschluss, PoE, Port-Security

Vorteile:

  • Skalierbarkeit: Neue Access-Switches einfach hinzufügen
  • Fehlerisolierung: Probleme in einer Ebene breiten sich nicht aus
  • Einfache Wartung: Klare Zuständigkeiten pro Ebene
  • Performance-Optimierung: Jede Ebene für ihre Aufgabe optimiert
Was sind die Nachteile der Stern-Topologie?

Die Stern-Topologie ist zwar die häufigste, hat aber auch Nachteile:

  • Single Point of Failure: Fällt der zentrale Switch aus, ist das gesamte Netzwerk lahm
  • Höhere Kosten: Mehr Kabel und teurer Switch benötigt
  • Kabelmanagement: Viele Kabel zum zentralen Switch
  • Switch-Kapazität: Begrenzt durch Anzahl der Ports

Lösung: In Enterprise-Netzen wird der zentrale Switch redundant ausgelegt (Stacking, LACP, redundante Switches).

Was ist der Unterschied zwischen IaaS, PaaS, SaaS und Serverless?

IaaS (Infrastructure as a Service): Du bekommst virtuelle Server, Storage und Netzwerk. Du musst dich selbst um Betriebssystem, Updates und Sicherheit kümmern. Beispiel: AWS EC2, Azure VMs.

PaaS (Platform as a Service): Du bekommst eine komplette Entwicklungs- und Laufzeitumgebung. Keine Server-Verwaltung – einfach Code deployen. Beispiel: Heroku, Google App Engine.

SaaS (Software as a Service): Du bekommst fertige Anwendungen aus der Cloud. Keine Installation, keine Updates. Beispiel: Google Workspace, Microsoft 365.

Serverless / FaaS: Du schreibst nur Funktionen – der Cloud-Anbieter führt sie bei Bedarf aus. Bezahlung nur für tatsächliche Laufzeit. Beispiel: AWS Lambda, Cloudflare Workers.

Was ist der Unterschied zwischen einem Container und einer virtuellen Maschine?

Container:

  • Teilt sich den Host-Kernel
  • Startet in Sekunden
  • Geringer Ressourcenverbrauch
  • Leichter und portabler
  • Beispiel: Docker, Podman

Virtuelle Maschine (VM):

  • Eigenes vollständiges Betriebssystem
  • Startet in Minuten
  • Höherer Ressourcenverbrauch
  • Vollständige Isolation
  • Beispiel: VMware, Proxmox, KVM

Fazit: Container sind ideal für Microservices und Entwicklung, VMs für Production-Workloads mit hohen Sicherheitsanforderungen.

Wann sollte ich Docker verwenden?

Docker ist ideal für:

  • Entwicklung & Testing: Gleiche Umgebung für alle Entwickler
  • Microservices: Jeder Service läuft in seinem eigenen Container
  • CI/CD-Pipelines: Einfaches Bauen und Testen von Anwendungen
  • Portabilität: "Build once, run anywhere"
  • Ressourcenschonend: Mehr Anwendungen auf einem Server

Weniger geeignet für:

  • Anwendungen mit GUI (Desktop-Apps)
  • High-Performance-Computing (HPC)
  • Kritische Sicherheitsanwendungen (Shared Kernel)
Was ist ein Dockerfile und wozu brauche ich es?

Ein Dockerfile ist eine Textdatei mit Bauanweisungen für ein Docker-Image. Es enthält alle Schritte, um eine Anwendung in einen Container zu verpacken.

Typische Befehle im Dockerfile:

  • FROM – Basis-Image (z.B. node:18-alpine)
  • WORKDIR – Arbeitsverzeichnis setzen
  • COPY – Dateien in das Image kopieren
  • RUN – Befehle während des Builds ausführen
  • EXPOSE – Port freigeben
  • CMD – Startbefehl für den Container

Beispiel: docker build -t myapp . erstellt ein Image aus dem Dockerfile.

Was ist der Unterschied zwischen Kubernetes und Docker?

Docker ist eine Container-Engine – sie erstellt und startet einzelne Container auf einem Host.

Kubernetes ist ein Container-Orchestrierer – er verwaltet, skaliert und überwacht Container über mehrere Hosts hinweg.

Zusammengefasst:

  • Docker: Container bauen und starten (lokal)
  • Kubernetes: Container orchestrieren (Production)
  • Beide: Docker ist die Engine, Kubernetes die Orchestrierung
  • Praxis: Docker wird oft lokal verwendet, Kubernetes für Production-Deployments
Welche Cloud-Anbieter gibt es und was ist der Unterschied?

AWS (Amazon Web Services):

  • Marktführer mit über 200 Services
  • Größte Auswahl und weltweite Verfügbarkeit
  • Sehr viele Dokumentationen und Tutorials

Azure (Microsoft):

  • Stark in Enterprise-Umgebungen
  • Nahtlose Integration mit Microsoft-Produkten (Office 365, Active Directory)
  • Hybrid-Cloud-Lösungen (On-Premise + Cloud)

Google Cloud (GCP):

  • Stark in Datenanalyse, KI/ML und Kubernetes (GKE)
  • Bekannt für BigQuery, TensorFlow und Looker
  • Attraktive Preise für Startups

Fazit: Die Wahl hängt von den Anforderungen ab – für Startups oft AWS oder GCP, für Enterprise oft Azure.

Zusammenfassung

Die wichtigsten Architektur-Diagramme

  • CPU-Architektur: Von-Neumann-Modell als Grundlage aller Computer
  • Speicher-Hierarchie: Pyramide von Registern (ns) bis zu Cloud (ms)
  • Virtualisierung: Type-1 (Bare Metal) für Produktion, Type-2 (Hosted) für Entwicklung
  • Betriebssystem: Schichtenmodell von Hardware bis Benutzer
  • CPU-Typen: amd64, arm64, ppc64el, s390x, riscv64 – jede mit eigenem Einsatzzweck
  • Netzwerk-Topologien: Stern (häufigste), Bus, Ring, Mesh, Baum
  • Heimnetzwerk: OPNsense mit DMZ für sichere Dienste
  • Enterprise: 3-Tier (Core – Distribution – Access) mit Dual-Homed DMZ
  • Programmierung: PAP, Struktogramm, Flussdiagramm für Algorithmen
  • UML: Klassen- und Sequenzdiagramme für OO-Design
  • ERD: Entity-Relationship für Datenbank-Design

Empfohlene Diagramm-Tools

  • draw.io / diagrams.net: Kostenlos, browser-basiert, viele Vorlagen
  • Lucidchart: Professionell, Team-Kollaboration
  • PlantUML: Text-basierte Diagramme, Git-freundlich
  • Mermaid: Markdown-Integration, perfekt für Docs
  • MySQL Workbench: ERD für MySQL-Datenbanken
  • Visual Paradigm: Vollständiges UML-Tool