Saturday, November 29, 2008

Reviews

Ich habe jetzt die Reviews durchgesehen, waren durchwegs sauber ausgeführt. Ich habe auch die Review-Abgaben freigeschalten, damit Sie das, was das andere Team zu Ihrem P3 zu sagen hatte, auch ansehen können.

Wednesday, November 26, 2008

Abwechselnde Styles mit XSLT

Also, Kollege Vilic hat die Frage aufgeworfen, wie man mit XSLT erreichen kann, dass z.B. Tabellenzeilen oder Listeneinträge mit abwechselnden Farben unterlegt werden. Das geht wie vermutet mit Verwendung der Modulo Funktion (die ja den Rest einer Division liefert). Nun wenn man aufsteigende Werte modulo 2 rechnet, kommt immer 0 oder 1 als Rest. Das können wir uns zu Nutze machen, in dem wir die Position der Elemente als Operand für die Modulo-Rechnung hernehmen):

im XSL:
<xsl:template match="person">
<li class="row{position() mod 2}"><xsl:value-of select="name"/></li>
</xsl:template>

und im CSS:
.row0 { background-color: blue; }
.row1 { background-color: green; }

Voila. Ein Beispiel gibts hier.

Monday, November 24, 2008

Morgen letzte VO

Also morgen werden wie die letzte VO Einheit dieses Semesters in SWA haben. Es werden noch die Reste zu XSLT kommen, sowie ein paar Beipiele von XML Anwendungen und als letztes Kapitel Web Services (wo so aufregende Dinge wie WSDL, SOAP, UDDI vorkommen werden!)

Anmerkungen zu A3

Ich habe ein paar der bereits hochgeladenen Abgaben zu A3 überflogen, und was ich öfter sehe: Sie bilden die Klassen (und Attribute) des Klassendiagramms korrekt in XML ab, aber die Beziehungen sind im XML nicht abgebildet. Wenn Sie z.B. eine m:n Beziehung zwischen Projekt und Mitarbeiter haben, dann müssen Sie natürlich XML Elemente für Projekte und Mitarbeiter erstellen, aber auch eine Struktur, die die Zuordnung von Mitarbeitern zu Projekten ermöglicht! Bitte das nicht übersehen, das ist der eigentliche Zweck (bzw. die "Schwierigkeit" der Aufgabe)

Sunday, November 23, 2008

A2 und P3 durchgesehen

Also, ich habe jetzt die Abgaben zu A2 und P3 durchgesehen. Bei P3 gabs ja einige Probleme, die wir schon im PR letzte Woche erläutern konnten. Einige Teams müssen die Architektur auf Basis dessen überarbeiten.

Enttäuscht haben mich einige Abgaben zu A2. Während der Großteil von Ihnen sehr Brauchbares abgeliefert hat, haben einige Kollegen (ich denke diejenigen die es betrifft, wissen es) völlig daneben gegriffen. Wenn man die Aufgabe schon nicht selbst erledigt sondern nur von anderen den dortigen Schwachsinn abschreibt, frage ich mich schon, wie hier die Einstellung zum Studium aussieht. Weitere Fälle von Abschreiben werden ausnahmslos mit sofortigem Ausschluss aus dem PR geahndet.

Friday, November 21, 2008

Kommentare

Ich bin momentan voll mit Terminen, darum bitte ich um Nachsicht, wenn die Kommentare zu den letzten Abgaben (P3, A2) noch etwas auf sich warten lassen.

Tuesday, November 18, 2008

AJAX und Javascript leicht gemacht

Es gibt ein Javascript Framework namens Prototype, das einem das Leben mit Javascript, AJAX und DOM wesentlich vereinfacht.

Es ist eigentlich nur ein einzelnes Javascript File, dass man runterladen kann und über den script Tag in die eigene Webseite einbinden, dann schon kanns losgehen.

Ich hab mal versucht den alten AJAX Calculator umzuschreiben auf eine neue Version, die Prototype verwendet. Ebenso habe ich das AJAX Beispiel dass ich im PR gezeigt habe, wo man eine Textzeile direkt editieren kann mit Protoype neu geschrieben. Der Sourcecode von beiden Beispielen ist nun wesentlich schlanker und einfacher.

Ich empfehle also die Verwendung von Prototype auch für die Projekte.

Zwischensitzung

Ich spiele mit dem Gedanken, nach der November-Aufgabenflut Anfang Dezember einen Praktikumstermin im Hörsaal zu ersetzen mit: jedes Team schaut bei mir im Büro persönlich vorbei, wir besprechen wie/was implementiert wird und gegebenenfalls Notenprobleme/Nachzipf für jene, bei denen die Einzelabgaben mangelhaft sind. So kann ich mich mal mit jedem/r von Ihnen einzeln und im Team besprechen.

Ein passender Zeitrahmen für diese Treffen wäre wohl die Woche vom 8.-12.12.

Sunday, November 16, 2008

Serialisieren in PHP

Für alle die Probleme beim schreiben und lesen von Daten aus aus einer Datei im Rahmen der Aufgabe A2 haben: ich habe ein kleines Demo Beispiel gemacht, wo eine Liga mit ihren Vereinen in eine Datei gespeichert und wieder ausgelesen wird.

Wenn man das umlegt auf Album und Tracks sollte es keine Probleme mehr geben.

Die Moral der Geschichte: nur eine Variable (Objekt einer Klasse) in die Datei serialisieren, nicht mehrere. Sonst gibts beim Auslesen Probleme, die zwar nicht unlösbar sind, aber aufwändig(er) und das ist nicht Ziel der Aufgabe.

Hier gibts das Beipiel, die PHPS Dateien zeigen jeweils den PHP Source Code.

Friday, November 7, 2008

Tom Pitner ist nun Dozent für Informatik

Also, mein Freund Tom Pitner, der ja die SWA Gruppen 1 und 2 leitet, hat soeben seine Habilitation für Informatik an der Universität Brünn erfolgreich abgeschlossen. Für jene die das nicht wissen: die Habilitation ist die höchste erreichbare wissenschaftliche Qualifikation. Um diese zu erreichen, muss man signifikante Beiträge in Wissenschaft und Lehre in dem betreffenden Fach vorweisen und gegen skeptische Kommissionen verteidigen können.

Da lassen wir ihm doch herzliche Gratulationen aus der SWA Familie zukommen!

Use Cases

Also nach Durchsicht der Anforderungen und Use Cases in den Gruppen 1, 4 und 5 lassen sich folgende wiederkehrende Probleme identifizieren (ich habe in den Kommentaren auch teilweise auf diese Punkte verwiesen):

1. Überladung: Die Diagramme sind oft überladen und werden somit unleserlich. Es wird anscheinend versucht alle Use Cases des Systems in ein Diagramm zu packen. Das ist nicht immer zielführend. Lösung: Diagramm auftrennen in mehrere Diagramme, die jeweils einen konkreten Ausschnitt (z.B. Benutzerverwaltung) zeigen.

2. Formulierung: Use Cases sind oft unklar formuliert. Z.B. "Suchen" klingt gut, aber es bleibt offen was gesucht wird. Lösung: Es hilft bei Use Case Benennung sich nach dem Schema Nomen+Verb zu halten, z.b. "Mitarbeiter suchen", "Forumseintrag erstellen", etc.

3. System Case: Es kommen Use Cases vor, die eher Systemverhalten repräsentieren (z.B. "Bestätigung erhalten"). Diese sind meist Systemaktionen, die durch einen anderen Use Case ausgelöst werden. Lösung: diese nicht als Use Cases modellieren. Es sollte aus der Beschreibugn bzw den Anforderungen dann erkennbar sein, dass das System eine Bestätigung verschickt. Konzentrieren Sie sich auf Interaktionen, die der Benutzer auslöst und wo der Benutzer aktiv mit dem System arbeitet um seine Ziele zu erreichen.

4. CRUD Use Cases: Oft sind Use Cases zu abstrakt, es ist keine konkrete Handlung dabei zu identifizieren, z.B. "Benutzer verwalten" (deshalb CRUD, weil Create, Retrieve, Update, Delete in einem Use Case vereint sind). Das ist kein Use Cases, bestenfalls noch ein abstrakter Use Case, der duch "Benutzer anlegen", "BEnutzerdaten ändern", etc. konkretisiert werden sollte. Auch ist es nicht sinnvoll, mehrere Use Cases in einen Use Case zusammenzufassen wie "Benutzer anlegen/ändern/löschen". In einem richtigen Use Case Dokument gibt es zu jedem Use Case eine strukturierte Beschreibung, das wäre in so einem Fall nicht möglich.

5. Zu Ablauforientiert: Oft wird zu viel Ablauflogik in die Use Cases durch übermäßiges Verwenden von «include» und «extend» eingebaut. Use Case Diagramme sind aber statische Diagramme ohne jegliche Ablaufinformation. Lösung: Beziehungen zwischen Use Cases nur wenn logisch und strukturell relevant, nicht versuchen alle Use Cases miteinander zu verknüpfen.

6. Keine Systemgrenze: Es ist die Systemgrenze unklar und/oder es fehlt die Benennung des Systems. Lösung: Rechteck um die Use Cases (im Zentrum) machen, bennenen, Use Cases innerhalb, Akteure links und/oder rechts ausserhalb. Das ist vor allem wichtig, wenn es mehrere Diagramme gibt.

Grundsätzlich war die Qualität der P2 Abgaben ganz gut, mit Ausschlägen nach oben aber auch einige nach unten. Je weniger schwerwiegend Sie die oben genannten Probleme ihren Use Cases anhängen können, desto besser :-) Die Anforderungen waren auch sehr unterschiedlich. Teilweise war kaum/nicht erkennbar wie diese erhoben wurden oder viel zu abstrakt formuliert, teilweise sehr klar und strukturiert.