Wichtigkeit von SW Architektur

[MrSpock]

In diesem Beitrag hat Holger die Wichtigkeit einer vorhandenen SW Architektur beschrieben. Ich hatte darauf geantwortet und einige weiterführende Fragen gestellt. Da es aber in dem dortigen Thread untergegangen ist, stelle ich die frage hier nochmal.

Zitat von IBExpert:

...
Das hat auch nichts mit einer Delphi Wohlfühlblase zu tun, wenn du eine Architektur als Backend hast ist, dann ist die Programmiersprache und IDE extrem austauschbar. Ohne Architektur machst du in der nächsten Welt viele Fehler wieder und hast nur den Teufel durch den Belzebub ersetzt.

Hallo Holger, ...

Eine Frage habe ich zur praktischen Anwendung der "Softwarearchitektur". Ich habe mich mit dem Thema Systemarchitektur schon oft auseinandergesetzt und kenne zum Beispiel den amerikanischen Verteidigungsstandard DoDAF zur Definition einer Architektur. Mich würde interessieren, wie ihr die Architektur definiert und nach Delphi bzw. Lazarus umgesetzt habt. Nutzt ihr UML, wenn ja, welches Tool und welche Ansichten. Beschränkt sich die Architektur auf Klassendiagramme oder geht sie darüber hinaus?

Neben dem Vorgehen von Holger, interessiert mich auch, wie andere professionelle Entwickler von Euch vorgehen, um eine SW Architektur zu beschreiben und zu entwickeln.

[AlexII]

Gute Frage, habe mich auch schon gefragt wie das gemacht wird. Da ich immer "ohne Plan" schreibe, und nach einem Jahr nicht mehr weiß, wie das ganze funktioniert.

[jobo]

Vor UML steht m.E. eine Sammlung von Anforderungen, die schon abhängig von der Projektart erhoben werden müssen.
- Kundenprojekt
- eigenes Produkt
- Neuentwicklung / Weiterentwicklung

Dann wäre zu klären, wie heterogen die Einsatzlandschaft ist und Nutzungsart. Jenachdem komme ich hier zu verteilten Systemen, Mehrschicht -, Zweischicht oder Monolith. Mehrschichtsysteme und verteilte laufen meist auf unterschiedlichen Architekturen. Unterschiedliche Architekturen haben unterschiedliche Anforderungen und Aufgaben. Daraus ergeben sich diverse Vorgaben, die das System erfüllen muss.
Diese Vorgaben gehen m.E. in Summe weit über eine funktionale bzw. fachliche Anforderung hinaus, sie betreffen auch Sicherheitsaspekte, Administration, Verfügbarkeit, Ressourcenbedarf, Kosten usw.

Damit kann man modellieren, z.B. in UML, BPMN, ..

Auch wenn es ja in einem solchen Prozess keine Umsetzungsentscheidungen geben soll. In der Realität ist das normal, von Unternehmenspolicies ala "nur MS Produkte mit Wartung / Support", über existierende Partnerschaften und eigene Produktlandschaften bis hin zu Entwickler und Know How Ressourcen bis was weiß ich. Diese Themen werden ebenso gesetzt

[Perlsau]

Unter Software-Architektur verstand ich bislang immer die Gestaltung der grundsätzlichen Arbeitsweise einer zu entwickelnden Anwendung. Dazu gehört erst einmal die Frage nach der Gestaltung der GUI, aber auch andere Fragen, z.B.:

• Wie soll das Ganze am Ende aussehen?
• Soll sich alles in einem Fenster abspielen?
• Arbeite ich mit Frames oder mit TabSheets?
• Lege ich Wert auf intuitive Bedienbarkeit?
• Wie gestalte ich die GUI so, daß sie für den Anwender übersichtlich bleibt?
• Setze ich auf einzubindende Module, die bei Bedarf zusätzlich erworben werden können?
• Setze ich mehr auf Menüsteuerung oder stehen Buttons und Toolbars im Vordergrund?
• Baue ich, um mit mehreren Dokumenten gleichzeitig umgehen zu können, eine MDI-Anwendung oder mache ich das wie bei MS-Word, daß für jedes Dokument die gesamte Anwendung wiederholt referenziert wird?
• Verwende ich kommerzielle Fremdkomponenten oder entwickle ich mir meine eigenen?

Das könnte man sicher noch um etliche Punkte ergänzen. Zur Software-Architektur gehört meiner Einschätzung nach aber auch die Frage, wie ich "intern" vorgehe:

• Habe ich überhaupt einen Plan oder programmiere ich eher "wild drauflos"?
• Arbeite ich direkt mit der Datenbank oder verwende ich Klassen (Objekte), um die Daten bereitzustellen und zu bearbeiten?
• Wie flexibel soll meine Anwendung hinsichtlich ihrer Verwendbarkeit sein? Z.B. bei Datenbank-Anwendungen mit Firebird: Wie gestalte ich die Anwendung so, daß sie wahlweise als StandAlone (Embedded-DB), als Serverversion mit lokalem oder Remote-Server einsetzbar ist?
• Welche Bereiche eines Projekts lagere ich in DLLs aus, so daß sie von anderen Projekten wieder verwendet werden können?
• Wie organisiere ich Units, um auch nach Jahren nahezu sofort den Überblick zu erhalten?
• Halte ich mich strikt an die Objektorientierung oder weiche ich bei Bedarf davon ab?
• Baue ich meine Anwendung modular auf und halte die Zuständigkeiten übersichtlich?

Derzeit präferiere ich die Arbeit mit Frames, die jeweils ein Modul darstellen und alle von einem Default-Frame abstammen, der bereits wichtige Methoden und Deklarationen enthält, die zur Verwaltung der Frames benötigt werden. Damit hab ich inzwischen mehrere Projekte absolviert, so daß ich diese Architektur mehr oder weniger verinnerlichen konnte. Damit habe ich nun eine Grund-Architektur für Projekte mit Frames, die als Vorlage für weitere Projekte dienen. Das verstehe ich unter Software-Architektur: Eine bestimmte Vorgehensweise, ein bestimmtes Konzept, bestimmte strikte Regeln, die eingehalten werden müssen und durch all das eine konkrete Linie, entlang der ein Projekt entwickelt wird.

[mkinzler]

Wobei das was Du "intern" nennst eigentlich das Wichtigere ist! Bzw. ein Teil davon, und vor Allem das, was Du vergessen hast.

Die UI ist in diesem Kontext unwichtig, bzw. gehört nur bedingt zur Architektur.

Zitat:

Habe ich überhaupt einen Plan oder programmiere ich eher "wild drauflos"?

Wild drauf los Programmieren verträgt sich nicht mit "Architektur", welche imho einen Plan bedingt.

• Einzelplatz;Client/Server;verteilt
• Fat/Thin Client
• ...

Zitat:

Arbeite ich direkt mit der Datenbank oder verwende ich Klassen (Objekte), um die Daten bereitzustellen und zu bearbeiten

Wenn man hierunter Bridgepattern o.ä versteht, könnte man das unter die Architektur stecken, sonst ist das ein Implementierungsdetail.

[Perlsau]

Zitat von mkinzler:

Wobei das was Du "intern" nennst eigentlich das Wichtigere ist! Bzw. ein Teil davon, und vor Allem das, was Du vergessen hast.

Nein, ich habe nichts vergessen, sondern lediglich beschrieben, was ich bislang unter Software-Architektur verstanden habe. Vergessen würde ja ein Wissen voraussetzen, das beim Wiedergeben übersehen wurde. Das ist hier nicht der Fall, denn ich weiß nicht mehr als das, was ich hier genannt habe. Auch möchte ich mich mit meinen Beitrag nicht unnötig wichtig machen, sondern habe lediglich auf die Frage von Albert geantwortet:

Zitat von MrSpock:

Neben dem Vorgehen von Holger, interessiert mich auch, wie andere professionelle Entwickler von Euch vorgehen, um eine SW Architektur zu beschreiben und zu entwickeln.

Natürlich könntest du jetzt entgegnen, ich sei kein professioneller Entwickler und gehöre daher nicht wirklich zur Zielgruppe. Diese Einschätzung bleibt dir überlassen ... Mich interessiert dieses Thema jedoch sehr, weshalb ich meine Definition des Begriffs hier darzustellen versucht habe.

Zitat von mkinzler:

Die UI ist in diesem Kontext unwichtig, bzw. gehört nur bedingt zur Architektur.

Das konnte ich der Definition bei Wikipedia nicht entnehmen, denn dort steht:

Eine Definition von Helmut Balzert beschreibt den Begriff als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“. Die Architekturkomponenten bilden eine Zerlegung des Gesamtsystems, was bedeutet, dass jedes Softwareelement genau einer Architekturkomponente zugeordnet ist.
Paul Clements beschreibt Softwarearchitektur als „Strukturen eines Softwaresystems: Softwareteile, die Beziehungen zwischen diesen und die Eigenschaften der Softwareteile und ihrer Beziehungen“.
Die Softwarearchitektur ist Teil des Softwareentwurfs (siehe SWEBOK), innerhalb dessen sie als Grobgliederung der Komponenten entsteht. Während der Softwareentwurf sich auch auf lokale Aspekte innerhalb des architektonischen Rahmens der Software bezieht und deshalb sehr detailliert sein kann, ist die Softwarearchitektur eine globale Eigenschaft des Gesamtsystems.

Dennoch danke ich dir für deine Korrketur, denn nun muß ich in Betracht ziehen, daß die visuelle Gestaltung der Anwendung nicht Teil der Software-Architektur ist – falls deine Aussage zutrifft, was ich derzeit nicht wirklich beurteilen kann.

Zitat von mkinzler:

Zitat:

Habe ich überhaupt einen Plan oder programmiere ich eher "wild drauflos"?

Wild drauf los Programmieren verträgt sich nicht mit "Architektur", welche imho einen Plan bedingt.

Ganz ohne Plan kann niemand eine Anwendung programmieren. Anfänger – und dabei gehe ich auch von mir aus, denn ich war ja schließlich auch einmal Anfänger – haben meist nur einen groben Plan, was die Software können soll und wie sie das erreichen. Zudem ergibt sich auch aus einer mehr oder weniger planlos entwickelten Software eine Architektur. Die Architektur ist ja kein Qualitätsmerkmal, sondern eine Beschreibung der Zusammenhänge der verwendeten Komponenten. Da stellt sich natürlich die Frage, ab welcher "Auflösung" ein Plan als Software-Architektur verstanden werden kann. Muß eine Software-Architektur so viel umfassen bzw. so detailliert sein, daß man sie schriftlich festhalten muß?

Zitat von mkinzler:

Zitat:

Arbeite ich direkt mit der Datenbank oder verwende ich Klassen (Objekte), um die Daten bereitzustellen und zu bearbeiten

Wenn man hierunter Bridgepattern o.ä versteht, könnte man das unter die Architektur stecken, sonst ist das ein Implementierungsdetail.

Was sonst sollte man darunter verstehen? Bridgepattern bedeutet doch die Schicht zwischen Anzeige/Verarbeitung und Datenbank. Ich denke, daß hier eher die Art & Weise, wie ich die Klassen entwickle, zum Implementierungsteil gehört, die Entscheidung jedoch, ob ich die Daten über Klassen, also Objekte bereitstelle, zur Software-Architektur.

[DeddyH]

Mit den Komponenten sind die Teile (oder meinetwegen auch die beteiligten Module) der Software gemeint, das hat mit Delphi-Komponenten nichts zu tun.

[mm1256]

Hallo,

was mich bisher besonders irritiert ist diese Aussage aus dem anderen Thread:

Zitat von IBExpert:

Viele setzen zwar eine Pseudosoftwarearchitektur auf Basis von Delphi Klassen ein, die ist aber oft schon in jede 2. Zeile mit TDataset verheiratet, so das die auf anderen Plattformen so gar nicht mehr implementierbar sind.

Das hat auch nichts mit einer Delphi Wohlfühlblase zu tun, wenn du eine Architektur als Backend hast ist, dann ist die Programmiersprache und IDE extrem austauschbar. Ohne Architektur machst du in der nächsten Welt viele Fehler wieder und hast nur den Teufel durch den Belzebub ersetzt.

Architektur als Backend...wieso sind dann Programmiersprache und IDE "extrem austauschbar"? Also konkret: Welche Architektur-Merkmale oder -Eigenschaften müssen erfüllt sein, um diesen Austausch so "extrem" realisieren zu können? Das würde mich "extrem" interessieren.

[Perlsau]

Zitat von DeddyH:

Mit den Komponenten sind die Teile (oder meinetwegen auch die beteiligten Module) der Software gemeint, das hat mit Delphi-Komponenten nichts zu tun.

Das habe ich auch nicht vermutet, daß sich der Komponentenbegriff auf Delphi-Komponenten bezöge, denn schließlich ist die Software-Architektur nicht auf eine Programmiersprache begrenzt. Nun müßte man aus meiner Sicht erst einmal definieren, was denn Teile oder Module im Zusammenhang mit Software-Architektur sind, denn auch hier darf man wohl nicht davon ausgehen, daß sie mit implementierten Modulen gleichzusetzen wären. Wikipedia meint dazu:

Ein Modul ist eine abgeschlossene funktionale Einheit einer Software, bestehend aus einer Folge von Verarbeitungsschritten und Datenstrukturen. Inhalt eines Moduls ist häufig eine wiederkehrende Berechnung oder Bearbeitung von Daten, die mehrfach durchgeführt werden muss. Das Modul führt eine Reihe von Verarbeitungsschritten durch, liefert bei der Rückkehr an das aufrufende Programm Daten als Ergebnis zurück.

Dann wäre jede Funktion im Programm ein Modul? Oder zusammengehörende Methoden z.B. einer Klasse wären ein Modul? Was ich damit sagen will: Es ist schwer, solche abstrakten Modelle wie die Software-Architektur zu verstehen, wenn die in der Erläuterung verwendeten Begriffe nicht eindeutig definiert sind. Wenn ich versuche, mir das alles mit Wikipedia zu erschließen, begegnet mir eine zunehmende Anzahl solcher Begriffe, die ich wiederum nachschlagen muß und die dann zu noch mehr unbekannten bzw. undefinierten Begriffen führen. Immerhin finde ich in der Erklärung des Modulbegriffs nun wieder einen Bezug zur Software-Architektur:

Ein Aspekt der Softwarearchitektur ist die Herstellung von Unterprogrammen zur Verwendung in mehreren Computerprogrammen/-Anwendungen. Bestimmte technische oder betriebliche Funktionen (zum Beispiel eine Prüfziffernberechnung) können so beispielsweise unternehmensweit einheitlich genutzt werden.

Natürlich weiß ich nicht, inwieweit Wikipedia-Artikel von kompetenten IT-Fachleuten geschrieben wurden und ob sie dem aktuellen Stand entsprechen, aber ich gehe einmal davon aus, daß dem zumindest im wissenschaftlich-technischen Bereich so ist. Die Beschreibung der aktuellen Bedeutung von Software-Architektur sieht demnach so aus:

Die Beschreibung einer Softwarearchitektur enthält Informationen über die Struktur („Komponentisierung“) eines Software-Systems, aber auch Informationen über die Kommunikation zwischen Komponenten, sowie deren Abbildung auf Hardware- oder Software-Ressourcen (Verteilung und Deployment). Dabei kann eine Softwarearchitektur unterschiedliche Ausprägungen haben:

• So kann in einer Funktionsarchitektur (oder auch fachliche Architektur) die Gliederung des Systems in Funktionen oder Features dargestellt werden.
• In der Komponentenarchitektur wird der Grobentwurf des Systems in einzelne Komponenten festgehalten.
• Dieser Grobentwurf lässt sich im Feinentwurf feingranularer darstellen. Hierbei handelt es sich beispielsweise um Klassenhierarchien, Modularchitekturen oder programmiersprachenspezifischen Quelltext. Die Übergänge zwischen Feinentwürfen sind teilweise fließend.

Festzuhalten ist, dass es nicht die eine Softwarearchitektur eines System gibt. Es müssen je nach Fragestellung und Interessenspunkt unterschiedliche Sichten hinzugezogen werden. Ein Beispiel hierfür ist das 4+1 Sichtenmodell (schon wieder so ein Begriff).

[mjustin]

Zitat von mm1256:

Architektur als Backend...wieso sind dann Programmiersprache und IDE "extrem austauschbar"? Also konkret: Welche Architektur-Merkmale oder -Eigenschaften müssen erfüllt sein, um diesen Austausch so "extrem" realisieren zu können? Das würde mich "extrem" interessieren.

"Architektur als Backend" ist nicht besonders selbsterklärend Ich verstehe es so, dass man im Backend eine sprachunabhängige Schnittstelle bereitstellt, mit der "das" Frontend (es können aber auch mehr als eins sein, z.B. ein mobiler Client, eine Web-Anwendung...) kommuniziert.

Diese sprachunabhängige Schnittstelle kann alle möglichen Ausprägungen haben - es kann eine simple Request/Response Web Service Schnittstelle sein (JSON über HTTP), oder ein Mix aus Kommunikationsmodellen (Broadcast, Publish/Subscribe ...).

"Extrem" einfach ist der Austausch, wenn die Schnittstelle nur Techniken und Protokolle verwendet die von allen gewünschten Entwicklungsumgebungen oder Sprachen weitgehend unterstützt werden. Ein Beispiel ist SOAP: wenn alle Werkzeuge in der Lage sind, eine WSDL-Datei (Web Service Definition) zu verstehen und daraus client- oder serverseitigen Sourcecode zu erzeugen, kann man SOAP einsetzen. Wenn man dann den Server austauschen will, kann man dies tun ohne an den Clients Änderungen vornehmen zu müssen.