Ja genau. Ich würde zwar überhaupt nicht behaupten DER Delphianer zu sein aber ohne Planung würde ich wirklich den roten Faden verlieren, insbesondere wenn im Projektverlauf immer Änderungswünsche kommen.

Aber das was ihr sagt stimmt natürlich auch, man kann es logischerweise auch total überziehen ich z.B. mach mir eigentlich garkeine Struktogramme.

Sind eigentlich diese Datenfluß-Diagramme wirklich aktuell oder sind die von UML abgelöst?

Bin deiner Meinung noidic.

Übertreiben kann man auch alles.. Aber auch ich setz mich gern mal mit nem Klassendiagramm hin und besprech das mit Kollegen, aber auch Reverse Engineering also sprich existierende Projekte wieder in UML darstellen ist sehr hilfreich.. Das Teil ausdrucken und es an die Wand hängen.. Eine sehr gute Übersicht.

Bei Kundenterminen können Use Case Diagramme sehr nützlich sein.. Es gibt Kunden die wissen selbst nich im Detail wie ihre Prozesse aussehen.. und n Blatt Papier und n Stift hat man immer dabei. Man zeichnet das grob auf fährt zurück ins Büro, bearbeitet es nach uns schickts mit der Nachbereitung dem Kunden (und legt es noch nebenbei in der Projektdefinition ab..) So hat man immer den Prozess leicht verständlich vor sich.. und der Kunde versteht es auch.

Software soll ja nicht nur ne Ansammlung von Funktionen sein sondern den Prozess verbessern..

digi_c hat folgendes geschrieben:

Sind eigentlich diese Datenfluß-Diagramme wirklich aktuell oder sind die von UML abgelöst?

Was meinst du mit abgelöst? Es geht hier nicht um Software-Versionen, Gesetze oder irgendwas anderes, was einer ständigen Evolution unterworfen ist. Welche Art von Diagramm man verwendet ist Vereinbarungssache zwischen den Personen, die darüber mitaneinder arbeiten müssen. DIe UML hat nichts abgelöst, sondern nur eine neue Möglichkeit zur Modellierung geschaffen. Wer sie nicht nutzen will, muss es nicht tun und braucht dabei keine Sorge zu haben, das deswegen seine Software nicht funktioniert oder seine Kollegen ihn nicht mehr verstehen

Jeder sollte so modellieren, wie er es am besten kann, zumindest für sich selbst. Für die Kommunikation mit Kunden oder Kollegen kann es natürlich Vorgaben geben, an die sollte man sich dann halten.

Ja natürlich stimmt das schon aber wenn man in den Lehrbüchern alle Modellierungsmöglichkeiten aufgezeigt bekommt(aber nicht wirklich wie man sie kombiniert,...) und auf Arbeit mit Word Skizzen in Richtung ERMs und Tabellenauszügen gearbeitet wird, steht man irgendwie aufm Schlauch

Könnt ihr vielleicht so ein bißchen erzählen wie das bei euch abläuft, so wie ich es im 1. Post gemacht hab. Zumindest wenn es bei euch so einen einigermaßen Ablauf gibt

Also ich erstell mit bei grösseren Sachen zuerst mal eine Zusammenstellung der benötigten Tabellen in der Datenbank. Wenn neue Tabellen angelegt werden müssen, bastel ich mir ein kleines ERD dazu.

Als nächstes kommt ein Klassendiagramm mit den nötigen Klassen. Meistens macht das einige Änderungen durch, bis es endgültig fertig ist ( So man bei Software von endgültig fertig reden kann... ).

Dann setze ich die Klassen um ( Wenn ich das Diagramm mit dem Modelmaker gebaut hab, ists weniger Arbeit ). Dabei sind meist auch noch Änderungen am Modell nötig.

Als letztes mache ich mir Gedanken über die Abläufe. Bei komplizierteren Abläufen erstelle ich mir dazu ein Aktivitätsdiagramm.

Manchmal, aber eher selten kommt dann für den Test noch ein Use Case - Diagramm zum Einsatz, bei einigen Backend-Geschichten, die ich baue, ist auch mal ein Einsatzdiagramm für den Kunden drin.

Wobei ich jetzt dazu sagen muss, dass die ganzen Diagramme meistens auf den Rückseiten von irgendwelchen Konzeptausdrucken hingeschmiert werden

Ich muss nochmal nachhaken und zwar wegen den Properties, wie ist den da der Zusammenhang zu OOP?

Also ich kann ja entweder eine Variable normal als Variable:Typ veröffentlichen oder eine Protectecte fVariable:Typ deklarieren und eine Property deklarieren die entweder direkt darauf zugreift oder über Get/Set Methoden um Sicherheit zu gewährleisten. Laut OOP soll man ja keine Variablen direkt "veräußern" sondern immer schön schützen...

Gibt es so ein Properties Konzept auch direkt in OOP? In Java musste man IMHO immer selbst als Get/Set Methode veröffentlichen und konnte die nicht als Property bündeln.

digi_c hat folgendes geschrieben:

Ich muss nochmal nachhaken und zwar wegen den Properties, wie ist den da der Zusammenhang zu OOP? Also ich kann ja entweder eine Variable normal als Variable:Typ veröffentlichen oder eine Protectecte fVariable:Typ deklarieren und eine Property deklarieren die entweder direkt darauf zugreift oder über Get/Set Methoden um Sicherheit zu gewährleisten. Laut OOP soll man ja keine Variablen direkt "veräußern" sondern immer schön schützen... Gibt es so ein Properties Konzept auch direkt in OOP? In Java musste man IMHO immer selbst als Get/Set Methode veröffentlichen und konnte die nicht als Property bündeln.

Hallo,
Getter/Setter sind nicht wirklich objektorientiert. Mal abgesehen davon, dass man beim Setzen oder Lesen irgendwie reagieren kann, oder dass man Accessoren in Schnittstellendefinitionen aufnehmen kann, besteht im Prinzip kein Unterschied zu öffentlichen Feldern. Ein interessanter Artikel dazu findet sich in der Javaworld www.javaworld.com/ja...jw-0905-toolbox.html .

Zitat:

Laut OOP soll man ja keine Variablen direkt "veräußern" sondern immer schön schützen...

Halte ich für ein Dogma.
cu

eine Variable erstmal schön private zu machen um sie dann als Property oder auch nicht über zwei public methoden auszulesen und zu schreiben grenzt für mich an Wahnsinn, und erinnert mich an manche Gesundheitsrichtlinien mit dem Unterschied, dass ein Computer deterministisch arbeitet. Traurigerweise wird einem dies in vielen deutschen Bildungsanstalten eingetrichtert, wahrscheinlich damit man gar keinen Grips mehr im Hirn braucht um zu programmieren, weil aufgrund der Regeln das Programm schon fehlerfrei geschrieben ist. Deshalb meine These: Wer zuviel mit diesen Hilfsdiagrammen rummacht verliert den Blick fürs wesentliche.
Deshalb auch meine Meinung zu Java: Auf keinen Fall eine gute Objektorientierte Sprache, weil die im Sinne der Objektorientierung sich so einen abgebrochen haben, dass man damit nicht gut programmieren kann.

Allesquarks hat folgendes geschrieben:

eine Variable erstmal schön private zu machen um sie dann als Property oder auch nicht über zwei public methoden auszulesen und zu schreiben grenzt für mich an Wahnsinn, und erinnert mich an manche Gesundheitsrichtlinien mit dem Unterschied, dass ein Computer deterministisch arbeitet.

Zitat:

Deshalb auch meine Meinung zu Java: Auf keinen Fall eine gute Objektorientierte Sprache, weil die im Sinne der Objektorientierung sich so einen abgebrochen haben, dass man damit nicht gut programmieren kann.

Das trifft genau genommen auf alle c++ - "Derivate" zu. Delphi ist auch nicht besser. Aber woran dachtest du? Smalltalk, Eiffel?
Grundsätzlich würde ich aber behaupten, dass es sich aber auch mit Java "sauber" programmieren lässt.

P.S.: Was haltet ihr eigentlich von einer extra Ecke zu diesen Themen?:
www.delphi-forum.de/...55888&highlight=

Gute Nacht
Thomas

Ein bischen zu Sauber. Bin da wohl zu sehr matheorientiert. Da behaupten viele nen Beweis muss auch kurz sein um schön zu sein.
Und wenn man bedenkt wie stolz die Javaner doch darauf sind, dass in Java doch alles so abgesichert ist der Programmierer also vor sich selbst geschützt ist, um ihn vor dem bösen c/C++ Stil zu bewahren, wundert es mich, dass sie die Groß/Kleinschreibung nicht abgeschafft haben. Neulich hat bei mir doch glatt nen Java-Compiler rumgemeckert, weil ich kein default im switch hatte.
Ich gebe zu in Eclipse wars dann glaube ich anders, aber es ist die Grundtendenz demjenigen der am meisten Ahnung vom Code hat nämlich dem Entwickler, bestimmte Dinge zu verbieten die es nervig macht. Nebenbei zeugt es auch von einer Arroganz, die ich nicht kommentieren möchte.
Und nach meiner bisherigen Erfahrung ist dies eben gerade in Delphi nicht so.

Also eigentlich ging es mir jetzt nicht um irgendwelche konkreten Programmiersprachen...
Außerdem habe ich mit Java noch nicht viel gemacht. Ich komme eher aus der c/c++ - Ecke. Bin aber zu c# gewechselt.

Allesquarks hat folgendes geschrieben:

Neulich hat bei mir doch glatt nen Java-Compiler rumgemeckert, weil ich kein default im switch hatte.

Was Ähnliches hat mich an c# auch anfangs geärgert. Mann kann nicht mehr von case zu case "durchrutschen".

Zitat:

... der am meisten Ahnung vom Code hat nämlich dem Entwickler, bestimmte Dinge zu verbieten die es nervig macht. Nebenbei zeugt es auch von einer Arroganz, die ich nicht kommentieren möchte.

Mach doch. Hier im Forum war sicher keiner an der Entwicklung von JAVA beteiligt
Du musst dann auch Dinge wie Garbage-Collection, Typprüfung, Frameworks etc. als Anmaßend empfinden, oder? Ich bewundere Leute, die über ein gesamtes Programm den Überblick behalten können. Wirklich. Ich fand’ schon damals krass, wie gut ein Freund von mir Assembler coden konnte. Ich kann so was nicht.

Zitat:

Und nach meiner bisherigen Erfahrung ist dies eben gerade in Delphi nicht so.

Bei c++ usw. auch nicht. In beiden PS kannst du sowohl prozedural als auch objektorientiert programmieren. (Nebenbei bemerkt ist die massenhafte Verwendung von Gettern/Settern zumindest ein Indiz für prozedurales Denken.) Klar ist es irgendwie albern, z.b. eine statische Klasse für ein paar Konstanten zu definieren. Mal schnell eine globale Konstante in irgendeiner Datei abgelegt geht einfach schneller. Aus objektorientierter Sicht ist beides nicht so schön. Aber wenn es funktioniert und alle zufrieden sind: Was soll’s?

Was sagt mir das jetzt zu Properties in Delphi

Also erstmal deklarier ich das meiste private und sortier es dann nach public aus und nur dort wo es mir sinvoll erscheitn mach ich ein Property mit Get/Set ansosnten wird direkt auf die lokale Variable per Property zugegrifen

digi_c hat folgendes geschrieben:

-SW dient größtenteils der Optimierung von (Geschäftsprozessen) -diese werden in der Wirtschaft per Ereignis Prozess Ketten-Diagrammen dargestellt werden -Analysephase: --Ist Beschreibung per Text/EPK/Datenfluss --SOLL Beschreibung per Text -->Zusammensetzen mit Kunden und verständlichen der Situation(Daten,Aktionen) für Coder per UML Use Case -Designphase(Bottom Top?): --Zielkonflikt(Geschwindigkeit,Wartbarkeit,...) Kompromiss Modell View Controller Gliederung(?Observer Patern?) --Erstellung DatenKlassen und ihrer Abhängigkeiten per UML Klassendiagrammen --finden/durchdenken von Algorithmen per Struktogramm/PAP -Implementierungsphase --GUI erstellen --Abtippen/Generieren der leeren Klassen (Idealerweise durch CASE Tool automatisiert) --Umsetzen der Zuweisungsmethoden der Attribute --Anbindung fertiger Funktionen aus Bibliotheken --Umsetzen der speziellen Algorithmen in Code --Datenschnittstellen einbauen

Du beschreibst im Wesentlichen einen Wasserfallprozess. Zuerst das, dann das usw. Mit OO- Techniken soll zunächst einmal erreicht werden, dass du auf Anforderungsänderungen schnell reagieren kannst. Die Kapselung soll dazu beitragen, Änderungen möglichst an einem Punkt vornehmen zu können. D.h., du schließt die Analysephase z.B. nicht ab, sondern erweiterst die Anforderungen in Abständen, die dir letztlich der Kunde diktiert. So wächst die Software allmählich. A. D. und I. werden nacheinander mehrfach in sogenannten Inkrementen durchlaufen. Softwareprozesse würden mich an deiner Stelle erstmal gar nicht so sehr interessieren.
Erwarte bitte nicht, dass man in einem Forum OO lernen kann. Konkrete Fragen sind was anderes. Ansonsten kann ich dir nur ein Buch empfehlen:
Craig Larmann (Applying UML And Patterns)
Er beschreibt zwar auch den Entwicklungsprozess, zeigt aber vor allem auch, wie man OO entwickelt. Er geht auf Dinge ein wie:
- Verantwortlichkeiten zuweisen (welche Klasse ist für was verantwortlich?)
- Kohäsion
- Kupplung
- Polymorphie

usw. ein.

tm77 hat folgendes geschrieben:

Hallo, Getter/Setter sind nicht wirklich objektorientiert. Mal abgesehen davon, dass man beim Setzen oder Lesen irgendwie reagieren kann, oder dass man Accessoren in Schnittstellendefinitionen aufnehmen kann, besteht im Prinzip kein Unterschied zu öffentlichen Feldern. Ein interessanter Artikel dazu findet sich in der Javaworld www.javaworld.com/ja...jw-0905-toolbox.html . Zitat: Laut OOP soll man ja keine Variablen direkt "veräußern" sondern immer schön schützen... Halte ich für ein Dogma. cu

Ich halte das ganz und gar nicht für ein Dogma. Ein wesentliches Ziel der OOP ist die Kapselung von Daten und Code in möglichst wiederverwendbare Teile und das Verstecken der Implementation eines Programmteils vor anderen Programmteilen. Mit public-Variablen hebelt man das aus, was dazu führt, dass wenn scih die Implementation einer Klasse ändert, wahrscheinlich auch andere Programmteile angepasst werden müssen. Mit einem sauberen Design will man ja genau das vermeiden.

Da finde ich das Property-Konzept von Delphi ziemlich gut: ich kann damit Felder öffentlich machen und damit ohne den Overhead eines Funktionsaufrufs darauf zugreifen. Wenn sich die Implementation der Klasse ändert und das ursprüngliche Feld ist gar kein Feld mehr oder das Objekt muss auf einen Feldzugriff irgendwie reagieren, kann ich stattdessen ohne Änderung des Interface Get- Und Set-Prozeduren verwenden. Damit kann ich die Effizienz einer public-Variablen haben und die Implementation der Klasse trotzdem sauber kapseln. Mit der Delphi-Codevervollständigung braucht ich damit nicht mal wesentlich mehr zu schreiben als wenn ich direkt eine public-Variable verwenden würde.
Delphi-Properties sind eins der Features, die ich bei Java schon vermisse.

Stefan

digi_c hat folgendes geschrieben:

Was sagt mir das jetzt zu Properties in Delphi Also erstmal deklarier ich das meiste private und sortier es dann nach public aus und nur dort wo es mir sinvoll erscheitn mach ich ein Property mit Get/Set ansosnten wird direkt auf die lokale Variable per Property zugegrifen

Eigenlich hat es einen Klienten nicht zu interessieren, welche Attribute ein Objekt besitzt. Das grundsätzliche Problem dabei ist nämlich, dass du Implementierungsdetails der Klasse preisgibst und damit Klassen eng aneinander bindest. Angenommen du hast in einer Klasse einen Preis als Fließkommazahl. Klienten sollen den Preis erfragen können. Du hast jetzt ein privates Feld Preis auf das Klienten über einen Getter zugreifen können. An x Stellen deines Progs. benutzt du nun diesen Getter (der natürlich auch vom Typ Fließkommazahl ist). Im UI konvertierst du diese Zahl, um z.B. nur 2 Nachkommastellen anzuzeigen. Andere Klienten machen keine Konvertierung um genaue Werte zu bekommen etc. Was, wenn du dich später entschließt, verschiedene Währungen einzubauen? Der Preis stellt jetzt mehr ein Konzept dar (also ist Kandidat für eine eigene Klasse). An x Stellen musst du nun ändern.
In der Regel (Außnahmen gibt es ja immer) solltest du Getter/Setter vermeiden, bzw. vorsichtig sein. Desto tiefer du in die Materie eindringst, desto weniger wirst du sie brauchen. Zu diesem Thema sei nochmal auf den Artikel : "Why getter and setter methods are evil" in der javaworld verwiesen. www.javaworld.com/ja...jw-0905-toolbox.html
Dabei spielt die Programmiersprache keine Rolle.

Thomas

Stefan.Buchholtz hat folgendes geschrieben:

Ich halte das ganz und gar nicht für ein Dogma. Ein wesentliches Ziel der OOP ist die Kapselung von Daten und Code in möglichst wiederverwendbare Teile und das Verstecken der Implementation eines Programmteils vor anderen Programmteilen. Mit public-Variablen hebelt man das aus, was dazu führt, dass wenn scih die Implementation einer Klasse ändert, wahrscheinlich auch andere Programmteile angepasst werden müssen. Mit einem sauberen Design will man ja genau das vermeiden. Da finde ich das Property-Konzept von Delphi ziemlich gut: ich kann damit Felder öffentlich machen und damit ohne den Overhead eines Funktionsaufrufs darauf zugreifen. Wenn sich die Implementation der Klasse ändert und das ursprüngliche Feld ist gar kein Feld mehr oder das Objekt muss auf einen Feldzugriff irgendwie reagieren, kann ich stattdessen ohne Änderung des Interface Get- Und Set-Prozeduren verwenden. Damit kann ich die Effizienz einer public-Variablen haben und die Implementation der Klasse trotzdem sauber kapseln. Mit der Delphi-Codevervollständigung braucht ich damit nicht mal wesentlich mehr zu schreiben als wenn ich direkt eine public-Variable verwenden würde. Delphi-Properties sind eins der Features, die ich bei Java schon vermisse. Stefan

Hallo Stefan,

Ja klar. Eine variable einfach öffentlich zu machen ist natürlich ganz schön an der Sache vorbei. Stimme ich dir voll zu. Mir geht es nur darum, dass es konzeptionell keinen großen Unterschied zwischen einer Variablen und einem Property gibt. Wenn man auf ein Attribut eines Objektes zugreifen MUSS, dann natürlich über ein Property. Ich finde das auch bei Delphi gut gelöst.

Thomas

@tm77 ich danke dir für den Buchtip aber mir mangelt es erstmal nicht an Büchern zu dem Thema sondern an zeit

Es ist erstaunlich bei welch kleinen Dingen man Orientierung sucht, in der Schule sah das mit dem "Obst Äpfel Birnen" Beispiel vor 2Jahren so einfach aus Es ist aber echt komisch, nach dem 3. Versuch hatte ich mein damaliges Beispiel "Lizenzverwaltung" was ja eigentlich ganz einfach war(Kunde,Lizenz,Progdukte,Komponenten) doch reichlich anders gebaut.

Ich finde es schwer OO mit DB zu kombinieren. Wie soll man das da machen? On Demand und ein Objekt erzeugen das mit Daten aus dem Dataset füttern?
Ich hatte das in meinem Beispiel durch eine 3 Teilung gelöst(Primitivlinge,Kollektoren,DBVerbinder) ob das gut ist weiß ich nicht aber was großartiges Anderes wüßte ich nicht...

Bei der Verbindung von OOP und DB kann sehr schnell die Performance mitspielen. Die Idee, Objekte ihre Daten selbst aus der DB holen zu lassen ist schön sauber. Wenn allerdings die Datenselektion aufwändig ist und zudem noch oftmals Objekte diesen Typs erzeugt werden, wird es schnell sehr träge. Da muss man dann drüber nachdenken, die Objekte von außen zu füttern, am besten über eine eigene Datenzugriffsschicht.

Es gibt kein Patentdesign für OOP-DB-Anwendungen und meistens ziehen sich auch 2 oder mehr Herangehensweisen durch ein Projekt.

digi_c hat folgendes geschrieben:

Es ist erstaunlich bei welch kleinen Dingen man Orientierung sucht, in der Schule sah das mit dem "Obst Äpfel Birnen" Beispiel vor 2Jahren so einfach aus Es ist aber echt komisch, nach dem 3. Versuch hatte ich mein damaliges Beispiel "Lizenzverwaltung" was ja eigentlich ganz einfach war(Kunde,Lizenz,Progdukte,Komponenten) doch reichlich anders gebaut.

Versteh mich bitte nicht falsch. OO sollte kein Dogma sein. Das Wesentliche ist, dass man fertig wird und dem Kunden ein Produkt präsentiert, das läuft. Punkt. Wenn man aber in Richtung OO gehen will, sollte man versuchen von Projekt zu Projekt besser zu werden.

Zitat:

Ich finde es schwer OO mit DB zu kombinieren. Wie soll man das da machen? On Demand und ein Objekt erzeugen das mit Daten aus dem Dataset füttern? Ich hatte das in meinem Beispiel durch eine 3 Teilung gelöst(Primitivlinge,Kollektoren,DBVerbinder) ob das gut ist weiß ich nicht aber was großartiges Anderes wüßte ich nicht...

Du meinst sicher die Anbindung an eine relationale Datenbank. Da haben sich schon eine Menge Menschen Gedanken zu gemacht. Ist wirklich ein riesiges Problem (Impedance Mismatch: en.wikipedia.org/wik..._impedance_mismatch).

Das einfachste ist es eine objektorientierte DB zu verwenden. Nur wird das nicht immer möglich sein.

Die zweite Möglichkeit ist ein objektrelationnaler Mapper. Ich weiß nicht, was es da für Delphi so gibt.

Dein Vorschlag mit dem Dataset ist nicht der schlechteste. Fakt ist, dass relationale Datenbanken nicht kompatibel zu OO sind. Am "Rand" deines Programmes musst du also dein Design "verschmutzen". Ein Dataset ist deswegen okay, weil es Teil des Frameworks und damit relativ stabil ist. Für kleinere Projekte wäre es sicher die einfachste und somit beste Lösung. Denkbar wäre es, eine persistenten Basisklasseklasse zu haben die ein Dataset aufnehmen kann. Eine Art Memento (GOF- Pattern).
Das ist jetzt aber ein sehr weites Feld und ich muss wieder auf Literatur verweisen. Aber wer zwingt dich denn sofort den elegantesten OO- Code zu schreiben. Fertig machen, Lesen, verbessern, nächstes Projekt, Lesen, usw.

Thomas

noidic hat folgendes geschrieben:

Die Idee, Objekte ihre Daten selbst aus der DB holen zu lassen ist schön sauber.

Jein. Solange du nur gegen ein bestimmtes DBMS programmierst, ist was dran. Ist aber eben leider nicht so, dass SQL = "Standard Query Language" sondern mehr "Structured English Query Language". Mit anderen Worten: Jeder DBMS- Hersteller kocht sein eigenes Süppchen.
Aus OO- Sicht lässt sich auch dagegenhalten, dass diese Klassen zu viel Verantwortung bekommen.
Es hängt aber immer vom restlichen Design, den Anforderungen und der Umgebung ab. Daher ist keine generelle Aussage möglich.