3. Informatiklehrer

Informatiklehrer

  • V

    Steven schrieb:

    Nein, ich habe mich nur unglücklich ausgedrückt: Bei großen Projekten mit mehr als ca. 6-8 Klassen schreibe ich mir auf, welche Klassen ich brauche und welche Klasse von welcher erbt. Viel mehr ist das eigentlich nicht. Für kleine Projekte habe ich das auch noch nie gemacht.

    ich empfehle es auch für 100 klassen nicht. die klasse leuchtet aus sich selbst heraus und ist rund und gut. sie lebt nicht erst im verband mit anderen klassen.

    [quote="Steven"]Goto macht den Code sogar in manchen Fällen lesbarer, nämlich, wenn man aus mehrfach verschachtelten Schleifen raus will.[quote]
    aber da will man nicht mt goto raus, da man die mehrfach verschachtelen schleifen in ne funktion ausgelagert hat, und aus den schleifen hüpft dort ein return.

    0
  • V

    Marc++us schrieb:

    Volkard, Du bist gerade an meiner Ausfahrt vorbei gerast.

    nicht wirklich, fürchte ich.

    Hacken alle Leute selbständig darauf los und explorieren ihren Code, passt hinterher vielleicht die Mutter nicht mehr auf das Gewinde. Bei Toll-Collect haben sie hinterher Module zusammenfügen wollen, bei denen die Datenschnittstellen nicht übereinstimmten. Da wäre irgendwann ein Bildchen vielleicht sinnvoll gewesen, bevor man an 2 getrennten Entwicklungsorten mit der Codierung beginnt.

    kann es sein, daß ich den befähigten coder unterstelle und du davon ausgehst, mit luschen zu arbeiten?

    So, nun mache ich einen umgekehrten Induktionsschluß und nehme an, daß auch ein Einzelentwickler (Teamgröße n = 1) so arbeitet - er kommuniziert mit sich selbst genauso über eine Abstraktionsebene. Natürlich völlig unnötig, da man diese Stufe vereinfachen kann.

    und schädlich!

    Aber wenn ich will, daß diese Person irgendwann mal im Team arbeitet, benötige ich diese Abstraktionsebene - damit diese Person eben über die notwendige Schnittstelle verfügt.

    er soll erstmal coden lernen! dann entwerfen. und nicht wie heutzutage andersrum. das kann nix werden. oder sollen schüler zuerst englische aufsätze schreiben und lernen erst im studium dann die vokabeln dazu?

    Netter Nebeneffekt ist, daß man Lehrnende auch mal zwingt, sich von ihrer gottverdammten Programmiersprache zu lösen und mal das Problem abstrakt zu durchdenken.

    nope! eine gottverdammte maschine hat drunter zu sein. und man kann in uml nicht denken. eckmarken und stolperfallen des schlechten entwurfs äußern sich immer darin, daß man letztendlich im coden und warten ein fieses problem kriegt. wie will man dafür ein verständnis aufbauen, wen man abstrakte bildchen malt?

    edit: streich am besten selbst alle argumente für UML, die mit gleichem wortlaut auch für struktogramme oder für UN sprecvhen würden.

    0
  • S

    Hm, also ich hab bisher meist drauf losgeschrieben, weil ich ungefähr im Kopf
    wusste wie ich es angehe, mein Nachteil ist, dass das Design ganz von meiner
    Laune, Müdigkeit und anderen Einflüssen abhängt, kann man natürlich nachträglich
    noch ändern, aber wozu wenn man es mehr zu Spass geschrieben hat 🤡

    Meine Notizen, wenn ich etwas plane sehen so aus:
    -Ich schreib mir auf was ich machen möchte, entwerfe erste Ideen für das Datendesign
    -Überlege mir was ich brauche um damit zu arbeiten, dann ändere ich das Datendesign
    höchstwarscheinlich, weil man es einfach noch besser machen kann
    -Entwerfe ein Klassendesign wo das ganze reinkommt, das ist einfach auf nem Papier:

    foo public: bar {
    // öffentliche Schnittstellen
    // Datenmembers
    };

    Die Verbindung der Klassen, kann man doch ganz einfach darstellen indem man ein
    Blatt nimm die Namen hinschreibt und je nach Art der Beziehung die Linie in ner
    anderen Farbe malt. Schnittstellen sind hier doch uninterressant.
    Nen Algo entwickle ich eigentlich meist außerhalb und schmiere den erstmal so hin,
    versuche zu verbessern und schreibe ihn am schluss nochmal schön (formatierung,
    Namen,...) teste ihn nochmal und bau ihn ein.

    0
  • M
    Mod

    volkard schrieb:

    kann es sein, daß ich den befähigten coder unterstelle und du davon ausgehst, mit luschen zu arbeiten?

    Ich unterstelle den real verfügbaren Entwickler. 🙂

    Mein Problem ist: die Leute hören die Problemstellung, schalten den PC an, starten die IDE, und beginnen zu tippen. Wenn's gut läuft, gleich mit der GUI anfangen. "Gerechnet wird noch nix, aber die Dialoge habe ich schon fertig"

    Ich versuche hier irgendwie den Zwischenschritt "Nachdenken" einzubauen. Bisher gelang das nur, wenn man die Leute zwingt den PC mal 4 Stunden aus zu lassen und auf Papier ihre Idee zu skizzieren. Sobald der PC an ist, entwickeln sich die meisten Leute zu brachialen Trial&Error-Codern, die bereits eine Schleife auf Assemblerebene optimieren, aber noch keine Bereichsprüfung im Algorithmus drin haben.

    Nur wenige sind in der Lage, aus dem Problem ein Gebilde zu entwerfen und das im Kopf zu haben, und dieses in Code umzusetzen. Also erzwinge ich die Visualisierung des Gebildes.

    Den Unterschied Struktogramm - UML sehe ich darin, daß man Struktogramme auf einer Ebene einsetzt, die sich auch schwache Entwickler noch vorstellen können, daher redundant sind. Aber nur wenige können sich auch noch die gesamte Applikation im Zusammenspiel vorstellen.

    0
  • V

    Marc++us schrieb:

    Mein Problem ist: die Leute hören die Problemstellung, schalten den PC an, starten die IDE, und beginnen zu tippen.

    das ist gut.

    Wenn's gut läuft, gleich mit der GUI anfangen. "Gerechnet wird noch nix, aber die Dialoge habe ich schon fertig"

    das ist schlecht.

    Ich versuche hier irgendwie den Zwischenschritt "Nachdenken" einzubauen.

    das ist schlecht.
    nachdenken muß nicht *ein* zwischenschritt mal sein, sondern immer dabei sein. sofort nach dem starten der ide bis ans späte ende, wenn die gui gestrickt wird.

    Bisher gelang das nur, wenn man die Leute zwingt den PC mal 4 Stunden aus zu lassen und auf Papier ihre Idee zu skizzieren.

    und danach plattes einhacken.

    Sobald der PC an ist, entwickeln sich die meisten Leute zu brachialen Trial&Error-Codern, die bereits eine Schleife auf Assemblerebene optimieren, aber noch keine Bereichsprüfung im Algorithmus drin haben.

    evtl solltest du den leuten beibringen, daß jede funktion und jede klasse in der ersten version schrott ist und eh reimlementiert weden soll? daß es ausnahmen gibt, und manch eine funktion auch mal auf anhieb kein designfehler ist, werden sie selber bemerken.

    Nur wenige sind in der Lage, aus dem Problem ein Gebilde zu entwerfen und das im Kopf zu haben, und dieses in Code umzusetzen. Also erzwinge ich die Visualisierung des Gebildes.

    ich habe eigentlch immer sehr früh das gebilde im kopf. so nen roten faden, an dem sich entlangzuhangeln lohnt. aber nie so, daß man es bereits verwerten könnte. und ich mische stats top-down mit bottom-up. vorher malen wäre echte zeitverschwendung. aber ich würde eh kündigen, wenn mein chef solchen blödsinn von mir verlangte.

    Aber nur wenige können sich auch noch die gesamte Applikation im Zusammenspiel vorstellen.

    die klasse lebt aus sich heraus, nicht aus dem kontext. wie drüben der FileExplorer http://forum.c-plusplus.net/viewtopic.php?t=73335&highlight= , der lebt einfach so, es ist brauchbar. egal, wer ihn warum benutzt.
    es ist unfug, sich die ganze applikation im zusammenspiel vorzustellen. es war in der rein prozeduralen zeit auch schon unfug, diese aufruf-diagramme zu malen, wo man entnehmen kann, welche funktionen welche funktionen aufrufen. hat die funktion *einen* zweck und einen guten namen, lebt sie allein gut.

    0
  • S

    Ich pers. hasse Struktogramme wir müssen sie immer in der Schule machen, die Aufgaben
    dort sind leider nur so billig, dass es in meinen Augen Zeitverschwendung ist,
    denn in Java prozedural zu coden, ist ja jetzt nicht _so_ schwer, dass ich mir
    über das Design Sorgen machen muss.
    Komischerweise tun sich alle anderen in der Klassen mit Struktogrammen schwerer,
    als direkt das ganze einzutippen, unser Lehrer meint zwar, dass man sich nen
    Struktogramm machen soll, wenn man nicht weiß wie man etwas angeht, aber hier
    ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso
    hilfreich.

    Edit:

    Volkard, wie machst du das bei komplexeren Vererbungsbeziehungen, hast du das dann
    irgendwie im Kopf, oder machst du dir vorher auf nem Blatt ne grobe Skizze, bzw.
    schreibst auf wie die zusammenhängen? Denn immerhin sind die Kinder, ja abhängig
    von den Parents und die Basisklasse, muss ja so designed werden, dass die Kinder
    sie optimal einsetzen können.

    0
  • S

    SirLant schrieb:

    Ich pers. hasse Struktogramme wir müssen sie immer in der Schule machen, die Aufgaben
    dort sind leider nur so billig, dass es in meinen Augen Zeitverschwendung ist,
    denn in Java prozedural zu coden, ist ja jetzt nicht _so_ schwer, dass ich mir
    über das Design Sorgen machen muss.

    Struktogramme sind überflüssig. Ganz einfach, weil man die meisten Fehler eh erst beim Ausführen des Programmes (im Einzelschritt-Modus eines Debuggers) erkennt und nicht beim Aufhängen des Struktogramms an der Wand. Und lesbarer als ein gut formatierter (!) und kommentierter (!) Java-Quelltext sind sie sicher auch nicht. Struktogramme stellen ja gegenüber Hochsprachen keine Vereinfachung dar, da die Hochsprachen im Prinzip die gleichen Kontrollstrukturen haben wie Struktogramme, mit dem Vorteil, gleich richtigen Code zu haben.

    SirLant schrieb:

    Komischerweise tun sich alle anderen in der Klassen mit Struktogrammen schwerer,
    als direkt das ganze einzutippen, unser Lehrer meint zwar, dass man sich nen
    Struktogramm machen soll, wenn man nicht weiß wie man etwas angeht, aber hier
    ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso
    hilfreich.

    Klar, man kann so etwas tun, was für das Problem angemessen erscheint. Baumstrukturen entwirft man z.B. besser, wenn man den Baum kurz skizziert und nicht, wenn man gleich versucht, den Algorithmus als Struktogramm zu malen. In dem Moment, wo man ein Struktogramm malen kann, kann man doch gleich den Code in den Rechner eintippen.

    0
  • V

    SirLant schrieb:

    Komischerweise tun sich alle anderen in der Klassen mit Struktogrammen schwerer, als direkt das ganze einzutippen,

    und man fragt sich, warum sie nicht dürfen.

    unser Lehrer meint zwar, dass man sich nen Struktogramm machen soll, wenn man nicht weiß wie man etwas angeht,

    wenn man zu ahnunslos ist, muß man es ausprobieren. und das geht nirgends so gut, wie am rechner.
    wenn man in sachen klassendesign zu ahnungslos ist, muß man auch erstmal ein gefühl für das genre kriegen. durch ausprobieren am rechner.

    aber hier ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso hilfreich.

    auch du bist schon verloren. es ist eben schlecht, vorher "DEN PLAN" hinzuschreiben und dann den zu coden. "DER PLAN" muss beim coden entstehen.

    Volkard, wie machst du das bei komplexeren Vererbungsbeziehungen,

    es gibt keine komplexen vererbungsbeziehungen. klar muß man dazu private erblichkeit meiden und noch zwei oder drei regeln einhalten, die aber klar in "effektiv c++ programmieren" stehen.

    hast du das dann irgendwie im Kopf, oder machst du dir vorher auf nem Blatt ne grobe Skizze, bzw. schreibst auf wie die zusammenhängen?

    normalerweise keine skizze. manchmal ein baum, in dem aber nur klassennamen vorkommen und sonst nix. und nicht als planung, sondern als test, ob sich ne idee gut anfühlt. nach angucken des baumes kann das blatt verbrannt werden.

    Denn immerhin sind die Kinder, ja abhängig von den Parents und die Basisklasse, muss ja so designed werden, dass die Kinder sie optimal einsetzen können.

    NEIN! die Basisklasse muss nicht und darf nicht so designed werden, daß die kinder sie optimal einsetzen können. der mensch denkt in begriffen. deswegen soll er auch in begriffen programmieren. das ist ne frage der wartungsfreundlichkeit. die basisklasse muss ein kapierbarer begriff sein. sie muss *einen* zweck erfüllen und einen sie exakt beschreibenden namen haben. außerdem soll sie performant sein. wen sie einen zweck hat und einen guten namen, lebt sie eigenständig und es ist irrelevant, wer sie verwendet.
    trotzdem passieren regelmäßig sachen, wie daß man gleichbedeutende members in childs findet. schwups, hoch damit in die basisklasse. uml-heinis würden sagen, das sei auf den bildern frher zu sehen gewesen. aber nein, noch häufiger als das, passiert es ja, daß man nachträglich members einfügt.
    ich lasse sogar attribute (manchmal) und methoden (immer) weg, solange keine andere klasse sie braucht und baue erst bei bedarf nach.
    es ist meinen klassen aber fast immer egal, wer von ihnen mal erben möchte, und was der tun will. außer mal, sie heißt "...Base", veröffentlich eine pur virtuelle methode und hat ein attribut.

    also nix plan vorher. es wächst schon in die richtige richtung. normalerweise ist der plan im kopf gleich da und ich könnte alle klassen und attribute und vererbungsbeziehunen sofort hinschreiben. öffentliche methoden dauern etwas länger. und wenn nicht, dann hilft auch kein überlegen. dann hilft nur ausprobieren, welche der alternativen sich "hübscher" anfühlt. dabei denkt man aber über fallen nach, die sich erst in 6 monaten auftun würden. sehr spekulatives eschäft. gegebenenfalls muss ich mehrere entwürfe ein paar tage lang vorantreiben und dann den enstandenen code bewerten.
    es bleibt mir gar keine andere wahl, wenn ich nur den besten code haben mag. manches läßt sich trocken einfach nicht abschätzen.

    edit: schaut mal, welch schweren stand ich habe, wenn ich euch hier erzählen will, daß der explorative programmierstil wirklich wirkungsvoll ist, aber auf der anderen seite das böse solches "c++" lehrt: http://forum.c-plusplus.net/viewtopic.php?t=73371&highlight=

    0
  • S

    volkard schrieb:

    aber hier ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso hilfreich.

    auch du bist schon verloren. es ist eben schlecht, vorher "DEN PLAN" hinzuschreiben und dann den zu coden. "DER PLAN" muss beim coden entstehen.

    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.

    0
  • H

    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 🙂

    0
  • V

    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.

    0
  • ?

    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. 🙄

    0
  • V

    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.

    0
  • ?

    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.

    0
  • C

    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.

    0
  • M
    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.

    0
  • C

    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.

    0
  • M
    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.

    0
  • V

    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++?

    0
  • V

    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.

    0
Anmelden zum Antworten