Passt hier vllt. nicht ganz optimal rein, womöglich müsste ich mir ein anderes Forum für meine Frage aussuchen, aber ich probiers mal trotzdem.
Mir wurde mitgeteilt, dass ein UML-Aktivitätsdiagramm abhängig davon ist, ob eine Anwendung prozedural oder objektorientiert programmiert wird. Ist dem denn so? Mir ist das nicht ganz klar, da dieses Diagramm ja die Aktivitäten/Abläufe darstellt und meiner Meinung nach nichts spezifisches mit OO zu tun hat und somit davon unabhängig ist, oder nicht?
Ist schon LANGE (Schule) her, dass ich was mit UML gemacht hab
Aber ich kann mich irgendwo dunkel erinnern, dass man in UML auch Klassen modellieren kann.
Wie die Abkürzungg schon sagt ist es ja eine Unified Modelling Language. Daher glaube ich, kann man damit sehrwohl auch OO und die Beziehungen zwischen den Objekten (Aktivitäten) darstellen.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
Mir geht es aber vielmehr um die Frage, ob es überhaupt notwendig ist, ein Aktivitätsdiagramm auf Objektorientierung basierend zu erstellen oder nicht. Da meiner Meinung nach ein Aktivitätsdiagramm unabhängig davon ist. In einem Aktivitätsdiagramm wird ja das Verhalten des Systems beschrieben. Aber dabei ist mir nun nicht klar, ob es einen Unterschied beim Modellieren macht, ob ich objektorientiert oder prozedural programmiere. Es wird ja "nur" das Verhalten modelliert/dargestellt, nicht aber, wie ich es umsetze (objektorientiert oder prozedural).
Hoffe meine Problematik oder Fragestellung ist klar geworden, da bin ich mir nämlich nicht so sicher.
Naja, ich könnte mir schon vorstellen etwas lieber OO zu modellieren als prozedural.
Dann kann man ja IMHO im ersten Schritt nur mal die Objekte die bestimmte Aspekte der Verarbeitung übernehmen modellieren und dann im zweiten Schritt die Abläufe zwischen den Objekten.
Ich denke da jetzt besonders an das MVC (Model View Controller) Prinzip:
Das Modell übernimmt die Datenhaltung, der View die Anzeige und der Controller die Ablauflogik.
Jeder ist für einen Teil zuständig und die Kommunikation zwischen den Objekten ist nur mehr auf das wesentliche beschränkt.
Ein Ablauf wäre dann:
- Der Controller weist dem Viewer an Daten anzuzeigen.
- Dieser muss erst beim Modell die Daten abholen.
- Das Modell lädt die Daten, kontaktiert dem Controller, dass neue Daten vorhanden sind.
- Der Controller entscheidet ob diese Daten verarbeitet werden dürfen.
- Nachdem dies geklärt ist erhällt der Viewer die korrigierten Daten und zeigt sie an.
Hingegen prozedural:
- Daten werden geladen
- Überprüfen der Daten
- Daten anzeigen
Nun gut das Ergebnis ist dasselbe, aber beim OO Modell haben wir mit der Anfrage zur Datenanzeige begonnen, was prozedural in der der Form nicht möglich ist.
Solange man die Kommunikation zwischen den Objekten nicht verändert, kann man außerdem beim UML ja auch die Teilobjekte intern andere Aktivitäten vollführen lassen.
Kurz: Ich denke schon, dass es einen Unterschied macht, ob man die Aktivitäten OO modelliert oder prozedural.
lg
ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.