Vorlagen für Software-Architektur

Das Henne-Ei Problem lässt sich nicht vermeiden. Erst nachdem die 
Software real eingesetzt wird, lässt sich die Struktur ausarbeiten.

Zu diesem Thema gibt es nur 2 brauchbare Leitfäden. Frederick Brooks, 
The Mythical Man-Month und Eric Raymond, The Cathedral and the Bazaar.

Brooks kam zu der Erkenntnis: "plan to throw one away; you will, 
anyhow." Und Raymond erklärt, wie das in der Praxis funktioniert.

Alex schrieb:
> kleinere PC-Tools(Softwareprojekte) in
> C++Builder

Der C-Builder bringt doch eigentlich etliche Komponenten für Editoren 
mit.
Sich eine Buttonliste Basteln und diese mit den entsprechenden 
Funktionsaufrufen verknüpfen ist eine Arbeit von weniger als einer 
Minute.

1

void Form1::Button1Click(...)

2

{

3

  RichEdit1->Undo();

4

}

Softwarearchitektur ist was ganz anderes...

Moin,

Danke schon mal für die Rückmeldungen!

Cyblord -. schrieb:
> Eine SW-Architektur gibt es nicht von der Stange. Was es aber gibt sind
> PATTERN. Die sind genau dafür da, um gleiche Probleme auf die gleiche
> Art zu lösen.
> Trotzdem können die nicht fertig in Code gegossen sein, weil die immer
> auf die konkrete Anwendung passen müssen.

Klar gibt es nicht eine perfekt passende Vorlage für alle meine 
Probleme.
Mein wunsch wäre eher aus einer Menge an Vorlagen die am besten 
passenste zu nehmen, meine Funktionen dort einzubauen und von dem 
Standpunkt aus dann weiter zu machen.

Cyblord -. schrieb:
> Allein dein Undo/Redo Beispiel hängt doch in größtem Maße von den Daten
> ab. Handelt es sich um Text oder Vektorgrafik oder einen Audioeditor.
> Da gibts doch keine Datenstruktur die für alles passt.

Deswegen hoffe ich ja, dass sich schonmal jemand schlaueres als ich 
darüber Gedanken gemacht hat und eine gute Allgemein nützliche Methode 
gefunden hat. Die komplexesten Programme die mir so einfallen sind 
CAD-Editoren - die haben jetzt nicht unbedingt mehr Grund-Features für 
den Editor, aber die Struktur
ermöglicht trotzdem alles mögliche wie Text, Grafik, Daten.
Sich in die ganzen Pattern einzulesen und funktionsfähig zu 
implementieren, dass die auch zusammenspielen ist ja auch nicht wenig 
Arbeit und ich hoffe da einfach auf Wiederverwendbarkeit etwas 
bestehenden...

Cyblord -. schrieb:
> Eventuell solltest du mal von deinem C++Builder weg zu etwas modererem
> wie C# inkl. Visual Studio.

Habe ich mir vor ~15 Jahren zum ersten Mal angesehen, aber für meine 
Anwendungen überwiegen einfach die Vorteile vom C++Builder... möchte ich 
jetzt nicht weiter drauf eingehen.

Heiko L. schrieb:
> Mag schon sein - die stehen aber absehbar vor dem selben Problem, wenn
> dann mal etwas gebraucht wird, was kein "grundlegendes Feature" war. Und
> tendenziell wird es dort dann noch ein wenig aufwändiger, die Neuerung
> mit den 80% an "grundlegenden Features" im Framework unter einen Hut zu
> kriegen, die man gerade nicht gebraucht hat. Aber Vorsicht: Ich denke
> recht negativ, was Softwareentwicklung betrifft. Wir sind am Ars*h.

Bin da auch eher Pessimist (erfahrener Realist). Springender Punkt bei 
meinem Problem ist denke ich, dass es nur ein Tool bleiben darf, wo es 
ruhig Grenzen geben darf. Bei den Grund-Features die so ein Template 
mitbringen würde, würde ich dann auch bleiben. Dann hätte ich evtl. 
schon mehr als ich jetzt habe, denn dann würde ich wenigstens mit den 
Features starten und diese nicht erst nach Jahren des Jammerns mal 
einbauen.

Heiko L. schrieb:
> Event Sourcing wäre da zB ein Stichwort zum Googlen.
Ja, danke - in die Richtung soll es gehen. Ich stehe jetzt halt vor der 
Entscheidung solche Dinge im Nachhinein einzubauen oder mein Projekt 
gleich auf eine Version 2.0 in irgendein Template einzubauen.

Heiko L. schrieb:
> Da hätte ich jetzt eher an ein Plugin für Excel o.Ä. gedacht. Wäre im
> Workflow um einiges angenehmer. Ist dann natürlich nur eine Lösung für
> die eine bestimmte Umgebung. Aber dafür eine brauchbare.

Excel ist keine Option, da ich auch viel Grafisch (mit Bildbearbeitung 
o.ä.) mache... oft startet es primitiv mit Zahlen und wenn das Tool sich 
als brauchbar erweist wird es durch komplexere Grafiken & Anzeigen 
erweitert. Da ist Excel das falsche Pferd.

Sisyphusarbeit schrieb:
> Brooks kam zu der Erkenntnis: "plan to throw one away; you will,
> anyhow." Und Raymond erklärt, wie das in der Praxis funktioniert.

Brooks ist echt gut :). Hatte nur immer mal wieder die Zusammenfassung 
gelesen - er hat leider viel zu oft recht. Ändert leider nur nicht viel 
an der gängigen Praxis ;).

Irgendwer schrieb:
> Sich eine Buttonliste Basteln und diese mit den entsprechenden
> Funktionsaufrufen verknüpfen ist eine Arbeit von weniger als einer
> Minute.void Form1::Button1Click(...)
> {
>   RichEdit1->Undo();
> }
>
> Softwarearchitektur ist was ganz anderes...

Da sind meine Programme leider schon vielfach komplexer... Funktion ist 
von Gui getrennt und die Undo-Methode einzelner Vcl Komponenten bringt 
mir leider nichts.

schönen Gruß,
Alex

> Ändert leider nur nicht viel an der gängigen Praxis ;)

Tja, die modernen Softwareentwicklungsmethoden sind ein Rückschritt. 
Ausgerechnet die drei wichtigsten Punkte ignorieren die modernen 
Methoden.
- Nachdem die Hälfte implementiert ist, fällt auf: Ein anderer Ansatz 
ergäbe nur 1/10 des Aufwandes
- Nach ein paar Jahren haben sich so viele zusätzliche Anforderungen 
angesammelt, die ursprünglichen Designentscheidungen passen einfach 
nicht mehr
- Die Dokumentation ist ein genau so wirres Chaos, wie der Programmcode.

Wahrscheinlich braucht man da eine ganz andere Denkweise. Das wirklich 
wertvolle ist die Dokumentation der Erfahrungen. Historisch gewachsener 
Programmcode hat weniger als gar keinen Wert. Das zentrale Ziel sollte 
eine konsistente, übersichtliche Dokumentation sein, aus der sich 
jederzeit eine neue, funktionierende Architektur entwickeln lässt.

> dass sich da schonmal jemand mehr Gedanken gemacht hat

Na klar, James Watt, Thomas Edison, Werner Siemens… Aber die kamen zu 
der Lösung: Für Erfindung, Konstruktion, Begutachtung, Leitung, 
Produktion und Qualitätssicherung braucht es unterschiedliche 
Charaktere, unterschiedliche Organisation und unterschiedliche 
Ausbildung.

In der Softwareentwicklung sammeln sich halt diejenigen, die mit dieser 
Lösung nicht einverstanden sind. Oder kennst du einen Kodierer, der 
einen Fließbandjob machen würde? Oder einen Entwickler, der sich auf die 
Konstruktion von Datenstrukturen beschränken will?

Heiko L. schrieb:
> Alex schrieb:
>> [...]
>> Es ist oft ein Krampf im Nachhinein weitere Features einzubauen, wenn
>> die dafür nötigen Programmstrukturen nicht berücksichtigt waren.
>
> Ja, das ist in der Entwicklung ein ständiges Problem. Genannt auch
> "schleichender Featurismus" (
> http://www.catb.org/jargon/html/C/creeping-featurism.html ). Wenn ein
> Feature unbedingt noch rein soll, muss man dann halt ggf. viel Code
> neuschreiben oder umstrukturieren.
>
> Alex schrieb:
>> Ich frage mich ob es hierzu nicht so etwas wie freie
>> Software-Architektur-Templates gibt, die Grundlegende Features von Haus
>> aus berücksichtigt haben.
>
> Mag schon sein - die stehen aber absehbar vor dem selben Problem, wenn
> dann mal etwas gebraucht wird, was kein "grundlegendes Feature" war. Und
> tendenziell wird es dort dann noch ein wenig aufwändiger, die Neuerung
> mit den 80% an "grundlegenden Features" im Framework unter einen Hut zu
> kriegen, die man gerade nicht gebraucht hat. [...]
> [...]
>> [...]


Interessant fände ich, begründete Bewertungen von Methoden wie "Agile 
Softwareentwicklung" (im folgenden mit ASE abgekürzt) und ähnlichen 
Ansätzen im Kontrast zu den oben erwähnten Problemen.

Es scheint mir insgesamt so zu sein, dass der Prozess der 
Anforderungsdefinition bei ASE effektiv ein Teil des Auftrags wird. Mehr 
nicht.
Ein Old-School-Entwickler (mal ganz wertfrei gemeint) wird eine 
komplette Anforderungsspezifikation voraussetzen bevor er ein Angebot 
macht und mit der Arbeit beginnt.
In den letzten Jahren (bis Jahrzehnten) aber verstärkt sich der Anteil 
an Auftraggebern, die mit sehr unscharfen Anforderungen Projekte 
anstossen wollen - da ist ASE sozusagen das Gegenmittel, gegen das 
Verlangen nach der kostenlosen Anforderungsanalyse und 
Angebotserstellung.
Der Auftraggeber mag ASE hingegen so sehen, dass er vor allem schnelle 
Umsetzungen seiner (in welchem Maß auch immer unscharfen) Vorstellungen 
bekommt und in gewisser Weise eine Art Mikromanagement betreibt ohne das 
das ausdrücklich so benannt wird.
So kann man das sehen, denke ich, oder was meint Ihr?

Mag dazu jemand was sagen?

Alter Wein in neuen Schläuchen. Früher waren auch niemandem die 
Anforderungen klar. Früher hatten die Old-School-Entwickler auch einen 
Prototypen zusammen gekloppt. Ist damals genauso im Chaos versunken wie 
die agile Software.

Das Problem an der Agilen Softwareentwicklung - sobald die Anforderungen 
klar sind, muss man den konfusen Prototypen wegwerfen und eine sinnvolle 
Architektur ausarbeiten. Das dauert halt 6 Monate.

Diese Agilen Consultingfirmen sind Scharlatane. Die erzählen den 
Managern, sie könnten diese 6 Monate einsparen, sie bräuchten nur deren 
teuren agilen Schulungen buchen.

PS. Selbst die blindesten BWLer haben inzwischen gemerkt - Agile 
Softwareentwicklung wird ein Fass ohne Boden. Und was machen diese 
Scharlatane? Die erzählen den BWLern, sie müssten nur teure Schulungen 
zum Thema Mikroservices buchen.

Alex schrieb:
> Ich programmiere immer mal wieder kleinere PC-Tools(Softwareprojekte) in
> C++Builder, die dann plötzlich größer werden als gedacht.

Poste doch erstmal ein paar Beispiele deiner Sourcen...

Ich hatte früher auch sehr oft das Problem mit dem schleichenden 
Featurismus (ich glaube euch einfach mal, dass das Wort echt ist). Ich 
habe sehr sehr gute Erfahrungen mit strenger Modularisierung gemacht.
Mein Ziel ist immer, dass ein Modul einen ganz klar abgegrenzten 
Aufgabenbereich hat. Ein Modul ist quasi immer ein Feature, oft auch mit 
Sub-Modulen. Mein Vorbild war damals der Editor Atom mit seinen 
Packages. Ein Package ist dort ein sehr autarkes Modul, ich habe das 
noch etwas mehr auf die Spitze getrieben. Oft nimmt das sogar schon 
API-Ähnliche Züge an. Ich habe meistens ein größeres Feature, bspw. für 
die Toolbar, die dann Methoden hat wie addButton(), oft hat die 
Toolbar-Klasse dann sogar noch ein Sub-Module, bspw. Button.

Ich habe damit wirklich sehr gute Erfahrungen gemacht und kann es 
wirklich jedem empfehlen.

Was ich noch vergessen habe:
Ich unterscheide zwischen zwei Arten von Modulen, die APIs (z.B. 
Toolbar) und die Module, die den Atom-Packages ähneln. Das Programm soll 
auch dann noch laufen, wenn so ein Modul weggenommen wird, auf dieses 
Modul wird nicht wirklich zugegriffen, höchstens am Anfang initiiert. So 
ein Package arbeitet für sich und greift nur auf API-Klassen zu, nicht 
aber auf andere Packages (außer Sub-Packages).
Die Packages greifen auf die unverzichtbaren API-Klassen zu, die kann 
man natürlich nicht einfach wegnehmen.

> Der Kunde ist in aller Regel unmündig, hat keine Ahnung, was er will

"Wenn ich die Menschen gefragt hätte was sie wollen, hätten sie gesagt, 
schnellere Pferde." – Henry Ford

Wir haben seit 100 Jahren ein iteratives Verfahren, in dem das Automobil 
ständig verändert wird. Warum eigentlich? Wieso braucht Fords Lösung 
seit 100 Jahren ein ständiges Refactoring?

Hat Henry Ford doch nicht verstanden, was sein Kunde will? War Ford 
nicht in der Lage die Wünsche seiner Kunden umzusetzen? Hat Fords Lösung 
die Wünsche seiner Kunden verändert?

Gibt es überhaupt irgend einen Bereich, in dem wir Menschen oder die 
Evolution oder die Götter oder sonst wer kein ständiges Refactoring 
betreiben? Wie kann sich ein Produkt der Evolution aus dem ständigen 
Refactoring befreien. Und wieso wollen wir ausgerechnet in der 
Softwareentwicklung das  ständige Refactoring vermeiden?

Theor schrieb:

> Interessant fände ich, begründete Bewertungen von
> Methoden wie "Agile Softwareentwicklung" (im
> folgenden mit ASE abgekürzt) und ähnlichen Ansätzen
> im Kontrast zu den oben erwähnten Problemen.

Agile Methoden sind in kundigen Händen eine gute
Sache; allerdings haben sie auch eigene Gefahren.


> Es scheint mir insgesamt so zu sein, dass der Prozess
> der Anforderungsdefinition bei ASE effektiv ein Teil
> des Auftrags wird. Mehr nicht.

Herrlich.

"Der Beweis von Andrew Wiles ist lediglich die Arbeit
eines Mathematikprofessors, in der der Fermatsche Satz
bewiesen wird. Mehr nicht."

:)


> Ein Old-School-Entwickler (mal ganz wertfrei gemeint)
> wird eine komplette Anforderungsspezifikation
> voraussetzen bevor er ein Angebot macht und mit der
> Arbeit beginnt.

Ja.


> In den letzten Jahren (bis Jahrzehnten) aber verstärkt
> sich der Anteil an Auftraggebern, die mit sehr unscharfen
> Anforderungen Projekte anstossen wollen - da ist ASE
> sozusagen das Gegenmittel, gegen das Verlangen nach der
> kostenlosen Anforderungsanalyse und Angebotserstellung.

Kann man so sehen, ja.


> Der Auftraggeber mag ASE hingegen so sehen, dass er vor
> allem schnelle Umsetzungen seiner (in welchem Maß auch
> immer unscharfen) Vorstellungen bekommt und in gewisser
> Weise eine Art Mikromanagement betreibt ohne das das
> ausdrücklich so benannt wird.
> So kann man das sehen, denke ich, oder was meint Ihr?

Das ist, denke ich, nicht falsch, greift aber zu kurz.

Der Kernpunkt sind die "unscharfen Vorstellungen" von den
Anforderungen.

Software dient einem Zweck; die meiste Software ist
in einen übergreifenden Arbeitsprozess eingebunden.
Der Arbeitsprozess und die Software sind aufeinander
abgestimmt.

Neue, verbesserte Software erfordert in der Regel auch
einen neuen Arbeitsprozess, der auf genau diese neue
Software abgestimmt ist. Diesen Arbeitsprozess KANN der
Auftraggeber aber noch gar nicht kennen, weil es ja die
zugehörige Software noch gar nicht gibt!

Das ist ein grundlegendes Henne-Ei-Problem. Alle Klein-
geister, die die Auftraggeber grundsätzlich für dumm,
faul und inkompetent halten, übersehen, dass sie Dinge
vom Auftraggeber wissen wollen, die er PRINZIPBEDINGT
noch nicht wissen KANN.

Agile Methoden sind hier mMn kein ganz falscher Ansatz,
weil sie die
1. gemeinsame
2. schrittweise
Erarbeitung von Produktwissen in den Vordergrund stellen.

Sisyphusarbeit schrieb:

> Wir haben seit 100 Jahren ein iteratives Verfahren,
> in dem das Automobil ständig verändert wird. Warum
> eigentlich?

Weil Firmen, die nichts verkaufen, weil alle alten
Bedürfnisse befriedigt und keine neuen geweckt wurden,
Pleite gehen, und weil Staaten, in denen die Firmen
reihenweise pleite gehen, keine Steuern einnehmen und
auch Pleite gehen.

Echte Notwendigkeiten spielen nur indirekt eine Rolle.

Moin,

Gab hier über Nacht ja einige philosopische Ergüsse - bringt aber keinen 
weiter.

Tomas T. schrieb:
> Poste doch erstmal ein paar Beispiele deiner Sourcen...

Das geht nicht weil es Firmeneigentum ist.

USB H. schrieb:
> Ich habe sehr sehr gute Erfahrungen mit strenger Modularisierung gemacht.
> Mein Ziel ist immer, dass ein Modul einen ganz klar abgegrenzten
> Aufgabenbereich hat. Ein Modul ist quasi immer ein Feature, oft auch mit
> Sub-Modulen.

Meinen Code versuche ich natürlich auch modular zu halten aber so 
wirklich streng bin ich da nicht. Ist sicher eines der Probleme ;).
Ich kenne den Atom Editor jetzt nicht genauer. Kannst du das evtl. mal 
als kleines Pseudocode-Beispiel zeigen wie die Klassen dann 
zusammenhängen oder so?

schönen Gruß,
Alex