Braucht man ein Architektur-Design, bevor man ein Projekt beginnt?

[Christoph Müller]

Was ich schon immer fragen wollte, mich aber bisher nicht getraut habe: Braucht man ein Architektur-Design, bevor man ein Projekt beginnt?
<br>
<br>Bevor ich ein Projekt beginne:
<br>- Muss ich wissen, wie viel Tier am Ende benötigt werden?
<br>- Muss ich wissen, welcher Code zu welcher Ebene gehört, bevor ich ihn schreibe?
<br>- Oder reicht es nicht einfach, bei der Entwicklung auf sinnvolle Kapselung zu achten und dann ggf. später eine Tier-Trennung zu konkretisieren?
<br>
<br>Gründe für diese Überlegung:
<br>- Vielleicht weiß ich ja noch gar nicht, ob ein X-Tier-Overhead überhaupt benötigt wird.
<br>- Vielleicht ist dieser Overhead gerade mein Performance-Killer.
<br>- Vielleicht sehe ich als Anwendungsentwickler gar nicht ein, wie ein Maschinist zu denken.
<br>- Vielleicht macht es in der Bilanz weniger Arbeit, die Tier-Trennung erst vorzunehmen, wenn die Akzeptanz des Anwenders anhand von Beta-Versionen sichergestellt ist.
<br>- Vielleicht muss ich meine Anwendung ja gar nicht anpacken, um Tiers umzuschichten, weil das alles im Framework gekapselt ist.
<br>- Vielleicht hat eine konkrete Technologie (EJB, RMI ...) in meiner individuellen Anwendung gar nichts verloren - schließlich ist so etwas bekanntermaßen der Mode unterworfen.
<br>
<br>Oder anders und freundlicher ausgedrückt:
<br>- Inwieweit kann ich die Design-Anteile Technische Architektur und Anwendungsdesign personell und zeitlich voneinander abkoppeln?
<br>- Wo muss konkret der Anwendungsdesigner auf die technische Architektur Rücksicht nehmen?
<br>

[Markus Leutner]

Interessante Frage, die bei uns im Zusammanhang mit dem XP-Ansatz aufgetaucht ist. XP sieht ja auch vor, statt langer Design-Sitzungen am Anfang des Projekts einfach loszulegen und das Design mit den Anforderungen ad hoc zu entwickeln.

Ich bin da allerdings skeptisch, zumindest wenn es um komplexere Systeme geht. Z.B. bei einem Web Application Server mit angeschlossenen Backend-Systemen muss m.E. immer erst das Big Picture (d.h. die Architektur) entwickelt werden, und wegen des "unscharfen Übergangs" zwischen Architektur und Design auch ein ganzes Stück Design des Application und Domain Models. Sicherlich kann man dabei leicht auch über das Ziel hinausschießen...

Bei Fat Clients oder Einzelplatzsystemen sieht das aber möglicherweise tatsächlich anders aus (obwohl ich auch da ein flaues Gefühl hätte, wenn man ohne Festlegung eines prinzipiellen Designs starten würde). Der XP-Ansatz taugt daher in Reinkultur m.E. auch eher für solche Systeme

[Christoph Müller]

<b>Ulrich Hamann</b> antwortete wie folgt:
<br>
<br>Meine Erfahrung ist: je mehr Gedanken ich mir über das System mache was ich bauen will, je detaillierter und sorgfältiger ich am Design arbeite, desto ausgereifter wird das Ergebnis, man braucht während der Entwicklung nicht so viel umschmeißen usw usw.
<br>
<br>Das gilt im kleinen und im großen.
<br>
<br>D.h. wenn ich ein richtig großes System plane würde ich mir schon Gedanken machen was für eine Architektur ich nehme. Und zwar ziemlich am Anfang. Man kann Klassen bestimmt auf mehrere Art gut designen, dsas liegt immer auch an der Architektur.
<br>
<br>Wenn ich 'nur' ein Basisframework entwickele und für alle Systeme offen bleiben möchte, dann muss ich mir auch über diese Flexibilität vorab Gedanken machen, sonst gehts eventuell auch schief

[Christoph Müller]

Vielen Dank für die Beiträge! :-)) Es ist einfach ungeheuer wichtig, zu wissen, wie man verstanden wird!
<br>
<br>Meine Frage lautete ja: 'Braucht man ein Architektur-Design, bevor man ein Projekt beginnt?' Ich hoffe, Ihr seht das nicht als Haarspalterei an, aber:
<br>
<br>- Ich glaube sehr wohl, eines zu brauchen, aber nicht unbedingt alle Details BEVOR ich beginne
<br>- Kein Architektur-Design zu haben heißt ja nicht, kein Konzept zu haben.
<br>
<br>Vielmehr ist das propagierte Konzept sogar XP (hier: extrem pingelig) und anspruchsvoll. Ein Kernpunkt des Konzepts lautet: 'Verbannt die Technologie aus der Anwendung, wo immer das möglich ist, und kapselt sie in ein Framework.'
<br>
<br>Natürlich passt ein Framework nur für bestimmte Anwendungsgebiete. Ich habe z.B. eines im Auge, das zu 90 % einfach Daten verwaltet. Wenn ich hier z.B. Entity-Beans einsetze, lege ich mich üblicherweise fundamental fest. Dass ich dann keinen Tomcat verwenden kann, ist ja nur eine Preisfrage und meist sehr leicht zu verschmerzen. Unangenehmer ist, dass ich damit Anwendung und EJB-Technologie praktisch untrennbar verschmelze. Ich habe in 14 Jahren Berufserfahrung schon viel Technologie kommen und gehen sehen. Was gestern hip war, ist heute 'Altlast'. Daher rührt auch meine Sensibilität für die Vermeidung von Abhängigkeiten. Es will doch auch jeder von Herstellern und Plattformen unabhängig sein, warum nicht auch von Technologie?
<br>
<br>Fazit: Eine Technologie ist vor allem auch dann eine gute Technologie, wenn sie in der konkreten Anwendung nicht sichtbar wird. Das lässt sich auch sehr oft realisieren. Für einen Wechsel von Fat Client zu 2-Tier braucht der 'Cameleon Style' z.B. für alle Tabellen einen einzigen Splitt im Framework und gar keine Änderung in der Anwendung.
<br>
<br>Übrigens: Hier soll nichts gegeneinander ausgespielt werden. Vielmehr bin ich auf der Suche nach neuen Wegen der angenehmen Arbeitsteilung. Ist die Idee für einen Architekt nicht verlockend, bestehende Anwendungen rückwirkend auf eine neue Architektur umstellen zu können

[tp]

Hallo alle,

wenn ein Programmierer "groß" ist, führt er nach der Analyse des Umfeldes der Applikation eine Architekturbetrachtung durch. Aus dieser ergibt sich wieder das Design, und sicherlich geht dieser Vorgang mehrfach von vorn los - man nennt es auch iterative Entwicklung.

Heerscharen von Projektleitern und Softwareentwicklern publizieren täglich tonnenweise Abhandlungen über dieses Thema, und Christoph Müller ist der Meinung, man bräuchte sich innerhalb eines Projektzyklus (Analyse, Design, Implementierung) nicht um seine Architektur zu kümmern.

Soll er doch. Es ist sein Ansatz. Viel Spaß dabei.

Aber ist dann nicht das Framework, welche die Frameworks kapseln, welche die Frameworks kapseln, komplizierter als das Framework? Oder bietet es einfach weniger Dienste unter dem Deckmantel der Vereinfachung? Geht doch mal zu einem CORBA-Entwickler, und sagt Ihm, sein Leben könnte einfacher sein, wenn er CORBA durch ein Framework kapselt

[Christoph Müller]

Gar nicht so falsch, die Aussage mit den "weniger Diensten". In der Tat ist Vereinfachung auch mit Beschränkung verbunden. Prinzipiell kann man als Programmierer jederzeit uneingeschränkt individuell entwicklen, aber jeder Programmierer, der mehrere Anwendungen über mehrere Jahre hinweg gewarted hat, weiß von dem Segen, wenn ein Bestandteil "im Standard" geblieben ist. Diese Teile machen einfach weniger Sorgen und damit weniger Kosten.
<br>
<br>Wer sagt, dass sich keiner um die Architektur kümmern soll? Ich habe gesagt, dass der Anwendungsentwickler so weit es geht sich nicht um die Architektur kümmern soll. An seiner Stelle soll sich der Architekt um Architekturen kümmern. Der Plural ist übrigens gewollt - heute ist diese hip, morgen eine andere. Oder es ist eine Frage der Skalierung.
<br>
<br>Hier geht es also um A R B E I T S T E I L U N G zwischen Anwendungs-Entwicklern, Technologie-Spezialisten (z.B. für CORBA) und (Framework-)Architekten!
<br>
<br>Der Architekt möge der Dienstleister des Anwendungsenticklers sein. Der Anwendungsentwickler kann dann dem Architekten mitteilen, welche (Programmier-)Interfaces er gerne benutzen möchte. Daraufhin kann der Architekt eine Palette von Technoligien nennen, die sich in einem Framework jetzt oder in Zukunft implementieren lassen und somit supported werden. Und wenn sich die Technologie nicht so ins Framework implementieren lässt, dass sie für den Anwendungentwickler unsichtbar ist, dann ist das halt ein (gravierender) Nachteil jener Technologie. Würde mich bzgl. CORBA durchaus interessieren, was da geht.
<br>
<br>Ein Beispiel für eines von vielen denkbaren Interfaces zwischen Anwendungsentwickler und verwendeter Technologie sagt bekanntlich mehr als viele Worte: http://www.must.de/Javams1.ht

[Christoph Müller]

Hier noch ein Versuch, meine Intention zu veranschaulichen:
Diagramm siehe http://www.must.de/camtech.jpg bzw. einschließlich Beschreibung http://www.must.de/cameleon.html
<br>
<br>Anmerkung: Was interessiert mich z.B. 100% pure Java? Ich will 100% Unabhängigkeit von Technologie! ;-

[Christoph Müller]

Und um die am Anfang gestellte Frage nun auch selbst zu beantworten:
<br>
<br>Nein, ich brauche kein Architektur-Desgin. Ich brauche ein geeignetes "Interface" zur Spezifikation der Anwendung. Dieses "Interface" sind die verfügbaren Klassen des Frameworks mit ihren Methoden. Und während ich die Anwendung über Java-Code spezifiziere, sorgt das Framework dafür, dass ich dank Default-Technologie bereits einen Prototypen habe.
<br>
<br>Möglicherweise sagt jetzt jemand, das sei doch eine Architektur. Das halte ich auch für gerechtfertigt! Bloß denkt halt beim Schlagwort "Architektur" sonst jeder an X-Tier, EJB, CORBA o.ä. . .

[Naseweis]

Hi Christoph,

warum nennt sich Dein Pool für Datenbankverbindungen DbConnStd und kann max. 5 Verbindungen verwalten? Und warum kann ich den Pool nicht per XML konfigurieren, um dann nur noch nach einer "OracleConn" zu fragen, während die Details in einer XML-Datei abgelegt sind? Und warum versuchst Du, JDBC noch einmal zu kapseln?

(Vom kleinen in's große, meine Fragen...).

Danke

[tp]

Christoph,

Deine Intentionen gehen in eine Richtung, die aktuell interessant wird: Implementierung von komplexen Systemen, ohne die geballte Komplexität auf den Anwendungsentwickler loszulassen. Grundgedanke dieses immer wichtiger werdenden Prinzips und auch Deines Framework ist, so viel wie möglich Komplexität vor gewissen Entwicklern zu verbergen, weil natürlich nicht jeder ein EJB/CORBA/RMI/COM-Experte sein kann. Eine anderes Beispiel wäre Dein Versuch, die Oberfläche von einer konkreten Darstellungsform in eine Meta-Form umzuwandeln, welche dann etwa Servlet/Swing sein könnte.

Die Sache ist nur, daß ich hier ein wenig skeptisch bin: Oberflächen sowohl in HTML als auch in Swing darzustellen ist ein sehr komplexes unterfangen, denn man implementiert eine Metasprache, welche komplexer als beide Teile ist - da man sowohl Funktionen von Swing als auch HTML benutzen möchte.

Komplizierter wird das System bei der persistenten Speicherung von Objekten oder in verteilten Systemen. Hier wird der Hauptteil der Arbeit durch Dich auf die Technologie-Spezialisten abgewälzt, welche nämlich dann den Code der Anwendungsentwickler optimieren müssen.

Was die Schnellebigkeit von Produkten angeht, bin ich ebenfalls nicht Deiner Meinung. RMI und CORBA sind sehr stabil (RMI ist ja nur ein Basiswerkzeug), und EJB kommt jetzt zwar in die Version 2.0, die Änderungen dort sind allerdings nicht extrem gravierend. EJB 2.0 ist nach wir vor nicht für Persistenz von Objekten geeignet, und jeder der diesen Umstand akzeptiert, wird sehen, daß in EJB 2.0 nicht so verschieden ist zu den vorherigen Ansätzen. Schau Dir CORBA 3.0 an - im wesentlichen EJB.

Ok, Pudels Kern ist folgender: ich kenne genügend Projekte, die so aufgebaut waren, wie es Deine Ideen wollen. Wir haben irgend was im Untergrund (CORBA vielleicht), kapseln, kapseln nochmal, haben viele Schichten. Dann baun wir uns noch unsere eigene Persistenzschicht. Am Ende sind viel zu viele (möglicherweise nicht qualifizierte) Entwickler damit beschäftigt, an den Zwischenschichten rumzubauen und nisten sich bequem im Projekt ein. Hätte man ein viertel der Leute (qualifiziert) genommen, denen viermal so viel bezahlt, wäre das Ding in einem zehntel der Zeit abgelaufen. Warum nimmst Du nicht gleich Technologie-Spezialisten, welche etwas von der Materie verstehen?

Naja, wieder mal viel zu viel geschrieben ;

[Christoph Müller]

Hi Naseweis,
<br>
<br>super, dass jetzt konkrete Fragen kommen! Als Detailfragen gehen sie zwar über die Architektur-Diskussion hinaus, aber ich beantworte sie trotzdem gerne.
<br>
<br>Wie so oft ist auch im diesem Framework einiges gewachsen. So habe ich früher eher Arrays statt Vektoren genommen, am Anfang kannte ich Vektoren auch nicht. Auch heute sehe ich in Arrays Vorteile, z.B. die Typsicherheit. Die Begrenzung kann aber ja leicht aufgehoben oder dynamisch erweitert werden. Habe ja nicht behaupted, dass das Framework "fertig" ist.
<br>
<br>DbConnStd soll heißen: Der Standardteil der database connection. Unterklassen dieser abstrakten Klasse heißen dann in meinen Anwendungen DbConn und repräsentieren die Connections dieser Anwendung.
<br>
<br>Für die Konfiguration der Haupt-Connection gibt es Swing-Verwaltungen, siehe Musteranwendung "Marketing". XML ist natürlich genauso gut denkbar.
<br>
<br>Warum ich "versuche, JDBC noch einmal zu kapseln?"
<br>In DbConn (database connection) errichte ich einen Zeiger auf die Datenbank(en). Die Daten-Objekte (Unterklassen von DataObject) holen sich bei der Instanzierung von dort ihre Connection. Schließlich will ich ja nicht für jede Tabelle eine eigene Connection verwenden.
<br>
<br>Ich kann mir leicht vorstellen, dass man vieles eleganter machen kann, z.B. dein Alias-Vorschlag. Was innerhalb des Framework passiert, hat bzgl. Eleganz auch eine geringere Priorität, weil ich es jederzeit verbessern kann. Es ist ja nur einmal zu ändern, nicht in allen bereits existierenden Anwendungen.
<br>
<br>Das Framework ist ja auch Open Source, damit sich mehrere Leute mit ihren guten Ideen einbringen können. Herzliche Einladung!

Gruß, Christop

[Christoph Müller]

Hallo Thomas,
<br>
<br>ich freue mich über dein Viel-Schreiben!
<br>
<br>Bitte schaue dir doch mal die Lösung an, wie ich HTML erzeuge. Das geht nicht über eine Metasprache. Es gibt ein package de.must.wuic und ein package de.must.markup. Wuic (windowing user interface components) macht aus den Anweisungen wie createTextField etc. letzlich JTextField, und das ziemlich direkt. Markup macht daraus ein internes MustTextField, welches über die Methode getCreationTag() seine HTML-Darstellungsweise preis gibt. Das ist nicht komplex!
<br>
<br>Bezüglich Optimierung der Persistenz: Durch die Reduktion der Möglichkeiten der Anwendungsentwickler kann bereits verhindert werden, das etwas "schlecht" gemacht wird. Mir ist schon klar, dass sich gutgemeinte Strukturen nicht immer durchziehen lassen. Aber was, wenn man es nicht einmal will? Dann verschenkt man auch das Erreichbare, oder?
<br>
<br>Du sagst, EJB und CORBA sind nicht schnelllebig. Wird man sehen, kann ich jedenfalls mal so stehen lassen. Wohl dem, der einfach bei einer Technologie bleiben darf. Als Freelancer bin ich persönlich mit unterschiedlichen Technologien konfrontiert, da komme ich halt auf solche Ideen, mich davon frei zu machen. Und weil ich auch aus einem Bereich komme, wo 50.000 DM schon "viel Geld" sind (Mittlere Datentechnik), spielt für mich auch CORBA-/EJB-lose Anwendungsentwicklung eine Rolle. Ein bisschen denke ich auch an diesen Markt. Den Mittelstand hat IBM dieses Jahr übrigens für den Wachstumsmarkt der nächsten drei bis vier Jahre erklärt. Und da ist mit Java-Know-How ziemlich gähnende Leere.
<br>
<br>Auch die Technologie-Spezialisten müssen finanzierbar sein. Außerdem habe ich es lieber, das Machbare zu klären und zu organisieren, als "einfach nur gut zu sein". Bitte fühle dich nicht angesprochen, aber ich bin bei Leuten, die sehr viel von Qualität reden immer misstrauisch. Und wenn du meine Grundstruktur der Kapselung im Diagramm anschaust - ist doch gar nicht so verschachtelt: Anwendungsentwickler, Framework, Technologien. Im Kern zähle ich drei Ebenen.
<br>
<br>Vielen Dank also für deinen Beitrag. Da ich mich mit CORBA nicht auskenne, interessiere ich mich sehr für Hinweise, wo meine Vorstellungen bei CORBA auf Grenzen stoßen.

Gruß, Christop

[tp]

Hi Christoph,

ich glaube, wir haben ein wenig aneinander vorbeigeredet. Du sprichst halt von Projekten, die im unteren und mittleren Segment liegen - was den Umfang als auch das Projektbudget angeht. Und dort ist es ok, wenn man Entwicklern Hilfsmittel in die Hand gibt, um eben HTML und Swing einfach darzustellen, oder eine Vereinfachung von JDBC anbietet. Ich denke, diese Idee ist nicht nur verlockend, sondern auch sinnvoll. Auch ist bei dieser Zielgruppe gerade die Furcht sehr groß oder die Zeit nicht vorhanden, sich mit den Basistechnologien (Servlets, JSP, Swing) in Ihrer Komplexität auseinanderzusetzen.

Grad wenn man aber nur die Applikation mit RMI oder auch Sockets verteilen will, kommt man schnell in ziemlich große Probleme - denn bestimmte Aufrufe müssen optimiert werden, damit nicht aus jeder Anfrage eine Remote-Aufruf dahintersteht. Das muß auch der Anwendungsentwickler wissen, da der Technologie-Spez hier nicht mehr viel optimieren kann.
(Weil Du geschrieben hast<br>
<i>
- Muss ich wissen, wie viel Tier am Ende benötigt werden? <br>
- Muss ich wissen, welcher Code zu welcher Ebene gehört, bevor ich ihn schreibe? <br>
- Oder reicht es nicht einfach, bei der Entwicklung auf sinnvolle Kapselung zu achten und dann ggf. später eine Tier-Trennung zu konkretisieren? <br>
</i>

Hast Du Dich mal mit den Ideen von Adam Bien (Buch: Enterprise Java Frameworks, Addison-Wesley) auseinandergesetzt? Ich denke, eure Ideen gehen in ähnliche Richtungen.

Leider ist der Framework-Ansatz für mich recht uninteressant, da ich auf konkreten Java-APIs aufsetzt und aufsetzen möchte, und gleichzeitig noch die Kentniss über den dahinterliegenden Dienst (EJB-Server) haben möchte/brauche.

Gerade innerhalb des "Divers"-Thread innerhalb des Forum trifft man jedoch Leute an, die gerade mit Java anfangen und die über etwas Hilfe sehr froh sind....

c

[tp]

Nochwas:

<i>
Auch ist bei dieser Zielgruppe gerade die Furcht sehr groß oder die Zeit nicht vorhanden, sich mit den Basistechnologien (Servlets, JSP, Swing) in Ihrer Komplexität auseinanderzusetzen.
</i>

Ich habe die Erfahrung gemacht, daß zum Lernen der Java-Kern-APIS mindestens 1 Woche Schulung und 1 Monat programmieren mit Tutor nötig ist, damit man sich erst mal auf der Client-Seite von Java zurechtfindet. Kenntnisse einer OO-Sprache vorrausgesetzt..

[Christoph Müller]

Hi Thomas,
<br>
<br>vielen Dank für den Buchtipp - klingt interessant - habe ich gleich mal bestellt.
<br>
<br>Das mit der Optimierung habe ich noch nicht ganz verstanden. Ich stelle mir ja eine Standardisierung vor. Sprich: Der Anwendungsentwickler bekommt für eine bestimmte Aufgabenstellung einen vorbereiteten Standard zur Verfügung gestellt. Einfaches Beispiel: "Properties verwalten", sprich einen Satz aus der Tabelle lesen, modifizieren und zurückschreiben. Siehe dazu auch http://www.must.de/Javams1.htm
<br>
<br>Einen solchen konkreten Fall kann ich doch in einem Framework bis zum geht nicht mehr optimieren, ohne die Anwendung anzupacken, oder?
<br>
<br>Danke auf für den Tipp mit "Divers". Ich fürchte jedoch, dass Anfängern auch mein Konzept zu komliziert, da zu umfangreich ist. Urprünglich dachte ich eigentlich an meine Traditions-Kollegen der Mittleren Datentechnik (COBOL usw.), aber die wagen meist nicht den Gedanken, für Neuentwicklungen auf eine neue Karte zu setzen. Wie du bereits sagtest, es ist nicht ganz einfach. Und wenn ich dann an die Unsinns-Werbung der IBM denke: Wer mit der Maus clicken und ziehen kann, der kann auch Java Programmieren . . . - kein Wunder!

Christop