Strukturieren und Organisieren eines Projektes

[Incubant]

Guten Morgen,

ich hab ein großes Problem. Nicht der Java Code an sich macht mir gewaltige Probleme, sondern das strukturieren meines Projektes (Vielleicht liegt es an den mangelnden OOP Kenntnissen).

Ich hab ein Java Programm, das funktionell nicht schlecht aussieht. Es erstellt per JDOM XML Dokumente, validiert sie mit SAX, sendet sie mit Sockets per TCP/IP, bekommt Response in Threads validiert und verarbeitet diese weiter. Soweit so gut!

Nur ich hab so ein Aufruf und Klassen-hick-hack, dass das Projekt einfach nicht übersichtlich ist, ganz zu schweigen davon, dass wahrscheinlich kein anderer durchblickt. :autsch:

:?: Jetzt wollt ich fragen, wie erlerne ich strukturiertes Arbeiten in Java, kennt da jemand vielleicht gute Tutorials oder Bücher. Als Entwicklungsumgebung verwende ich JBuilder2005 (ich glaub Enterprise).

:?: Wie habt ihr das in den Griff bekommen? Sicher erlernt man das vorallem mit Erfahrung, aber ich muss mal über eine Anfangshürde springen.

Vielen Dank im Vorraus.
Gruß Basti

 

[byte]

1. OOP richtig lernen, am besten aus nem vernünftigen Buch
2. OOP anwenden
3. Entwurfsmuster lernen
4. Entwurfsmuster anwenden

Buchtipps gibts im Bücherforum zuhauf.

 

[Anmeldeboykottierer]

Hi,
eigentlich hast du deine Frage mit deinem ersten Satz schon beantwortet, schau dir unbedingt die OOP an.
Alle Punkte die du hier findest sollten dir helfen ein besseres Design deines Projektes zu realisieren. Dazu muss ich gleich sagen, dass die OOP nur bei konsequenter Anwendung aller Punkte dazu führt, deswegen ist das A und O die OOP und die Ideen hinter den einzelnen Punkten auch zu verstehen.
Der Wichtigste für ein gutes Design ist immer die Abstraktion. Mag jetzt ein wenig zu pauschal klingen, aber eben die findest du in jedem großen Projekt wieder. An sich lohnt es sich erst einmal die Schnittstellen (Interfaces oder Abstrakte Klassen) zu modellieren und hier (ohne Implementierung) das Problem in seine Teilprobleme zu zerlegen. Dies erlaubt es dir nun die einzelnen Probleme beliebig zu lösen. Solange du nichts am Interface änderst ist es kein Problem jede dieser Lösungen gegen eine beliebige andere (mit gleichem Interface) auszutauschen.
Das findest du dann sehr ausgeprägt an vielen Stellen wieder. So stellt dir ein OS-API auch nur bestimmte Schnittstellen zur Verfügung, die meist über mehrere Versionen (mit komplett anderen Kernen und Bibliotheken) erhalten bleiben, an deinem Programm (dass dieses API verwendet) änderst du aber nichts, da du weiterhin nur die Schnittstelle kennst.
Ziemlich nah dran (an der OOP) ist dann die Idee von Komponenten in der Softwaretechnik. Dabei geht es auch (sehr vereinfacht) gesagt darum, dass du einfach eine Art Baustein hast, den du mit anderen über eine definierte Schnittstelle verbinden kannst (der Name kommt dann von der Komposition). Eine Komponente legt halt alles mögliche in einem Interface fest (Vorraussetzungen, angebotene Funktionalität, Fehlermeldungen, ....). Mehrere Komponenten kann man nun zu einer weiteren Komponente zusammen setzen, die wiederum Teil einer größeren Komponente sein kann. Der Vorteil liegt halt darin, dass du nur mit den Interfaces und einer Black-Box arbeitest. Einerseits kannst du den Inhalt der Black-Box zu jedem Zeitpunkt beliebig austauschen, ohne dass es Auswirkungen nach außen hat, andererseits kannst du auch jede dieser Blackboxen an jeder Stelle verwenden, an der du mit diesem Interface arbeiten möchtest.
Die eigentliche Entwicklung besteht dann hauptsächlich darin, dass du schaust was für Komponenten es bereits gibt, die du verwenden kannst. Dazu zählen auch solche, die nur ein Problem lösen, das sehr nah an deins rankommt, da gilt es dann natürlich zu schauen, ob du diese Lösung verwenden und umbauen kannst.

Wie gesagt, vieles davon findest du auch in der OOP wieder, auch hier geht es um Abstraktion und Wiederverwendbarkeit (unter anderem). Eine Komponente kann aber auch mit jedem anderen Programmierparadigma erstellt werden (COM Komponenten sind z.B. Imperativ, Corba Komponenten hingegen OO).

Gruß Der Anmeldeboykottierer

 

[SnooP]

Also UML wäre hier eigentlich auch ein Stichwort, da du damit die eigentliche OOP besser planen kannst. Und in der UML gibt es nicht nur Klassendiagramme, sondern auf oberster Ebene z.B. sowas wie Use-Case-Diagramme... man muss ja nicht jede Funktion in use-cases unterbringen - aber zumindest die grobe Funktionalität sollte man damit mal skizzieren. Dann kann man daraus nen Klassenentwurf machen, bei dem man wie der Boykottierer schon sagte, zunächst auf Interfaces bzw. abstrakte Klassen achten sollte... erst danach designed man mögliche konkrete Klassen - sprich wenn schon feststeht, welche Funktionalität die jeweiligen Klassen nach außen haben müssen... - wenn man das alles hat, dann kann man auch nochmal gröber über einzelne Komponenten nachdenken, z.B. welche Klassen in welche Packages sinngemäß gehören würden... usw.
Letztlich ist das ganze eine sehr evolutionäre Sache - sprich häufig hat man Projekte in denen sich das Design doch stark ändert, bzw. man stellt fest, dass der aktuelle Code nicht mehr konsisten zum eigentlichen Plan ist... dann muss man das Refactoring anschmeißen. Und hierzu empfehle ich das Refactoring-Handbuch vom Martin Fowler - das Standardwerk dazu, was darüberhinaus, wenn man es denn ganz gelesen und verinnerlicht hat auch beim Programmieren selbst hilft, indem man bestimmte "Smells" gar nicht erst programmiert, weil man schon beim Coden merkt.. hmpf... das riecht jetzt komisch

 

[Incubant]

Vielen dank für die Antwort, also weiß ich das ich am OOP arbeiten muss.

Ich denke, dass ich mich in OOP schon über die Möglichkeiten eingelesen habe, von wegen vererbung und extends usw., aber ich glaub im OOP muss man Erfahrungen sammeln.

Ich hab mein Projekt schon in schöne Teile zerschnitten und die Interfaces hab ich mir auch schon überlegt.

Aber mir gehts um die Komposition um die oben genannte Blackbox, kennt da niemand ein schönes Beispiel, indem man sieht so sollte die Über-Main Funktion aussehen, die dann die anderen verwaltet. Müsste ja vom Prinzip immer ähnlich sein.

:!: Mir persönlich bringt es wenig, wenn ich mir 3x trocken das Kapitel "Polymorphismus" durchlese, ich lern am besten durch handfeste Beispiele.

:?: Kennt keiner ein solches Beispiel, sozusagen das Musterprojekt?

 

[Incubant]

Ich hab ein Beispiel gefunden.

Ein Javakurs der Wirtschafts Universität Wien, für alle die ein handfesteres Beispiel für OOP brauchen.

http://wwwai.wu-wien.ac.at/manuals/hahsler/java/javakurs/javakurs05.html

Vielleicht hilft es auch anderen, und nicht nur mir.

Es erklärt zwar recht anschaulich OOP, aber gibt jetzt auch noch nicht wirklich die Einführung zur Verwaltung von großen Projekten, mal schauen, vielleicht hat ja jemand noch das ultimative Beispiel.

Gruß Basti

 

[Incubant]

Hallo Snoop,

hab erst eben bemerkt, dass sich da noch ein Eintrag vor meinen 10:11 Eintrag geschmuggelt hat.

Aber mit deinem Beitrag hast mir jetzt doch einiges um die Ohren gehauen, was mir ziemlich neu ist. Gut den unteren Teil deines Beitrags hab ich soweit verstanden, also den Teil mit dem Refactoring.

Das mit der Evaluation hab ich auch verstanden und deshalb hab ich mich ja hier gemeldet. Ich glaub über den ersten kleinen Punkt bin ich ja raus, weil ich die funktionalität der Software gecoded habe (ich würd sagen ich bin quasi ein Kleinkind, dass das grundlegende gelernt hat und jetzt muss es geordnete Wege gehen, quasi die Einschulung)

Im oberen Teil schreibst du von UML und Use-Case-Diagrammen, das ist mir neu und ich kann nicht wirklich was damit anfangen.

Gruß Basti

 

[SnooP]

Na dann schau doch mal nach UML bei Wikipedia oder ähnlichen Quellen... gute Bücher zum Thema UML gerade auch in Verbindung mit Java gibt's sicherlich auch ... gabs auch erst vor kurzem nen Thread zu.

Grob gesagt ist die UML eine Menge von formalen Diagrammen, mit deren Hilfe man die Struktur und das Verhalten von Programmen, bzw. Programmteilen modellieren kann. Wichtig für dich sind insb. die Diagramme für die Struktur, im Wesentlichen die Klassendiagramme, Objektdiagramme (evtl.) und die von mir beschriebenen Use-Case Diagramme... dazu kommen evtl. noch Komponenten (?)-Diagramme - das ist aber erst hilfreich, wenn man tatsächlich stark komponentenbasiert programmieren will/muss - ist imho erst bei Projekten mit >100 Klassen wirklich erforderlich... bzw. man hat wirklich klar abzugrenzende Programmteile die noch grob-granularer als es Klassen eh schon sind

Use-Case-Diagramme sind sehr simple Diagramme, die den User oder einzelne Programmkomponenten als Akteure haben, die bestimmte Anwendungsfälle ansprechen können - diese Anwendungsfälle können dann später in Programmfunktionen umgewandelt werden... das ganze ist der OOA zuzuordnen, bei der es erstmal darum geht, genau zu analysieren, was überhaupt benötigt wird... z.B. ich brauche in meinem Programm eine Funktion "Datei laden" ... dann wäre das ein entsprechender use-case.
Aus dem konkreten Usecase wird später dann klar, dass man mit irgendwelchen Dateiformen umgehen wird müssen... d.h. man braucht mit Sicherheit irgendwie ne Klasse, die Dateioperationen ausführen kann und z.B. von der Haupt-Anwendungsklasse gehalten wird... usw. ... also aus der Menge an Use-Cases kann man dann die grobe Struktur ableiten...

Man kann letztlich dann darüber streiten, ob bei privaten Projekten nen formal gültiges Use-Case Diagramm tatsächlich benötigt wird, oder nicht... ich würde mal spontan sagen, man brauchts nicht - aber man kann nach dem Muster vorgehen und sich auf nem Blatt papier zumindest grob skizzieren was man für Anwendungsfälle hat... und erst danach kann man mit nem zweiten Stift *g* beigehen und einzelnen Anwendungsfällen konkrete bzw. abstrakte (!) Klasse zuzuweisen... - wichtig ist auch, dass die Anwendungsfälle alles Funktionen sind, die später in Interfaces oder abstrakten Oberklassen auftauchen müssen... damit hat man schonmal ne bessere Übersicht über zu implementierenden Methoden...