Wichtigkeit von SW Architektur

[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.

[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.

[jobo]

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.

Ich vermute, dass eine "klassische" 3 Schicht Architektur gemeint ist. Also Datenschicht, (Business)Logik und die (austauschbare) Darsstellungs-/Anwenderschicht, realisierbar über Interfaces für Daten, Befehle, also Rest, SOAP usw..
Total beliebig ist es natürlich nicht, sondern man geht davon aus, dass backend seitig die Services oder Daten konform zu gewissen Standards bereitgestellt werden. Letztlich definiert sich genau der Nutzen der "Austauschbarkeit" und damit Unabhängigkeit und Flexibilität an den verwendeten Interfaces, die Anzahl der Schichten bzw. das konkrete Produkt ist dann eben egal. Zumindest in der Theorie, in der Praxis eben dann, wenn beide Seiten des Interfaces dieses auch vollständig und fehlerfrei bedienen.

Interface Beispiel IMAP, es interssiert niemanden, welcher Provider, welche Software serverseitig läuft und es interessiert genausowenig, welcher Client, welches ClientOS, .. die Daten abfragt, solange beide IMAP sprechen.

P.S: hab die Antwort von mjustin übersehen.

[Sir Rufo]

Sehr unterhaltsam und lesenswert dazu ist
http://blog.cleancoder.com/uncle-bob...hitecture.html

[HeZa]

Zitat von Sir Rufo:

Sehr unterhaltsam und lesenswert dazu ist
http://blog.cleancoder.com/uncle-bob...hitecture.html

Danke für die Info, das kannte ich noch nicht. Dieses fiktive Interview zeigt ganz gut welche Kräfte sich dem Software Architektur Gedanken in den Weg stellen.

Zitat:

But that means that you're going to have lots of interfaces, and lots of little implementation classes ...

Freie Übersetzung:
Aber das bedeutet ja, dass es ganz viele Schnittstelle (ala IPrintService = interface) gibt, die dann auch noch von ganz vielen kleinen Klassen implementiert werden müssen ...

Da habe ich schon viele Programmier kennengelernt, die von der objektorientiert Entwicklung überzeugt sind und dann sagen, "ach nee nicht noch ne Schnittstelle/Klasse, dass können wir doch auch gleich hier in dieser Methode lösen ..." oder was auch gerne kommt, "aber dann sehe ich gar nicht was passiert, dann muss ich mir jedes mal erst die eigentliche Implementierung suchen ...".

Wenn man sich dem Thema Software Architektur nähern will, dann schießt man meiner Meinung nach mit Begriffen wie MVC, 3-Schichten-Architektur, Micro-Services über das Ziel hinaus. Das sind vorgedachte Architektur Patterns, die im schlimmsten Fall einem Missbrauch nicht standhalten.

Ich gestehe ich lerne auch immer noch. Zur Zeit lese ich (passend zum Link) mal wieder "Clean Code" von Robert C. Martin. Da ich täglich mit Delphi Leagcy-Systemen arbeite deren Entwicklung teilweise mit Delphi3 begonnen wurde, brauch ich manchmal eine kleine Erinnerung um die "hohen" Ziele nicht aus den Augen zu verlieren.

Als ich das Buch zum ersten Mal gelesen habe, haben mir Aussagen wie:

• eine Klasse/Methode sollte nur eine Aufgabe haben
• für eine Klasse/Methode sollte es nur einen Grund geben sie ändern zu müssen

ganz schön "Angst" gemacht haben. Da schaut man sich dann seine eigenen Klassen/Methoden an und zählt mal wieviele Aufgeben die so haben: 5, 10? Dann überschlägt man wieviele Gründe es für Änderungen wohl geben könnte. 20, 50?

Zum Glück ist das schon eine Weile her, aber ich habe ja noch meine Leagacy-Projekte. Vor ein paar Monaten fand man da noch, sagen wir mal 10 Klassen mit mindestens einer Methode, die 30 Parameter hatten, meistens waren es die gleichen, in der gleichen Reihenfolge, aber natürlich nicht immer. Mein Highlight 30 Parameter, 50 locale Variablen, 1000 Zeilen Code.

Zum Glück sind die Dinge die einem helfen können bereits seit langem niedergeschrieben. Lesen und die Kraft finden die Ideen und Vorschläge umzusetzen muss man dann allerdings schon selbst. Leider hatte ich nie einen Kollegen, wie im fiktiven Interview, der weiß wovon er spricht.

[mm1256]

Hallo,

vielen Dank euch Beiden für die Antworten. Dass damit die 3-Schicht-Architektur gemeint sein könnte, hab ich mir auch schon gedacht, war mir allerdings nicht sicher. Denn, daraus die "extreme" Austauschbarkeit der IDE bzw. der Programiersprache abzuleiten, halte ich persönlich für etwas gewagt.

Eine 3-Schicht-Architektur ist wohl nicht extenzielle Grundvoraussetzung für irgend ein popeliges Kleinprojekt. Wenn es folglich um größere Projekte geht, dann wird der Austausch der IDE bzw. der Programmiersprache - egal ob beim Front- oder Backend - schon eine echte Herausforderung, an welcher sich wahrscheinlich schon einige SW-Hersteller etwas "verhoben" haben.

EDIT: @SirRufo Jetzt hab ich etwas mehr Ahnung davon, warum Manager so viel Gutes tun

[mjustin]

Zitat von mm1256:

Wenn es folglich um größere Projekte geht, dann wird der Austausch der IDE bzw. der Programmiersprache - egal ob beim Front- oder Backend - schon eine echte Herausforderung, an welcher sich wahrscheinlich schon einige SW-Hersteller etwas "verhoben" haben.

Großer Vorteil für weitgehend 'entkoppelte' Systemarchitekturen, deren Bausteine man dann leicht auf neue Programmiersprachen oder 'umfangreich renovierte' Programmversionen umstellen kann.
Wenn man es richtig angeht, kann man mit den Bausteinen dieser Architekturen dann auch Lastverteilung auf beliebig viele Server leichter umsetzen als mit monolithischen Lösungen.
Ich habe dazu vor längerer Zeit diese Präsentation gefunden, die das Thema locker angeht:
Dopplr: It's made of messages - Matt Biddulph
Ein lesenswertes Buch das darin empfohlen wird ist "Enterprise Integration Patterns"