Pseudocode, EPKs, DFDs und ERMs

[Rafael]

Gibt es sowas wirklich in der Welt da draußen? In der Uni muss ich dieses Jahr die Vorlesung Wirtschaftsinformatik besuchen. Dort existieren nur "Ereignisgesteuerte Prozessketten", "Datenflussdiagramme", "Struktogramme" und "Entity-Relationship-Modelle" (nicht die Theorie dahinter, sondern Kreise und Vierecke mit Pfeilen dazwischen. Programmieren mit Stift und Papier...

Eine Lösung zu einer Aufgabe mit "Pseudocode" sieht zum Beispiel so aus:

switch(Bestimme den Tankstellenausdruck)
{
 case Auto für EU:
  Verwende Aufdruck 1; break;
 case Auto für USA:
  Verwende Aufdruck 2; break;
 case Auto für Asien:
  Verwende Aufdruck 3; break;
 default: Verende Aufdruck X;
}

Das ist doch bitte alles nur ein Albtraum? Arrghs!

[Sven Rautenberg]

Moin!

Gibt es sowas wirklich in der Welt da draußen? In der Uni muss ich dieses Jahr die Vorlesung Wirtschaftsinformatik besuchen.

Tja, das, was früher mal in der Schule unter dem Fach "Informatik" verkauft wurde, ist alles andere als "Informatik" gewesen, sondern eigentlich nur "Programmieren". "Informatik" ist in Wirklichkeit die ganze Theorie dahinter.

Dort existieren nur "Ereignisgesteuerte Prozessketten", "Datenflussdiagramme", "Struktogramme" und "Entity-Relationship-Modelle" (nicht die Theorie dahinter, sondern Kreise und Vierecke mit Pfeilen dazwischen. Programmieren mit Stift und Papier...

Ich halte es für grundsätzlich eine gute Idee, sich mit dem theoretischen Aufbau und auch mit Papierskizzen zu beschäftigen. Das schützt auch in der Realität davor, Irrwegen zu folgen, und hilft bei der klareren Darstellung des zu verfolgenden Ziels.

Abgesehen davon ist Papierprogrammierung im universitären Betrieb die virensicherste Variante, die zudem noch komplett ohne Strom auskommt und auch in überfüllten Hörsälen und Klausuren noch angewandt werden kann. Du bringst also auch ein Opfer für die Lehre. ;)

- Sven Rautenberg

[Der Martin]

Hallo Sven,

Tja, das, was früher mal in der Schule unter dem Fach "Informatik" verkauft wurde, ist alles andere als "Informatik" gewesen, sondern eigentlich nur "Programmieren".

das kann ich absolut nicht nachvollziehen. Was damals in meiner Gymnasialzeit als "Informatik" angeboten wurde, war eine Mischung aus "Was ist ein Computer?", Spielen, und einer oberflächlichen Einführung in CP/M. Dabei waren etwa fünf Schüler im Kurs, die den Lehrer in puncto Fachwissen locker in die Tasche gesteckt haben, und ungefähr zwanzig weitere, die nur dem Irrtum erlegen waren, hier könnte man mal eben im Vorbeigehen 15 Punkte abstauben.

"Informatik" ist in Wirklichkeit die ganze Theorie dahinter.

Richtig, und das hat mir das Informatikstudium dann auch vermittelt. Wobei ich der Meinung bin, dass die FH, an der ich studiert habe, eine ausgewogene Kost aus theoretischer Informatik, Grundlagen der Elektrotechnik, Elektronik und Programmiersprachen serviert hat. Alles zusammen nannte sich dann "Technische Informatik".

Ich halte es für grundsätzlich eine gute Idee, sich mit dem theoretischen Aufbau und auch mit Papierskizzen zu beschäftigen.

Ja, unbedingt. Solche Überlegungen, gern auch entsprechende Skizzen (unsere Profs nannten das immer "Mickey-Mouse-Diagramme wegen der Kreise mit den Pfeilen), sollten der Anfang jedes größeren Projekts sein, das man nicht intuitiv in fünf Minuten überblicken kann.

Abgesehen davon ist Papierprogrammierung im universitären Betrieb die virensicherste Variante, die zudem noch komplett ohne Strom auskommt und auch in überfüllten Hörsälen und Klausuren noch angewandt werden kann. Du bringst also auch ein Opfer für die Lehre. ;)

Da ist natürlich auch was dran. ;-)

Schönen Abend noch,
 Martin

[Daniel Thoma]

Hallo Rafael,

"Ereignisgesteuerte Prozesskette" sagt mir als Begriff jetzt nicht direkt was.

"Datenflussdiagramme" scheinen Ingenieure tatsächlich zu verwenden bzw verwendet zu haben (ist ja schon recht alt). In der Informatik selbst scheinen sie mir wenig verbreitet zu sein.

"Struktogramme" halte ich für Papierverschwendung, würde aber nicht versprechen, dass nicht irgend jemand da draußen wirklich solche Dinger malt ;-)

"Entity-Relationship-Modelle" finden bei Datenbanken wirklich Verwendung, die ihnen nicht unähnlichen Klassendiagramme aus UML bei objektorientierter Softwareentwicklung sowieso.

Pseudocode wird sehr oft verwendet, um Algorithmen zu beschreiben. Eine Algorithmus in einer konkreten Sprache auszuformulieren kann sehr umständlich sein und ist für eine Beschreibung oft ungeeignet, weil der Leser den überblick verliert.

In der Informatik ist es aber eher üblich, mathematische Konstrukte zu verwenden und solche Beschreibungen zu vermeiden. Für Anwendungen in der Wirtschaftsinformatik mag sowas aber schon sinnvoll sein.

Das ist doch bitte alles nur ein Albtraum? Arrghs!

Graphische Modellierung mit ERMs (oder diversen UML-Diagrammen) ist schon nützlich, mindestens mal zur Dokumentation/Erläuterung und Pseudo-Code wirst Du in vielen wissenschaftlichen Artikeln in der Informatik finden, wenn auch in etwas anderer weise.

Meine Erfahrung mit manchen Vorlesungen in dieser Ecke ist allerdings, dass Da viel angestaubtes Zeug vorgestellt und vor allem der Eindruck erweckt wird, als ginge es darum, tonnenweise Papier mit nutzlosen Diagrammen vollzumalen.
Guck Dir vielleicht mal UML an, wenn Du sehen willst, was mit graphischer Modellierung so gemacht werden kann.

Grüße

Daniel

[Længlich]

Ciao!

Gibt es sowas wirklich in der Welt da draußen?

Teilweise. Nicht so häufig, wie es der Prof erzählt, bei dem Du es lernst, aber auch nicht so selten, wie es der Prof erzählt, bei dem Du die konkrete Programmierung lernst. ;-)
Es hängt auch immer sehr stark vom jeweiligen Unternehmen/Gruppierung, der Abteilung und den einzelnen Mitarbeitern ab. Manche Teams planen länger als sie programmieren, andere tippen gleich drauf los. Bei beiden kann sowohl was Gutes als auch Murks rauskommen.

In der Uni muss ich dieses Jahr die Vorlesung Wirtschaftsinformatik besuchen. Dort existieren nur "Ereignisgesteuerte Prozessketten", "Datenflussdiagramme", "Struktogramme" und "Entity-Relationship-Modelle" (nicht die Theorie dahinter, sondern Kreise und Vierecke mit Pfeilen dazwischen. Programmieren mit Stift und Papier...

Eine Lösung zu einer Aufgabe mit "Pseudocode" sieht zum Beispiel so aus:

switch(Bestimme den Tankstellenausdruck)
{
case Auto für EU:
  Verwende Aufdruck 1; break;
case Auto für USA:
  Verwende Aufdruck 2; break;
case Auto für Asien:
  Verwende Aufdruck 3; break;
default: Verende Aufdruck X;
}

Das ist doch bitte alles nur ein Albtraum? Arrghs!

Hmm, kommt drauf an. Pseudocode finde ich sehr angenehm - das heißt letzten Endes nur, daß Dir der Prof keine konkrete Programmiersprache vorschreibt, sondern Du Dir Syntax und Funktionsnamen selbst aussuchen (sogar aus verschiedenen Sprachen mischen) kannst - solange immer klar bleibt, was gemeint ist. Im obigen Beispiel würde Dir z.B. ein C-Compiler ein großgeschriebenes "Default" sofort vor die Füße werfen; in Pseudocode ist das okay. Du vergeudest also keine Zeit mit dem Googeln nach konkreten Schlüsselwörtern oder Funktionsnamen.
Dagegen finde ich Struktogramme reichlich nervig. Sie sind kaum übersichtlicher als Pseudocode, aber viel schwieriger zu erstellen. Insbesondere bekommt man bei verschachtelten Strukturen sehr schnell Platzprobleme in den immer kleiner werdenden Kästen.

Bei den ganzen Diagrammtypen gibt es auch nützliche und weniger nützliche. Die EPKs (die ich erst jetzt während der Diplomarbeit kennengelernt habe) gefallen mir sehr gut: Sie bringen die Informationen genau und übersichtlich rüber, und es gibt Darstellungsmöglichkeiten für alle Strukturen (Verzweigungen, Schleifen, ...). Auch Klassendiagramme sind bei größeren objektorientierten Projekten gar nicht so falsch.
Dagegen habe ich bei einigen anderen Typen noch gar nicht herausgefunden, wozu sie gut sein sollen. V.a. in Sequenzdiagrammen und Use Case sehe ich kaum einen Sinn - die damit darstellbaren Infos werden mit Pseudocode und Klassendiagrammen IMHO viel übersichtlicher.

Das alles ist jetzt natürlich nur meine persönliche Meinung. Wahrscheinlich favorisiert jeder andere Diagrammtypen, und wer an großen Projekten mitarbeiten will, sollte die gängigen zumindest lesen können. Aber wenn es um das Verstehen vorhandener Programme geht, ist mir auch oft ein (ordentlich kommentierter) Quelltext mit Syntax-Highlighting lieber. ;-)

Viele Grüße vom Længlich