In den späten 1960er Jahren teilten gute Programmierer eine Intuition über die Softwareentwicklung: Wenn man die Datenstrukturen richtig hinbekommt, wird der Aufwand die Entwicklung des restlichen Programms viel einfacher machen. Die Arbeit an abstrakten Datentypen der 1970er Jahre kann als eine Entwicklungsmaßnahme angesehen werden, die diese Intuition in eine reale Theorie umwandelte. Der Übergang von einer Intuition zu einer Theorie erforderte Verständnis
• die Softwarestruktur (die eine mit ihren primitiven Operatoren verpackte Darstellung enthielt),
• Spezifikationen (mathematisch Architektur Modellbau Bielefeld ausgedrückt als abstrakte Modelle oder Algebraicaxiome),
• Sprachprobleme (Module, Umfang, benutzerdefinierte Typen),
• Integrität des Ergebnisses (Invarianten von Datenstrukturen und Schutz vor sonstiger Manipulation),
• Regeln für die Kombination von Typen (Deklarationen),
• Ausblenden von Informationen (Schutz von Eigenschaften, die nicht explizit in den Spezifikationen enthalten sind). Der Effekt dieser Arbeit bestand darin, das Designniveau bestimmter Elemente von Softwaresystemen, nämlich abstrakter Datentypen, über das Niveau von Programmiersprachenanweisungen oder einzelnen Algorithmen zu heben. Diese Form der Abstraktion führte zu einem Verständnis einer guten Organisation für ein ganzes Modul, das einem bestimmten Zweck dient. Dabei wurden Darstellungen, Algorithmen, Spezifikationen und funktionale Schnittstellen auf einheitliche Weise kombiniert. Natürlich war eine gewisse Unterstützung durch die Programmiersprache erforderlich, aber das abstrakte Datentypparadigma ermöglichte die Entwicklung einiger Teile von Systemen aus einem Vokabular von Datentypen und nicht aus einem Vokabular von Programmiersprachenkonstrukten.
Softwarearchitektur So wie gute Programmierer Ende der 1960er Jahre nützliche Datenstrukturen erkannten, erkennen gute Softwaresystemdesigner heute nützliche Systemorganisationen. Garlan & Shaw: Eine Einführung in die Softwarearchitektur 5 Eine davon basiert auf der Theorie abstrakter Datentypen. Dies ist jedoch nicht die einzige Möglichkeit, ein Softwaresystem zu organisieren. Viele andere Organisationen haben sich im Laufe der Zeit informell entwickelt und sind heute Teil des Vokabulars von Softwaresystementwicklern. Typische Beschreibungen von Softwarearchitekturen umfassen beispielsweise Zusammenfassungen wie (von uns kursiv):
• „Camelot basiert auf dem Client-Server-Modell und nutzt Remote-Prozeduraufrufe sowohl lokal als auch remote, um die Kommunikation zwischen Anwendungen und Servern bereitzustellen.“
• „Abstraktionsschichtung und Systemzerlegung vermitteln den Clients den Eindruck von Systemeinheitlichkeit, ermöglichen Helix jedoch die Aufnahme einer Vielzahl autonomer Geräte. Die Architektur fördert ein Client-Server-Modell für die Strukturierung von Anwendungen.“
• „Wir haben einen verteilten, objektorientierten Ansatz zur Verwaltung von Informationen gewählt.“
• „Der einfachste Weg, den kanonischen sequentiellen Compiler in einen gleichzeitigen Compiler zu verwandeln, besteht darin, die Ausführung der Compilerphasen über eine Reihe von Prozessoren zu verteilen … Eine effektivere Möglichkeit besteht darin, den Quellcode in viele Segmente aufzuteilen, die …“ werden gleichzeitig durch die verschiedenen Phasen der Kompilierung [von mehreren Compilerprozessen] verarbeitet, bevor ein abschließender Zusammenführungsdurchlauf den Objektcode wieder zu einem einzigen Programm zusammenfügt. Andere Softwarearchitekturen werden sorgfältig dokumentiert und häufig weit verbreitet. Beispiele hierfür sind das Open Systems Interconnection Reference Model (eine mehrschichtige Netzwerkarchitektur) der International Standard Organization, das NIST/ECMA Reference Model (eine generische Software-Engineering-Umgebungsarchitektur, die auf mehrschichtigen Kommunikationssubstraten basiert) und das X Window System (eine verteilte Benutzeroberflächenarchitektur mit Fenstern). basierend auf Ereignisauslösung und Rückrufen). Wir sind noch weit davon entfernt, über eine anerkannte Taxonomie solcher Architekturparadigmen zu verfügen, geschweige denn über eine vollständig entwickelte Theorie der Softwarearchitektur. Aber wir können mittlerweile eine Reihe architektonischer Muster oder Stile klar identifizieren, die derzeit das Grundrepertoire eines Softwarearchitekten bilden.