Präsentation about conference-system

[autarchprinceps]

Wenn ich mir unseren Code so angucke fällt mir auf, dass wir ein Anemic Domain Model benutzen (unsere Entities haben ja höchstens getter und setter, Dinge wie revisePublication sind eine Methode eines EJBs und nicht eine Methode der Publication Entitiy) und dass der lesende und der schreibende Zugriff auf Entities von völlig verschiedenen Komponenten durchgeführt wird. Ich glaube das nennt man CQRS, oder? Ich finde allerdings die Folie dazu nicht mehr.
Es wäre wahrscheinlich gut beides in der Präsentation an passender Stelle zu erwähnen.

Wir sollten wahrscheinlich vorstellen, wie wir Login, Authentication und Rollen umgesetzt haben.

[autarchprinceps]

Was ist mit Screenshots?

Ich würde es eher Live zeigen, oder?

[mbasti]

• Patterns: muss ich selber nochmal gucken. Eigentlich besteht die gesamt Applikation ja nur aus CRUD-Operationen.
• Probleme: Naja welche Probleme hatten wir? Das mit der DB-Konfiguration vllt., aber das ist eher peinlich als interessant...
• Screenshots: keine würde ich sagen, dafür eine kurze Live-Demo vorführen.

Auf Authentifizierung., Login und Rollen können wir näher eingehen. Was ist eigentlich mit der Authentifizierung? Genügt das?

[mbasti]

Mir ist nicht klar das wozu genau jetzt dieser Bericht (arc42) sein soll. Den schaut sich doch keiner an ?

[autarchprinceps]

Ich weiß es auch nicht. Im Bachelor in Softwareengineering haben wir auch immer so einen Scheiß gemacht. Verschwendeter Aufwand meiner Meinung nach.

Wir sollten den Bericht natürlich trotzdem machen, aber die Präsentation ist definitiv wichtiger.

[autarchprinceps]

Ich habe mal einige der Diagramme erstellt (im Ordner Präsentation/Diagramme).

Was meinst du, passt das Use Case Diagramm noch, oder muss das angepasst werden?

Meinst du wir sollen den Page Flow auch nur Live zeigen, oder auch als Diagramm darstellen?

[mbasti]

Du musst das Zeug noch hochladen.

Page Flow: Kommt imo ein bisschen darauf an, wie lange Präsentation wird. Aber nen simplen Page Flow kann man schon machen, glaube ich.

[autarchprinceps]

Sorry, hatte commited, aber push vergessen.

Ich meine einen Page Flow nur mit den Seiten und Verbindungen, keine Skizze der Seiten oder so.

[mbasti]

Also quasi nur als Graph - ja, warum nicht.

[mbasti]

Womit hast du die Diagramme erstellt? Sieht gut aus.

Ich hab mir nochmal unser UserCase-Diagramm angeschaut:
Kommitee erstellen: Das Kommitee wird eigentlich gleich bei der Erstellung der Conf. gemacht. Oder damit ist die Zuordnung Reviewer -> Pub. vom Organizer gemeint.

was strenggenommen fehlt:
Deregister
Conference löschen

haben wir bisher gar nicht umgesetzt: Publikation löschen

[autarchprinceps]

Visio, außer das Klassendiagramm, das habe ich mit Visual Studio erstellt.

Vielleicht kannst du das Use Case Diagramm erstellen. Wenn nur Kleinigkeiten angepasst werden müssen, kannst du ja ruhig das bestehende anpassen. Ich würde Register und Deregister unter Umständen ruhig zu einem Use Case zusammenfassen.

Was den letzten Punkt angeht, ich kann das in die UI aufnehmen, aber ich bin mir nicht sicher, wie man eine Entity richtig löscht. Kannst du eine deletePublication-Methode in die PublicationAdministration EJB aufnehmen, die ich benutzen kann?

[mbasti]

Was den letzten Punkt angeht, ich kann das in die UI aufnehmen, aber ich bin mir nicht sicher, wie man eine Entity richtig löscht. Kannst du eine deletePublication-Methode in die PublicationAdministration EJB aufnehmen, die ich benutzen kann?

Hab ich gerade gemacht. Bei den JPA-Sache muss ich sowieso nochmal gucken ob das alles so seine Richtigkeit hat...

[autarchprinceps]

Ich habe mal eine Präsentation erstellt. Es fehlen noch ein paar Sachen und es müssen noch ein paar Diagramme aktualisiert werden. Ich habe im Inhaltsverzeichnis TODOs hinzugefügt. Für dich vor allem: Page Flow & Authentifizierung. Der Text zu den Diagrammen fehlt teilweise auch noch, wenn dir was gutes einfällt, schreib es ruhig hin.

Ich will eine Einschätzung von dir: Sollen wir den Komponentenentwurf neu machen, oder ist das detailierte Komponentenschichtendiagramm auf der Folie davor genug? Ich meine die Verbindungen und die Komponenten sind da auch aufgeführt und ein extrem detaillreicher Komponentenentwurf mit API-Dokumentation, das zusätzliche Informationen enthielte, würde nie auf die Folie passen. Auf der anderen Seite will der das vielleicht unbedingt haben, auch wenn es keine weiteren Infos liefert.
Was denkst du?

[mbasti]

Ich denke, sich an arc42 zu halten ist schon wichtig für den Professor und deshalb habe das Inhaltsverzeichnis etwas mehr danach gegliedert.

Wo denkst du gehört PageFlow hin? Ich denke zum Kapitel Konzepte nach arc42 (Punkt Ablaufsteuerung oder Bedienoberfläche):
http://confluence.arc42.org/display/templateDE/Ablaufsteuerung

Habe den PageFlow mal angefangen, aber ich weiß nicht ob das so ok ist. Hast du dir das so vorgestellt? Sollen alle Pfeile für die Navigation dran? Weil, zur Suche zb. kommt man ja fast immer.

Die Folie Einleitung/Motivation ist nur obligatorisch erstmal, weiß nicht ob wir sowas brauchen.

Ich will eine Einschätzung von dir: Sollen wir den Komponentenentwurf neu machen, oder ist das detailierte Komponentenschichtendiagramm auf der Folie davor genug? Ich meine die Verbindungen und die Komponenten sind da auch aufgeführt und ein extrem detaillreicher Komponentenentwurf mit API-Dokumentation, das zusätzliche Informationen enthielte, würde nie auf die Folie passen. Auf der anderen Seite will der das vielleicht unbedingt haben, auch wenn es keine weiteren Infos liefert.
Was denkst du?

Ne, natürlich nicht den restlichen API-Kram noch in die Präsentation. Zur not haben wir ja noch die (verweste) Doku.

[autarchprinceps]

Mir gefällt der Page Flow so gut. Ist schön simpel. Das Use Case Diagramm ist jetzt auch viel übersichtlicher.

Ich habe die Verteilungssicht mal etwas nach vorne gezogen. Das passt sonst meiner Meinung nach gar nicht.

Ich kann das Projekt an meinem Rechner nur in einer Windows VM laufen lassen, weil Glassfish irgendwie nicht funktioniert. Ich würde vorschlagen, dass wir für Präsi & Demo deinen Rechner benutzen. Ich werde es trotzdem auf meinem Rechner vorbereitet haben, für den Fall der Fälle, ist aber nicht so schön. Bereite am besten schon mal ein Paar User, Konferenzen und Pubs vor. Ich weiß nicht ob du Postgres oder Derby benutzen willst, das überlasse ich dir.

[mbasti]

Ok. Wir haben die Prüfung ja um 14:40. Sollen wir uns vorher nochmal treffen? Dann können wir ja auch nochmal über die Präsentation reden.

[autarchprinceps]

Ich hatte noch gar nicht geguckt, welcher Tag?
Wir sollten uns auf jeden Fall vorher treffen, 14:40 ist ja auch nicht besonders früh.

[autarchprinceps]

Was haben wir für "Lessons Learned"?

Sag einfach, wann du dich treffen willst, mir ist relativ egal, wenn es frühestens 12:00 wäre, würde es uns doch mehr als genug Zeit geben, oder?

[mbasti]

Hm ich glaube das ist für die Probleme, auf die wir gestoßen gestoßen sind und wie wir die dann gelöst haben. Aber mir fällt grad auch nichts konkretes ein.

Also ich bin am Montag wahrscheinlich dann schon um 11:00 in der Hochschule, wieder im Raum A133.

[autarchprinceps]

Wir haben irgendwie so gar nichts für die Laufzeitsicht, aber Sequenzdiagramme für das zu zeichnen, ist unfassbar aufwendig und vollkommen nutzlos. Da kann man sich lieber gleich den Code anschauen, der ist weniger kompliziert.
Sollen wir das aus dem Bericht komplett streichen, oder fällt dir irgendwas anderes ein, was da noch rein könnte?

[mbasti]

Irgendwo stand auch mal, dass wir die Laufzeitsicht ignorieren können.

Vielleicht wie generell unser Vorgehen war, aber das lässt sich auch aus den UML-Diagrammen rauslesen.

[autarchprinceps]

Ja und allgemeine Strategien gehören eher in 4. Lösungstrategien.
Ich entferne das Kapitel aus der Doku.
Es gibt noch ein paar Punkte, in denen nichts oder wenig ist. Ich werde versuchen noch ein bisschen was hinzuzufügen, aber viel fällt mir auch nicht mehr ein.

• 1.2 Qualitätsziele (nichts) - laut arc42: ·Verfügbarkeit (availability), Änderbarkeit (modifiability), Performanz (performance), Sicherheit (security), Testbarkeit (testability), Bedienbarkeit (usability)
• 2.2 Organisatorische Randbedingungen (nichts)
• 2.3 Konventionen (sehr wenig) - fallen dir vielleicht Programmierrichtlinien ein
• 4 Lösungsstrategien - hier soll "Kurzer Überblick über Ihre grundlegenden Entscheidungen und Lösungsansätze, die jeder, der mit der Architektur zu tun hat, verstanden haben sollte." rein, ich schreibe gerade ein bisschen über grobste Aufteilung, aber alles weitergehende kommt ja eigentlich danach

[mbasti]

1.2 Qualitätsziele: Haben wir ja nicht bekommen und wir können uns ja nichts dazu schreiben, was wir ja sowieso nicht beachtet haben, oder?
2.2. Organisatorische Randbedingungen: Naja Arbeiten in 2er-Gruppe, Fertigstellung bis Montag und erste Version bis 16. Dezember mit definierten Control-Objekten und Schnittstellen (Übung 8), aber das ist auch so unsinnig...
4 Lösungsstragien: Initial mit SQL die Relationen definiert und mithilfe von Netbeans die Entity-Klassen generieren lassen. Sukzessiv dann einige Anpassungen vorgenommen. Verwendung von JPA für JDBC und ORM.

[autarchprinceps]

Ich habe alles was mir eingefallen ist eingefügt. Wenn dir auch nichts mehr einfällt, kannst du die leeren Kapitel löschen.

[autarchprinceps]

Haben/Sollen wir irgendwo dokumentieren, dass die UI komplett in Primfaces implementiert ist?