Frage zu Herangehensweise von Softwareprojekten (Prozedural vs. OOP)

[DennisXX]

Hi Folks !

Ich hoffe, ich habe hier die richtige Forenkategorie erwischt!?

Ich habe mal eine Frage zu der Herangehensweise / der Planung und Definition von zu entwickelnden Programmen / Projekten. Ich kenne die Herangehensweise bisher nur bei objektorientierter Software (Schreiben von Pflichtenheft, Definition von Use Cases, Schreiben von Klassendiagrammen und Sequenzdiagrammen mit der UML).

Aber ich stelle mi die Frage, wie man so etwas bei reinen prozeduralen Sprachen machen kann, also bei Programmen, die nciht aus Objekten bestehen, sondern aus Funktionen, die vielleicht nur Objekte in Komponenten nutzen (z.B. Objekte in Excel wie ein Diagramm, eine Achse des Diagramms usw.). Mir fällt da nur ein, evl. die Funktionsnamen festzulegen, das was die Funktionen machen sollen und die explizite Benenung von Imputparametern und Outputparametern. Das wäre quasi eine Art UML Ersatz.

Habt ihr euch vielleicht schon mal auseinandergesetzt. Gibt e vielleicht noch andere Methoden, solche prozeduralen Programme zu definieren.

Ich frage euch das, weil ich heute in einem Vorstellungsgepräch genau darauf angesprochen worden bin und viel improvisieren musste. Ich habe meine prozedualen Programme bisher eher adhoc umgesetzt und feste vorerhige Plannung. Bei OOP habe ich es anders gemacht.

Greetz

Dennis

[Pixie]

Pflichtenheft, UseCases, Sequenzdiagramme sind ja nicht OOP-spezifisch. Es gibt also ersteinmal viele Gemeinsamkeiten in der generellen Planung.

Objekte kann es dann z.B. auch geben für die Datenhaltung. Ebenso wird man versuchen auch mit einer Schichtenarchitektur zu arbeiten, den Code wiederverwertbar zu halten, also vermutlich verschiedene Module zu erstellen, die sich aus den einzelnen Funktionalitäten ergeben.

Ich frage euch das, weil ich heute in einem Vorstellungsgepräch genau darauf angesprochen worden bin und viel improvisieren musste.

Vielleicht ging es ja genau darum... zu beobachten, wie der Kandidat eine Antwort herleitet und begründet... ihm quais beim Denken zuzugucken und zu sehen, ob er zur Abstraktion von Problemstellungen in der Lage ist.

[i � unicode]

Das "prozeduale Analogon" zu Klassendiagrammen heisst "Nassi-Shneidermann-Diagramm" oder schlichtweg "Struktogramm".

Damit kannst du nahezu alles abbilden, was die prozeduale Programmierung dir bieten kann.

Grüße.

[DennisXX]

Hi Folks !

Pflichtenheft, UseCases, Sequenzdiagramme sind ja nicht OOP-spezifisch. Es gibt also ersteinmal viele Gemeinsamkeiten in der generellen Planung.

Der Ansatz ist auf jeden Fall interessant.

da hast Du definitiv recht mit Deiner Aussage, die Frage ist allerdings, wie genau man so etwas vernünftig und mit welchen wissenschaftlichen Methoden planen und aufzeichen / aufzeigen kann? (UML fällt ja raus, aufgrund der OOP und Klassenstrukturen).

Genau ist das mir auch schon durch den Kopf gegangen, dass man einfach nur intenisv getestet wurde. Trotzdem hat es mir auch etwas neugierig gemacht, genau hierauf jetzt eine Antwort finden zu können.

Danke für Deinen Post !

Greetz

Dennis

[Pixie]

wie genau man so etwas vernünftig und mit welchen wissenschaftlichen Methoden planen und aufzeichen / aufzeigen kann?

Wie viele Firmen machen das wirlich in der Praxis? Microsoft bei der Erstellung neuer Office-Produkte sicherlich, aber kleine 6-Mann-Firmen werden nach einem gewissen Grad der Grobplanung einfach anfangen, weil gar nicht die Zeit ist, solange auf diese Phasen zu verwenden.

(UML fällt ja raus, aufgrund der OOP und Klassenstrukturen).

Vorsicht!! UML heißt nicht nur Klassendiagramme. UML ist eine Sammlung von diversen Darstellungsformen für verschiedene Aspekte in der Softwareentwicklung, aber z.B. auch zur Abbildung von Geschäftsprozessen.

Unified Modeling Language

Man kann z.B. auch mit ganz normalen Ablauf-/Flussdiagrammen planen. Sowohl für OOP als auch für prozedural.

[DennisXX]

Wie viele Firmen machen das wirlich in der Praxis? Microsoft bei der Erstellung neuer Office-Produkte sicherlich, aber kleine 6-Mann-Firmen werden nach einem gewissen Grad der Grobplanung einfach anfangen, weil gar nicht die Zeit ist, solange auf diese Phasen zu verwenden.

Du sprichst mir aus der Seele, denn genau das dachte ich auch in dem Vorstellungsgespräch, als ich intensivst dannach gefragt wurde, wie ich ein Softwareprojekt aufsetzen würden (intensivste Planung eben). Das Unternehmen, bei dem ich mich beworben hatte, ist ein IT Consulting Unternehmen, bei denen viele Softwareentwickler speziell geschult werden und dann genau in diesem Rahmen direkt vor Ort beim Kunden Projekte aufsetzen und programmieren sollen. Es wurde ausdrücklich erwähnt, dass sehr sehr viel Wert auf die Planungen der Projekte gelegt werden (und dieses IT Consulting Unternehmen macht alles andere, als einen sperrlichen und armen Eindruck). Ich wollte zwar erst was in diese Richtung im Gespräch sagen, dass man sich nicht so statisch auf die Planung von Methoden, Objekten, ER-Modellen, Sequenzdiagremmen und was weiß ich was festklammern sollte, habe es mir aber dann aber doch lieber verkniffen.

Also ich habe etwas Vorstellungsprobleme mit ienem Ablaufdiagramm / Fußdigramm für prozedurale Programmierung, vielleicht einfach auch deswegen, weil ich total auf OOP versteift bin. Gibt es da vielelicht irgendwie mal ein Anschauungsbeispiel, was mir die Möglichkeiten dieser Modell im Rahmen der prozeduralen programmierung aufzeigen kann?

Kann man denn auch Sequenzdiagramme für prozedurale Programmierung verwenden und wenn ja, wie genau werden dann die Objekte in diesem Diagramm ersetzt, an denen Methoden aufgrufen werden?

Greetz

Dennis

Bearbeitet 6. September 2011 von DennisXX

[flashpixx]

UML fällt ja raus, aufgrund der OOP und Klassenstrukturen

Nein das ist nicht korrekt, man kann eine Software mit Hilfe von UML designen und mit Hilfe von Metatransformationen in prozeduralen Code übersetzen lassen.

Die abstrakte Basis für die Modellentwicklung ist die Model Driven Architecture wobei man dort eben in einer Architektur das Computation- und Plattform-Indepetent-Modell entwickelt und dann über das Plattform-Specifed-Modell den Code generiert. Methodenrümpfe können natürlich wieder als Nassi-Schneider-Diagramm entwickelt werden. Bei abstrakter Modellierung mit UML setzt man aber da häufig auf Zustandsübergangsdiagramm bzw Zustandsdiagramm (UML) wobei man natürlich aus dieser abstrakten Sicht auch in die Aspektorientierte Programmierung dann entwickeln kann.

UML bitte nicht mit irgendwelchen Klassendiagrammen gleich setzen.