Notizen aus dem Entwickleralltag

[Andreas Rudolph]

In diesem Themenstrang werden in unregelmäßigen Abständen verschiedenste Anmerkungen, Kommentare und andere Nebensächlichkeiten aus der alltäglichen Entwicklungsarbeit im OpenEstate-Projekt zusammengefasst.

[Andreas Rudolph]

Mit Hilfe des Programmes SLOCCount habe ich aus Neugier mal eine Analyse der OpenEstate-API gemacht. Ich möchte Ihnen das Ergebnis nicht vorenthalten und ein paar Gedanken dazu formulieren.

Zahlen über Zahlen

Lines of Code (Quelltextzeilen)

In der folgenden Übersicht werden die physischen Quelltextzeilen (Spalte SLOC) eines jeden Teilprojektes (Spalte Directory) dargestellt.

Code: Alles auswählen

SLOC    Directory   SLOC-by-Language (Sorted)
78502   OpenEstate-Impl java=78431,sh=71
31569   OpenEstate-Tool-Agency java=31470,php=99
22481   OpenEstate-Tool java=22435,sh=46
9728    OpenEstate-Tool-Calendar java=9728
4559    OpenEstate-Tool-Agency-Addons java=4559
4394    OpenEstate-Tool-Contacts java=4394
2162    OpenEstate-Tool-Contacts-Addons java=2162

Gruppiert nach verwendeten Programmiersprachen bedeutet dies:

Code: Alles auswählen

Totals grouped by language (dominant language first):
java:        153179 (99.86%)
sh:             117 (0.08%)
php:             99 (0.06%)

Wenn das Programm richtig gerechnet hat, besteht die OpenEstate-API zur Zeit aus 153.395 physischen Quelltextzeilen. Der Löwenanteil davon wurde in Java programmiert (99,86%).


Kostenmodell

Unter Verwendung des 'Constructive Cost Model' (COCOMO) kann aus den Quelltextzeilen der betriebswirtschaftliche Aufwand für ein Softwareprojekt dieser Größenordnung abgeschätzt werden.

Code: Alles auswählen

Total Physical Source Lines of Code (SLOC)                = 153,395
Development Effort Estimate, Person-Years (Person-Months) = 36.84 (442.13)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 1.66 (19.88)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Total Estimated Cost to Develop                           = $ 4,977,109
(average salary = $56,286/year, overhead = 2.40).

Die geschätzten Gesamt-Entwicklungskosten für ein Projekt der aktuellen Größenordnung von $ 4.977.109 (US-Dollar) sind schon erstaunlich. Es ist jedoch anzumerken, dass im COCOMO der komplette Software-Entwicklungsprozess (vom Reißbrett bis zur Inbetriebnahme) berücksichtigt wird. Die OpenEstate-API (bzw. das ImmoTool) hat kein solches 'starres Konzept'. Viel mehr handelt es sich um einen 'stetig wachsenden' Entwicklungsprozess, der offen für Einflüsse von Außen ist.

Anmerkungen, Schlussfolgerungen & Interpretationen

Die Anzahl der Quelltextzeilen ist kein Maß für die Qualität eines Programmes

Die Qualität einer Software kann nicht mit Quelltextzeilen gemessen werden. In Wikipedia wird der Sachverhalt wie folgt beschrieben:

Computerprogramme können aus nur wenigen Dutzend bis zu hunderten von Millionen Programmzeilen bestehen. Der Umfangs eines Programmes muss nicht zwangsläufig Rückschlüsse auf die Komplexität des Programms erlauben, da die Zählweise der Zeilen nicht einheitlich ist und das Ergebnis außerdem von der Formatierung des Quelltextes, der Programmiersprache und anderen Faktoren abhängt. Je nach Zählweise sind insbesondere Rückschlüsse auf die investierte Arbeitszeit meistens sinnfrei.

Das ImmoTool stellt weniger als 50% des gesamten Quelltext-Umfangs dar

Das ImmoTool (inkl. Add-Ons) belegt mit 74.893 Zeilen weniger als 50% des gesamten Projektes. Die andere Hälfte wird allein von der Bibliothek 'OpenEstate-Impl' in Anspruch genommen. In diesem Teilprojekt sind die Lese- & Schreibfunktionen für die verschiedenen Immobilienformate (OpenEstate, OpenImmo, IS24, etc.) programmiert worden. Diese große Zahl verdeutlicht den Entwicklungsaufwand für solche vermeintlich selbstverständlichen Funktionen und erklärt vermutlich auch, warum die meisten Softwarelösungen nur wenige Immobilienformate unterstützen.


Der Umfang des Projektes wird in den Zahlen nur unvollständig erfasst

Das Analyseprogramm verarbeitet nur die Quelltextdateien und leitet unter verschiedenen Annahmen (Lohnkosten, 152 Arbeitsstunden pro Monat, etc.) den Gesamtaufwand des Projektes ab. Dies stellt aber nur einen Bruchteil des gesamten Projektes dar. Verschiedene wichtige Aspekte bleiben unberücksichtigt:

• Übersetzungsarbeit
• Dokumentation im Wiki
• Support / Betreuung der Anwender
• Spezifikation von OpenEstate in XML & SQL
• Organisation der internen Abläufe / Entwicklung von Hilfsprogrammen

Wer trägt nun die Kosten am OpenEstate-Projekt?

Die im COCOMO errechneten Kosten kann man sicherlich je nach Sichtweise höher oder niedriger ansetzen. Dennoch verdeutlicht diese Zahl, dass eine Softwareentwicklung in dieser Größenordnung für ein betriebswirtschaftlich agierendes Unternehmen durchaus ein wirtschaftliches Risiko darstellen kann. Hier wird der enorme Vorteil eines gemeinschaftlich entwickelten Projektes deutlich. Jeder Anwender, Supporter, Übersetzer, Sponsor & Entwickler trägt seinen Teil zur 'Wertsteigerung' des Projektes bei - eine klassische Win-Win-Situation.

[Andreas Rudolph]

Eine der großen Herausforderungen bei der alltäglichen Arbeit am OpenEstate-Projekt ist die Optimierung der Arbeitsabläufe. Wir sind derzeit 'nur' zwei Programmierer und müssen jede Möglichkeit zur Zeitersparnis nutzen, damit das Projekt nicht im Sande verläuft. An verschiedenen Stellen wurden deshalb in den letzten Wochen Umstellungen / Verbesserungen vorgenommen.

Optimierung der Projektplanung

In den letzten Wochen wurden verschiedene Verbesserungen vorgenommen, um die Alltagsarbeit im OpenEstate-Projekt zu erleichtern.

Zeitersparnis durch öffentliches 'Bug-Tracking'
Unsere 'Todo-Liste' ist öffentlich im Bug-Tracker einsehbar. Sich wiederholende Fragestellungen aus Forum / Ticketsystem / E-Mails müssen damit nicht mehrfach beantwortet werden. Ein Verweis auf den jeweiligen Eintrag im Bug-Tracker genügt, damit der Anwender sich über den aktuellsten Stand unserer Überlegungen zu einem Problem informieren kann.

Zeitersparnis durch öffentliche Diskussion
Damit wir unserer Zielsetzung gerecht werden, alltagstaugliche Lösungen für die Immobilienwirtschaft zu entwickeln, wurde dieses Forum in Betrieb genommen. An dieser Stelle können Probleme / Änderungswünsche gemeinsam diskutiert werden, bevor diese programmiert werden. Es ist weitaus effizienter ein Problem vorab mit den Anwendern diskutiert zu haben, als nachträglich Änderungen / Umstellungen vornehmen zu müssen.


Optimierung der Projektentwicklung

In dieser Disziplin bestand ebenfalls Bedarf zur Optimierung. Die internen Strukturen zur Organisation der Quelltexte stammen noch aus einer Zeit, in der an das OpenEstate-Projekt nicht zu denken war. Das stetige Wachstum des Projektes stellte uns vor Herausforderungen, die bisher nur 'provisorisch' gelöst wurden.

Zeitersparnis durch verbesserte Versionierung
Bei der Betreuung & Entwicklung einer Software ist es nötig, mehrere Versionsstränge parallel verwalten zu können. Einen solchen Mechanismus gab es zwar bereits, jedoch waren dabei nicht alle Fälle in überschaubarem Aufwand zu realisieren.

1. Es müssen allgemein beliebig viele Versionsstränge parallel verwaltet werden können.
2. Bei eventuellen Problemen muss der Quelltext der aktuell veröffentlichten ImmoTool-Version im Versionsstrang 0.9.x jederzeit vorliegen.
3. Zur Weiterentwicklung des Projektes muss ein separater Versionsstrang 1.x gepflegt werden können.
4. Fehlerkorrekturen aus Strang 0.9.x müssen mit überschaubarem Aufwand in Strang 1.x 'portiert' werden können.
5. Weiterentwicklungen aus Strang 1.x müssen mit überschaubarem Aufwand in Strang 0.9.x 'portiert' werden können.

Vor solchen Problemen stehen auch andere Software-Projekte. Wir haben uns deshalb an der gängigen Programmierpraxis in Open-Source-Projekten orientiert und die Quelltextverwaltung entsprechend umgestellt.

Zeitersparnis durch einen besseren 'Build-Prozess'
In Java programmierte Software wird in der Regel mit Hilfe des Programmes Ant zu einem ausführbaren Programm kompiliert. So war es bisher auch im OpenEstate-Projekt der Fall. Ant ist zweifelsohne eine gute und stabile Software, dennoch gibt es gewisse konzeptionelle Probleme, die mit der alternativen Software Maven elegant gelöst wurden.

Dieser Artikel fasst die wesentlichen Unterschiede sehr ausführlich zusammen. Im Folgenden ein kurzes Zitat aus dem Artikel dazu:

Apache Ant

* Ant kennt keine formalen Konventionen bezüglich einer gemeinsamen Projekt Verzeichnis-Struktur. Sie müssen Ant genau sagen, wo sich die Quelldateien befinden und wo die Ausgabe abgelegt werden soll. Informelle Konventionen haben sich im Laufe der Zeit herausgebildet, aber diese wurden nicht im Produkt kodifiziert.
* Ant ist Prozedural, Sie müssen Ant genau sagen, was zu tun ist und wann dies zu tun. Sie mussten definieren: erst kompilieren, dann kopieren, dann paketieren.
* Ant kennt keinen Lebenszyklus, Sie mussten Targets definieren und deren Abhängigkeiten. Sie mussten die Abfolge der Schritte manuell für jeden Target festlegen.

Apache Maven

* Maven arbeitet nach Konventionen. Da Sie diese beachteten, wusste Maven wo Ihr Quellcode sich befand. Es stellt den Bytecode unter target/classes und es erzeugte ein JAR-Archive in /target.
* Maven ist deklarative. Alles was Sie tun musste, war eine pom.xml Datei zu erzeugen sowie Ihre Quelle im Standard-Verzeichnis ablegen. Maven kümmerte sich um den Rest.
* Maven kennt einen Lebenszyklus, welchen Sie mit dem Aufruf von mvn install angestossen haben. Dieser Aufruf bringt Maven dazu, eine Abfolge von Schritten abzuarbeiten, bis das Ende des Lebenszykluses erreicht ist. Als Nebeneffekt dieser Reise durch den Lebenszyklus führt Maven eine Reihe von Standard-Plugin-Goals aus, diese erledigen Arbeiten wie z.B. kompilieren oder dem Erstellen eines JAR-Archives.

Das 'Killer-Feature' von Maven im Vergleich zu Ant (und Hauptgrund zur Umstellung für uns) ist die Möglichkeit, Abhängigkeiten zu definieren und diese automatisch auflösen zu lassen. Am Beispiel des ImmoTools sieht dies wie folgt aus.

Abhängigkeitsbaum des ImmoTools, erzeugt mit Maven & Netbeans

dependencies.png (93.79 KiB) 778-mal betrachtet

Bisher war es nötig, die zahlreichen verwendeten Bibliotheken von Hand zu zu pflegen.

1. Maven kann diese sehr aufwändige Prozedur erleichtern, indem Abhängigkeiten (sowie transitive Abhängigkeiten) automatisch aufgelöst werden.
2. Maven kann Versionskonflikte in den Abhängigkeiten feststellen.
3. Im Falle, dass eine verwendete Bibliothek von den Entwicklern aktualisiert wurde, kann diese Änderung mit geringfügigen Anpassungen in das Projekt integriert werden. Alle aktualisierten Bibliotheken werden automatisch von einem Maven-Server heruntergeladen und müssen nicht mehr von Hand auf den Webseiten der Entwickler herausgesucht, heruntergeladen, entpackt und integriert werden.

Die Umstellung von Ant auf Maven ist bereits weitestgehend abgeschlossen. Grundsätzlich sind die neuen Maven-Projekte ordnungsgemäß kompilierbar und ausführbar. Nur noch ein paar Detailfragen sind zu klären (z.B. eventuell die automatische Erzeugung von Installationspaketen etc.).


Was machen wir mit der gewonnenen Zeit?

Mit den vorgenommenen Änderungen soll nun endlich die Entwicklung von ImmoTool 1.0 aktiv beginnen. Bisher haben wir nur 'nebenbei' verschiedene technische Konzepte ausprobiert, aber noch nicht aktiv mit der Entwicklung beginnen können. Wie die Entwicklungsarbeit genau stattfinden wird, werden wir in den kommenden Tagen in einer weiteren Mitteilung für alle Anwender dokumentieren.

[Andreas Rudolph]

Seit der ersten Veröffentlichung des ImmoTools im Mai 2009 haben wir den Anwendern die Netzwerkfähigkeit des Programmes in Aussicht gestellt. Im Laufe der Zeit kamen immer wieder berechtigte Wünsche / Änderungen / Problemstellungen hinzu, sodass der Zeitplan zur Veröffentlichung der Netzwerkfähigkeit in regelmäßigen Abständen verschoben werden musste.

Mit unserer perfektionistischen Veranlagung könnten wir das Programm wohl noch bis zur Version 0.9.99 weiter entwickeln, ohne jemals mit der Netzwerkfähigkeit begonnen zu haben. Auch wenn es schwer fällt, muss früher oder später ein 'Schlusstrich' mit Versionsstrang 0.9.x gezogen werden. Mit den nächsten Veröffentlichungen des ImmoTools soll genau dies forciert werden.

Die alltägliche Entwicklungsarbeit findet an Version 1.0 statt.

• Die im Bug-Tracker für Version 0.9.12 geplanten Änderungen werden zuerst in Version 1.0 programmiert und dann entsprechend 'zurückportiert'.
• Diese Prozedur ist geringfügig aufwändiger. Ich sehe aber den Vorteil, dass wir uns damit selbst zur aktiven Entwicklung von ImmoTool 1.0 'zwingen' und es nicht regelmäßig verschieben müssen. Manchmal muss man sich einfach selbst zu seinem Glück zwingen.

Aus dieser Vorgehensweise folgt im Umkehrschluss: ImmoTool 0.9.12 wird vorraussichtlich die letzte Veröffentlichung im '0.9.x'-Versionsstrang sein.

Die Arbeit an ImmoTool 1.0 hat bereits begonnen.

Mit Umstellung der Entwicklungsabläufe wurde mittlerweile bereits mit der Entwicklung des ImmoTool-Servers begonnen.

Da wir nicht jedes 'Rad' neu erfinden können / wollen, haben wir uns entschieden den ImmoTool-Server mit Hilfe der Servlet-Technologie umzusetzen. Der ImmoTool-Server wird gemeinsam mit Jetty vorkonfiguriert von uns ausgeliefert werden. Dies hat verschiedene interessante Vorteile:

• Die ImmoTool-Datenbank kann auch ohne Jetty in bestehende Server-Infrastrukturen integriert werden, welche die Servlet-Technologie unterstützen. Verbreitet sind z.B. Tomcat, JBoss, Websphere, etc. Wer keinen solchen Server in Verwendung hat, bekommt mit dem ausgelieferten Jetty eine schlanke Komplettlösung an die Hand gegeben.
• Auf die ImmoTool-Datenbank kann mit Hilfe eines Web-Browsers zugegriffen werden. Es wäre zukünftig denkbar auf dieser Grundlage z.B. ein Web-Interface zur Verwaltung von Immobilien / Kundendaten zu entwickeln, das als Alternative zum ImmoTool-Client verwendet werden kann.

Unsere Tests mit Jetty und der neuen Version 1.4 der eXist-Datenbank liefen nahezu problemlos ab. Grundlegend funktioniert der ImmoTool-Server bereits. Momentan erweitern wir das ImmoTool entsprechend, dass Einzel- & Mehrplatz-Projekte verwaltet werden können. An dieser Stelle hat sich die Umstellung der Entwicklungsabläufe von Ant auf Maven bereits mehr als bezahlt gemacht.

Mein persönliches Fazit: Es geht voran - und das mit größeren Schritten als gedacht.

[Andreas Rudolph]

Wie bereits in der letzten Entwicklernotiz angekündigt wurde, haben wir mit der Entwicklung von Netzwerk- und Mehrbenutzerfähigkeit begonnen. Im Folgenden möchten wir über den aktuellen Entwicklungsstand berichten.


Der ImmoTool-Server funktioniert bereits weitestgehend

Mit der Einrichtung von Jetty inkl. einiger Servlets, die von den eXist-Entwicklern bereitgestellt wurden, konnte mit relativ geringem Aufwand der 'ImmoTool-Server' entwickelt werden.

Sobald der 'ImmoTool-Server' gestartet wurde, kann man darauf mit einem normalen Web-Browser zugreifen. Das Ergebnis wird ungefähr wie folgt aussehen:

Administration des Servers via Web-Browser

dev_networking_01.jpg (67.82 KiB) 614-mal betrachtet

Der Server stellt eine XML-RPC-Schnittstelle bereit, über welche externe Programme (z.B. ImmoTool) auf die Datenbank zugreifen kann.


Das Hilfsprogramm zur Administration des ImmoTool-Servers

Allgemein wäre es möglich, die Datenbank komplett über den Web-Browser zu administrieren. Auf Grund verschiedener Problemstellungen haben wir uns aber für den Anfang dazu entschlossen, ein zusätzliches Hilfsprogramm zur Datenbank-Administration zu entwickeln.

Administration des Servers via Admin-Programm

dev_networking_02.jpg (34.04 KiB) 614-mal betrachtet

Der Vorteil dieses Programmes besteht darin, dass es auch für 'Einzelplatz-Projekte' verwendet werden kann. Im Falle eines Datenbankproblems, bei dem das ImmoTool eventuell nicht mehr korrekt startet, können z.B. Daten gesichert werden ohne das ImmoTool starten zu müssen.

Mit Hilfe der XML-RPC-Schnittstelle kann das Admin-Programm eine Verbindung zum 'ImmoTool-Server' aufbauen. Wenn man sich als Administrator anmeldet, können die Einträge in der Datenbank verwaltet werden.


Verwaltung der Benutzerzugänge

Der Administrator kann beliebig viele Benutzerkonten erzeugen, mit denen eine Anmeldung auf der Datenbank ermöglicht wird. Ein Datenbank-Benutzer hat einen eindeutigen Login-Namen, ein Zugangspasswort und kann ggf. auf Benutzergruppen zugeordnet werden.

Verwaltung der Benutzer

dev_networking_03.jpg (32.5 KiB) 614-mal betrachtet

Darüber hinaus können weitere Personendaten erfasst werden, die der Benutzer auch nachträglich selbst korrigieren kann.

Personendaten zum Benutzer erfassen

dev_networking_04.jpg (38.63 KiB) 614-mal betrachtet

Verwaltung der Projekte

Die Datenbank des ImmoTool-Servers kann beliebig viele Projekte parallel verwalten. Jedes Projekt muss eine eindeutige Bezeichnung haben.

Verwaltung der Projekte

dev_networking_05.jpg (26.85 KiB) 614-mal betrachtet

Zu jedem Projekt in der Datenbank können verschiedene Firmendaten erfasst werden. Diese Firmendaten können nur von Administratoren bearbeitet werden. Eine nachträgliche Korrektur dieser Daten muss nicht zwingend über das Admin-Programm erfolgen und ist auch weiterhin via ImmoTool möglich.

Firmendaten zum Projekt erfassen

dev_networking_06.jpg (39.37 KiB) 614-mal betrachtet

Die erfassten Benutzer können nach Bedarf auf die jeweiligen Projekte zugeordnet werden. So ist es denkbar, dass ein Benutzer auf Projekt A zugreifen darf, jedoch nicht auf Projekt B.

Zuordnung von Benutzern zu einem Projekt

dev_networking_07.jpg (23.49 KiB) 614-mal betrachtet

Automatische Erzeugung der Datenstrukturen im Hintergrund

Gemäß der erzeugten Projekte / Benutzer erzeugt das Administrationsprogramm automatisch die nötigen Datenstrukturen in der Datenbank.

Automatisch erzeugte Ordnerstrukturen in der Datenbank

dev_networking_08.jpg (54.01 KiB) 614-mal betrachtet

Im Vergleich zum ImmoTool 0.9.x war es hier leider nötig, die Ordnerstruktur nochmal komplett neu zu konzipieren. Wir haben uns dabei grundlegend an den Unix- / Linux- Ordnerstrukturen orientiert.


Anbindung des ImmoTool-Servers im ImmoTool

Beim Erzeugen eines neuen Projektes hat der Anwender in Zukunft die Wahl zwischen Einzelplatz- & Mehrplatz-Projekten.

Einrichtung der Serveranbindung im ImmoTool

dev_networking_09.jpg (41.45 KiB) 614-mal betrachtet

Der Administrator des 'ImmoTool-Servers' stellt dem Anwender / Mitarbeiter die nötigen Zugangsdaten zur Verfügung. Der Mitarbeiter kann sich daraufhin am Server anmelden. Die Firmendaten werden automatisch vom Server ermittelt und müssen in diesem Falle nicht erneut eingegeben werden.


Wie geht es weiter?

Im nächsten Schritt werden wir das ImmoTool von vorn bis hinten auf die neuen Anforderungen der Netzwerk- & Mehrbenutzerfähigkeit hin testen. Die bestehenden Quelltexte müssen geprüft und ggf. angepasst werden. Aufgrund der Umstellungen in den Datenstrukturen wird dies an vielen Stellen nötig sein.

Desweiteren sind noch ein paar interessante Problemstellungen offen.

• Der Add-On-Mechanismus wird unter Umständen bei Mehrbenutzer-Systemen umgestellt. Eventuell wird es nötig, dass der Administrator des 'ImmoTool-Servers' die Add-Ons für die Anwender zur Verwendung freigeben muss.
• Um sicherzustellen, dass alle Anwender die gleichen Versionen eines Add-Ons verwenden, sollten die Aktualisierungen eventuell vom 'ImmoTool-Server' (an Stelle des OpenEstate-Aktualisierungsservers) heruntergeladen werden, nachdem der Administrator die Aktualisierung geprüft und freigegeben hat.
• Die neue Version 1.4 der eXist-Datenbank stellt Grundfunktionen zur Versionierung der XML-Dokumente zur Verfügung. So wäre es möglich, die vorgenommenen Änderungen an einer Immobilie dauerhaft zu speichern und diese ggf. auf eine frühere Version zurückzuführen. Ob wir diese Funktion in das ImmoTool implementieren werden, ist noch nicht abschließend geklärt.

Mein persönliches Fazit: Die Grundlagenarbeit für ImmoTool 1.0 ist geschafft - nun folgt die Detailarbeit.

[Andreas Rudolph]

Neben den bekannten Änderungen wird es bei ImmoTool 1.0 auch verschiedene Umstellungen 'unter der Haube' geben, von denen man als Anwender auf den ersten Blick nichts mitbekommen wird. An dieser Stelle möchte ich zwei erwähnenswerte Beispiele benennen.

(1) Umstellung der Arbeitsabläufe für die Erstellung von Handbüchern / Dokumentationen

Mit der Einführung des OpenEstate-Wikis haben wir vor mehreren Monaten bereits begonnen, das Handbuch an einer zentralen Stelle zu verwalten. Das Problem dabei ist, dass diese Änderungen zwar online verfügbar sind, aber das 'Offline-Handbuch' im ImmoTool weiterhin separat gepflegt werden muss. Eine Synchronisation mit dem Wiki ist zwar denkbar, wäre aber sehr umständlich in das existierende Hilfesystem (JavaHelp) zu integrieren.

Aus diesem Grund haben wir uns entschlossen, die Erfassung des Handbuches auf DocBook-XML umzustellen. Aus einer verfassten DocBook-XML-Datei kann das Handbuch mit sehr geringem Aufwand in verschiedenen Zielformaten erzeugt werden. Derzeit planen wir:

(a) Ein HTML-Handbuch, dass sich auf mehrere Seiten verteilt. Dies ist zukünftig unserer 'Online-Handbuch' und ersetzt das Handbuch im Wiki.
(b) Ein PDF-Handbuch, dass man sich bei Bedarf ausdrucken kann.
(c) Ein JavaHelp-Handbuch, dass als zusätzliches Add-On in das ImmoTool integriert werden kann. Wenn das Add-On nicht aktiviert ist, öffnet das ImmoTool das 'Online-Handbuch' im Web-Browser.

Damit ist erstmals sichergestellt, dass Online- & Offline-Handbuch jederzeit synchron sind und der Pflegeaufwand für die verschiedenen Formate reduziert sich auf das absolute Minimum. Eigentlich schade, dass wir diesen Schritt nicht schon früher gegangen sind.

(2) Umstellung des Addon-Systems im ImmoTool

Der Addon-Mechanismus ist ein wichtiger Grundbestandteil des ImmoTools. Auf Grundlage dieses Ansatzes haben wir uns damals entschieden, ein eigenes Plugin-System zu entwickeln. Dieser Mechanismus funktioniert im Kleinen sehr gut, stößt an verschiedenen Stellen aber an seine Grenzen (z.B. keine Abhängigkeiten von Addons zueinander definierbar, keine Prüfung auf Versions-Konflikte zwischen den Addons, kein einheitlicher 'Extension-Mechanismus' für Entwickler etc.) und sollte deshalb unbedingt überdacht werden.

Wir haben uns in dieser Frage entschlossen, den Addon-Mechanismus des ImmoTools auf das Java Plugin Framework (kurz JPF) umzustellen. Dies hat verschiedene Vorteile:

(a) Eine ähnlich mächtige Eigenentwicklung kann viele Probleme mit sich bringen. Dynamisches 'Classloading' ist keine Freude in Java. Wenn es offene & etablierte Lösungen wie JPF gibt, kann uns dies viel Zeit (bei der Entwicklung) & Nerven (bei der Fehleranalyse) sparen.
(b) Erweiterungen werden in JPF präzise durch 'Extensions' und 'Extension Points' definiert (ähnlich zum Addon-System von Eclipse). Diese einheitliche Vorgehensweise wird es anderen Entwicklern erleichtern, eigene Addons für das ImmoTool zu entwickeln.
(c) Da wir uns weitestgehend an den Vorgaben von JPF orientieren, müssen für Addon-Entwickler keine längeren Dokumentationen verfasst werden. Die meisten Dokumentationen sind bereits auf der JPF-Webseite zu finden.

Die bestehenden Addons müssen für die Umstellung auf JPF nur geringfügig umprogrammiert werden. Es wird aber verständlicherweise nicht möglich sein, ein Addon aus ImmoTool 0.9.x mit ImmoTool 1.x zu verwenden oder andersherum.

[Andreas Rudolph]

So langsam neigt sich der Monat seinem Ende zu. Gemäß unserer bisheriger Planungen, sollte die Beta-Version des netzwerkfähigen ImmoTools in diesem Zeitraum veröffentlicht werden.

Da wir uns bei der Entwicklungsarbeit etwas ausführlicher mit dem AdminTool (dem zukünftigen Hilfsprogramm zur Administration einer ImmoTool-Datenbank) und dem neuen Plugin-Framework beschäftigt haben, werden wir die geplante Veröffentlichung der Beta-Version nicht halten können. Auch wenn das grundlegende Gerüst für Netzwerkfähigkeit / Mehrbenutzerfähigkeit bereits auf unseren Testsystemen funktioniert, sind noch verschiedene Anpassungen & Nacharbeiten am Programm nötig. Es ist davon auszugehen, dass noch ca. 1 bis 2 Wochen ins Land gehen werden, bis wir die Beta-Version 'auf die Öffentlichkeit loslassen' können.

Neben den Weiterentwicklungen werden wir in den kommenden Tagen die Version 0.9.12.2 veröffentlichen, welche diverse Fehler korrigiert und Verbesserungen in das Programm integriert. Eine genaue Übersicht der Änderungen finden Sie wie gehabt im Bug-Tracker.

[Andreas Rudolph]

Da sich mittlerweile auch der Juli so langsam seinem Ende zuneigt und wir die Beta-Version noch immer nicht veröffentlicht haben, möchte ich im Folgenden mal ein Lebenszeichen geben und kurz über den aktuellen Entwicklungsstand berichten.

• Die Programmierung zur Netzwerkfähigkeit ist nahezu vollständig abgeschlossen. Das bereits in früheren Ankündigungen vorgestellte Modell, den 'ImmoTool-Server' in einem Jetty-Server zu betreiben, funktioniert erfreulich unkompliziert - dank der erstklassigen Vorarbeit der eXist-Entwickler.
• Das Hilfsprogramm zur Datenbank-Administration (kurz AdminTool, siehe hier) wurde nochmal komplett neu entwickelt und wurde ebenfalls in das neue Plugin-Framework (JPF) integriert. Auch das Administrationsprogramm kann damit durch Add-Ons erweitert werden.
• Die Programmierungen für das Mehrbenutzer-System sind weitestgehend abgeschlossen. Mit Hilfe des AdminTools können beliebig viele Benutzer erzeugt und einem Projekt zugeordnet werden. Dabei können verschiedene Rechte vergeben werden.
  
  

  

  Benutzer-Rechte im AdminTool bearbeiten

  admin-roles.png (33.33 KiB) 139-mal betrachtet

  
  
• Wenn ein Benutzer das ImmoTool startet und ein Mehrplatz-Projekt öffnet, öffnet sich ein Fenster zur Anmeldung mit Passwort.
  
  

  

  Anmeldung in einem Mehrbenutzer-Projekt

  remote-login.png (8.39 KiB) 139-mal betrachtet

  
  
• Nach erfolgter Anmeldung kann kann ein Benutzer in einem Mehrplatz-Projekt zusätzlich seine Profildaten und das Passwort bei Bedarf ändern.
  
  

  

  Zugangsdaten im Mehrbenutzer-Projekt bearbeiten

  remote-account.png (59.92 KiB) 139-mal betrachtet

  
  
• In einem Mehrplatz-Projekt hat jedes Objekt in der Datenbank (Immobilien, Adressen, Mitarbeiter, etc.) einen Besitzer. Dies ermöglicht eine Zugriffssteuerung. So kann ein Benutzer z.B. festlegen, ob auch andere Benutzer seine Immobilie lesen oder bearbeiten dürfen. Die Verfahrensweise ist ähnlich zu den Dateisystemen unter Windows & Unix.
  
  

  

  Zugriff auf Objekte in Mehrbenutzer-Projekten

  remote-access.png (39.42 KiB) 139-mal betrachtet

  
  
• Individuelle Programm-Einstellungen eines Benutzers (z.B. aktivierte Plugins, abonnierte RSS-Feeds, etc.) werden permanent in der Datenbank gespeichert. Egal von welchem Arbeitsplatz der Benutzer sich am ImmoTool-Server anmeldet, diese Einstellungen sind überall einheitlich verfügbar.

Um eine Aussicht auf die Veröffentlichung der ersten Beta-Version zu geben, fasse ich im folgenden die verschiedene Probleme zusammen, die vorher noch erledigt werden müssen.

• Umstellung der Immobilienablage in der Datenbank (siehe Bug-Tracker)
• Fertigstellung des Add-Ons zur Darstellung des Offline-Handbuches (siehe Bug-Tracker)
• Zusammenstellung der ImmoTool-Servers zu einem ZIP-Archiv (eventuell EXE-Installer)
• Kleinere Überarbeitung auf der Web-Oberfläche des ImmoTool-Servers (wenn man mit dem Web-Browser auf den ImmoTool-Server zugreift)
• Erstellung der nötigen Anleitungen, um den ImmoTool-Server in Betrieb zu nehmen und ein Mehrplatz-Projekt einzurichten.
• Ein ausführlicher Vorab-Test, inkl. der nötigen Korrekturen.
• Veröffentlichung von ImmoTool 1.0-Beta

Optimistisch, wie wir veranlagt sind, rechnen wir mit keinen größeren Problemen mehr. Damit sollte die Beta-Version nun (hoffentlich) im Laufe des Augusts veröffentlicht werden können. Wir entschuldigen uns bei allen wartenden Anwendern für die Verzögerungen und hoffen, dies mit einem tollen Endprodukt entschädigen zu können.