Softwaredesign und -architektur
Softwaredesign und -architektur befassen sich damit, wie ein Softwaresystem in Komponenten und Konnektoren strukturiert ist, wie Verantwortlichkeiten aufgeteilt werden und wie Designentscheidungen funktionale Anforderungen und Qualitätsattribute erfüllen.
Definition
Softwaredesign ist der Prozess der Definition der Architektur, Komponenten, Schnittstellen und anderer Merkmale eines Systems, und Softwarearchitektur ist die Menge der Strukturen, die die Elemente des Systems, ihre Beziehungen und die Eigenschaften beider umfassen.
Scope
Dieser Bereich umfasst Architekturstile und -muster (geschichtet, Client-Server, Microservices, ereignisgesteuert, Pipe-and-Filter); Designprinzipien wie Modularität, Informationskapselung, Kohäsion, Kopplung und Trennung der Belange; objektorientiertes und komponentenbasiertes Design; Entwurfsmuster; architektonische Qualitätsattribute und deren Kompromisse; sowie Modellierungsnotationen wie UML, die zur Darstellung von Designs verwendet werden.
Sub-topics
Core questions
- Wie sollte ein System in Module und Komponenten zerlegt werden?
- Welcher Architekturstil unterstützt die erforderlichen Qualitätsattribute am besten?
- Wie leiten Designprinzipien wie Kopplung und Kohäsion eine gute Struktur?
- Wie werden wiederkehrende Designprobleme durch wiederverwendbare Muster gelöst?
Key theories
- Informationskapselung und Modularität
- Parnas argumentierte, dass Module so definiert werden sollten, dass sie voraussichtlich ändernde Designentscheidungen hinter stabilen Schnittstellen verbergen, sodass Änderungen lokalisiert werden; dieses Prinzip liegt der Modularität, Kapselung und geringen Kopplung zugrunde.
- Architektonische Qualitätsattribute und Kompromisse
- Architektur wird von Qualitätsattributen wie Leistung, Änderbarkeit, Verfügbarkeit und Sicherheit bestimmt; da diese im Konflikt stehen, geht es bei der Architektur grundsätzlich darum, Kompromisse abzuwägen, die durch Taktiken und Muster geleitet werden.
- Entwurfsmuster
- Wiederkehrende Designprobleme haben gut verstandene, benannte Lösungen – erzeugende, strukturelle und verhaltensbezogene Muster –, die Expertenpraxis erfassen und ein gemeinsames Vokabular für objektorientiertes Design bieten.
Clinical relevance
Architekturentscheidungen sind später am schwierigsten zu ändern und bestimmen am stärksten die Qualitätsattribute eines Systems. Daher reduzieren ein solides Design und eine solide Architektur die langfristigen Wartungskosten, ermöglichen Skalierbarkeit und Evolution und prägen die Teamorganisation.
Evidence & guidelines
Der Standard ISO/IEC/IEEE 42010 standardisiert die Architekturbeschreibung, und der SWEBOK-Wissensbereich Softwaredesign liefert zusammen mit Referenztexten wie „Software Architecture in Practice“ konsensbasierte Leitlinien.
History
Modulare Designprinzipien wurden von Parnas in den frühen 1970er Jahren formuliert. Objektorientiertes Design und Entwurfsmuster reiften in den 1980er und 1990er Jahren, Softwarearchitektur entwickelte sich Mitte der 1990er Jahre mit der Arbeit von Shaw und Garlan zu einer eigenständigen Disziplin, und serviceorientierte sowie Microservice-Stile folgten in den 2000er und 2010er Jahren.
Debates
- Monolithische versus Microservice-Architektur
- Ob Systeme als einzelner deploybarer Monolith oder als viele unabhängig deploybare Dienste gebaut werden sollen, wird breit diskutiert; Microservices bieten unabhängige Skalierung und Bereitstellung auf Kosten der Komplexität verteilter Systeme, sodass die richtige Wahl von Skalierung und Organisationsstruktur abhängt.
Key figures
- David Parnas
- Mary Shaw
- Len Bass
- Erich Gamma
- Grady Booch
Related topics
Seminal works
- parnas1972
- gamma1994
- bass2012
Frequently asked questions
- Was ist der Unterschied zwischen Design und Architektur?
- Architektur betrifft die höchsten Strukturen und die am schwierigsten zu ändernden Entscheidungen – Hauptkomponenten, deren Interaktionen und systemweite Qualitätsattribute –, während Design die detailliertere interne Struktur dieser Komponenten abdeckt; die Grenze ist eher eine der Bedeutung als eine scharfe Trennlinie.
- Warum sind Entwurfsmuster wichtig?
- Muster erfassen bewährte Lösungen für wiederkehrende Designprobleme und geben Ingenieuren ein gemeinsames Vokabular, wodurch Designs leichter zu kommunizieren, zu begründen und weiterzuentwickeln sind; sie sind eine Richtschnur, die umsichtig angewendet werden sollte, keine zwingenden Rezepte.