1. als Eigenschaft von Software das, was die Struktur der Software ausmacht: die programmtechnischen Elemente aus denen sie besteht und wie diese aufgebaut sind und miteinander interagieren
2. die Tätigkeit, ein SoftwareDesign wie in 1. zu entwickeln

• Die (wesentliche) Struktur einer Software (entwickeln)
• ...

Die Struktur eines Systems (Knochengerüst bei einem Tier, statische Elememente bei einem Bauwert) besteht aus den starren, dauerhaften Elementen. Positiv gesehen gibt die Struktur einem System Kraft und bestimmt Eigenschaften und Freiheitsgrade; Negativ gesehen begrenzt die Struktur durch ihre Starrheit die Entwicklungsmöglichkeiten und erzeugt Probleme, wenn sie den Anforderungen nicht (mehr) entspricht.

Das ist bei Dingen der Fall, bei denen es teuer ist, das Design zu ändern - im wesentlichen jegliche Form von HardWare?. Ich glaube nicht, das SoftwareDesign diese Starrheit ebenfalls besitzen muss oder sollte - im Gegenteil, durch die Anwendung von CodeRefactoring kann ein SoftwareDesign etwas sehr bewegliches, agiles werden.

• Gegenbeispiele von Software-Strukturelementen, die verschiedene Grade von Starrheit bewirken:
• Festlegungen auf Hardware, Sprachen, Libraries, Datenbanken, Tools, Protokolle, Paradigmen, Standards, Hierarchien, Modularisierungen, Bezeichnungen ...
• Sprachen, Paradigmen - dies sind sicherlich Dinge, die sich schwierig im Nachhinein ändern lassen und die das Design wesentlich beeinflussen.
• Hardware, Libraries, Datenbanken, Protokolle - all dies kann in einem guten Design so gekapselt werden, dass Auswirkungen von Änderungen auf einen kleinen Bereich des Systems beschränkt bleiben, und die damit nicht zu einer wesentlichen Starrheit beitragen müssen.
• Tools, Standards - hier bin ich mir nicht ganz im Klaren über den Einfluss auf das Design. Beispiele?
• Hierarchien, Modularisierungen, Bezeichnungen - es scheint mir, als wären dies Teile des Designs, und mir ist nicht ganz klar, inwiefern diese Starrheit *bewirken* (wenn man davon ausgeht, dass sie selber nicht zwangsweise starr *sind*).

Ist das nicht eher das, was man als SoftwareArchitektur? bezeichnen würde?

Sicher gibt es da eine Grauzone (wobei ich eher den Architektur-Begriff entbehrlich finde). Die Grauzone gibt es aber auch nach unten: "Ist alles, was beim Programmieren entsteht Design?" (Andererseits gibt es diesen inflationären Sprachgebrauch schon beim WebDesigner)

Ich meinte an der Stelle schon wirklich "teuer" - wie kann etwas starr sein, das billig zu ändern ist??? -- ip