Posts tagged: UML

Gefangen, nicht gefunden! #22

Informatik

  • Wie man einen Graph plottet
  • Nächstes Frühjahr werd ich mit dem Studium fertig und stürz mich ins Berufsleben. Ich hoff dann mal, dass ich dann nicht sowas erleben muss: Joy of Programming: SNAFU — Situation Normal, All Fouled Up!. Bei Firmenkontaktmessen, Exkursionen und Co. ist es ja ganz sinnvoll, die Leute dort auszufragen, um nen Eindruck zu kriegen. Vielleicht sollte ich meinen Fragenkatalog erweitern, um solche Fälle zu erkennen. Hm…
  • Letztens hat jemand behauptet, dass Joel Spolsky ja so konservativ wäre. Mal davon abgesehen, dass ich Leute kenne, die noch viel konservativer sind, wusste ich erstmal nicht so ganz, woran man das festmachen sollte. Und ich hab mich gefragt, ob ich auch so “konservativ” bin. Zumal ich seine Ansichten über Management gar nicht so konservativ finde. Letztens hab ich aber seinen Artikel How Microsoft Lost the API War gelesen. Und da seh ich manches denn doch etwas anders. Nicht in der Kernthese des Artikels: Dass es MS mittlerweile schwerer hat, weil SaaS und die Cloud immer wichtiger werden und iOS und Android auch Windows bedrohen, zeigt eigentlich, dass Spolsky schon vor 8 Jahren nicht ganz unrecht hatte mit der Entwicklung. Über weite Strecken erzählt er aber — durchaus lesenswert — von zwei Lagern bei MS. Die einen, die Rückwärtskompatibilität über alles stellen und die anderen, die gerne mal was Neues machen. Und er beklagt, dass letztere “gewonnen” haben. Seine Argumente sind nicht ganz falsch. Aber er unterschlägt, dass es auch immer wieder neue Produkte gibt und manchmal nur ein Bruch in der API wirklich Fortschritte bringt. Es ist kein Schwarz oder Weiß. Es ist immer eine Abwägungssache.
  • Wenn wir schon dabei sind: Noch ein interessanter Text von Joel Spolsky: Getting Things Done When You’re Only a Grunt
  • Wie schon erzählt, mache ich mir momentan so ein bisschen Gedanken darüber, wo ich nach meinem Studium hin will. Dass ich in die Softwareentwicklung will, steht fest. Dabei stellt sich für mich aber u.a. auch die Frage, ob ich lieber Standardsoftware oder Individualsoftware entwickeln will. Beides hat wohl seine Vor- und Nachteile. Außerdem frage ich mich, ob ich lieber plangetrieben oder lieber agil Software entwickeln will. Auch das hat seine Vor- und Nachteile und ich kann mir beides vorstellen. Bei den ganzen Überlegungen merke ich aber mal wieder: Der eigentliche Unterschied liegt in der Denkweise. Man kann auch einen klassischen Ansatz mit Scrum verbinden. Ob das Ergebnis dann “agil” ist, ist ne andere Frage, aber das heißt nicht, dass das Ergebnis schlecht wäre. Die Idee finde ich jedenfalls ganz interessant.
  • Über Technical Debt bzw. techische Schulden hab ich ja schon des öfteren erwähnt. Ich finde das ist eine sehr hilfreiche Metapher. Eine detailliertere Taxonomie beschreibt Steve McConnell. Lesenswert. Und noch ein Artikel zu dem Thema: Understanding technical debt
  • Wenn wir grad beim unsortierten Auflisten von Artikeln sind, die ich gelesen hab: Hier ist noch einer: Death by UML Fever. Ich mag die UML. Eigentlich. Man kann sie aber sehr unterschiedlich einsetzen. Der Artikel behandelt problematische Anwendungen der UML.
  • Irgendjemand hier, der wissen will, wie und warum man Entwickler wird? Und wie man ein besserer wird? Vermutlich wissen das die meisten von euch schon. Egal. Hier ist trotzdem ein interessantes Video, das das veranschaulicht: So You Want to Be a Developer Part 1 und Part 2
  • Wie ein paar Praktikanten innerhalb von 12 Wochen eine marktreife Software schreiben: Aardvark’d: 12 Weeks with Geeks

Anderes

  • Ich war noch nie ein großer Comic-Leser. Was ich aber ganz gerne lese, sind Web-Comics wie xkcd. Randall Munroe, der Autor von xkcd, hat aber noch ein paar andere Projekte, die mitunter auch ganz interessant sind. Das neueste ist “what-if“. Dort gibt er physikalische Antworten auf hypothetische Fragen. Beispielsweise, was passieren würde, wenn man einen Baseball auf 90% der Lichtgeschwindigkeit beschleunigen könnte. Das Ergebnis liest ich überraschend und unterhaltsam.
  • Momentan läuft ja The Amazing Spider-Man in den Kinos. Kurzreview hierzu: Ich war ganz gut unterhalten, aber viel mehr auch nicht. Die Story verschenkt einige Potenziale und ist ziemlich vorhersehbar linear. Schade. Außerdem dachte ich, dass 3D bei den Wolkenkratzer-Szenen beeindrucken sein müsste. Weit gefehlt: Durch die Bewegungsunschärfe verschwimmt der Hintergrund und der Effet verschwindet.

Gefangen, nicht gefunden! #17

Informatik

  • Nick Hodges altes Blog ist wieder da; http://www.nickhodges.com/post/My-Old-Blog-is-Back!.aspx. Schön. Da ist so mancher lesenswerter Eintrag dabei.
  • Letztens war Barbara Liskov (ja, das ist die mit dem Liskovschen Substitutionsprinzip) bei uns an der Uni und hat einen Vortrag zum Thema The Power of Abstraction gehalten. Letztlich war der Vortrag ein bisschen Historisches zur Entwicklung der Abstraktion. Angefangen von Dijkstras “Go To Statement Considered Harmful” über abstrakte Datentypen bis zur Objektorientierung. Inhaltlich für jemanden der im 9. Semester Informatik studiert kaum etwas Neues, aber dennoch sehr interessant. Nicht zuletzt wegen Liskov selbst, die eine wirklich herausragende Informatikerin ist. 2009 erhielt sie einen Turing-Award; das ist quasi der Nobelpreis für Informatiker. Das, was sie erforscht hat, ist mittlerweile dermaßen anerkanntes Allgemeingut, dass eine Reaktion auf ihren Turing-Award der folgende Kommentar war: “What does she get this price for? Everybody knows this.” Das zeigt sehr schön dass man vor 30, 40 Jahren noch *ganz* anders programmiert hat. Noch bedeutender wird die Geschichte, wenn man erfährt, dass Liskov — ich hoffe ich krieg das noch einigermaßen zusammen — als sie sich auf ne Doktorandenstelle bewarb, erstmal auf Ablehnung traf (So à la “Wie weiblich und will Doktor in Informatik machen? Vergiss es!”). *kopfschüttel*
    Der Vortrag scheint der hier zu sein: http://www.infoq.com/presentations/liskov-power-of-abstraction Ich hab mir das Video nicht ganz angesehen, aber es scheint so ziemlich genau das zu sein, was sie uns erzählt hat. Auch die Folien sind wohl die selben. Wer also mal ein Stündchen Zeit hat…
  • Ich hab mal wieder was Interessantes bei Martin Fowler gefunden: TolerantReader. Dort beschreibt er Postel’s Law (ui, wieder eine Daumenregel!) und dessen Anwendung auf Webservices. Aber auch, wenn man nix mit Webservices am Hut hat, ist der Artikel lesenswert.
  • Hab gerade per Zufall eine sehr interessante Seite gefunden: http://www.uml-diagrams.org/ Dort gibt es sehr detailliert Informationen zu UML, samt Erklärungen und Beispielen. Sehr zu empfehlen!
  • Ein interessantes Gedankenspiel von einer Studentengruppe, die ich betreue: Klassen nach den Teammitgliedern benennen, die sie entwickeln. Nicht, dass das von irgendeiner praktischen Relevanz wäre (war auch als Jux gedacht), jedoch zeigt das Gedankenspiel schön den Nachrichtenaspekt (und die Aufgabenverteilung) der OO: Hans.HolMirMalDieDatenAusDerDatenbank(), Fritz.BerechneDenMittelwert(). Taugt zwar nur als Gedankenspiel, ist aber trotzdem ganz lustig.
    Wobei mich das Ganze an etwas erinnert, was sogar tatsächlich Relevanz hat: Vor einiger Zeit hab ich mal folgenden Vorschlag gelesen (ich glaub es war in “The Pragmatic Programmer”; kanns grad auf die Schnelle nicht finden): Um Schnittstellen (Methoden) für Klassen zu finden, kann man die Kommunikation der Klassen im Entwicklerteam quasi nachspielen. Jeder begibt sich in die Rolle einer Klasse und dann werden verschiedene Szenarien durchgesprochen. Also sowas wie “Ich bin jetzt mal die Formularklasse. Und ich erzeuge jetzt eine Datenbankverbindung. Dazu geb ich dir host, username und password.” “Und jetzt nehm ich, die Datenbankverbindung, die übergebenen Daten und rufe damit den JDBC-Treiber auf, der mir die Verbindung aufbaut.” etc. Die Kommunikation wird dann dokumentiert und hinterher generiert man daraus eine Schnittstellenspezifikation.

Anderes

  • Ich frage mich, ob es einen offiziellen Unterschied zwischen “parametrisieren” und “parametrieren” gibt. Gefühlsmäßig ist parametrisieren das Ermöglichen der Parametereingabe (beispielsweise das Auslagern in eine Methode und damit die Spezifikation der formalen Parameter) und parametrieren das Belegen von Parametern mit Werten (also die Spezifikation aktueller Parameter). Aber ist das nur ein Gefühl oder ist das wirklich so? OK, Sprache definiert sich durch Verwendung. Aber dann stellt sich die Frage, wie weit diese Unterscheidung verbreitet ist oder ob ich das allein so sehe.

Patterns

Überblick


Motivation

Es soll vorkommen, dass man in der Softwareentwicklung Probleme lösen muss. Und es soll vorkommen, dass man ein Problem, dass man schonmal gelöst hatte, nochmal lösen muss. Und es soll vorkommen, dass sich manche Probleme ähneln. Typischerweise versucht man, wenn man ein Problem zum zweiten Mal lösen muss, schneller zu sein als beim ersten Mal. Das nennt sich “lernen”.

Aber es gibt noch eine weitere Möglichkeit, beim zweitem Mal Arbeit zu sparen: Wiederverwendung. Besteht die Lösung eines Problems in einem Stück Code, dann kann man diesen verallgemeinern (parametrisieren) und beim zweiten Mal einfach hernehmen und benutzen. Das Ergebnis ist dann eine Prozedur, eine Klasse oder allgemein: ein Modul.

Aber auch, wenn die Lösung nicht in einem Stück Code besteht, sondern in einer bestimmten Herangehensweise, einer bestimmten Strukturierung oder Idee, so kann man sie wiederverwenden. Das Gegenstück zum Modul, dem wiederverwendeten Code, ist das Pattern bzw. Muster, sozusagen die wiederverwendete Idee. weiter lesen »

Gefangen, nicht gefunden! #5

Informatik

  • Ich arbeite mich gerade etwas in git ein. Hier ein interessanter Vortrag: Git The Basics Tutorial Leider ist der Ton nicht so gut. Am Anfang katastrophal, wird dann besser aber nicht gut. Der Inhalt ist aber gut. Relativ viel Zeug, sodass man sich nicht sofort alles behalten kann, dennoch eine gute Einführung.
  • Wer ein Tool zum schnell mal n UML-Diagramm Hinschmieren sucht, kann sich mal yUML ansehen. Man kann damit auf einfache Weise einfache Klassen-, UseCase- und Aktivitätsdiagramme erstellen. Text dient als Input, die Diagramme werden automatisch gezeichnet. Nichts um ernsthaft zu modellieren, aber gut zum schnell mal was zusammen zu kritzeln…
  • Auf DelphiGL.com (übrigens ne gute Adresse, wenns um OpenGL geht) habe ich drei Tutorials zum Thema Softwareentwicklung gefunden. Sowas wollte ich auch mal schreiben. Streckenweise sind diese Tutorials ganz gut, das ein oder andere gefällt mir aber nicht so ganz. Manches Wichtige wird unterschlagen (Grundprinzipien der Modellierung z.B.), anderes ist etwas… äh… ungenau (man könnte auch sagen: falsch). Teilweise bin ich auch nur anderer Meinung. Insgesamt wird der Modellierungprozess etwas zu starr beschrieben, wie ich finde. Ist also nur bedingt zu empfehlen. Vielleicht schreibt ich ja auch mal was zu dem Thema. Es darf sich aber jeder selbst ein Bild davon machen…
  • Durch das Lesen der Tutorials ist mir nochmal aufgefallen, dass ich mir mal genauer Gedanken darüber machen sollte, was ich von Robustheitsdiagrammen halten soll. Im Studium haben wir die nie benutzt und auch so hab ich sowas noch nie verwendet. Abwechselnd finde ich die Dinger entweder klasse oder kontraproduktiv, weil in die falsche Richtung führend. Momentan tendiere ich zu letzterem, das kann sich aber schnell wieder ändern. Ich glaube ich muss das irgendwann einfach mal ausprobieren…

powered by WordPress | QuickLaTeX | WordPress Themes