<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="de">
	<id>https://demowiki.knowlus.com/index.php?action=history&amp;feed=atom&amp;title=Komplexit%C3%A4t_%28Informatik%29</id>
	<title>Komplexität (Informatik) - Versionsgeschichte</title>
	<link rel="self" type="application/atom+xml" href="https://demowiki.knowlus.com/index.php?action=history&amp;feed=atom&amp;title=Komplexit%C3%A4t_%28Informatik%29"/>
	<link rel="alternate" type="text/html" href="https://demowiki.knowlus.com/index.php?title=Komplexit%C3%A4t_(Informatik)&amp;action=history"/>
	<updated>2026-04-09T21:46:54Z</updated>
	<subtitle>Versionsgeschichte dieser Seite in Demo Wiki</subtitle>
	<generator>MediaWiki 1.44.2</generator>
	<entry>
		<id>https://demowiki.knowlus.com/index.php?title=Komplexit%C3%A4t_(Informatik)&amp;diff=1895&amp;oldid=prev</id>
		<title>imported&gt;Redonebird: Abschnittlink korrigiert</title>
		<link rel="alternate" type="text/html" href="https://demowiki.knowlus.com/index.php?title=Komplexit%C3%A4t_(Informatik)&amp;diff=1895&amp;oldid=prev"/>
		<updated>2023-11-22T05:14:41Z</updated>

		<summary type="html">&lt;p&gt;Abschnittlink korrigiert&lt;/p&gt;
&lt;p&gt;&lt;b&gt;Neue Seite&lt;/b&gt;&lt;/p&gt;&lt;div&gt;Der Begriff &amp;#039;&amp;#039;&amp;#039;Komplexität&amp;#039;&amp;#039;&amp;#039; wird in der [[Informatik]] in verschiedenen Teilbereichen verwendet. Die [[Komplexitätstheorie]] befasst sich dabei mit dem Ressourcenverbrauch von [[Algorithmus|Algorithmen]], die [[Informationstheorie]] dagegen verwendet den Begriff für den [[Informationsgehalt]] von [[Daten]], die [[Praktische Informatik]] wiederum bewertet damit Software oder Softwareteile hinsichtlich der Anzahl von Interaktionen.&lt;br /&gt;
&lt;br /&gt;
== Komplexitätstheorie ==&lt;br /&gt;
{{Hauptartikel|Komplexitätstheorie}}&lt;br /&gt;
Unter der Komplexität (auch &amp;#039;&amp;#039;Aufwand&amp;#039;&amp;#039; oder &amp;#039;&amp;#039;Kosten&amp;#039;&amp;#039;) eines Algorithmus versteht man in der [[Komplexitätstheorie]] seinen Ressourcenbedarf. Dieser wird oft in Abhängigkeit von der Länge &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; der Eingabe angegeben und für große &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; [[asymptotisch]] unter Verwendung von [[Landau-Symbole]]n abgeschätzt. Analog wird die Komplexität eines [[Problem#Wissenschaften|Problems]] definiert durch den Ressourcenverbrauch eines optimalen [[Algorithmus]] zur Lösung dieses Problems. Die Schwierigkeit liegt darin, dass man alle Algorithmen für ein Problem betrachten muss, um die Komplexität desselben zu bestimmen.&lt;br /&gt;
&lt;br /&gt;
Die betrachteten [[Betriebsmittel (Informatik)|Ressourcen]] sind fast immer die Anzahl der benötigten Rechenschritte ([[Zeitkomplexität]]) oder der Speicherbedarf ([[Platzkomplexität]]). Die Komplexität kann aber auch bezüglich einer anderen Ressource bestimmt werden. Dabei interessiert nicht der Aufwand eines konkreten [[Computerprogramm|Programms]] auf einem bestimmten Computer, sondern viel mehr, &amp;#039;&amp;#039;wie&amp;#039;&amp;#039; der Ressourcenbedarf wächst, wenn mehr Daten zu verarbeiten sind, also z.&amp;amp;nbsp;B. ob sich der Aufwand für die doppelte Datenmenge verdoppelt oder quadriert ([[Skalierbarkeit]]).&lt;br /&gt;
&lt;br /&gt;
Oft ist es schwierig, eine Funktion anzugeben, die allgemein zu jeder beliebigen Eingabe für ein Problem den zugehörigen Aufwand an Ressourcen angibt. Daher begnügt man sich in der Regel damit, [[Konstante Funktion|konstante]] [[Faktor (Mathematik)|Faktoren]] und [[Summand]]en auszulassen und sich lediglich mit dem Verhalten in Abhängigkeit der &amp;#039;&amp;#039;Eingabelänge&amp;#039;&amp;#039; &amp;lt;math&amp;gt;n = |w|&amp;lt;/math&amp;gt; zu befassen. Die Eingabelänge wird hierbei in der Anzahl an [[Bit]]s gemessen, die benötigt werden, um die Information darzustellen.&lt;br /&gt;
&lt;br /&gt;
Eine weitere Vereinfachung ist die Annahme, dass alle elementaren Operationen dieselbe Zeit benötigen, sodass z.&amp;amp;nbsp;B. die [[Addition]] zweier Zahlen und die [[Multiplikation]] zweier Zahlen genau eine Zeiteinheit kostet.&lt;br /&gt;
&lt;br /&gt;
Algorithmen und Probleme werden in der Komplexitätstheorie gemäß ihrer so bestimmten Komplexität in so genannte [[Komplexitätsklasse]]n eingeteilt. Diese sind ein wichtiges Werkzeug, um bestimmen zu können, welche Probleme „gleich schwierig“, beziehungsweise welche Algorithmen „gleich mächtig“ sind. Dabei ist die Frage, ob zwei Komplexitätsklassen gleichwertig sind, oft nicht einfach zu entscheiden (zum Beispiel [[P-NP-Problem]]).&lt;br /&gt;
&lt;br /&gt;
Die Komplexität eines Problems ist zum Beispiel entscheidend für die [[Kryptographie]] und insbesondere für die [[asymmetrische Verschlüsselung]]: So verlässt sich zum Beispiel das [[RSA-Kryptosystem|RSA]]-Verfahren auf die Vermutung, dass die [[Primfaktorzerlegung]] von großen Zahlen nur mit sehr viel Aufwand zu berechnen ist – anderenfalls ließe sich aus dem [[Öffentlicher Schlüssel|öffentlichen Schlüssel]] leicht der [[Privater Schlüssel|private Schlüssel]] errechnen.&lt;br /&gt;
&lt;br /&gt;
Ein Problem, das selbst für einen Computer von der Größe der Erde nicht lösbar ist, wird als [[transcomputationales Problem]] bezeichnet.&lt;br /&gt;
&lt;br /&gt;
== Komplexität von Daten ==&lt;br /&gt;
In der [[Informationstheorie]] versteht man unter der Komplexität von Daten bzw. einer [[Nachricht]] ihren [[Informationsgehalt]]. Neben der klassischen Definition dieser Größe nach [[Claude Shannon]] gibt es verschiedene andere Ansätze, zu bestimmen, wie viel [[Information]] in einer Datenmenge enthalten ist:&lt;br /&gt;
&lt;br /&gt;
Zum einen gibt es die so genannte &amp;#039;&amp;#039;[[Kolmogorow-Komplexität]]&amp;#039;&amp;#039; (auch &amp;#039;&amp;#039;Algorithmische Komplexität&amp;#039;&amp;#039; oder &amp;#039;&amp;#039;Beschreibungskomplexität&amp;#039;&amp;#039;), die den Informationsgehalt als die Größe des kleinsten Programms definiert, das in der Lage ist, die betrachteten Daten zu erzeugen. Sie beschreibt eine absolut optimale [[Datenkompression|Komprimierung]] der Daten. Eine Präzisierung des Ansatzes [[Andrei Nikolajewitsch Kolmogorow|Andrei Kolmogorows]] bezüglich des [[Maschinenmodell]]s bietet die &amp;#039;&amp;#039;[[Algorithmische Informationstheorie]]&amp;#039;&amp;#039; von [[Gregory Chaitin]].&lt;br /&gt;
&lt;br /&gt;
Dagegen betrachtet &amp;#039;&amp;#039;[[Algorithmische Tiefe]]&amp;#039;&amp;#039; (auch &amp;#039;&amp;#039;Logische Tiefe&amp;#039;&amp;#039;) die [[Zeitkomplexität]] eines optimalen Algorithmus zur Erzeugung der Daten als Maß für den Informationsgehalt.&lt;br /&gt;
&lt;br /&gt;
== Softwarekomplexität ==&lt;br /&gt;
Programm- oder Softwarekomplexität umfasst viele Eigenschaften einer Software, die einen Einfluss auf interne Interaktionen haben. Meist wird zwischen den Begriffen &amp;#039;&amp;#039;Komplex&amp;#039;&amp;#039; und &amp;#039;&amp;#039;Kompliziert&amp;#039;&amp;#039; unterschieden. Kompliziert bedeutet in diesem Zusammenhang &amp;#039;&amp;#039;für Programmierer schwer zu verstehen&amp;#039;&amp;#039;, also eine interne Eigenschaft des Codes, der Algorithmen, des technischen Designs oder der Architektur der Software. Komplexität wiederum beschreibt die Eigenschaften der Interaktionen zwischen Teilen der Software. Mit der Anzahl der Abhängigkeiten zwischen Teilen der Software steigt die Anzahl der Interaktionen und somit die Komplexität der Software. Das Verständnis der Abhängigkeiten und Interaktionen hat einen großen Einfluss auf das gesamte Verständnis der Software, darum wird Software, wenn sie komplexer wird, auch schwerer zu verstehen, also komplizierter. Die Komplexität einer Software kann einen Grad erreichen, wo es für Menschen unmöglich ist, die Software vollumfänglich zu verstehen.&lt;br /&gt;
&lt;br /&gt;
Ähnlich dazu erhöht eine hohe Komplexität das Risiko, dass Änderungen an einer Stelle ungewollte Auswirkungen an einer anderen Stelle bewirken. Das führt zu einer höheren Wahrscheinlichkeit, Fehler in die Software einzubauen, und zu größeren Aufwänden, die Ursache dieser Fehler zu finden bzw. diese zu beheben. Im schlechtesten Fall kann die Komplexität dazu führen, dass die Software de facto unwartbar wird, da die Risiken von Änderungen deren Nutzen übersteigen. Die Abhängigkeit zwischen Komplexität und [[Softwarewartung#Wartungsaufwand|Wartungsaufwand]] wurden durch [[Meir Manny Lehman]] untersucht und in seinen Gesetzen der Softwareevolution 1980 zusammengefasst.&amp;lt;ref&amp;gt;{{Literatur |Autor=M.M. Lehman |Titel=Programs, Life Cycles, and Laws of Software Evolution |Sammelwerk=Proceedings of the IEEE 68 |Datum=1980 |Seiten=1060-1076 |Sprache=en}}&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Meir Manny Lehman und [[Laszlo Belady]] untersuchten auch eine Reihe von [[Softwaremetrik]]en zur Messung des Zustandes einer Software.&amp;lt;ref&amp;gt;{{Literatur |Autor=Meir Manny Lehman, Les A. Belady |Titel=Program Evolution |TitelErg=Processes of Software Change |Hrsg=Academic Press Inc |Datum=1985-12-01 |Sprache=en |Umfang=538 |ISBN=978-0124424418}}&amp;lt;/ref&amp;gt; Die folgenden Softwaremetriken messen die Komplexität von Daten und Algorithmen in der Informatik auf unterschiedliche Art und Weise:&lt;br /&gt;
; Chapins Data-Metrik: Misst den Anteil der Bedingungs- und Ergebnisdaten an allen verwendeten Daten.&lt;br /&gt;
; Elshofs Data-Flow-Metrik: Misst die Anzahl der Datenverwendungen relativ zur Anzahl der Daten. Sie ist verwandt mit hoher [[Kohäsion (Informatik)|Kohäsion]]. Hohe Kohäsion entspricht einer häufigen Verwendung von möglichst wenig Variablen.&lt;br /&gt;
; Cards Data-Access-Metrik: Misst das Verhältnis der Anzahl der Zugriffe auf externe Dateien und Datenbanken relativ zur Anzahl derselben.&lt;br /&gt;
; Henrys Interface-Metrik: Misst die Anzahl der Zugriffe von fremden Funktionen/Methoden in ein Modul (englisch &amp;#039;&amp;#039;fan-in&amp;#039;&amp;#039;) beziehungsweise Anzahl der Aufrufe fremder Funktionen/Methoden aus einem Modul (englisch &amp;#039;&amp;#039;fan-out&amp;#039;&amp;#039;) relativ zu allen Funktionen/Methoden des Moduls.&amp;lt;ref&amp;gt;{{Literatur |Autor=S. Henry, D. Kafura |Titel=Software Structure Metrics Based on Information Flow |Hrsg=IEEE |Sammelwerk=IEEE Transactions on Software Engineering |Band=SE-7 |Nummer=5 |Datum=1981-09 |Sprache=en |Seiten=510 - 518 |ISSN=1939-3520 |DOI=10.1109/TSE.1981.231113 |Zitat=&amp;quot;the procedure length multiplied by the square of fan-in multiplied by fan-out&amp;quot;}}&amp;lt;/ref&amp;gt;&lt;br /&gt;
; [[McCabe-Metrik]] bzw. Eulers Maß bzw. Zyklomatische Komplexität: Misst die Komplexität des Ablaufgraphen als Verhältnis der Kantenanzahl zur Knotenanzahl.&lt;br /&gt;
; McClures Decision-Metrik: Misst den Anteil der Entscheidungen an allen Anweisungen.&lt;br /&gt;
; [[Harry Sneed|Sneeds]] Branching-Metrik: Misst das Verhältnis der Anzahl Verzweigungen jeglicher Art zur Summe aller Anweisungen.&lt;br /&gt;
; [[Halstead-Metrik]]: Misst die Anzahl der verschiedenen Wörter (hier Anweisungstypen) relativ zur Anzahl verwendeter Wörter (hier Anweisungen). Sie behauptet, je weniger verschiedene Anweisungstypen man verwendet, desto einfacher ist der Code, was sehr umstritten ist.&lt;br /&gt;
; NPATH: Zählt die azyklischen Pfade durch Funktionen&amp;lt;ref&amp;gt;{{Literatur |Autor=Brian A. Nejmeh |Titel=NPATH: a measure of execution path complexity and its applications |Sammelwerk=Communications of the ACM |Band=31 |Nummer=2 |Datum=1988-02 |Seiten= |DOI=10.1145/42372.42379}}&amp;lt;/ref&amp;gt;&lt;br /&gt;
; Cognitive Complexity: Wird von [[SonarQube]] zur Messung der Komplexität von Programmen und Programmteilen gegenüber anderen Komplexitätsmetriken empfohlen.&amp;lt;ref&amp;gt;{{Literatur |Autor=G. Ann Campbell |Titel=Cognitive Complexity |TitelErg=A new way of measuring understandability |Hrsg=SonarSource |Datum=2016 |Sprache=en |Umfang=20 |Online=https://www.sonarsource.com/docs/CognitiveComplexity.pdf |Format=PDF |KBytes=214 |Abruf=2020-03-10}}&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Sechs Komplexitätsmetriken für [[Objektorientierte Analyse und Design|objektorientiertes Design]] wurden von S.R. Chidamber und C.F. Kemerer 1994 vorgestellt:&amp;lt;ref&amp;gt;{{Literatur |Autor=S.R. Chidamber, C.F. Kemerer |Titel=A Metrics Suite for Object-Oriented Design |Hrsg=IEEE |Sammelwerk=IEEE Transactions on Software Engineering |Band=20 |Nummer=6 |Datum=1994-06 |Sprache=en |Seiten=476 - 493 |ISSN=1939-3520 |DOI=10.1109/32.295895}}&amp;lt;/ref&amp;gt; Gewichtete Methoden pro Klasse, Kopplung zwischen Objektklassen, Antworten pro Klasse, Anzahl an Subklassen, Tiefe des Vererbungsbaumes und ungenügende [[Kohäsion (Informatik)|Kohäsion]] von Methoden.&lt;br /&gt;
&lt;br /&gt;
== Siehe auch ==&lt;br /&gt;
* [[Effizienz (Informatik)|Effizienz]]&lt;br /&gt;
&lt;br /&gt;
== Einzelnachweise ==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{SORTIERUNG:Komplexitat #Informatik}}&lt;br /&gt;
[[Kategorie:Komplexitätstheorie]]&lt;/div&gt;</summary>
		<author><name>imported&gt;Redonebird</name></author>
	</entry>
</feed>