Ein Kreis... oder doch lieber ein Schälchen?

Aus irgendeinem Grund habe ich immer wieder das Problem nicht ganz sicher zu wissen, ob jetzt ein required interface nun eigentlich der Teil der Schnittstelle ist, der die Schnittstelle benötigt oder doch eigentlich anbietet.
Selbes Problem gilt natürlich vice versa für die provided interfaces.
Natürlich, die Benennung scheint klare Bände zu sprechen, aber ist dem wirklich so?!

Zwar dachte ich (so wie vermutlich alle anderen) das Prinzip verstanden zu haben, doch trotzdem tauchen immer wieder gewisse Zweifel auf.
Deswegen werde ich in diesem Blogeintrag versuchen, dieser Frage auf die Spur zu kommen um dem Mysterium endlich ein Ende zu setzen.

Zweifel 1

Hier einmal das Modell, welches maßgeblich an dem ganzen Problem beteiligt ist:


Und jetzt meine Frage: macht das Sinn, dass der ShockwavePlayer eine Komponente anbietet, auf die sich der Browser einlassen muss?!
Oder verfeinern wir die Frage: wenn es wirklich so wäre, dass der Player eine Komponente anbietet, auf die sich die Browser einstellen müssen, wieso gibt es dann verschiedene Player-Implementationen für verschiedene Browser?

Fortsetzung folgt...

Vorlesung vorbei, Skriptum komplett (ausgedruckt) !!

Die Vorlesung ist vorbei und das Skriptum steht nun zum vollständigen Download bereit. Aber es gibt noch immer Leute (so wie mich), die nicht gerne vom Bildschirm lernen, sondern es lieber auf Papier haben.

Habe also das Skriptum komplett ausgedruckt, 2 Folien pro Seite, vorne und hinten bedruckt (gut leserlich und platzsparend).

Wer will, kann sich das komplette Ding (oder auch nur Teile daraus) kopieren. Einfach eine Mail an mich schreiben oder auf diesen Post antworten.

Bis dann,
lg
Fred

P4: Dawning

Vorweg eine persönliche Bemerkung:

STRESS

Wo man hinsieht, überall gibt es Stress! Morgen Vormittag eine Prüfung, am Abend diese Abgabe und die Abgabe eines Zwischenberichts für die LV "Netzwerktechnologien".
Morgen während des Tages dann die Fahrt nach Hause, da ich in Oberösterreich als Fahrschullehrer tätig bin und am Samstag unschuldige Fahrschüler gequält werden wollen.
Samstag Abend Ankunft meiner in Salzburg studierenden Freundin amerikanischer Herkunft, welche die Tradition des feierlichen Thanksgiving über den Ozean zu retten versucht und mich dafür Sonntag um 6.00 Uhr morgens als Truthahn-Koch benötigt, da sie, trotz ihrer Vorliebe fürs Kochen, eine geradezu ungesunde Abneigung gegen die Arbeit mit rohem Fleisch hat.
Sonntag Abend dann, in einem voraussichtlich überfüllten Zug, die Rückreise nach Wien, um am Montag wieder den Pflichten eines Tutors nachzukommen. Am Dienstag dann die Abgabe von A4, sowie die Aufgabe aus der LV "Datenbanksysteme", sowohl von dieser Woche als auch für die versäumte Aufgabe der vergangenen (also dieser) Woche (versäumt aufgrund der morgigen Prüfung), am Mittwoch dann der nächste Meilenstein in derselben LV und am Freitag ein 20- bis 30-seitiger (!, aber Hallo ?!) Bericht für "Netzwerktechnologien" zum Thema VoIP, mit dem ich bisher wirklich noch nie auf technischer Ebene in Berührung gekommen bin.

Das kann ja spaßig werden, zumal ich am Donnerstag zuvor als Nikolaus bei einem Krampus-Club aktiv bin, wo meine beiden Krampus-Helfer dieses Jahr zum ersten Mal gegen ledertragende Dominas ausgetauscht werden =;-)

Sicher eine schlechte Kombination mit dem 30-Seiten-Bericht am Freitag =-(

So, genug gejammert!

P4: Review

Wir haben die große Freude, Team 3 reviewen zu dürfen, welches im Unterricht schon (zu Recht) in vorzüglichem Maße für ihre Abgabe gelobt wurde. Auch wenn ich bislang (aufgrund der morgigen Prüfung) noch nicht die Zeit gefunden habe, mir die Abgabe genauer anzusehen, so gehe ich im Moment doch davon aus, dass ich mich übermäßig positiv dazu äußern werde (keine Sorge, ich werde schon ein paar konstruktive Kritikpunkte einbringen).

Aus Zeitgründen haben ich und meine Kollegin Theresa uns entschieden, diese Aufgabe strikt zweigeteilt zu erledigen. Sie schreibt in einem Google-Doc unabhängig von mir ihre Meinung zur Abgabe. Ich werde mir diese dann runterladen und zusammen mit meiner eigenen Meinung (im Zug auf dem nachhause Weg nach OÖ) in LaTeX verfassen.

Weitere Infos dann morgen...

A3: Bericht

Da die Abgabefrist nun vorbei ist: mein Abschlussbericht zur A3: XML/DTD steht zum Download über den Almighty bereit.

Für die Interessierten: hier das entsprechende TeX-File als ZIP-Download. Eine etwas ausführlichere Erläuterung zur Abgabe folgt in Kürze.

Erweiterung

Habe in der Übung gesehen, dass ich beim Erstellen des Abgabedokuments wohl ein wenig über das Ziel hinausgeschossen bin. So haben die Kollegen ein PDF-File ihres UML-Klassendiagramms abgegeben und evtl. noch eine "natürlichsprachliche" Beschreibung dazugehängt.

In meinen Dokument wurde diese Beschreibung ausgespart. Dafür findet man darin eine Analyse des Diagramms sowie eine zeilenweise Erläuterung der DTD. Für das XML-File war ebenfalls eine solche ausgiebige Beschreibung geplant, ließ sich jedoch mit dem Abgabedatum nicht mehr vereinbaren.

Nichst desto trotz hat diese Fleißaufgabe nicht geschadet, da es für mich das erste Mal, Listings in LaTeX zu erstellen bzw. einzubinden. Wie ich feststellen musste, eine sehr interesssante Erfahrung, die ohne größere Komplikationen verlaufen ist und mit einem optisch anspruchsvollen Ergebnis auffährt.

A3: UML-Diagramm

Nachdem so viele meiner Kollegen es schon so prima vorgemacht haben (David Selig, Martin Graf, Florian Schwarz) - hier nun mein Klassendiagramm.



Das Diagramm wurde mit OmniGraffle erstellt (Vielen Dank an Werner Robitza für diesen Tipp!)

Dieses Diagramm weist eine 1:1 Beziehung zwischen den beiden Klassen Benutzer und Profile auf. Gemäß der Spezifikation kann eine Kardinalität der Größe 1 ausgelassen werden bzw. wird eine nicht gekennzeichnete Kante implizit mit 1 belegt.

Die Unterscheidung der Inhalte von Benutzer und Profile: Benutzer enthält lediglich Daten, die für das System von Interesse sind. Profile enthält hingegen Daten, die für andere Personen von Interesse sind. Die 1:1 Beziehung drückt aus, dass ein Benutzer genau ein Profil hat und ein Profil genau zu einem Benutzer gehört.
Nicht modelliert wurde in diesem Zusammenhang, dass Benutzer die Profile anderer Teilnehmer betrachten können.

Benutzer lässt sich weiter unterteilen in Content_Ersteller und Content_Manager. Diese beiden Entitäten wurden mit keinen weiteren Attributen ausgezeichnet, da der einzige wesentliche Unterschied in der Erlaubnis des Content_Managers liegt, bereits erstellte Inhalte zu editieren.

Ein Problem, welches sich hieraus ergibt: dieser Umstand lässt sich nicht als DTD abbilden. Wie bereits in einem Forumseintrag diskutiert ist es in einer DTD leider nicht möglich, IDREF(S) nur auf bestimmte IDs hin abzufragen. Die Abfrage erfolgt automatisch dokumentweit. Folglich muss dieser Teil der Modellierung in einem anderen Arbeitsschritt implementiert werden.

Protocol wird hier nur als der Grundeintrag betrachtet, ausreichend für die gegenwärtige Aufgabenstellung. Für die Weitermodellierung empfiehlt es sich, Protocol als eigenes Paket darzustellen und die Inhalte in einem eigenen Diagramm zu beschreiben.

Vermutlich fällt auch noch die dargestellte 1 an der Kante zwischen Benutzer und Protocol auf. Wie zuvor gesagt, eine leere Kante impliziert 1, was zum anderen jedoch nicht, dass die 1 nicht explizit aufgeführt sein darf. Der Grund, wieso ich hier die 1 modelliert habe: das verwendete Programm bot eine vorgefertigte 1:n Kante an und diese wurde einfach übernommen ;-)

Notizen an mich selbst
Bei einer Überarbeitung des Modells darauf achten, Sprachkonsistenz beizubehalten (bezieht sich hier auf die Ausdrücke Benutzer und Content_Erzeuger)

Notizen

Habe vor zwei Tagen erfahren, dass ich Freitag, den 28.11, eine Prüfung über Medienhistorie habe, und der Umfang in diesem Fach doch ziemlich beträchtlich. Zusätzlich ist bis Sonntag die nächste SWA-Einzelaufgabe abzugeben und das obwohl ich noch nicht einmal die letzte Einzelaufgabe bislang vollendet habe. Hinzu kommen auch noch die anderen Fächer, in denen auch wieder in den kommenden Tagen und einige Abgaben zu erledigen sind.

Das heißt, die kommende Woche wird wieder einmal viel Kaffee und wenig Schlaf bedeuten.

Dankeschön
Danke an Werner für die Zur-Verfügung-Stellung seiner TeX-Datei. Hatte bei meinen Dateien Probleme mit dem Einbinden von Grafiken. Werner hat hierbei andere Parameter benutzt, die ich nicht kannte. Während sich in Werners Fall die Grafiken relativ zum Textfluss anpassen, haben meine Parameter eine absolute Positionierung verursacht - ein Effekt, der mehr als unwillkommen war. So ist es einfach ständig passiert, dass meine Grafiken meinen Text überlagert und somit unlesbar gemacht haben.

Bei diesem Weg auch gleich noch ein Dankeschön an Flo (Schwarz), dass er seinen produzierten Content so einfach und selbstverständlich zur Verfügung stellt. Ich bin noch immer ein Mensch, der am besten von anderen, guten (und hoffentlich zahlreichen) Beispielen lernt, und ich bin mir sicher, dass ich da nicht der Einzige bin. Im Übrigen ein sehr bemerkenswerter Blog!

Ausserdem vielen Dank an Kollege Selig für das präsentieren seines Klassendiagramms für die nächste Aufgabe und an die Antwort von Michael Derntl. Ich war schon wieder drauf und dran, einen wesentlich komplizierteren Ausschnitt aus unserem Projekt zu modellieren, was aber vermutlich wieder in unsagbaren Stress und einer Auf-Den-Letzten-Drücker-Aktion geendet hätte.

Buchrezensionen
Wie man vielleicht schon festgestellt hat bin ich ein ziemlicher Buchliebhaber. Im Übrigen besitze ich die Bücher, die ich bisher in meinen Buchrezensionen erwähnt habe. Wenn sich also jemand Kapitel daraus kopieren möchte, so stelle ich diese (kurzzeitig) gerne zu Verfügung.

Ich plane nun schon seit einiger Zeit, die Sidebar in meinem Blog durch eine Bücherliste aufzupeppen - doch leider mangelt es wieder man an Zeit und dem nötigen Tatendrang.

P3: Reminiszenz

Die heutige Einheit war sehr aufschlussreich. Schade, dass die Erkenntnis immer erst dann zu Tage tritt, wenn es schon zu spät ist. Ja, keine Frage

Nicht für die Schule, sondern für das Leben lernen wir!

aber dennoch wäre es schöner, wenn man schon im Vorfeld alles richtig gemacht hätte.

Was mir immer mehr einleuchtet bei diesem Komponentendiagramm ist die Tatsache, dass sich die Komponenten im Grunde nicht von Klassen unterscheiden. Auch wenn ich diesen Satz in unzähligen Varianten bereits in den Unterlagen, in Büchern und sonstigen Webressourcen bereits gefunden hatte, so hatte er doch noch nicht mein Verständnis erreicht. Als ich mich nun aber in meinen Gedanken daran machte, das Klassendiagramm für die nächste Einzelaufgabe zu erstellen, ist der Groschen nun endlich gefallen!

Wir haben versucht, unsere Methoden als Komponenten zu modellieren!

Wie ich es in einem früheren Blog schon einmal anzudeuten versuchte, fehlte mir bei den Aufgabenstellungen der eine oder andere Zwischenschritt. Für mich persönlich ergab sich das Problem, von dem dynamischen Use-Case (P2) auf das statische Komponentendiagramm rückzuschließen. Für mich wäre es zuvor bereits notwendig, ausgehend von der Problemstellung durch diverse Analysemuster ein einfaches Klassendiagramm zu erstellen. Ausgehend von Problemstellung und Klassendiagramm sollte das Use-Case-Scenario gestaltet werden, aus welchem dann ein verfeinertes Klassendiagramm und eben das Komponentendiagramm hervorgehen sollten. Schließlich bleibt einem das Modellieren der Klassen, sofern man diese Aufgabe tatsächlich ernst nimmt, ohnehin nicht erspart.

Unsere veröffentlichten Diagramme haben wenig Reaktion hervorgerufen, was zumindest auch bedeutet, dass sie sich nicht negativ ausgewirkt haben! Aus meiner mehrjährigen Erfahrung als Mitarbeiter am Institut für TFM weiß ich, dass so ein Versuch auch ganz gewaltig in die Hose gehen kann (einer macht etwas falsch vor, und alle anderen ziehen falsch hinterher!). Zumindest lebe ich in der Vorstellung, dass die eine oder andere Gruppe doch von unseren Überlegungen profitiert haben könnte. Sofern möglich werden wir versuchen die Methode der Vor-Veröffentlichung beizubehalten.

Daraus erwächst nun aber auch die Verantwortlichkeit, die publizierten Daten zu überarbeiten, um sie entweder zu berichtigen oder zumindest als falsch zu kennzeichnen. Sprich: die Geschichte um unser Komponentenmodell geht weiter!

P3: Statements

Vielen Dank an den Kollegen Graf für die positive Kritik in seinem Blog an unseren Modellen.
Wie er bereits richtig erkannt hat haben wir uns bei der Erstellung oftmals zu sehr von Aktivitäten leiten lassen, anstatt diese in eine generische Umgebung zu abstrahieren. Ein sehr praktischer Tipp, wie das herausfinden von Komponenten leichter von der Hand geht, hat Michael Derntl in einem Comment zu einem meiner früheren Posts aufgezeigt.

Zum Komponentendiagramm, welches Kollege Graf in seinem Blog veröffentlicht hat: SEHR GUT!

Wir waren bemüht, eben ein solches Diagramm zu entwerfen, wenn auch vielleicht doch ein wenig spezifischer. Doch in einigen Punkten wussten wir eben schon zu genau, was wir wollten bzw. was wir brauchten. Anstatt dass dieses Wissen uns aber geholfen hätte, hat es uns vielmehr die Daumenschrauben angelegt.

P3: Architektur V2.1

Wie in meinem Post P3: Architektur bereits erwähnt folgt hier nun die neue Version unseres Komponentendiagramms. Dabei konnten die Empfehlungen, die Michael Derntl in seinem Comment zu meinem Post erwähnt hat, noch nicht vollständig berücksichtigt werden. Daran arbeiten wir im Augenblick noch.



Danke an dieser Stelle wieder an Theresa! Auch wenn wir die Struktur gemeinsam erarbeitet haben, so war sie es, die das Diagramm mit BOUML erstellt und in GoogleDocs eingefügt hat.

Beginning XML

Auch wenn wir in der Vorlesung in Sachen XML doch schon ein wenig vorangeschritten sind, so kann ich doch dieses Buch nur wärmstens empfehlen.
Es deckt sämtliche Themenbereiche ab, die bisher in der VO erklärt wurden und liefert dazu noch viele praktische und hilfreiche Beispiele.

Aus dem Inhalt
Neben der grundsätzlichen Klärung, was XML überhaupt ist, wie es aussieht und was wohlgeformtes XML bedeutet behandelt es auch sehr ausführlich die Validierungsmöglichkeiten via DTD, XML Schema und RelaxNG.
Es bietet eine Einführung in XSLT und XPath, XML als Datenbank und so weiter.
Auch Progrommierung mit SAX und DOM werden darin angeschnitten, und ebenso spielen auch Communication (RSS, Atom, SOAP, WSDL und AJAX) sowie Display (CSS, SVG, XForms) eine Rolle.

Ganz ehrlich: selten konnte ich ein Buch so sehr weiterempfehlen wie dieses.

LINKS:

WROX.com (Verlag) - http://www.wrox.com/WileyCDA/WroxTitle/Beginning-XML-4th-Edition.productCd-0470114878.html

Google-Buch - http://books.google.at/books?id=E__5CaOqSuAC&printsec=frontcover&dq=beginning+xml#PPP1,M1

Amazon.de - http://www.amazon.de/Beginning-XML-Programmer-to/dp/0470114878/ref=sr_1_1?ie=UTF8&s=books-intl-de&qid=1227031292&sr=8-1

Thalia.at - http://www.thalia.at/shop/at_tha_buch_startseite/suchartikel/beginning_xml/david_hunter/ISBN0-470-11487-8/ID14245371.html?jumpId=158582

P3: Architektur

Haben heute Nachmittag in einer Marathonsitzung versucht, dieses Komponentenmodell auf die Reihe zu bringen. Leider stellte es sich heraus, dass wir trotz all der geforderten Aufgaben, die bisher abzugeben waren, noch nicht einmal selbst alle Komponenten/Aspekte unseres Projektes kennen.

Ständig kehrten wir zum Anfang zurück um alles vom Beginn an neu aufzurollen. Startend bei der Anmeldemaske haben wir überlegt, was der angemeldete User von dort aus machen kann. Dabei ertappten wir uns ständig, dass wir aus dem statischen Komponentendiagramm ausbrechen und in das dynamische Aktivitätsdiagramm eindringen wollten.

So hatte zumindest ich während der Erstellung des (bisherigen) Diagramms das Gefühl, dass wir wesentliche Schritte der Objektmodellierung ausgelassen hätten. Zum anderen muss man aber auch dazu sagen, dass wir womöglich unter den Folgen eines schlecht modellierten Use-Case-Diagramms leiden, welches wir für diesen Arbeitsschritt nicht wirklich zu Hilfe nehmen konnten.
Folglich lautet hier die einzig richtige Lösung, dass wir zum Use-Case-Diagramm zurückkehren und dieses noch einmal überarbeiten sollten. Aber natürlich fehlt dazu wieder einmal die Zeit (schließlich ist ja morgen Abgabetermin).

Obwohl wir im Grunde rechtzeitig mit der Aufgabe angefangen hatten (Donnerstag vor einer Woche) erleben wir nun doch dieselben Probleme, als wenn wir auf den letzten Drücker angefangen hätten.

Unser bisheriges Workingdraft ist über Theresas Blog zu bewundern, doch dieses wurde bereits wieder wesentlich abgeändert. Über das neue Diagramm werde ich dann hoffentlich bald berichten können.

Lehrbuch der Objektmodellierung

Ich habe mir dieses Buch gekauft, da es den praktischen Ablauf der Erstellung eines Softwareprodukts beschreibt und mir die Inhalte auf einen flüchtigen Blick mit den Unterlagen der Vorlesung deckungsgleich schienen. Zudem befindet sich darin ein kurze und prägnante Beschreibung über das Komponentenmodell, welches der ausschlaggebende Grund für den Erwerb des Buches war. mir sehr praktisch erschien.

Leider ist es aus lizenzrechtlichen Gründen nicht möglich, die relevanten Seiten über das Komponentenmodell einzuscannen und den Teilnehmern dieser LV zur Verfügung zu stellen (selbst in geschlossenen Bereichen nicht gestattet).

Als mich mich dann daran machte, daraus eine Zusammenfassung zu erstellen, welche ich dann meinen Kollegen zur Verfügung stellen hätte können ist mir etwas aufgefallen: es wäre beinahe dasselbe gewesen wie die Vorlesungsunterlagen! Einige (sehr kurze) praktische Beispiele hätten ergänzt werden können, aber wirkliche Neuerungen wären dabei nicht zu Tage getreten.

Jedoch muss ich dazu sagen, dass sich das Buch dennoch auszahlt! Wie die (Beinahe-)Zusammenfassung bewiesen hat, sind die grundlegenden Konzepte des Komponentenmodells im Buch und in den VO-Unterlagen gleich. Dennoch bekommt man durch das Buch eine völlig neue Perspektive präsentiert, die durch eine Zusammenfassung im wesentlichen erst wieder verloren ginge.

Somit kann ich dieses Buch nur wärmstens an alle LV-Besucher weiter empfehlen. Es wird mit Sicherheit auch noch in den kommenden Übungsaufgaben (und auch für das Projekt selbst) von Nutzen sein und das Preis-Leistung-Verhältnis (mehr als 500 Seiten, verständlich geschrieben und das für knapp €20) spottet jeder Beschreibung.

F-PrOT - Layers

Ausgehend von den allgemeinen Anforderungen an das System und von den Use-Cases (welche in unserem Fall noch einmal einer Überarbeitung bedürfen) haben wir versucht, die Architektur auf das Layersystem umzulegen.

Herzlichen Dank hierbei an Theresa, die sich bei dieser Aufgabe besondere Mühe gemacht hat.

Don't forget: Requests are welcome!


1. Layer: HTML-GUI

• Anzeige eines Protokolls

• Protokoll auswählen

• Protokoll eingeben
  

• Unterteilt nach Einstellungen/Transitionen (von Schnitt zu Schnitt)
  
• einzelne Einstellungen werden weiter unterteilt in Zeilen

• Userprofil ansehen
  

• eigenes Profil bearbeiten

• Anmelden

• Registrieren

• Forum (Protokollabhängig)

• verschiedene Versionen ansehen

• verschiedene Versionen erstellen

• E-Mail Funktion

• intern Nachrichten versenden

Dafür benötigte HTML Seiten:

• Formular für Registrierung

• Anmeldemaske

• Usermenu zum Navigieren zu „Userprofil bearbeiten“, „eigenes Userprofil ansehen“, „Postfach“, „Freunde“

• Userprofil bearbeiten

• Userprofil: Daten, erstellte Protokolle, Möglichkeiten zur Kontaktaufnahme (E-Mail, interne Nachrichten verschicken)

• Postfach: Ansehen der empfangenen und gesendeten Nachrichten, weiterleiten und verfassen von Nachrichten

• Suchmaske für Protokolle

• Ansicht eines Protokolls: Möglichkeit zur Druckansicht, Ansicht älterer Versionen, Link zu www.imdb.com, Kommentare

• Bearbeiten eines Protokolls → Erstellen einer neuen Version: Identisch mit Erstellen eines neuen Protokolls nur mit der Option die Inhalte der alten Version hinein zukopieren

• Bearbeiten eines Protokolls → Geringfügige Änderungen: Bearbeitung mit Ajax Zeilenweise (oder Abschnittsweise) möglich

• Erstellen eines Protokolls: HTML Tabellen und Ajax zum Strukturieren und Autovervollständigung

2. Layer: ruft die Datenoperationen auf (Schnittstelle)

• Ausgeben des gefundenen Protokolls (verwendet: search, wird benötigt für: Ansicht und Bearbeiten eines Protokolls

• Speicherung neuer Protokoll-Versionen (verwendet: add, benötigt für: Eingabemaske)

• Bearbeiten eines Protokolls (verwendet: search, edit; benötigt für: Bearbeiten)

• Ajax Autovervollständigung (benötigt für: Bearbeiten)

• Versenden von Nachrichten (verwendet: add, edit, search; benötigt für: Postfach)

• Erstellen von links zu anderen Versionen

• Userprofil bearbeiten (edit, search)

• Userprofil ansehen (search)

• Registrierung (add, search)

• Anmelden (search, benötigt für: Anmeldemaske)

3. Layer:

• Datenbanken: Userverwaltung + Kommunikation, Protokolle

• Funktionen:

  • add

  • search

  • delete

  • edit

  
  
  • move
    

Again about Use-Case

Nachdem ich in der LV die Use-Case Diagramme der Kollegen gesehen hatte habe ich erst verstanden, wie dieses logisch auf mehrere Diagramme aufgeteilt werden konnte. Die Präsentation wird auf diese Art viel flexibler.

Ich habe heute mit Florian Schwarz und Werner Robitza darüber gesprochen, ob es nicht sinnvoll wäre, unsere Use-Case-Diagramme in diesen Blogs zu veröffentlichen. Da die Abgabetermine nun ja vorbei sind würde dadurch ja niemandem mehr "Arbeit abgenommen", sondern interessierte Leser könnten auf diese Art ihr Wissen vertiefen.

PHP Hacks & PHP/MySQL-Lernkurs

Um mich ausreichend auf die nächste Aufgabe vorzubereiten habe ich mir heute das Buch "PHP Hacks" von Jack D. Herrington in der deutschen Übersetzung von Jorgen W. Lang gekauft.
Auf einen ersten Blick sieht es sehr vielversprechend aus. Auf der Amazon-Website habe ich jedoch gerade gesehen, dass die englische Originalausgabe schlecht bewertet wurde (wenn auch nur von einem User).
Wir werden ja sehen, als wie praktisch sich das Buch herausstellen wird.

Ausserdem habe ich einen PHP-Lernkurs von Boris Gedat wieder aus den Regalen hervorgeholt. Dabei handelt es sich um einen sehr vielversprechenden Kurs auf DVD im Gesamtumfang von ca. 22 (!) Stunden. Der einzige Nachteil ist, dass diese Schulungs-DVD nur unter Windows lauffähig ist.

Notizen zur 2. Gruppenaufgabe

Die Erstellung des Zieldiagramms hat sich als Herausforderung dargestellt. Über die Qualität sind wir uns im Augenblick noch nicht bewusst.
Aufgrund von diversen Änderungen, die während des Erstellens des Use-Case-Diagramms aufgetreten sind musste das Zieldiagramm im Anschluss noch einmal leicht abgeändert werden.
Aber es lässt sich jetzt bereits sagen, dass im Zieldiagramm noch einige (wichtige) Aspekte des Tools noch nicht integriert sind. Dafür sind unwichtige Features viel zu hoch gereiht.

Zusatzeintrag

Haben in der Übung festgestellt, dass die präsentierenden Gruppen ihre Use-Case-Diagramme alle aufgesplittet haben. Während wir versucht haben, die ganze Anwendung in ein Use-Case-Diagramm aufzuteilen, haben sie verschiedene Diagramme für verschiedene Anwendungen modelliert.

Die Kollegen haben diese Aufgabe sicher besser gelöst als wir. Ehrlich gesagt war mir während des Erstellens nicht klar, in welcher Weise diese Use-Case-Ding hilfreich sein soll. Nun scheint die Antwort schon etwas klarer zu werden.

Eventuell werde ich mir noch einmal ein Buch zu den Themen UML-Modellierung und Softwarearchitekturen besorgen. In diesen beiden Fällen lässt meine Bibliothek derzeit noch zu wünschen übrig.