Hallo, wie ihr zweifelsohne gemerkt habt will ich wirklich OOP verstehen und bin gezwungen mir das im Selbststudium beizubringen. Aber irgendwie gehen alle Dokumente die ich dazu lese (für mich) am Thema vobei.
Versteht mich nicht falsch, aber ich weiß schon das OOP Klassen bedeutet und das man diese mit UML Klassendiagrammen darstellen kann
Aber die ganze Verbindung mit den großen Konzepten sind mir nicht wirklich klar. Am besten ich fange erstmal an (damit ihr nicht einschlaaft in Stichpunkten)

-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

Tja mir ist jetzt bloß total unklar wie da jetzt die Heinzelmänchen im UseCase nützlich sind und überhaupt 13 Diagrammtypen und zig Abstraktionsschichten. Und was ist mit den Patterns? Und ist DB da nicht total inkompatibel/umständlich? Wäre wirklich schön wenn mal jemand der das macht auch alltagstaugliche und überschaubare Beispiele bringen könnte. Vielleicht sogar in Delphi

Bitte speißt das jetzt nicht mit schau hier schau da ab, habe ich nämlich eigentlich schon:
wwwswt.informatik.un...h/Infothek/uml/kurs/
www.jeckle.de/unified.htm
www.oszhdl.be.schule...rmatik/oop/index.htm
mezmedia.de/oop/
www.educeth.ch/infor.../xmlintro/index.html
UML , OBJEKTORIENTIERTE PROGRAMMIERUNG
de.wikibooks.org/wik..._Softwareentwicklung
de.wikibooks.org/wiki/Muster
de.wikibooks.org/wiki/Softwaretechnik

Irgendwie fehlen da immer die Brückenschläg und dauernd TSkoda von TAuto abzuleiten macht ja auch keinen Spass

UML zielt auf 2 Dinge: 1. Durchgängigkeit in allen Phasen der Softwareentwicklung und "gemeinsame "Sprache" von SW-Entwickler und Anwender.

USE-Cases dienen i.e.R. festzulegen was das Programm können soll, wie der allg. Datenfluß ist. Die einzelnen usecases finden sich später meistens als Methoden irgend welcher Klassen wieder.

Am besten besorgst du dir mal ein UML-Tool wie z.B. Poseidon und gehst die Tut durch.

Aber um das Konzept von OOP zu verstehen würde ich nicht unbedingt zuerst UML lernen.

OOP = Objekt Orientiertes Programmieren, sowas:

oder auch:

welche man ganz einfach so verwendet:

Um Objekt-Orientiert Programmieren zu lernen ist UML mehr als ungeeignet. Ich sehe in der Hinsicht keine Notwendigkeit UML zum "Modellieren" zu verwenden ... Man macht sich eh meist auf'm Papier ne viel übersichtlichere Darstellunge, was in eine Klasse rein muss.

Eine der wichtigsten Fähigkeiten bei OOP ist es, zu wissen, was wohin muss; eine Fähigkeit, die mir heutzutage immer weniger begegnet!

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Ja ebend und um diese "Schlauigkeit" weiterzureichen benutzt man doch Patterns oder? Dort wird doch der Aufbau/Beziehungen von Klassen sowie ihr zeitliches Zusammenspiel beschrieben?

Also mit UML soll ich durchgängig arbeiten können, das ist mir klar aber nicht wie das gehen soll. Ich muss ja den Prozess darstellen, daraus die Informationsflüsse und beteiligte Objekte isolieren und diese als Klasse überführen.

CASE Tools habe ich ja schon reichlich durch. Aber gerade da begegnen einem ja die ganzen Dinge und da will ich wissen, wie ich sie zu meinem Vorteil gebrauchen kann.

Wie ich sagte ich bin ja nicht auf den Kopf gefallen und weiß WAS OOP ist und ich denke auch ganz gut WIE man es benutzt aber ich verstehe das Zusammenspiel der ganzen Techniken die beim Engeniering so benutzt werden nicht...

Ursprünglich hätte UML ja UMM ( Unified Modelling Method) heißen sollen, wurde aber dann zu UML. Also keine Methode sondern nur eine (Notations-)Sprache.
Für solche Automatiken benötigst du dann weiter Tools welche das sogenannte MDA anbieten. Mit reinen UML-Tools muß der Programmierer die Überführung zwischen den einzelnen UML-Diagrammen noch manuell durchführen.
Diese Tools kosten allerdings auch etwas. Es gibt auch OS-Ansätze dafür. Borland's ECO-Framework geht in diese Richtung.

Ich denke MDA ( MODEL DRIVEN ARCHITECTURE) läuft UML teilweise entgegen?

So richtig alles durchziehen tut das wohl aber keiner, oder? Habe jedenfalls noch keinen kennengelernt
Vielleicht setzen sich wirklich nir JAVAraner diesem Stress aus

Ich bin auch der Meinung, bevor man sich mit UML auseinandersetzt, sollte man in OOP erstmal absolut sattelfest sein. Denn nur dann bringt man auch gescheite Modelle zustande.

Der wichtigste Punkt bei OOP ist, dass man sich aneignet, in Objekten zu denken. Wenn ich z.B. eine Überwachungssoftware bauen soll, müssen mir Räume, Etagen, Kameras und Personen direkt als Klassen ins Hirn springen, und nicht zuerst die einzelnen Aktionen, die durchgeführt werden. Da sehe ich auch ein Problem vieler Einsteigerbücher, gerade in Delphi, die erstmal damit anfangen, wie ich verschiedene Aktionen abbilde. Wenn das erstmal drin ist, isses schwierig, die Perspektive auf Objekte umzuschwenken. Soweit meine Meinung dazu

Was die Patterns angeht, einige lassen sich in Delphi recht gut abbilden ( z.B. Factory, Singleton ) und sind auch sehr hilfreich, andere wiederum sind nur mit grösserem Aufwand und auch dann nur unbefriedigend umzusetzen ( MVC z.B. ). Das liegt mE daran, dass Delphi zu konzipiert wurde, dass Oberfläche, Daten und Programmlogik eng miteinader verknüpft sind ( siehe allein datensensitive Komponenten ).

Um sich intensiv mir OOP zu beschäftigen, kann ich nur Java empfehlen, da kommt man garnicht erst in die Verlegenheit, an Objekten vorbei zu arbeiten

Durch Java bin ich ja auch darauf gekommen da wir ein Jahr damit verbracht haben und mir das auch sehr gut bekommen ist. Aber wie ist den das mit Patterns nun im Detail zu verstehen?

digi_c hat folgendes geschrieben:

Durch Java bin ich ja auch darauf gekommen da wir ein Jahr damit verbracht haben und mir das auch sehr gut bekommen ist. Aber wie ist den das mit Patterns nun im Detail zu verstehen?

Ein Design Pattern ist allgemein gesagt eine Lösung für ein häufiger vorkommendes Problem.
Ein einfaches Beispiel ist das Singleton-Pattern - das ist wohl das einfachste Design Pattern. Ein Singleton ist eine Klasse, von der immer nur eine Instanz existieren soll. In dem Projekt, an dem ich arbeite, haben wir eine ganze Menge Singletons, z.B. sind die Datenbankverbindung, eine globale Icon-Liste, die Programm-Voreinstellungen und diverse Factories als Singletons implementiert.

Ein Singleton sieht dann zum Beispiel so aus:



Der zugriff auf das Singleton erfolgt dann immer über TSingleton.Shared. Der erste Aufruf von Shared erzeugt die Singleton-Instanz, alle weiteren benutzen sie dann. Vorteile:
1. keine globale Variable
2. die Erzeugung geschieht automatisch bei der ersten Benutzung
3. es sit nicht möglich die Klasse versehentlich mehrfach zu erzeugen, weil der Konstruktor private ist.

Stefan

OK das habe ich verstanden, kommt dem sehr nahe was ich mir so vorgestellt hatte.

Wozu benötige ich aber die vielen anderen UML Diagramme? Klassendiagramm ist ja sehr gut aber schon bei Use Case würde eine einfache Kundenverwaltung total unübersichtlich werden.

Muss ich für Algorithmen/... wirklich immernoch Struktogramme nehmen?

Kannst auch Aktivitätsdiagramme nehmen. Oder Zustandsdiagramme. Was halt grad besser passt.

Aber das beschreibt eher den Prozess als jetzt irgendein technisches Vorgang(Berechnungen,...) oder?

Was du damit beschreibst ist ganz allein dir überlassen. Das Diagramm wird sich nicht beschweren

Du kannst ja auch mit einem Klassendiagramm zusammenhänge beschreiben, die so garnix mit Klassen im Softwaresinne zu tun haben. Die verschiedenen Diagrammtypen wurden zwar für bestimmte Anforderungen entwickelt, das heisst aber nicht, dass sie nich auch für andere Anforderungen benutzt werden können.

Ich benutze z.B. eigentlic immer zur Modellierung von Algorithmen Aktivitätsdiagramme, da ich sie leichter lesbar finde als Struktogramme.

Struktogramme finde ich auch nicht so gut, PAPs sind o.k. wenn es z.B. um ASM geht.

Schöne neue Developer Welt

Häh, so'n PAP für ASM tät'sch gern mal sehen wollen *g*

Naja, ich entwickel meine Softwareklassen auch nach der Ausfertigung eines Datenfluss-Diagramms, dass als stupides Organigramm vorliegt ... Wer sich beim Programmieren an das hält, was ihm beigebracht wurde, kann nicht weiter kommen, wie er es gelernt hat. Ich könnt nach einem Seminar "Einführung in die Informatik" immer wieder ganze Flugzeug-Hangars überfallen, um meinen Vorrat an Kotzbeuteln aufzustocken.

Software-Modellierung ist was von Leuten, die nicht programmieren können für Leute, die es nie können werden.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Naja also erst denken und dann coden ist ja nun schonmal net verkehrt aber wenn man x tausend Möglichkeiten hat das dazustellen *aua*
Zumal ich gemerkt habe das die meisten Probleme durch Mißverständnisse("wie ich soll das Objekt kreiieren, ich dachte du machst das..."), mangelnden Datenaustausch("ich hab ne neue Komponente, ich maile sie euch mal", Wochen später: " wie du hast noch Komponente 1.2?") und mangelnde Absprache/Abstraktion("nö genau die selbe habe ich gestern erst geschrieben") zustande kommen.

BenBE hat folgendes geschrieben:

Häh, so'n PAP für ASM tät'sch gern mal sehen wollen *g* Naja, ich entwickel meine Softwareklassen auch nach der Ausfertigung eines Datenfluss-Diagramms, dass als stupides Organigramm vorliegt ... Wer sich beim Programmieren an das hält, was ihm beigebracht wurde, kann nicht weiter kommen, wie er es gelernt hat. Ich könnt nach einem Seminar "Einführung in die Informatik" immer wieder ganze Flugzeug-Hangars überfallen, um meinen Vorrat an Kotzbeuteln aufzustocken. Software-Modellierung ist was von Leuten, die nicht programmieren können für Leute, die es nie können werden.

Du sagst es
Na ich mein, ein wenig Struktur schadet wohl keinem, ohne Struktur gehts net, aber wenn man für 5 Zeilen Code, vorher 5 Stunden Diagramme gemalt hat ist das einfach zu viel. (Denke im Studium wird das nochmal dicke auf mich zukommen *schauder*)

Man kann die Modellierung auch übertreiben, das stimmt wohl. Aber die Aussage vom BenBE kann ich nicht nachvollziehen...

Ich halte mich eigentlich für einen veritablen Programmierer, trotzdem greife ich gerne auf Klassen- und Aktivitätsdiagramme zurück. Zum einen, um mir einen Überblick zu verschaffen, was an welcher Stelle wann zu tun ist, zum anderen, um mit anderen aus dem Team die Überlegungen diskutieren zu können, ohne das man sich auf, im Vergleich zu einem Modell unübersichtlichen, Code stürzen müsste.