Informatiklehrer



  • Hallo,
    bei dem Gedanken daran einen komplizierten Automaten zu implementieren ohne mir vorher ein Zustandsübergangsdiagramm zu skizzieren wird mir schwindelig. Ich versuche das zwar immer wieder, jedesmal kommt aber totaler Müll dabei raus. Tausche ich hingegen einfach mal Tastatur gegen Stift und Papier und mal ein zwei Stunden vor mich hin, dann kommt in der Regel ein brauchbarer Grobentwurf bei raus. Während des Programmierens stolpere ich dann über bis dato nicht berücksichtigte Spezialfälle, die sich dann aber einfacher integrieren lassen, da der Grobentwurf steht.
    Ähnliche Erfahrungen habe ich auch mit Klassen, deren Aufgaben und Schnittstellen gemacht. Ohne Grobentwurf wird es ein großer Haufen ohne Struktur. Aber egal wie lange man vorher plant und malt und denkt, sobald man programmiert stolpert man über Probleme, die man vorher nicht gesehen hat.

    Wie machst du das?

    Und zum Thema Klassen:
    Du benutzt nicht mal sowas wie CRCs? Nichts? Natürlich sollen Klassen genau eine wohldefinierte Aufgabe erfüllen, aber mir kommt es so vor, als würdest du sagen, dass Klassen immer im Vakuum existieren können müssen (sprich: Jede Klasse macht sinn auch wenn sie in Isolation betrachtet wird).
    Das scheint mir aber nur in absoluten Ausnahmefällen der Fall zu sein (für so Dinge wie Containerklassen). Ansonsten hat man imo viel häufiger Verbände von Klassen, deren Objekte irgendwie kollaborieren um gemeinsam eine Aufgabe zu erfüllen (nicht umsonst hat besteht jedes DP aus mehr als einer Klasse).
    Hier helfen mir CRCs oder auch Diagramme die die Kommunikation zwischen Objekten verdeutlichen ungemein. Code ist dazu imo viel zu Detailbeladen. Da mache ich lieber einen Schritt zurück und schaue mir das ganze im Überblick an.

    Ich gehöre zwar keinesfalls zu den UML-Fans und ich bin auch keinesfalls der Meinung, dass der Richtige Weg(tm) über Use-Case, Use-Case-Digramm, Aktivitätsdiagramm, Aspekt-Modelle und zugehörige Integrations-Modelle usw. geht (so wie man es mir in Softwarekonstruktion beigebracht hat), aber so ein bischen Planen (ohne Code und Computer) scheint mir nicht verkehrt.

    Am Besten hat bei mir bisher eine Kombination aus Use-Cases bzw. Szenarios (damit ich weiß *was* ich überhaupt für ein Problem lösen will), CRCs (Grobentwurf der Klassen) und Test-Driven-Development (Schnittstellen, Kommunikation, erkennen von widerlichen Abhängigkeiten) funktioniert. Wobei ich letzteres noch nicht so perfekt hinbekomme (insbesondere nicht, wenn ich mir vorher nicht wenigstens ein paar Gedanken über die Grundstruktur mache).
    Und wenn ich für mich komplizierte Algorithmen (also komplizierter als eine Zählschleife von 1 bis 10) implementieren muss, dann brauche ich immer eine Menge Papier und einen Stift. Ohne Kreise, Kugeln, Pfeile, Wertelisten, kritzelige Berechnungen über Randfälle usw. wird das bei mir sonst nichts 🙂



  • der algo für wpc112 http://www.geocities.com/acmesofties/wpcq.htm ist sicherlich als kompliziert anzusehen. und mit genuss warf ich die ide an und tippte drauf los. erstmal den funktionsrumpf und dann

    while(
    

    dort am ende der zeile darf der cursor dann ein paar phasen lang blinken und ich überlege mir, wie es weiter geht.
    wenn ich fertig bin, werden zwei a5-zettel mit test-daten draufgegangen sein.

    klassen sind aber ganz anders kompliziert. da muß man nicht sowas verknotetes wie komplizierte schleifen machen, sondern arbeitet mit inhalten und bedeutungen. und gemeinerweise erschließt sich die genaue bedeutung manchmal erst genau, wenn die klasse schon seit drei wochen lebt. zum glück hat diese eigenschaft mir noch kein projekt gekippt. nee, kann ja nicht. ich sehe ja gleich, welche klassen projektentscheidend sind und die treibe ich voran. ok, ich würde niemals sachen machen, wie private zu erben, um ne konstruktorreihenfolge zu erzwingen. mag sein, daß ich deswegen normalerweise keine klassen malen muß.
    daß du sagst, du machst klassen, die nur im zusammenspiel mit anderen sinn ergeben (mal von iteratoren und zum model passenden views abgesehen), erstaunt mich. ich hab den eindruck, das kommt nicht vor. muss mal dahingehend die augen offen halten.



  • Sehr schön volkard. Bei der Seite springt mein Virenscanner an, dass in das temporär Verzeichnis des IE ein Virus runtergelanden wurde beim Aufruf der Seite. 🙄



  • Luckie schrieb:

    Sehr schön volkard. Bei der Seite springt mein Virenscanner an, dass in das temporär Verzeichnis des IE ein Virus runtergelanden wurde beim Aufruf der Seite. 🙄

    omisch. bei mir wird da nix gemeldet. ob das daran liegt, daß ich keinen virenscanner mitlaufen lasse?
    welcher virus isses denn? würde den gerne auf meiner platte sehen und gegebenenfall sogar entfernen.



  • omisch. bei mir wird da nix gemeldet. ob das daran liegt, daß ich keinen virenscanner mitlaufen lasse?

    Was soll dir denn in diesem Fall bitte den Virus melden? 🙄

    VBS-Scriptvirus VBS/Redlof.A.



  • SirLant schrieb:

    Hm, d.h. du machst dir nie Notizen um deine Gedanken zu ordnen? Finde sowas, manche
    machen sowas auch als Mindmap, ziemlich effektiv, da man sich sonst zu leicht in
    den Gedanken verstrickt, geht mir jedenfalls so.

    Ist wohl gewöhnungssache. Hab sowas auch nie gemacht und gehe stattdessen immer über die Prozedur:
    a) Zigarette rauchen und das Problem analysieren
    b) drauflos-hacken ohne Gnade
    c) Zigarette rauchen und den Code analysieren 😃

    Ich glaube die wenigsten (vor allem professionelle Programmierer mit dem Release-Plan im Nacken) haben die Zeit, sich vorher alles in PAP's, Struktogrammen oder Mindmaps auszudenken.


  • Mod

    Cpp_Junky schrieb:

    Ich glaube die wenigsten (vor allem professionelle Programmierer mit dem Release-Plan im Nacken) haben die Zeit, sich vorher alles in PAP's, Struktogrammen oder Mindmaps auszudenken.

    Dazu fällt mir ein, daß 98% aller Softwareprojekte unpünktlich sind. Ob da ein Zusammenhang besteht?

    Eine Person mag noch im Loshacken ein Projekt beginnen können, mir ist aber schleierhaft wie man mit 3 oder 4 Personen ein Softwareprojekt beginnen kann, ohne vorher mal über Entwürfe, Ideen und Zerlegungen diskutiert zu haben. Und diese auch festzuhalten. Nicht als Wegplanung zur konkreten Ausprogrammierung, aber einfach als ungefähre Richtlinie, als roter Faden. Es verlangt doch keiner eine 1:1 Umsetzung, natürlich wird's Abweichungen geben im Verlauf der Programmierung. Aber wer wo startet, das muß man doch festlegen.

    Ich weiß, daß viele Firmen das nicht tun, selbst bei Projekten mit 6-7 Personen gibt's keinerlei Grobpläne für die Software. Hinterher werden dann noch Schnittstellen in "fertige" Teile reingehackt, damit alles überhaupt miteinander kommunizieren kann.



  • Ja is schon klar, das man irgendwo festhält wie in etwa man die Sache angeht. Vor allem bei grossen Projekten mit mehreren Programmierern. Aber glaubst du im Ernst die pinseln sich ihre Ideen erst mit PAP's o.ä. zusammen ? Kann ich mir beim besten Willen nicht vorstellen.


  • Mod

    Ich weiß nicht, warum Ihr Euch an den PAPs aufhängt - diese Analogie PAPs/Struktogramm vs. UML hinkt gewaltig. PAPs sind was im Kleinklein, aber davon sprechen wir hier nicht. UML umfasst auch PAPs und Struktogramme, wenn man will - aber eigentlich geht's hier mehr um Use-Cases oder Klassendiagramme.

    Dieser Analogieschluß will mir nicht in den Kopf - weil ein Mittel für das Kleinklein veraltet ist und wenig bringt, ist auch ein Mittel für das Großgroß wenig sinnvoll? Das ist doch nicht linear extrapolierbar.

    Ich habe noch nie jemanden in der Praxis gesehen, der PAPs verwendet.

    Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".

    Und dafür ist UML als einheitliche Sprache doch ganz nett - solange man nicht in die Tiefen von UML 2.0 absteigt UND die Freiheit lässt, diese ersten Ideen im Laufe der Entwicklung auch zu variieren.



  • Marc++us schrieb:

    Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".
    Und dafür ist UML als einheitliche Sprache doch ganz nett

    warum nicht c++?



  • Marc++us schrieb:

    Dieser Analogieschluß will mir nicht in den Kopf - weil ein Mittel für das Kleinklein veraltet ist und wenig bringt, ist auch ein Mittel für das Großgroß wenig sinnvoll? Das ist doch nicht linear extrapolierbar.

    vorhin haste noch gesagt: ich zwinge meine leute mit uml, sich VORHER nen plan zu machen, damit sie nicht so unüberlegt rangehen. das ist genau der struktogramme-fehler!

    und von anderen höre ich, daß sie auch algos vorher planen. die wissen evtl nicht, was sie sich damit antun. ich hab bei wpc112 mal mitgeschrieben, wie es gelaufen ist und man sieht krass, daß vorherige planung unfug gewesen wäre. (kann es leider schlecht hier posten vor dem einsendeschluss.)

    und genauso ist es bei klassen auch. an der herangeensweise ist zwischen dem entwerfen von algos und dem von klassenverbänden kein riesiger unterschied. der unterschied ist nur, daß man bei algos von der test-suite bei fehlern sofort abgestraft wird, bei klassen erst nach monaten vom terminplan und den magengeschwüren.

    Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".

    das ist ne andere schiene. dafür ist c++ mit auslassungen ganz nebenbei ne hochgeeignete sprache. hab da aber auch gute erfahrungen damit, daß man einfach inhaltlich trennt und mindestnes die erste woche im selben büro arbeitet. schnittstellenverhandlungen geschehen unter profis so:
    "ich muss bei dir gucken können, welche dateien du verändert hast"
    "magste nen vector?"
    "jo"
    "kriegste"
    und sofort ne mail dahinter (ja, per mail über die usa kommuniziert man mit seinbem tischnachbarn . mit der neuen header-datei.)
    nervig wirds nur, wenn sender oder empfänger nix können, und das hab ich auch erlebt. da musste die dame bildunterschriften kriegen und man sagt ihr: such dir irgendein format aus, kriegst. sie konnte sich nix aussuchen. man sagt "kannste vector<pair<int,string> > (x-kordinate der textmitte, text) gebrauchen?". sie sagte, das könne sie nicht verarbeiten, aber machte keinen besseren vorschlag. die software hing und sate, der sender sei nicht kooperativ.



  • Ich bin ja auch nicht gerade ein Fan von UML, PAPs, Struktogrammen, Netzplänen usw. und trotzdem finde ich es wichtig, dass man zumindest eine Grobplanung auf Papier in einem größeren Projekt hat. Es geht da einfach nicht ohne, ansonsten endet alles in einem großen Chaos. Schließlich ist dieses vorherige Skizzieren eine Art Dokumentation.

    @volkard
    Ich hoffe du wirst niemals ein Haus bauen.

    @thema lehrer
    Warum hackt ihr eigentlich immer auf diese Informatiklehrer rum? Seid ihr vielleicht schon mal auf die Idee gekommen, dass die das vielleicht gar nicht studiert haben?

    So in etwa läuft es nämlich tatsächlich ab:
    Herr Müller ist ca. 40 Jahre alt und Lehrer an einer Schule. Sein Hauptfach ist Mathematik. Eines Morgens zitiert ihn sein Direktor in dessen Büro.
    Direktor: "Hallo Herr Müller. Sie sind ja unser Spezialist in mathematischen Angelegenheiten."
    Müller: "Naja ich habe hald Mathematik als Lehrfach studiert."
    Direktor: "Ich habe in Ihrer Akte gelesen, dass Sie als Wahlfach auch etwas Informatik hatten."
    Müller: "Ja, das war ein Semester lang."
    Direkter: "Sie kennen sich doch auch mit Computern aus."
    Müller: "Naja, ich mache privat ein wenig was mit dem Computer."
    Direkter: "Gut, dann sind Sie ja genau der richtige Mann für unser neues Fach Informatik. Sie haben jetzt eh die ganzen Sommerferien Zeit sich etwas einzuarbeiten. Im neuen Schuljahr haben Sie dann auch das Fach Informatik."
    ...

    Schimpft also nicht so einfach drauf rum, denn die können meistens selber nichts dafür, dass sie den Posten draufgedrückt bekommen haben.



  • AJ schrieb:

    Ich bin ja auch nicht gerade ein Fan von UML, PAPs, Struktogrammen, Netzplänen usw. und trotzdem finde ich es wichtig, dass man zumindest eine Grobplanung auf Papier in einem größeren Projekt hat. Es geht da einfach nicht ohne, ansonsten endet alles in einem großen Chaos. Schließlich ist dieses vorherige Skizzieren eine Art Dokumentation.

    und was bringt es, was vorher zu dokumentieren, was man nachher nicht haben will?
    je früher und je exakter festlegungen sind, desto schlechter wird das ergebnis.
    je bereiter man ist, festlegungen und code (auch mal dutzende von seiten) wegzuschmeißen, desto besser wird das ergebis.
    dem gegenüber steht, daß es im team auch nachteilhaft sein kann, wenn die linke hand nicht weiß, was die rechte tut.
    dem versucht man durch frühe festlegunen entgegenzuwirken.
    aber es bleibt ein zielkonflikt. man muss kompromisse eingehen und leider teilweise früh festlegen und dabei auf die top-code-quali zum teil kacken.

    ihr mußt das so sehen: jede frühe festlegung schadet. man darf sie nur in kauf nehmen, um schlimmere gefahren abzuwenden. man darf auf keinen fall einfach so aus lust und laune alles mal festlegen, wie AJ es zu mögen scheint.

    @volkard
    Ich hoffe du wirst niemals ein Haus bauen.

    Ich hoffe, du wirst niemals Software bauen.



  • Heute hatten wir wieder IT und wie haben heute mit OOP angefangen und natürlich auch UML
    bin mal gespannt was mich in Zukunft erwartet 🤡

    Volkard ich kann mir echt nicht vorstellen, wie du in nem 20 Mann Team (oder auch weniger)
    zusammen ne Software entwickelst, ohne jegliche Absprache, ihr müsst doch schon
    nen Konzept haben bevor ihr anfangt, woher weiß sonst jeder was er machen soll?


  • Mod

    volkard schrieb:

    Marc++us schrieb:

    Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".
    Und dafür ist UML als einheitliche Sprache doch ganz nett

    warum nicht c++?

    Weil die dann sofort ständig anfangen zu compilieren. Bevor man sich umsieht, stehen die ersten Variablen bereits im private-Teil. Damit kann man aber nicht anfangen, wenn man noch Zerlegungen diskutiert.

    Das UML dient nur zur Verhinderung dessen, daß mit einem Detail losgehackt wird, weil der Compiler zu früh aktiviert wird.

    Weiterhin hatte ich oft die Situation, daß 3 Leute vor einer Tafel stehen und mit einem Edding bewaffnet eine Sache diskutieren. Wenn man nun die Notation "C++" verwendet findet sich immer ein Brettlesbohrer, der plötzlich einwendet "da fehlt noch ein Strichpunkt". S***** doch auf den Strichpunkt zu diesem Zeitpunkt. Trotzdem hängen sich die Leute daran auf. Sobald man eine Sprache als Beispiel verwendet, macht es *klick* und die Masse der Entwickler denkt nur noch in Implementationsdetails. Oder wenn man eine Klasse skizziert und es kommt die Frage "der Copycon wird aber private gemacht, oder?". Ja, brav, hast Du gut Scott Meyers gelesen und auswendig gelernt. Aber das interessiert doch zu dem Zeitpunkt gar nicht.

    Daher die Wahl einer Notation, die nicht so leicht in Implementationen abrutschen kann.

    Und weiterhin hat's noch einen Effekt - Kostenplanung. Wenn ich ein Diagramm mit 40 Klassen habe und lauter Linien dazwischen, drucke ich das auf A3-Blättern aus und gehe damit zu einem Betriebswirt. Dann sage ich, daß jedes Kästchen auf dem Bild ca. 25 Stunden Arbeit sind und verlange dafür ein Budget. Man stelle sich die gleiche Situation vor, wo ich mit 40 Headern mit C++-Pseudocode zu dem Mann gegangen wäre - niemals wäre das so einfach durchgekommen. [Ich nenne das auch "fuck the fakers"-Methode]

    In meinen Augen hilft UML (wobei ich auch was anderes nehmen würde, vor 8 Jahren habe ich Booch genommen) dabei, real auftretende Probleme der Softwarewelt mit real exisitierenden Entwicklern zu lösen. Daher fällt es bei mir in die Schublade "brauchbares Hilfsmittel".



  • volkard schrieb:

    ihr mußt das so sehen: jede frühe festlegung schadet. man darf sie nur in kauf nehmen, um schlimmere gefahren abzuwenden. man darf auf keinen fall einfach so aus lust und laune alles mal festlegen, wie AJ es zu mögen scheint.

    Falsch. Ich persönlich mache es privat so wie du. Ich hab ne Idee ein paar Vorstellungen im Kopf und programmier munter drauf los. Später werf ich dann sowieso alles wieder um.
    Allerdings kann man sich sowas im Job nicht so einfach leisten, besonders nicht in größeren Projekten. Eine grobe Planung ist ohne Grobkonzept unmöglich (wie Marc++us auch schon angedeutet hat mit seinem Beispiel). Allerdings ist nicht jeder Kunde so naiv, wartet bis das Projekt endlich mal fertig programmiert ist und zahlt dann horense Summen für die Entwicklung.

    Vielleicht reden wir auch etwas aneinander vorbei. Es ist sicherlich sinnlos die Software vorher komplett (Feinkonzept) auf dem Papier zu entwickeln, aber zumindest die Richtlinien (Grobkonzept) sollten vor der Implementation vorhanden sein.

    Schreibst du eigentlich Pflichtenhefte oder Spezifikationen, wenn du einen neuen Auftrag erhältst? (Klingt nämlich bisher nicht so)

    @volkard
    Ich hoffe du wirst niemals ein Haus bauen.

    Ich hoffe, du wirst niemals Software bauen.

    Zu spät! :p



  • AJ schrieb:

    Schreibst du eigentlich Pflichtenhefte oder Spezifikationen, wenn du einen neuen Auftrag erhältst? (Klingt nämlich bisher nicht so)

    nö, ich darf machen, was ich will. ich gebe nen auftrag gut ab, um den nächsten auftrag zu kriegen. und der chef zahlt gut, um mich für den nächsten auftrag zu bekommen. manchmal ist vorher nichtmal kalr, um was es überhaupt geht.



  • volkard schrieb:

    nö, ich darf machen, was ich will. ich gebe nen auftrag gut ab, um den nächsten auftrag zu kriegen. und der chef zahlt gut, um mich für den nächsten auftrag zu bekommen. manchmal ist vorher nichtmal kalr, um was es überhaupt geht.

    Wenn es nur immer so einfach wäre *schwelg*


  • Mod

    @AJ:

    Hm, da hast Du was falsch verstanden - sein Weg ist der schwere Weg.



  • Hallo,
    spätestens wenn ich in einem Team arbeite und ich nicht in einer perfekten Welt lebe, in der sich jedes Team rund um die Uhr an einem gemeinsamen Ort befindet, benötige ich imo auf jeden Fall eine gewisse Form der Planung.
    Erstmal müssen die Teammitglieder in Sachen Ziel übereinstimmen.
    Ansonsten löst jeder lustig ein anderes Problem.
    Das heißt natürlich nicht, dass meine Use Cases oder Szenarios in Stein gemeißelt sind. Natürlich können die sich im Laufe der Zeit ändern. Eine Änderung kann man imo aber nur feststellen und diskutieren, wenn man sie gegen etwas anderes vergleichen kann. Allein deshalb brauche ich imo eine Menge von Basis Use-Cases. Das macht sich auch im Zuge eine evolutionären Entwicklung ganz gut. Ich kann mir eine Menge von Use Cases raussuchen, und so Schritt für Schritt von Release zu Release wandern. Ohne Festlegung von Funktionalität habe ich keinen möglichkeit meinen Fortschritt zu messen.

    Will ich dazu Aufgaben verteilen, dann setzt das voraus, dass ich zuvor eine Zerlegung meines Problems erstelle. Die kann ja von mir aus sehr grob und informell sein, sie muss aber dennoch existieren. Will ich allerdings ein Problem zerlegen, so muss ich vorher zumindest wissen, was mein Problem überhaupt ist.

    Und es geht ja auch nicht immer nur um Softwareneuentwicklung. Manchmal muss vorhandene Software ja auch gewartet werden (habe ich mir sagen lassen). Oder neue Teammitglieder müssen integriert werden und müssen sich deshalb in vorhandene Software einarbeiten. Oder man möchte ein neues Framework einsetzen. Oder unterschiedliche Teammitglieder haben ein unterschiedliches Verständnis bzw. einen unterschiedlichen Wissensstand.
    Hier hat UML (oder eine alternative Methode) clever eingesetzt imo große Kommunikationsvorteile. Natürlich kommt man nicht drum rum sich zu einem gegebenen Zeitpunkt mit dem Quellcode auseinanderzusetzen, aber wenn man vorher auf einer abstrakteren Ebene schon mal die Grobzusammenhänger verstanden hat, fällt das Codelesen deutlich leichter (guter Code sollte natürlich eigentlich alle notwendigen Informationen enthalten. Allerdings ist Code häufig viel zu genau - er muss ja schließlich auch von so einem Hirni wie dem Compiler verarbeitet werden können). Warum soll ich mich z.B. durch tausende Zeilen Code wühlen um die Verarbeitung eines CORBA-RPCs zu verstehen, wenn ich das mit einem Diagramm und ein paar Worten viel schneller erklären kann?

    Ich denke also alles in Allem sehe ich das wohl so ähnlich wie Marcus.


Anmelden zum Antworten