Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Projekt: P2P Java Gui Plattform für LoNo Funktionen

<< < (4/8) > >>

animate:

--- Zitat ---Was würdest du statt xml-Datei verwenden???
Datei? Vielleicht besser. Oder was anderes?

--- Ende Zitat ---
mir würde in diesem Fall schon reichen, dass eine Liste aller Datensätze erstellt wird.
Wie das Teil mal aussieht ist im Moment nicht relevant.

Mir ist beim Durchlesen des Replizieren-Use Cases noch was aufgefallen: nämlich ein weiteres Beispiel dafür, dass du die UseCases viel zu detailliert beschreibst. In meinen Augen ist das Ziel von Use Cases nicht, z.B. eine Replikation in all ihren Schritten detailliert zu beschreiben (mit Formaten, Speicherorten, Kommunikationsmechanismen, etc.). Ich denke, sie sollten abstrakter beschrieben werden, um z.B. einen Überblick zu bekommen, welche Stakeholder beteiligt sind und was da mal ganz grob ablaufen wird.
Wie die Replikation genau abläuft, das kannst du dann z.B. in einem Aktivitätsdiagramm modellieren; eine genaue Beschreibung des Ablaufs gehört IMHO aber nicht in die Anforderungen an dieses System.

Axel_Janssen:
Hallo Potsmoker,

Auf jeden Fall. D.h. ein Aktivitätsdiagramm ist das bessere Format.

Ich würde aber diesen Use Case schon in der Inception-Phase genauer spezifizieren (besser mit Aktivitätsdiagramm als mit Use Case).
Der Grund für die frühe Spezifizierung sehe ich darin, dass dies der sowohl programmatisch und v.a. organisatorisch der komplexeste Use Case ist. Hier ist das Risiko am größten, dass der Budget-Verantwortliche nicht mit diesem Vorgehen einverstanden ist. Deshalb neige ich hier dazu, früh für klare Verhältnisse zu sorgen.

Aktivitätsdiagramme sind
- an sich nicht objektorientiert.
- eignen sich sehr gut dazu, Workflows darzustellen
Deshalb stellen sie ein sinnvolles Modellierungs-Werkzeug für Notes-Projekte dar. Teilzweck dieser Veranstaltung besteht ja darin herauszufinden, wo UML für Lotus Notes gut genutzt werden kann.

Zu allgemein bei der Spezifizierung zu bleiben, halte ich übrigens aus meiner Erfahrung für keine gute Idee. Vor allem in Organisationen mit einer strengen Trennung zwischen Projekt-Management und Coding dürften zu wolkige Spezifikationen dazu führen, dass dem Programmierer zuviel Verantwortlichkeit/Arbeit übertragen wird. Ich arbeite zum Glück nicht in einer solchen Organisation.

some work for a lazy friday afternoon.
Werd mal den Jakobs Krönung stock der hiesigen Kiosk-Szene abchecken und meld mich dann wieder...

Gruß Axel

Axel_Janssen:
Hier ist das Aktivitäts-Diagramm für den Anwendungsfall "Pull Replizierung initiieren".


Die schwarzen Kreise am Start und Ende symbolisieren den Anfang und das Ende der Aktivität. Die Kästchen mit den runden Ecken sind Aktivitäten. Die Pfeile dazwischen Transitionen zwischen den Aktivitäten.  
Die einzelnen Aktivitäten sind auf "Spalten" aufgeteilt mit einem "Spaltentiteln" (z.B. "Replication Requester System". Der Fachmann spricht hier von Verantwortlichkeitsbereichen (swimlanes). Durch sie ist eine Zuordnung von einer Aktivität zu einem Akteur möglich.

Ein Aktivitätsdiagramm beschreibt einen Fluss von sequentiell aufeinander folgenden Aktivitäten. Es existiert auch eine Syntax für Verzweigungen (if-then) und Aufspaltung (für nebenläufige parallel in verschiedenen Threads ablaufende Aktivitäten). Beides wird aber in diesem Diagramm nicht benötigt.
Diese Abfolge von Aktivitätszuständen hat nix mit OO zu tun. Der Diagrammtyp hat sich aber für die folgenden Aufgaben bewährt:
- Analyse eines Anwendungsfalls
- Verstehen eines Workflows/Geschäftsprozesses.
- Beschreiben eines komplizierten sequentiellen Algorithmus
- Umgang mit Anwendungen mit mehreren Threads.  

Die Kästchen mit den Eselsohren sind sogenannte UML-Notes. Das sind sowas wie Kommentare. Die UML-Notes können in verschiedenen UML Diagrammtypen benutzt werden.

Was oben ein bischen untergegangen ist: Bei den << >> wie in <<uses>>  handelt es sich um sogenannte Stereotypen. Mit ihnen kann die semantische Bedeutung von UML Elementen erweitert, d.h. genauer spezialisiert werden. Der Use Case "Code-Dokument erstellen" steht in einer Beziehung zu dem Use Case "Kategorie erstellen" .<<benutzt>> zeigt an, dass diese Beziehung eine "benutzt"-Beziehung und keine "erbt-von" Beziehung handelt.

Inzwischen dürfte klar sein, dass die UML ein Bündel an verschiedenen Diagramm-Typen für unterschiedliche Aufgabenstellungen für ein Softwareprojekt enthält. Es gibt in UML 1.4 ungefähr 8 bis 10 verschiedene Diagrammtypen. Man kann wirklich nicht sagen, dass 1 Diagrammtyp "wichtiger" ist als ein anderer.  
 

Semeaphoros:
Hab mir den ganzen Thread jetzt noch einmal in aller Ruhe angeschaut und auf mich wirken lassen. Und dann ein wenig zurück überlegt. Interessant ist ja schon, dass ich diese Vorgehensweise schon immer praktiziert habe, natürlich ohne die unterdessen erfolgte Formalisierung, der Weg war hingegen in etwa derjenige, der jetzt durch (R)UP ganz offensichtlich in ein formales Gerüst gegossen wurde.

Als Vorbereitung auf die Verbindung mit LotusNotes: Im Zusammenhang mit meinen Vorträgen über OOP und Prototyping (das gehört hier auch mit hinein, man will ja den Anwender in die Entwicklung mit einbeziehen) bin ich natürlich mit verschiedenen Leuten ins Gespräch gekommen.

Erstens: zu OOP: Offensichtlich ist für viele ND-Entwickler, auch wenn sie intensiv mit LS arbeiten und dabei eigentlich Objekte perfekt benutzen, OO ein absolut fremd(artig)er Begriff. Ja, man interessiert sich dafür, wagt aber den Schritt nicht zu machen, in diese Welt einzusteigen. Ok, LS macht es einem ja nicht leicht, da die Unterstützung für eigenes OOP zwar vorhanden, aber nicht gerade ideal ist. Sprich, der Hauptteil der LoNo Entwicklung wird nach wie vor prozessorientiert durchgeführt, man arrangiert sich irgendwie mit dem OO-Framework und dem Event-Modell, das zugrunde liegt, ohne es aber eigentlich zu verstehen. Von verschiedenen Leuten wurde ich sehr lobend dafür angesprochen, das Thema aufgegriffen zu haben. Schaut man die Literatur an, so stellt man auch rasch fest, dass es für die Basics, die für den "Umsteiger" so wichtig sind, so gut wie keine Literatur gibt.

Zweitens, Prototyping: Ich hab mal in der Runde der Teilnehmer in Dortmund gefragt, wie ihre Erfahrungen und Erwartungen sind: Nur gerade 2 der Teilnehmer haben es überhaupt je versucht, Prototyping zu verwenden. Natürlich waren die Zuhörer dort motiviert, sonst wären sie ja nicht in den Vortrag gekommen, es zeigte sich aber deutlich, dass man zwar ganz gerne "neues" machen möchte, gleichzeitig spürte man aber auch die Angst heraus, mit dem Endanwender schon während der Entwicklung zusammen zu arbeiten. Natürlich gibt es auch auf der Anwenderseite Probleme: das setzt natürlich voraus, dass der Benutzer eben auch Zeit aufwendet schon während der Entwicklung. Und die Leute dazu zu motivieren, ist nicht einfach, geht aber definitiv nicht, wenn die Entwicklerseite nicht von der Wirksamkeit überzeugt ist. Danach habe ich mich nicht mehr gewundert, dass es fast keine Literatur zum Thema gibt, obwohl man doch schon bald seit Jahrzehnten von Prototyping spricht, und in anderen Branchen ist das Verfahren ja schon lange absoluter Alltag.

Fazit: Es geht nicht nur darum, neue Verfahren auszuhecken und umzusetzen, man darf nicht vergessen, die Menschen mitzunehmen. Schliesslich gilt das auch für die Softwareentwicklung selber: Wenn wir die Anwender nicht mitnehmen, mit einbeziehen, dann funktioniert der Prozess nicht (und das gilt jetzt eigentlich ganz allgemein und sagt auch gleich aus, warum das Wasserfall-Model so leicht zu langen Gesichtern führt ....).

Hatte gerade mit jemandem von Lotus-Education einen kurzen Mailwechsel kurz vor Weihnachten und werde in dem Sinne in Orlando weiter diskutieren: Das ist bei der gegenwärtigen IBM-Strategie eindeutig ein Problem, will man die Leute, die heute mit LoNo entwickeln, in die "neuen Welten" mirgrieren, muss man ihnen genau diese Zusammenhänge nahebringen. Das geschieht aber nicht, wenn man nicht genau diesen Leuten spezielle Brücken zur Verfügung stellt in Form von Aus- und Weiterbildung spezifisch auf das Problem des "Paradigmenwechsels" von Prozess-O zu OO und alles was damit zusammenhängt. Ich denke mal, das Bewusstsein dafür ist noch nicht vorhanden.

Axel_Janssen:
Use Cases fokussieren sich hauptsächlich auf funktionale Anforderungen an das System. Daneben existieren die sogenannten nicht-funktionalen Anforderungen.
Allgemein spricht man von FURPS+ Requirements.
- Functionality
- Usability
- Reliability
- Performance
- Supportability
- Implementations-Beschränkungen, Komponenten, Interfaces, Domain Rules, Legal Issues

Die meisten dieser Anforderungen sollten laut (R)UP in einem speziellen Dokument gesammelt werden, dem sogenannten Supplementary Specification Document.  Viele der nicht funktionalen Anforderungen sind Gegenstand der Architektur-Analyse. Mehr dazu später.

Ich übernehme das Template von Larman für das Supplementary Specification Document.

+ Functionality
(gemeinsam für viele Use Cases)
Logging und Error Handling
Alle Fehler werden in ein Log geschrieben. Ausserdem erhält der Anwender eine Nachricht in Form einer Messagebox.

- Sicherheit
Ist hier nicht so wichtig

+ Usability
Das User Interface soll möglichst ähnlich wie für die Anwender vertraute Windows-Anwendungen aussehen.

Schnelligkeit, Einfachheit und Fehlerfreiheit sind wichtig, damit die Anwendung benuttz wird.  
 
+Reliability
Außer beim halbautomatisierten Replikations-Prozess handelt es sich bei der Anwendung um eine Standalone-Anwendung. Ausfälle des Netzwerk fallen erst mal aus. Ausfälle von externen Komponenten oder Systemen (RDBMS, Lotus Notes, korrupte xml Datei, Indexierungsservice) sollen dem Anwender in Form einer Messagebox in transparenter Form mitgeteilt werden. Ausserdem werden sie in das log geschrieben.

+Performance
Performance ist sehr wichtig für die Akzeptanz der Anwendung. Um die Responsivität der GUI zu maximieren, soll Multithreading benutzt werden. Die GUI soll nie länger als 0.5 Sekunden blockiert sein.  

+ Supportability
- Adaptability
Als Datenbank soll zunächst eine xml-Datei genommen werden.
Der Database Access Layer wird so designt, dass die xml-Datei einfach durch Lotus Notes oder eine Relationale Datenbank ersetzt werden kann.
Die Anwendung soll mehrsprachlich sein.
- Configurability
Die Wahl der Datenbank (und der spätere Wechsel) soll über eine Konfígurationsdatei (ohne Programmierung) möglich sein.
Die GUI soll ohne Programmierung neue Sprachen unterstützen.

Implementation Constraints
Das Management board hat sich mit einstimmiger Mehrheit für Java als Programmierplatform entschieden.
Grund dafür ist die Einfachheit der Programmierung.

Gekaufte Komponenten
- Lotus Notes
- evtl db2

freie Open Source Komponenten
Open Source ist oft eine gute Idee (es gibt Ausnahmen). Es sollen reife und häufig verwendete Open Source Komponenten eingesetzt werden.
Kandidaten sind:
- Java Swing
- Log4u
- Look and Feel von Carsten Jentzsch (damit Swing nach Windows und nicht wie eine Milka-Kuh aussieht).
- Forms Layout Manager von Carsten Jentzsch (weil das sehr vielversprechend aussieht und ich dem Mann vertraue. Ausser denke ich darüber nach, einen Bericht über das Forms-Layout für den Javaranch Newsletter zu schreiben).
- Für xml entweder DOM oder JDOM. JDOM ist möglicherweise einfacher.
- vermutlich Dinge aus dem utils Package von apache.jakarta
- als Haupt-Entwicklungs-RDBMS MySQL.  

Interfaces- Hardware
PC (inklusive Laptop).

Legal Issues
sauber bleiben und kein Scheiss bauen.

Information in Domain of Interest
...

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete