Anleitung zur Erstellung von Open-Source Software

Programme, Applikationen, Anwendungen. Was tun, wenn die App spinnt?
Antworten
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Anleitung zur Erstellung von Open-Source Software

Beitrag von Bernd Malessa »

Ziel dieses Projektes ist es eine Anleitung zur Entwicklung gemeinnütziger Software-Projekte zu erstellen und einen entsprechenden Support anzubieten.
Dabei soll u.a. die Vorgehensweise anhand der Umsetzung eines oder mehrerer nicht trivialer Softwareprojekte hier umfangreich dokumentiert werden.

Dieses Projekt richtet sich daher an Mitmenschen, die Interesse an der Softwareentwicklung haben und gerne bei der Entwicklung von gemeinnütziger OpenSource-Software mitarbeiten möchten. Die zu entwickelnde Software ist dabei erst einmal nicht festgelegt. Projektvorschläge sind daher willkommen. Mitmachen dürfen alle, die so etwas gerne einmal ausprobieren möchten. Ein wenig Programmierkenntnisse in einer objektorientierten Sprache bzw. das Interesse eine solche zu erlernen wären natürlich hilfreich, sind aber keine Voraussetzung für die Mitarbeit. In jedem Softwareprojekt werden unterschiedlichste Skills benötigt und Programmieren ist nur einer davon. Das Schreiben der Projektdokumentation, die Anforderungsanalyse und das Testen sind letztlich genauso wichtig für den Erfolg eines Softwareprojekt.

Die zu erstellende Software sollte einem gemeinnützigen Zweck dienen und die erstellten Programme und Dokumentationen sollen nach der Fertigstellung unter einer noch festzulegenden OpenSource-Lizenz im Internet zum Download angeboten werden. Das Ziel ist es dabei nicht, die ultimativ beste Software zu entwickeln, sondern über den Weg dahin ein Verständnis zubekommen, wie viele Aspekte bei der Erstellung einer nicht trivialen Software zu berücksichtigen sind. Insofern gilt hier das Motto: Der Weg ist das Ziel.

Was wir hier nicht machen wollen, ist das Ausfechten irgendwelcher "Glaubenskriege" nach dem Motto, diese oder jene Programmiersprache, Entwicklungsumgebung, Datenbank etc. ist die einzig wahre Lösung und alles andere ist Schrott. Ich habe in den letzten 25 Jahren in der IT der Telekom an vielen verschiedenen IT-Projekten mitgearbeitet und wenn ich dabei eines gelernt habe, dann die Tatsache, das viele Wege nach Rom führen. Für die ersten Erfahrungen ist es daher nicht so wichtig die ultimativ beste Lösung zu bauen, sondern immer wiederkehrender Anfängerfehler zu vermeiden.

Sobald sich die passende Projektaufgabe gefunden hat, würde ich gerne den komplette Lebenszyklus eines Softwareprojekt über Anforderungsanalyse, Festlegung der Systemarchitektur, Entwicklung des internen Softwaredesign, die Programmierung, das Testen etc. inklusiver der dazugehörenden Projektdokumentation anhand etablierter Best-Practices aus meiner Sicht erläutern und dokumentieren. Diskussionen und Verbesserungsvorschläge sind dabei natürlich jederzeit willkommen. Bei Bedarf wird dafür gesorgt, dass ein interaktiver Austausch über Telefon- oder Videokonferenz ermöglicht wird. Wie sich das dann genau entwickeln wird, kann ich heute auch noch nicht sagen. Das ist dann auch abhängig von der Anzahl der Interessenten und deren Präferenzen. Heute stehen im Internet so viele kostenlose Informationen und Videos über Open-Source Softwareenwicklung zur Verfügung, dass es sicher vermessen wäre zu glauben, dass man im Rahmen einer ehrenamtlichen Tätigkeit noch etwas Neues oder Besseres anbieten kann, aber manchmal ist es gerade der persönliche Austausch und das konkrete eigene Projekt, welches dazu beiträgt, überhaupt einen guten Einstieg in dieses Thema zu finden.

Sofern sich kein Projektvorschlag aus der Community findet, würde ich gerne diesen hier machen:
Ein "Tool zur Erstellung einer beamtenrechtlichen Versorgungsauskunft".

Das ist insofern ganz praktisch, weil hier aus technischer Sicht erstmal alle Möglichkeiten offen bleiben, d.h. es kann sowohl als Einzelplatzsystem, aber auch als Webanwendung umgesetzt werden. Außerdem sind die fachlichen Anforderungen an dieses Projekt sicher mindestens genauso komplex, wie die Implementierung dieser Anforderungen in eine Software. Als langjähriger Beamter bei der Telekom, der sehr lange auf die entsprechende Versorgungsauskunft der Bundesanstalt für Post- und Telekommunikation warten musste, weis ich auch, dass dafür ein Bedarf bei den noch im Arbeitsleben stehenden Kolleginnen und Kollegen besteht. Aufgrund der sehr komplexen fachlichen Anforderungen, wäre es natürlich super, wenn sich hier auch Interessenten finden, die Ihr fachlichen Know-Know aus dem Beamten- und Versorgungsrecht einbringen möchten. Insbesondere bei der fachlichen Anforderungsanalyse und dem Testen wäre dieses Know-How sehr wertvoll.

Ich denke, das soll es zur Vorstellung des Projekt erstmal gewesen sein. Jeder der an diesem Projekt mitarbeiten möchte, kann sich gerne melden!
Bin mal gespannt auf die Rückmeldungen.
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Re: Anleitung zur Erstellung von Open-Source Software

Beitrag von Bernd Malessa »

Da aus der Community bisher noch kein Vorschlag für eine individuelle Softwarelösung eingegangen sind, werden ich erst einmal mit dem von mir vorgeschlagenen "Tool zur Berechnung einer beamtenrechtlichen Versorgungsauskunft" weitermachen.

Bevor wir mit der Projektarbeit starten, benötigen wir aber noch eine Art Fahrplan, eine Methodik bzw. ein Vorgehensmodell nach dem wir arbeiten möchten.
Wie soll die Projektarbeit organisiert und strukturiert werden? Welche relevanten Parteien (Stackholder) sind involviert und müssen berücksichtigt werden?
Welche Aufgaben stehen überhaupt an und in welcher Reihenfolge sollten die Arbeiten an diesen Aufgaben sinnvoll gestartet werden.

In der Vergangenheit (ca. bis zum Beginn des sog. Internetzeitalter in den 1990-2000er Jahre) war das vorherrschende Modell für die Vorgehensweise in der Softwareentwicklung das sog. Wasserfallmodell. Bei diesem Modell wurde alle Phasen des Software-Entwicklungsprozess sequentiell nacheinander abgearbeitet. Das von allen relevanten Projekt-Stackholdern abgenommene Endergebnis der vorgelagerte Projekt-Phase wurde benötigt, um mit der nächsten Projekt-Phase starten zu können. Konkret konnte mit der Implementierung einer Software erst dann gestartet werden, wenn alle fachlichen, technischen Anforderungen an das Projekt vollständig erfasst waren und eine entsprechend Architektur und das Design der Software-Lösung vollständig spezifiziert und von den relevanten Stackholdern abgenommen wurde. An den Übergänge der jeweiligen Entwicklungsphasen wurde sog. Milesstone-Reviews durchgeführt. Erst wenn diese Reviews erfolgreich durchlaufen wurden, konnte mit der nächsten Projektphase gestartet werden.

Die folgende Grafik gibt eine Übersicht über die im Wasserfall-Model vorhandenen Projekt-Phasen.

download/file.php?mode=view&id=34

Da Nachteil des Wasserfall-Model wird relativ schnell klar. Spätere Erweiterungen oder Änderungen in den fachlichen Anforderungen können nur mit hohen Aufwand aufgenommen werden und erfordern immer einen Rücksprung in eine eigentlich bereits abgeschlossene Phase des Entwicklungsprozess. Fehler in der fachlichen Spezifikation werden z.B. erst sehr spät in der Test-Phase erkannt. Solche Änderungen in den Anforderungen werden dann sehr aufwändig und damit sehr kostenintensiv.
Die verschiedenen am Projekt beteiligten Personen oder Gruppen arbeiten in diesem Model oft nicht miteinander, sondern gegeneinander. Das "über den Zaun werfen" von Projekt-Dokumenten hat noch nie gut funktioniert. Natürlich benötigt jedes Projekt auch eine bestimmte Ordnung im Entwicklungsprozess, aber im Wasserfall-Modell fehlt jeglicher Freiraum, um flexibel mit sich ändernden Projektanforderungen umgehen zu können. Diese Nachteile haben dazu geführt, dass dieses Vorgehensmodell dahingehend erweitert wurde, mehr Flexibilität zuzulassen. Ab ca. den 2000er Jahren wurde das Wasserfall-Prozessmodel mehr oder weniger ersetzt durch eine Vorgehensweise, die mehr Flexibilität im Entwicklungsprozess ermöglichen sollte. Es gab eine größere Anzahl unterschiedlicher Prozessmodelle, die aber im Kern alle dasselbe Ziel adressierten. Die Softwareentwicklung sollte flexibler gegenüber sich ändernden Anforderungen während der Entwicklung des Softwareprodukt werden.
Ein Vertreter dieser neuen Vorgehensweise war der "Rational Unified Process". Parallel dazu entwickelte sich die UML (Unified Modelling Language). Mit der UML wurde es nun möglich die Dokumentation um standardisierte grafische Modelle wie z.B. UseCase-Diagrammen, Klassen-Diagrammen, Komponenten-Diagramme etc. zu erweitern. Dies ermöglicht eine bessere Kommunikation zwischen fachlichen und technischen Stackholdern, da sich viele Sachverhalte grafisch deutlich aussagekräftiger darstellen lassen, als dies durch reine Textbeschreibungen möglich wäre. Außerdem sah der RUP ein iteratives Vorgehen bei der Umsetzung vor. Ein Projekt wurde in mehrere Iteration aufgeteilt, wobei dann für jede Iteration die verschiedenen Phasen wie Anforderungsanalyse, Implementierung, Test etc. wie im Wasserfall abgearbeitet wurden. Durch diese Vorgehensweise konnten relativ einfach noch nachträglich neue oder geänderte Anforderungen für eine spätere Iteration berücksichtigt werden. Eine Trennung zwischen den eher fachlich und technisch am Projekt arbeitenden Stackholdern war in diesem Vorgehnsmodell jedoch immer noch stark ausgeprägt.

Die folgende Grafik gibt einen Überblick über die im "Rational Unified Process" (RUP) unterschiedenen Disziplinen und Phasen des Software-Entwicklungsprozess.

download/file.php?mode=view&id=35

Heutzutage ist eine möglichst kurze "Time to Market" die erste Priorität vieler Softwareprojekte. Es wird nicht mehr so viel Wert auf eine vollständige und widerspruchsfreie Dokumentation gelegt, bevor man mit der Implementierung überhaupt erst anfängt, sondern man möchte möglichst schnell mit einem "Minimum Viable Product" einen Mehrwert schaffen. Fachseite und Entwicklung arbeiten nicht getrennt wie im Wasserfallmodell oder im "Rational Unified Process", sondern in einem Team zusammen, um die Entwicklungszeit zu minimieren. Auch die Kundenseite ist bereits in dieser frühen Phase beteiligt und muss daher nicht so lange warten, bis sie zum ersten mal das fertige Produkt zu Gesicht bekommt. Neue Anforderungen oder Änderungswünsche werden in einem sog. "Backlog" gesammelt, priorisiert und dann in sog. "Sprints" umgesetzt. Das Vorgehensmodel für diese Methodik nennt sich "Scrum-Modell". Es werden in relativ kurzen Iteration (meistens innerhalb einer Zeitspanne von 2-4 Wochen) neue Programmversionen geplant, implementiert, getestet und dem Kunden bereitgestellt. Nicht der "Big Bang", sondern viele kleine Änderungen in kurzen Zeitabständen. Der Kunde bekommt nicht das eine große "Ding", sondern aus den Rückmeldungen der betroffenen Projekt-Stakeholder werden die Prioritäten festgelegt und die Iterationen geplant und der Projekt-Backlog wird so sukzessive abgearbeitet. Für jemanden, der viel Wert auf eine saubere Dokumentation und abgegrenzte Verantwortung legt, ist diese Vorgehensweise natürlich "gewöhnungsbedürftig", aber der wirtschaftliche Erfolg gibt dieser Vorgehensweise heute recht.

Auch hier eine kleine grafische Übersicht über die das SCRUM-Model

download/file.php?mode=view&id=36


Die meisten kommerziellen oder Open-Source Software-Projekte werden heute nach der SCRUM-Methodik geplant und umgesetzt.
Die o.g. Vorgehensweisen nach dem "Wasserfall-Model" oder nach dem "Rational Unified Process" kommen heute vor allem noch in sicherheitskritischen Bereichen zur Anwendung - dort wo nicht die "time to market", sondern eine saubere Dokumentation und eine klar abgegrenzte Verantwortung einen hohen Stellenwert eingeräumt bekommt.

Für unsere geplantes Projekt bietet sich natürlich auch eher die SCRUM-Methodik an. Alles was uns so an fachlichen und technischen Anforderungen einfällt, werden wir zunächst in einem Projekt-Backlog sammeln. Wenn wir dann eine erste Übersicht über die umzusetzenden Anforderungen gewonnen haben, werden wir uns die Prioritäten dieser Anforderungen ansehen und dann versuchen diese Anforderungen in Iteration, die jeweils ca 2-4 Wochen dauern sollten, umzusetzen. In diesen Iterationen werden dann die fachlichen Anforderungen (wie sich bspw. aus dem BeamtVG ergeben) festgelegt, programmiert, getestet und in die sukzessive wachsende Anwendung integriert.
Parallel dazu müssen wir natürlich auch sowas wie eine Softwarearchitektur und eine Komponenten-Design entwickeln, das eine gewisse Stabilität gewährleistet und in der Lage ist, Änderungen und Erweiterungen zuzulassen. Das ist eben die Kunst in der Softwareentwicklung. Eine Software so zu bauen, das sie einerseits stabil läuft, aber andererseits auch erweiterbar und wartbar bleibt. Funktionale vs. nicht funktionale Anforderungen gleichwertig zu berücksichtigen. Das ist dann aber ein anderes Thema und dazu werden ich dann irgendwann auch noch mal einen separaten Beitrag hier in diesem Forum schreiben.
Dateianhänge
Scrum_Framework.jpg
RUP Phase Model.png
1-wasserfall-.png
Schulschrat
Beiträge: 4
Registriert: 20.09.2017

Vereinsheim-Software

Beitrag von Schulschrat »

Hallo Bernd Malessa,
was Du da schreibst klingt ja sehr expertös :-) Vielleicht klinke ich mich mit meinem Problemchen hier ein: ich benötige für unseren Vereinsheim ein Programm, mit dem ich die laufenden Kosten usw. etwas komfortabler als mit meiner bisherigen Excel-Tabelle erfassen kann und dabei sollen auch Verbrauchsberechnungen, Prognosen usw. möglich sein.
Folgende Parameter sollten anfangs detailliert erfasst werden können: Strom (2 Zähler, Tagesverbrauch usw.) , Wasser , Heizung (Tagesverbrauch, Brennerlaufzeit, und einige weitere). Die Werte werden jedoch nur sporadisch erfasst, müssen also teilweise interpoliert werden. Es sollen dann Vergleichsdaten (wie war das im letzten Juni?) und Prognosen (wann steigt der Verbrauch so, dass die Brennerdüse getauscht werden muss?) und viele weitere Ideen, die man mit berechnen könnte. Ich verfolge Deine Ausführungen erst einmal mit Interesse weiter und kommen dann gerne mit präzisen Fragen, wenn es recht ist :-)
Gruß vom Schulschrat (alles für den Verein :-)
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Re: Vereinssoftware

Beitrag von Bernd Malessa »

Hallo Schulschrat,

vielen Dank für die Rückmeldung. Als ich mein Projekt beim Prot-In Support e.V. für meine ehrenamtliche Tätigkeit im Engagierter Ruhestand vorgestellt habe,
habe ich meine Idee u.a mit folgenden Sätzen beschrieben:
...
In der Vereinsarbeit oder bei gemeinnützigen Organisationen besteht gelegentlich der Wunsch, für wiederkehrende manuelle Tätigkeiten eine Softwarelösung einzusetzen.
Die Rede ist hier nicht vom Aufbau einer Homepage im Internet oder dem Einsatz einer softwarebasierten Mitgliederverwaltung oder ähnlichem, sondern von einer individuellen Problemstellung, für die selbst nach ausreichender Recherche keine frei verfügbare bzw. kostengünstige Softwarelösung gefunden werden kann.

Hier stellt sich also die Frage: Weitermachen wie bisher oder selber eine Softwarelösung für dieses Problem entwickeln.

Häufig ist zumindest ein Basiswissen über Programmierung bereits vorhanden. Zudem existieren unzählige Tutorials in Form von Videos und Dokumente für alle möglichen Programmiersprachen, Frameworks und sonstige Entwicklertools im Internet, z.B. auf Youtube. Sobald die Problemstellung aber etwas komplexer wird, fehlt oft das Wissen, wie man so eine individuelle Softwarelösung überhaupt angehen und umsetzen könnte. Die reine Betrachtung unter technischen Aspekten, wie sie in den verfügbaren Tutorials vermittelt wird, ist in aller Regel nicht ausreichend, um eine individuelle Software so zu entwickeln, dass sie auch noch erweiterbar und wartbar bleibt. Es gilt also die fachlichen Anforderungen und die notwendigen technischen Skills für die Umsetzung so zusammenzuführen, dass allgemein anerkannte Standards und BestPractices berücksichtigt werden.
...

Das passt ja ziemlich gut auf deine Anfrage. Insofern freue ich mich wirklich, wenn ich dir ein paar Anregungen oder Hinweise geben kann, die dir bei deinem Vorhaben hilfreich sein können. In den nächsten Wochen plane ich so etwas wie eine wöchentliche Kolumne zu den verschieden Themenbereichen im Softwareentwicklungprozess wie z.B. fachliche Anforderungsanalyse, Festlegung des Datenmodel etc. aber auf zum Thema Programmierung, wobei ich da natürlich nicht jede Programmiersprache abdecken kann. Meine Beispiele und das von mir erwähnte ausgewählte Projekt "Versorgungsauskunftrechner" werde ich in der Programmiersprache Java implementieren.
Das ist eine objektorientierte Programmiersprache, für die sich im Internet tonnenweise gute Dokumentation und Tutorials findet.

Du kannst aber auch gerne direkt mit deinen Fragen auf mich zukommen. Wenn es eher allgemeine Fragen oder Anmerkungen sind, direkt als Antwort auf einen meiner Beiträge oder als "Persönliche Nachricht", wenn es sich um eine spezielle Frage zu deinem geplanten Projekt handelt.

Wenn du möchtest, kannst du für dein geplantes Projekt aber auch gerne ein eigenes Thema im Software-Forum des Bürgerportal neu anlegen. Evtl. interessiert diese Lösung ja auch noch weitere Leute, die etwas ähnliches suchen. Dann könnten wir gemeinsam versuchen, dein Projekt, neben dem "Versorgungsauskunft-Rechner", als Musterbeispiel für ein gemeinnütziges Software-Projekt zu nehmen. Die weiteren Überlegungen und Arbeitsschritte dazu würden wir dann ebenfalls im Bürgerportal dokumentieren.

Viele Grüße
Bernd
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Fachliche Anforderungsanalyse für das OpenSource Software-Tool "Versorgungsauskunft-Rechner"

Beitrag von Bernd Malessa »

Nachdem ich in der letzten Woche etwas über das allgemeine Vorgehensmodel in der Softwareentwicklung geschrieben habe, möchte ich heute langsam in die Projektarbeit für den "Versorgungsauskunft-Rechner" einsteigen und mich dem Thema "Fachliche Anforderungsanalyse" zuwenden.
Egal, nach welchem Vorgehensmodel wir vorgehen - das Wasserfall-Modell, ein Objektorientiertes Vorgehensmodell (z.B. Rational Unified Process) oder nach einem agilen Vorgehensmodell auf SCRUM-Basis. Bei allen fängt der Entwicklungsprozess mit der fachlichen Anforderungsanalyse an. Ich hatte ja schon im letzten Beitrag angedeutet, dass sich für unser geplantes Projekt eher ein leichtgewichtiger Prozess eignet und deshalb werden ich auch gar nicht erst versuchen eine 100% vollständige, konsistente und fehlerfreie Anforderungsanalyse durchzuführen. Außerdem fehlt dazu momentan auch der Gegenpart oder Auftraggeber, der dann für das Ergebnis dieser Anforderungsanalyse eine Art Abnahme durchführen könnte. Ziel ist es deshalb, hier den Umfang und die Grenze für das beabsichtigte Softwareprojekt festzulegen. Das hilft auch dabei, ein wenig Ordnung in unsere Gedanken zu bringen. Das sollte man generell nicht unterschätzen, wie wichtig es ist, seine Ideen für das beabsichtigte Projekt dann auch tatsächlich mal aufzuschreiben und nicht nur im Kopf mit diesen Ideen herum zu jonglieren. Vieles wird erst dann wirklich klar, wenn man sich zwingt diese Ideen, Anforderungen und Rahmenbedingungen aufzuschreiben und parallel dazu versucht, das ein oder andere UML-Diagramm zu erstellen.

Ziel der fachlichen Anforderungsanalyse ist es, die Anforderungen an das zu entwickelnde System zu ermitteln, zu strukturieren und zu prüfen.
Das Ergebnis einer Anforderungsanalyse wird dann meistens in einem Lastenheft dokumentiert. Bei einer agilen Softwareentwicklung, wie in unserem Projekt, ist das Ziel der Anforderungsanalyse die Erstellung eines Anforderungs-Backlog. Dabei kann es sich um funktionale, aber auch um nichtfunktionale Anforderungen handeln. Eine funktionale Anforderung wäre beispielsweise: das Tool soll in der Lage sein, den Ruhegehaltssatz und/oder den Versorgungsabschlag auf der Basis der eingegebenen Daten zu errechnen. Eine nichtfunktionale Anforderung könnte beispielsweise sein, dass dieses Tool über ein Web-Frontend im Browser zu bedienen sein soll.
Das Ziel der Anforderungsanalyse ist es also, eine Spezifikation als Grundlage für den anschließenden Systementwurf und die Realisierung der Software zu erstellen.

Wir können und sollten bereits auch in dieser frühen Phase des Entwicklungsprozess nichtfunktionale Anforderungen betrachten, aber wir beschäftigen uns hier noch nicht mit irgendwelchen technischen Restriktionen, z.B. der Frage, welche Datenbank, welche Programmiersprache oder welches Framework für die Implementierung einzusetzen ist. Die Beschreibung der fachlichen Anforderungsfälle erfolgt komplett frei von irgendwelchen technischen Restriktionen.

Wie werden nun die fachlichen Anforderungen ermittelt und welcher Input wird dafür benötigt?
Für den "Versorgungsauskunft-Rechner" ergeben sich viele Anforderungen in erster Linie aus den gesetzlich festgelegten Bestimmungen, die sich zum Beispiel im Beamtenversorgungsgesetz und im Bundesbeamtengesetz finden. Alleine mit dem Gesetzestext kommt man aber auch nicht weit, zumindest dann nicht, wenn man kein Jurist ist und/oder mit diesem Thema täglich zu tun hat. Wir benötigen noch weiteren Input in Form von Ausführungsbestimmungen, Beiträgen, Fachbüchern und anderer verfügbarer Dokumentation zu diesem Thema. Alles was wir dazu in die Hände bekommen und uns beim Verständnis für diese fachliche Domäne weiterhilft ist geeignet. Das können z.B. auch themenbezogene Foren im Internet (z.B. beamtentalk.de) sein oder Interviews/Unterhaltungen mit fachlich kompetenten Mitmenschen, die uns hier dabei helfen, diese Materie zu verstehen. Hilfreich ist auch die Einsicht in Versorgungsauskünfte, wie sie von der Bundesanstalt für Post- und Telekommunikation (BAnstPT) erstellt werden. Je mehr Infos und Einsicht in die Materie wir bekommen, umso konkreter und vollständiger können wir die Anforderungen an unser geplantes Softwareprogramm beschreiben und dokumentieren.

In den wenigsten Fällen ist man ja der erste, der die Idee hat, eine Softwarelösung für ein bestimmtes Problem zu erstellen.
Es lohnt sich daher auf jeden Fall auch, zunächst einmal zu recherchieren, was es denn bereits alles an verfügbaren Lösungen gibt. Eventuell existiert ja bereits eine Lösung die alle unsere Anforderungen erfüllt und wir können uns die Arbeit komplett ersparen. Für das von mir angedachte Tool habe ich mehrere kostenfreie Lösungen gefunden. Richtig zufrieden bin ich damit aber nicht. Meiner Meinung nach bilden alle vorhandenen kostenfreie Lösungen nur die einfachsten Sachverhalte ab. Es wird z.B. bei der Erfassung von ruhegehaltsfähigen Zeiten keine Unterscheidung dahingehend gemacht, ob die erfassten Zeiten generell als ruhegehaltsfähig anerkannt werden
müssen (z.B. § 6,8,9 BeamtVG) oder ob die eingegebenen Zeiten als SOLL-Zeiten (§ 10 BeamtVG) oder KANN-Zeiten (§12 BeamtVG) zu betrachten sind. Der Wechsel zwischen Teilzeit- und Vollzeitbeschäftigung wird bei der Erfassung der ruhegehaltsfähigen Zeiten ebenfalls meistens nicht unterstützt. Dasselbe gilt für Kindererziehungszeiten.

Hier sind mal die Links zu zwei kostenfreien Versorgungsauskunft-Rechnern, die ich im Internet gefunden habe:
  • n-heydorn.de/pensionsrechner.html
  • hilfreiche-tools.de/pensionsrechner
Es existieren natürlich auch professionelle Lösungen, an die wir mit unseren Möglichkeiten vermutlich nicht herankommen werden. Die Lizenzkosten für solche professionellen Programme dürften jedoch für die allermeisten Interessierten das Budget sprengen und insofern versuchen wir hier den Mittelweg zu finden. Wir möchten etwas Besseres bauen, als das was kostenfrei verfügbar ist, sind uns aber durchaus bewusst, das die Materie so komplex ist, das wir vermutlich nicht das Niveau und den Feature-Umfang einer hochpreisigen, professionellen Software erreichen werden.

Hier ist mal die Adresse für so eine kostenpflichtige Software:
  • ams-software.de/html/rgbausk.html


Bis jetzt war es ja noch ziemlich schwammig und wenig konkret. Jetzt werden wir aber konkreter und schreiben unsere fachliche Anforderungen an die zu erstellende Software auf:
  • Das Programm soll eine Versorgungsauskunft erstellen, aus der für den Anwender nachvollziehbar ersichtlich wird, wie diese Berechnung durchgeführt wurde.
    Dafür orientieren wir uns an den von der BAnstPT erstellten Versorgungsauskünften. D.h. wir möchte die Berechnung der folgenden Beträge bzw. Faktoren für
    den Anwender nachvollziehbar erstellen
    - Berechnung der Höhe des Ruhegehalt
    - Aufstellung und Berechnung der ruhegehaltsfähige Zeiten
    - Berechnung eines ggf. vorzunehmenden Versorgungsabschlag
    - Berechnung des ungekürzten Kindererzeihungszuschlag
    - ggf. durchtzuführende Vergleichsberechnungen bei Besitzstandsregelungen

  • Der Antragsteller einer Versorgungsauskunft soll die Möglichkeit haben, dem System die folgenden, für eine Versorgungsauskunft, erforderlichen Angaben zu übergeben:
    • Welche Art des Ruhestand wird beantragt (Ruhestand wg. gesetzlicher Altersgrenze, Antrags-Ruhestand, Engagierter Ruhestand, Vorruhestand (Altersteilzeit), Dienstunfähigkeit, Dienstunfall)
    • Datum der Begründung des Beamtenverhältnis
    • Datum des geplantes Eintritt in den Ruhestand
    • Anzuwendendes Recht (wir unterstützen zunächst nur Versorgungsauskünfte für Bundesbeamte; länder-, kommunal- oder sonstige körperschaftsspezifische Regelungen werden zunächst nicht berücksicht, können aber evtl. in einer Folgeversion unterstützt werden)
    • Welche Altersgrenze soll zur Anwendung kommen (Gesetzliche Altersgrenze oder eine besondere Altersgrenze)
    • Bestand das Beamtenverhältnis am 31.12.1991 und am 01.01.1992 (ggf. ist eine Vergleichsberechnung gem. §85 BeamtVG erforderlich)
    • Name und Vorname des Antragsteller (optional)
    • Geburtsdatum des Antragsteller
    • Ist ggf. eine Schwerbehinderung vorhanden und muss diese in der Versorgungsauskunft berücksichtigt werden?
    • Besoldungsdaten des Antragsteller: Laufbahngruppe, Besoldungsgruppe, Besoldungsstufe, Ruhegehaltsfähige Amtszulage, sonstige ruhegehaltsfähigen Zulagen
    • Art des Familienzuschlag
    • Die Auflistung aller für die Versorgungsauskunft relevanten ruhegehaltsfähigen Zeiten
      Davon eine Zeitperiode, die als Start-Datum das Datum der Begründung des BeaV (siehe oben) hat. Diese Zeitart muss nach $6 BeamtVG immer als ruhegehaltsfähig anerkannt werden.
      ggf (Wehr- oder Zivildienstzeiten (§8-9 BeamtVG)
      ggf. weiter Soll-Zeiten (§10)
      ggf. weiter Kann-Zeiten (§12)
    • Kindererziehungszeiten. Dabei muss unterschieden werden zwischen Kindererziehungszeiten für
      - Kinder, die vor dem 01.01.1992 geboren wurden und
      - Kindern, die nach dem 31.12.1991 geboren wurden
  • Unser geplantes Tool soll es ermöglichen, alle zulässigen Arten von ruhegehaltsfähige Zeitabschnitte zu erfassen. Dabei möchten wir diese Zeiten so konkret wie möglich unterscheiden, z.B. Zeiten im Beamtenverhältnis, Ausbildungszeiten, Zeiten im Vorbereitungsdienst, Wehrpflicht- oder Zivildienst etc. Grundsätzlich muss unterschieden werden können zwischen Zeiten, die grds. immer anzuerkennen sind und solchen Zeiten, die im BeamtVG als ruhegehaltsfähige Kann- oder Soll-Zeiten definiert sind.
    Die Zeitperioden haben ein Start und ein Enddatum. Die Anzahl der Tage in diesem Zeitraum soll vom Programm automatisch ermittelt werden. Da diese Zeiten nicht immer vollständig als ruhegehaltsfähig anerkannt werden (z.B. werden Studienzeiten nur bis zu einem bestimmten Umfang anerkannt), soll die Möglichkeit bestehen, die vom Programm berechnete Anzahl an ruhegehaltsfähigen Tagen manuell zu ändern. Teilzeitbeschäftigung innerhalb einer Zeitperiode soll über einer Faktor abgebildet werden. Per Default hat dieser Faktor für eine Vollzeitbeschäftigung den Wert 1,0. Bei Teilzeit von z.B. 50% der regulären Arbeitszeit soll die Möglichkeit bestehen diesen Faktor manuell auf 0,5 zu ändern. Es soll auch die Möglichkeit bereitgestellt werden, zu einer erfassten Zeitperiode einen Freitext zu erfassen, in dem detaillierter auf die Umstände eingegangen werden kann. Sofern diese Versorgungsauskunft dann später von einem fachkundigen Versorgungsservice geprüft wird, ist dies evtl. eine sehr hilfreiche Information.

    Die Liste der bisher bekannten relevanten ruhegehaltsfähigen Zeitarten findet sich in der folgenden Aufstellung:
    • Zeiten, die grds. als ruhegehaltsfähig anerkannt werden

      Beschäftigungszeiten im Dienst eines öffentlich-rechtlichen Dienstherrn im Beamtenverhältnis (§ 6 BeamtVG)
      Ausbildung im Vorbereitungsdienst (Beamter auf Widerruf)
      Wehrdienst- oder Zivildienstzeiten (§8 und §9 BeamtVG)
      Altersteilzeit (§ 93 BBG)
    • Sog. SOLL-Zeiten

      Zeiten im Angestelltenverhältnis im öffentlichen Dienst (§10 BeamtVG)
    • Sog. KANN-Zeiten

      Sonstige Zeiten (§ 11 BeamtVG)
      Vorgeschriebene oder Förderliche Ausbildungs- und Studienzeiten (§12 BeamtVG)
    • Sonderregelungen für Zeiten, die mit einem höheren Faktor anerkannt werden können

      Aufbauhilfe in den neuen Bundesländern
      Verwendung in Ländern mit gesundheitsschädlichem Klima (§ 13 BeamtVG)
  • Wir möchten in unserem Programm so viel wie möglich an Validierungen durchführen. Die User-Eingaben sollen auf korrekte Formate (z.B. gültiges Datumsformat, nummerische Werte etc.) geprüft werden. Es sollen aber auch alle erforderlicher fachlichen Validierungen durchgeführt werden. Es macht beispielsweise keinen Sinn eine Berechnung für eine Berechnung des Ruhegehalt wegen altersbedingten Eintritt in den Ruhestand zu berechnen, wenn der Antragsteller zu dem Zeitpunkt noch nicht die gesetzliche Altersgrenze erreicht hat. Daher müssen wir für jede Art des Ruhestand (Altersbedingter Ruhestand, Antrags-Ruhestand, Engagierter Ruhestand, Dienstunfähigkeit, Dienstunfall) die entsprechenden gesetzlichen Bestimmungen ermitteln und diese in unseren dokumentierten Anforderungen festhalten. Für jede Versorgungsauskunft muss eine ruhegehaltsfähige Zeitperiode erfasst werden, deren Start-Datum dem Datum der Begründung des Beamtenverhältnis entspricht.
  • Unsere geplante Software soll auch die Möglichkeit anbieten, die vom Anwender erfassten Daten zu speichern und diese Daten später erneut einzulesen. Damit hätten wir auf die Möglichkeit, diese Daten später noch einmal zu ändern oder von einer anderen Person überprüfen zu lassen.
  • Im Fall eines Ruhestand wegen Dienstunfähigkeit oder Dienstunfall soll die Zurechnungszeit gem. §13 BeamtVG berechnet werden.
  • Das System soll die Möglichkeit anbieten, die erstellte Versorgungsauskunft formatiert auszudrucken.
  • Wünschenswert wäre auch, in dem Programm kontextbezogenen Hilfetext anzuzeigen. Bei der Erfassung der ruhegehaltfähigen Zeiten könnte
    beispielsweise der entsprechende Gesetzestext oder andere kontextspezifische Erläuterungen angezeigt werden.
  • Das System soll zumindest 3 verschiedene User-Rollen unterscheiden können und ein Berechtigungskonzept für die Rollen Antragsteller, Administrator und Support-Mitarbeiter abbilden
  • Ein Anwender in die Rolle "Antragsteller" benötigt keine Authentifizierung am System. Diese Rolle kann die für die Versorgungsauskunft relevanten Daten im System erfassen und auf der Basis dieser Daten vom System eine Versorgungsauskunft errechnen lassen. Diese Versorgungsauskunft wird dem Antragsteller angezeigt und kann von ihm dann gespeichert und ausgedruckt werden.
  • Ein Anwender in der Rolle "Support-Mitarbeiter" benötigt eine Authentifizierung am System (Login mit UserId und Password). Diese Rolle hat dieselben Rechte wie die Rolle Antragsteller. Zusätzlich hat diese Rolle die Möglichkeit bereits erstellte Versorgungsauskünfte erneut einzulesen und zu bearbeiten. Zusätzlich kann diese Rolle erläuternden Freitext an den ruhegehaltsfähigen Zeiten der Versorgungsauskunft erfassen. Weiterhin soll die Möglichkeit bestehen, das Freitext direkt an der vom System generierten Versorgungsauskunft erfasst und gespeichert werden kann. Damit soll die Möglichkeiten geschaffen werden, solche Information, die sich nicht über einen Algorithmus errechnen lassen im Kontext der jeweiligen Versorgungsauskunft zu speichern.
  • Die Rolle Administrator benötigt ebenfalls eine Authentifizierung am System. Diese Rolle soll die Möglichkeit haben, die im System hinterlegten besoldungs- und versorgungsrelevanten Daten zu bearbeiten oder neu zu erfassen. Dazu gehören beispielsweise die zum Zeitpunkt des Ruhestandseintrittsdatum gültige Besoldungstabelle, aber auch andere Parameter, die sich regelmäßig ändern, z.B. der aktuelle Rentenwert, welcher für die Berechnung des Kindererziehungszuschlag benötigt wird.


Ebenso wichtig wie eine möglichst präzise Beschreibung der geplanten Geschäftsfälle, die vom System unterstützt werden sollen ist es, die Grenzen unserer geplanten Software festzulegen und dazu gehört auch zu dokumentieren, was in unserem Projekt "out of scope" ist. Da fallen mir spontan die folgenden Aspekte ein:
  • Keine Netto-Berechnung (ohne Steuer, Sozialabgaben), d.h. wir berechnen nur die Brutto-Versorgungsbezüge, Steuerklasse und Sozialabgaben etc. bleiben außen vor
  • Die Anrechnung von gesetzlichen Renten oder anderen Einkommensarten wird wir in unserem Programm ebenfalls nicht berücksichtigen. Dies würde die Komplexität enorm erhöhen. Kompetente Ansprechpartner könnten diese Anrechnungsberechnung dann außerhalb des Programms vornehmen. Wir werden in der vom System generierten Vorsorgungsauskunft aber einen entsprechenden Hinweis aufnehmen und anzeigen, dass weitere Einkommensarten ggf. zu einer Kürzung der Versorgungsbezüge führen können.
  • Wir beabsichtigen in unserer geplanten Software den Kindererziehungszuschlag zu berechnen. Aufgrund der Komplexität bei der Berechnung etwaiger Kürzungen des Kindererziehungszuschlag werden wir in unseren Versorgungsauskünften allerdings nur den generellen Hinweis aufnehmen, das der Kindererziehungszuschlag gekürzt oder komplett entfallen kann, wenn während der Kindererziehungszeit eine Voll- oder Teilzeitbeschäftigung vorgelegen hat oder wenn für diese Kindererziehungszeiten in der gesetzlichen Rentenversicherung Ansprüche vorhanden sind.

Nachdem wir alle funktionalen und nichtfunktionalen Anforderungen so präzise wie möglich aufgeschrieben haben, werden wir versuchen diese in Cluster zusammenzufassen und in unserem Projekt-Backlog aufzunehmen. Für diese Zwecke verwendet man entweder spezielle Programme (z.B. mal nach "Tool Anforderungsmanagement Requirements engeneering o.ä." googlen) oder findet seine eigene Organisation in Form von geeigneten Listen, Dokumenten, Ablagen etc.
In der Telekom-IT haben wir für das Anforderungs-Backlog die (kostenpflichtige) Software Programm "JIRA" verwendet. Damit hat man dann noch viel mehr Möglichkeiten die Anforderungen zu strukturieren.

An diesem Punkt kann man auch mal damit anfangen und versuchen, den Stand der fachlichen Anforderungsanalyse in Form von UML-Diagrammen abzubilden. Dafür eignen sich insbesondere UML UseCase- und Interaktions- bzw. Sequenz-Diagramme. Ich füge hier mal ein paar Beispiele für solche UML-Diagramme ein, welche die o.g. Ausführungen nochmal grafisch zusammenfassen. Die Diagramme wurden mit dem kostenfreien OpenSource-Tool ArgoUML (argouml.de.softonic.com) erstellt:

Übersicht über die im System bekannten bzw. unterstützten Aktoren und UseCases
download/file.php?mode=view&id=41

Detaillierte Sicht auf den UseCases "Versorgungsauskunft berechnen"
download/file.php?mode=view&id=42

Interaktionsdiagram "Erstellung einer Versorgungsauskunft"
download/file.php?mode=view&id=40

Im Endergebnis sollte die fachliche Anforderungsanalyse zumindest so weit durchgeführt werden, dass wir auf dieser Basis unseren ersten Softwareentwurf angehen können.
Wir sind uns jetzt darüber im klaren, dass wir sicher noch nicht 100% aller Anforderungen berücksichtigt haben, aber der grobe Rahmen ist jetzt klar. Wer die Liste der Anforderungen noch erweitern oder konkretisieren möchte ist gerne eingeladen entsprechende Vorschläge hier einzubringen.

Nächste Woche geht es dann weiter. Dann werden wir uns damit beschäftigen, wie unsere Entwicklungsumgebung aussehen soll. Welche Tools wir dafür benötigen und wie unserer erster technische Entwurf aussehen könnte. Evtl. macht es auf jetzt schon Sinn über einen GUI-Prototypen nachzudenken, um ein Verständnis dafür zu bekommen, wie die für die Berechnung der Versorgungsauskunft relevanten Daten vom Antragsteller dem System bereitgestellt werden.
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Aufbau der Entwicklungsumgebung für das Projekt "Versorgungsauskunft-Rechner"

Beitrag von Bernd Malessa »

Nachdem ich in der letzen Woche einen längeren Beitrag zum Thema "Fachliche Anforderungsanalyse" geschrieben habe, möchte ich diese Woche in die praktischen
Tätigkeiten der Projektarbeit überleiten. Letztlich besteht das Ziel eines jeden Softwareprojekts darin, eine lauffähige Software zu erstellen, die den Anforderungen der sie
nutzenden User erfüllt. Um eine Software zu erstellen, benötigen wir aber eine ganze Anzahl unterschiedlichster Tools, die ich heute mal kurz vorstellen möchte.

Die Welt der IT so vielfältig, dass es natürlich eine Rolle spielt, in welchem Kontext man das Projekt startet. Zum Beispiel, welche technischen Skills die am Projekt beteiligten Personen mitbringen oder welche Trends momentan gerade besonders angesagt sind. Je nachdem welche Art von Software erstellt werden soll, eignen sich bestimmte Technologien dafür besonders oder im Gegenteil überhaupt nicht und so weiter.

Da wir hier über Open-Source Software reden und wir keinen Auftragsgeber haben, der unsere Arbeit bezahlt und dessen Vorstellungen bzw. Vorgaben wir berücksichtigen müssen, sind wir glücklicherweise erst einmal frei in der Wahl unserer Mittel. Deshalb bin ich jetzt mal so frei und entscheide einzig und alleine aufgrund meiner persönlichen Präferenzen und auf der Basis meiner vorhandenen Skills, wie die Software-Entwicklungsumgebung für das geplante Projekt "Versorgungsauskunft-Rechner" aussehen soll.

Bei dem Vorhaben eine nicht triviale Software zu bauen, sind zunächst einmal die folgenden Fragen zu beantworten:

In welcher Programmiersprache wollen wir das Projekt umsetzen. Eignet sich eine Programmiersprache für unser Vorhaben besonders oder überhaupt nicht und welche Gründe können wir dafür anführen. Wenn wir uns für eine Programmiersprache entschieden haben, stellt sich die nächste Frage. Programmieren wir alles mit einem einfachen Editor und kompilieren unseren erstellten Sourcecode mit den Core-Utilities der jeweiligen Programmiersprache (z.B. mit dem Java-Compiler des Java Development Kit in einer DOS-Console oder Unix-Shell) oder nutzen wir dafür eine integrierte Entwicklungsumgebung (IDE) in der alle erforderliche Tools enthalten sind. Welche kostenfreien Tools existieren und wo bekommen wir die her? Wir benötigen für unsere erstellte Artefakte (Sourcecode, Dokumentationen etc) auch so etwas wie eine Versionskontrolle. Das dient uns zur Sicherung unseres Projektfortschritts und dazu im Fehlerfall auf einen lauffähigen Stand zurücksetzen zu können. Sobald mehrere Personen im Projekt mitarbeiten, wird eine gemeinsame Ablage für die im Projekt erstellten Artefakte benötigt. Für diesen Zweck ist es eigentlich immer zwingend notwendig, sich mit der Frage bzgl. der Versionskontrolle frühzeitig auseinander zu setzen. Wenn wir noch weitere Anforderungen für die Dokumentation oder Anforderungsanalyse haben, benötigen wir ggf. noch ein Tool zur UML-Modellierungs und evtl. auch noch ein Bildbearbeitungsprogramm, falls wir Bilder, Icons o.ä. grafische Elemente benötigen, die wir selber erstellen oder anpassen müssen.

Hier wäre mal die von mir präferierte Liste der Tools, die ich für die Umsetzung des Vorhaben "Versorgungsauskunft-Rechner" einsetzen möchte:

Programmiersprache: Java (eine aktuelle Version des Java Development Kit, mindestens jedoch JDK 8)
Entwicklungsumgebung : Eclipse IDE for Java Developers (mindestens Version: 2019-12 (4.14.0))
UML-Tool: Argo-UML
Bildbearbeitung: GIMP
Versionsverwaltung: Aktuelle GIT-Version (mindestens Version 2.9.0)

Was sind die Gründe für meine Entscheidung?

Einzig und alleine meine persönlichen Erfahrungen und Kenntnisse. Mit einer anderen Konstellation an "Tools und Toys" kann man sicher dasselbe Ziel erreichen, aber die Welt der IT ist so vielfältig, dass es unmöglich ist, sich in alle Facetten und Tools der Softwareentwicklung so einzuarbeiten und auszukennen, wie es manchmal wünschenswert wäre. Jeder erarbeitet sich mit der Zeit seinen eigenen Werkzeugkasten und kennt sich dann damit einigermaßen aus. Der Spruch "Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel." hat natürlich auch seine Berechtigung, aber irgendwann muss man ja auch mal anfangen und dann spricht aus meiner Sicht auch nichts dagegen, erst einmal mit dem anzufangen, was man zur Verfügung hat. Solange man für gute Argumente offen bleibt ist das ok. Genauso unsinnig wie der Gedanken, alles immer genau so zu tun, weil es schon immer so gemacht wurde, ist die Vorgehensweise immer das letzte "hippe Ding" zu nehmen, nur weil das jetzt in allen einschlägigen Internetforen und Fachzeitschriften gepusht und hochgelobt wird. Oft ist das letztlich auch nur "alter Wein in neuen Schläuchen". Was sich dann wirklich mal an neuen Ideen und Konzepten durchsetzt ist auch nicht immer sofort zu erkennen. Manchmal braucht man neben der immer hilfreichen Erfahrung auch etwas Glück, um bei seinen Entscheidungen - worauf konzentriere ich mich, wo arbeite ich mich intensiv ein, welche Tools verwende ich etc - auf das richtige Pferd zu setzen.

Es gibt ein paar Quellen, an denen man sich bei seiner Entscheidungen orientieren kann, wenn man z.B. vor der Frage steht, in welche Programmiersprache man seine Zeit und Energie investieren sollte, wenn man beabsichtigt eine neue Programmiersprache zu erlernen. Eine Quelle für Inspiration ist der TIOBE-Index (siehe auch https://de.wikipedia.org/wiki/TIOBE-Index). Dort bekommt man zumindest mal einen guten Anhaltspunkt, welche Programmiersprachen besonders relevant sind. Manche Sprachen eignen sich für bestimmte Anwendungsgebiete besser als andere. Die Anforderungen bei der Entwicklung von Web-Anwendungen, App-Entwicklung oder maschinennahe Softwareentwicklung von Gerätetreibern unterscheiden sich einfach deutlich voneinander und deshalb existieren eben auch unterschiedliche Programmiersprachen. Manche Sprachen haben eine extrem große Community, die mit kostenloser Dokumentation, Programmierbeispiele, YouTube-Videos etc. den Einstieg leichter machen. Andere Programmiersprachen sind extrem mächtig hinsichtlich ihres Feature-Umfang, sind aber auch extrem aufwändig zu erlernen und/oder nur für einen kleinen spezifischen Anwendungsbereich geeignet, mit entsprechend kleiner Community, die aushelfen kann, wenn's mal nicht weitergeht.

Ich möchte für die Entwicklung des geplanten "Versorgungsauskunft-Rechner" jedenfalls auf die o.g. Technologien und Tools zurückgreifen. Die Programmiersprache Java in einer halbwegs aktuellen Version (mindestens Java 8) und als Entwicklungsumgebung die Eclipse IDE. Beides ist als OpenSource kostenfrei verfügbar. Die Links zum Download füge ich hier mal ein:

Java: https://openjdk.java.net/
Eclipse: https://www.eclipse.org/downloads/

Eine leistungsfähige IDE ist schon alleine deshalb erforderlich, weil erst damit auch das Debugging und Refactoring ermöglicht wird. Die Entwicklung alleine mit einem Editor und mit den Command-Line-Tools des Java SDK ist vielleicht noch für einfaches Ausprobieren ausreichend, aber wenn das Projekt komplexer wird, dann verliert man da einfach zu schnell den Überblick.

Für das Thema UML-Modellierung habe ich im letzten Beitrag ja schon das Tool "Argo-UML" empfohlen.
Für die Bildbearbeitung eignet sich als kostenfreies Tool "GIMP".

Für die Versionsverwaltung möchte ich gerne GIT (https://git-scm.com/downloads) verwenden. Das ist ebenfalls OpenSource. Die Frage, ob wir die Versionsverwaltung lediglich auf dem eigenen, lokalen Rechner einsetzen oder dafür ein zentrales Repository anlegen, auf das alle Projektbeteiligte zugreifen können, lasse ich erstmal offen. Für die ersten Arbeiten kann man zunächst mit einer lokalen Lösung anfangen, auch um erste Erfahrungen im Umgang mit diesem Tool zu erlangen. Je weiter das Projekt fortschreitet, desto wichtiger wird es, dass alle Projektbeteiligten einen Zugriff auf den aktuellen Projektstand bekommen. Spätestens dann benötigen wir ein zentrales Repository für die Ablage unserer erstellten Software-Artefakte. Für die OpenSource-Projekte existieren im Internet kostenfreie Lösungen (z.B. Github) für die Versionsverwaltung und das Hosting von Softwareprojekten. Dazu dann später mal mehr in einem separaten Beitrag.

Auf der Basis dieser ausgewählten Tools und Technologien ist die nächste Aufgabe, die nun ansteht, die Entwicklung eines GUI-Prototypen. Aus den Ergebnissen der fachlichen Anforderungsanalyse und unter Zuhilfenahme der o.g. Tools sollte nun die nächste Aufgabe darin bestehen, einen GUI-Protoypen (GUI=Graphical User Interface) zu entwickeln. Sobald der fertig ist, hat man etwas vorliegen, an dem man sein Projekt anderen Interessierte gut vorstellen kann. Es macht schon ein Unterschied, ob man seine Ideen lediglich mit Textdokumenten oder Powerpoint-Folien einem Dritten vorstellt oder ob man ein Programm startet und anhand der graphischen Nutzerschnittstelle die verschiedenen UseCases demonstriert. Die Implementierung der Geschäftslogik wird in diesem GUI-Prototypen soweit wie möglich durch simulierte Werte oder Konstanten ersetzt. Wichtig ist, dem zukünftige Anwender mit diesem Prototypen die Ideen vorzustellen. Bereits hier gewinnt man im Feedback der zukünftigen Anwender wertvoller Erkenntnisse. Sofern erforderlich kann man diese neu gewonnenen Erkenntnisse dann noch in die weitere Projektplanung aufnehmen und das Anforderungsbacklog entsprechend erweitern. Vermutlich wird man bei der Entwicklung des GUI-Prototypen auch noch den einen oder anderen Mangel in seinen eigenen Annahmen aufdecken. Das ist auch völlig ok. Ich jedenfalls finde es sehr realistisch anzunehmen, dass man es nicht schaffen wird, in der vorangegangenen Anforderungsanalyse alle relevanten Aspekte aufzudecken und von Anfang an zu berücksichtigen. Das ist ja auch der Grund, warum heutzutage in der Softwareentwicklung, zumal in der OpenSource-Community", nicht mehr nach dem Wasserfall-Vorgehensmodel arbeitet, sondern weitgehend Methoden der "agilen Softwareentwicklung" einsetzt.

Das soll es dann für heute gewesen sein. Wer Vorschläge oder Ideen für den GUI-Prototypen hat, kann die gerne hier im Forum teilen. Meinetwegen auch handgefertigte Skizze, die mittels Foto in das Forum hochgeladen werden oder mir als persönliche Nachricht geschickt werden.
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

GUI-Protoyp für den Versorgungsauskunft-Rechner

Beitrag von Bernd Malessa »

Heute möchte ich die ersten Ergebnisse des GUI-Prototypen für den "Versorgungsauskunft-Rechner" anhand einiger Screenshots zeigen. Bevor ich dazu komme, möchte ich aber noch einige Worte über die zugrunde liegende Technik verlieren.

Jede Programmiersprache bzw. Programmierumgebung bringt ihre eigene Technologie für die Realisierung eines Graphical User Interface (GUI) mit.
In der Programmiersprache Java verwendet man für die Implementierung von sogenannten Rich-Client-Anwendungen häufig das bereits im JDK (Java Development Kit) bzw. JRE (Java Runtime Environment) mit ausgelieferte SWING-Framework. Ganz ähnlich funktioniert das "Standard Widget Toolkit (SWT)". Dieses Framework wurde ursprünglich von der Firma IBM entwickelt und ist heutzutage ebenfalls als OpenSource-Software kostenfrei verfügbar. Die GUI der für unser Projekt ausgewählten Entwicklungsumgebung, die Eclipse IDE, wurde beispielsweise mit dem SWT-Framework implementiert. Im Prinzip funktionieren beide Frameworks (SWING und SWT) relativ ähnlich. Der Featureumfang des SWT-Framework ist etwas umfangreicher und die erstellte GUI sieht meiner Meinung nach auch besser aus. Beim SWING-Framework erkennt man irgendwie immer sofort, das dieses Programm in Java programmiert wurde. Das ist beim SWT-Framework anders. Die SWT-Widgets (z.b. Button, Eingabefelder, Listen, Tabellen etc.) nutzen für das Rendering die Grafikschnittstelle des Betriebssystem und die damit erstellte GUI ist somit nicht von anderen nativen Applikationen zu unterscheiden. Da dieses Framework in der Eclipse-IDE sehr gut unterstützt wird und dafür auch eine große Community existiert, die mit kostenfreien Tutorials Unterstützung beim Erlernen liefert sowie User-Foren, die bei der Fehlersuche Hilfestellung geben können, habe ich das SWT-Framework für die Implementierung des GUI-Prototypen verwendet.

Ein weiteres GUI-Framework in der Java-Welt ist das modernere JavaFX. Dieses Framework ist allerdings nicht Bestandteil des JDK bzw. JRE, sondern muss separat heruntergeladen und eingebunden werden. Da ich bisher noch keinerlei Erfahrung mit JavaFX gemacht habe, werde ich mich in diesem Projekt damit nicht weiter befassen.

Für unseren geplanten GUI-Protoypen möchte ich vorschlagen, dass wir die Implementierung als sog. Rich-Client-Anwendung durchführen werden. Rich-Client-Anwendungen werden im Gegensatz zu Web-Anwendungen auf dem Rechner installiert, auf dem das Programm später zur Ausführung gebracht wird. Web-Anwendungen haben natürlich den Vorteil, dass sie nur einmal an zentraler Stelle auf einem im Netz zugänglichen Server installiert werden müssen und Änderungen in Form von Updates oder Fehlerbehebungen direkt allen Nutzern zur Verfügung gestellt werden. Der Umfang der für die Erstellung von Web-Anwendungen notwendigen technischen Skills ist meiner Meinung nach aber deutlich umfangreicher. Neben Kenntnissen in HTML, CSS, Javascript und evtl. noch dem ein oder anderen Web-Framework, benötigen wir auch noch einen Web- bzw. Application-Server im Netz, der auch entsprechend administriert werden muss. Alles in allem ist es zumindest für den Start einfacher, wenn wir die Implementierung des "Versorgungsauskunft-Rechner" zumindest für die erste Version als Rich-Client-Anwendung planen und umsetzen. Sofern wir weitere Versionen des Tools planen, kommen wir ggf. nochmal auf die Implementierung als Web-Anwendung zurück. Für den späteren Anwender ist es natürlich schon wesentlich angenehmer, wenn er die Anwendung direkt im Browser aufrufen kann und nicht erst dafür Sorge tragen muss, dass er ein Java-SDK oder Java-JRE in der richtigen Version auf seinen Rechner installieren muss, damit er unsere Applikation nutzen kann. Wenn wir es richtig hinbekommen, sollten wir später größere Anteile der Geschäftslogik 1:1 aus der Rich-Client-Anwendung in die Web-Anwendung übernehmen können und insgeheim spiele ich dieses Thema gedanklich auch schon durch. Als Stichworte nenne ich mal RCP (Rich Client Platform) und RAP (Remote Application Platform). Wen es jetzt schon interessiert, der kann mal danach googlen. Das sind Technologien, aus dem Eclipse-Umfeld (unsere IDE, die wir im Projekt nutzen) mit denen es ermöglicht wird, mit mehr oder weniger Aufwand, Rich-Client-Anwendungen automatisch in Web-Anwendungen zu transformieren. Bis wir allerdings irgendwann evtl. mal dahin kommen, haben wir aber noch viel Arbeit vor uns.

Die GUI-Entwicklung ist meiner Meinung nach relativ aufwändig zu erlernen und wenn man im Projekt die Möglichkeit hat, bietet es sich an, sich zu spezialisieren. Manche Leute fühlen sich eher in der Frontend-Entwicklung zuhause, anderen wiederum sagt das überhaupt nicht zu. In kleineren Projekten mit wenigen Mitarbeitern gelingt das aber leider eher selten. Wenn im Projekt für die Implementierung der Software mehr unterschiedliche Skills benötigt werden, als Mitarbeiter vorhanden sind, dann wird schon klar, dass man sich in allen Bereichen zumindest ein wenig auskennen sollte.

Bis man sich mit den Möglichkeiten und Eigenarten des eingesetzten GUI-Frameworks einigermaßen auskennt, wird vermutlich jeder, der sich darauf einlässt, die ein oder andere frustrierende Erfahrung machen. Der Umgang mit Layout-Manager, das Event-Handling, die Implementierung von Event-Listenern zwecks sauberer Trennung von GUI und Applikationslogik sind nicht trivial und erfordern etwas Geduld beim Erlernen. Als Hilfe kann man zum Einstieg auch sog. GUI-Builder verwenden. Damit ist sog. Rapid-Prototyping möglich. Window- oder GUI-Builder sind spezielle Tools mit denen man sich seine gewünschte grafischen Oberflächen (Fenster, Dialoge, Menus, Tabellen, Buttons etc) zusammenklicken kann. Hört sich erstmal super an, aber auch hier wird man schnell feststellen, das man letztlich doch verstehen muss, was der GUI-Builder da so automatisiert erstellt hat. Meine Erfahrung ist, dass man spätestens dann, wenn man versucht sein eigenes Problem anzugehen, nicht darum herumkommt, sich mit den Untiefen der GUI-Entwicklung und der dazu verwendeten Frameworks zu beschäftigen. In den ersten Tutorials sieht alles immer super easy aus, aber spätestens beim ersten eigenen Versuch seine individuelle GUI zu bauen, wird man feststellen, dass es doch nicht so einfach ist. Und dann haben wir über ergonomische und barrierefreie grafische Benutzerschnittstellen noch gar nicht angefangen zu sprechen.

Soviel zur Einleitung. Meine bisher erstellten GUI-Elemente möchte ich jetzt mal kurz vorstellen. Ausgehend von den in der Anforderungsanalyse gesammelten Anforderungen, habe ich mir überlegt, wie die GUI aussehen könnte, um eine Versorgungsauskunft zu berechnen und anzuzeigen bzw. auszudrucken.
Dafür benötigen wir von Anwender verschiedene Eingaben, die für die Berechnung der Versorgungsauskunft zwingend erforderlich sind. Wenn der Anwender alle Daten erfasst hat, sollte zunächst eine Validierung dieser Daten vorgenommen werden. Sofern die Validierung erfolgreich durchgeführt wurde, wird die Versorgungsauskunft vom System errechnet und diese Berechnung dem Anwender am Bildschirm in einer formatierten Darstellung angezeigt. Diese formatierte Darstellung orientiert sich dabei an den von der Bundesanstalt für Post und Telekommunikation (BAnstPT) ausgestellten Versorgungsauskünften.

Mein GUI-Prototyp für den "Versorgungsauskunft-Rechner" sieht wie folgt aus. Der Antragsteller gibt die für die Versorgungsauskunft relevanten Daten in drei verschiedenen Eingabemasken ein. Dies ist deshalb erforderlich, um die GUI nicht zu überfrachten und die Daten einigermaßen übersichtlich zu strukturieren.

Für die Berechnung sind folgenden Daten relevant:

Die sog. Grunddaten umfassen u.a. die Angaben zur Art des angestrebten Ruhestand, das Datum des Beginn des Ruhestands sowie alle für die Versorgungsberechnung relevanten persönlichen Daten des Antragsteller. Diese Daten werden in der Eingabemaske "Grunddaten" erfasst. Wie dies aussehen könnte, sieht man im folgenden Screenshot.
Erfassung der Grunddaten für eine Versorgugnsauskunft
Erfassung der Grunddaten für eine Versorgugnsauskunft

das Tool unterstützt die Berechnung einer Versorgugnsauskunft für die folgenden "Arten des Ruhestand".
Erfassung_Grunddaten_2.PNG

Fehlerhafte Validierung von Eingabedaten wird wie folgt angezeigt:
Validierung.PNG
Validierung.PNG (10.46 KiB) 473 mal betrachtet


Die Zusammenstellung der "ruhegehaltfähigen Zeiten" erfolgt auf einer separaten Eingabemaske. Die einzelnen Zeiträume werden in einer Tabellenstruktur erfasst. Die Art der "ruhegehaltsfähigen Zeit" kann aus einer Auswahlliste ausgewählt werden. Durch Angabe eines Faktor kann Vollzeit oder Teilzeitbeschäftigung während einer Zeitperiode abgebildet werden. Die Anzahl, der in einer Zeitperiode enthaltenen Kalendertage wird vom System automatisch berechnet. Im Normalfall sollte die Anzahl der Kalendertage mit der Anzahl der "ruhegehaltsfähigen Tage" übereinstimmen. Allerdings ist es durchaus möglich, das nicht die komplette Anzahl der Kalendertage als ruhegehaltsfähige Zeit anerkannt wird. Deshalb muss es möglich sein, die Anzahl der "ruhegehaltsfähigen Tage" manuell zu überschrieben, z.B. weil Studienzeiten nur bis zu einem bestimmten Anteil als ruhegehaltsfähig anerkannt werden.
Erfassung der ruhegehaltsfähigen Zeiten
Erfassung der ruhegehaltsfähigen Zeiten
Auswahlliste der ruhegehaltsfähigen Zeiten
Auswahlliste der ruhegehaltsfähigen Zeiten
Die Versorgungsauskunft soll gemäß den in der Anforderungsanalyse gesammelten fachlichen Anforderungen auch den (ungekürzten) )Kindererziehungszuschlag berechnen können. Für diesen Zweck existiert eine weitere Eingabemaske, in welcher die Kindererziehungszeiten erfasst werden können. Bei der Berechnung des Kindererziehungszuschlags wird grds. zwischen Kindern, die vor dem 01.01.1992 geboren wurden und solchen Kindern, die nach dem 31.12.1991 geboren wurden unterschieden. Dies ist in der Eingabemaske entsprechend berücksichtigt.
Erfassung der Kindererziehungszeiten
Erfassung der Kindererziehungszeiten
Aus diesen 3 verschieden Datenblöcken (Grunddaten, Zusammenstellung der ruhegehaltsfähigen Zeiten, Zusammenstellung der Kindererziehungszeiten) kann nun die Versorgungsauskunft berechnet werden. Wie diese Versorgungsauskunft aussehen könnten, kann man sich auf den folgenden Screenshots anschauen.
Versorgungsauskunft_Anzeige_1.PNG
Versorgugnsauskunft_Anzeige_2.PNG
Versorgungsauskunft_Anzeige_3.PNG

Es wäre natürlich auch wünschenswert, wenn man die erfassten Daten speichern könnte, damit man diese Daten und die darauf basierende Berechnung zu einem späteren Zeitpunkt noch einmal überarbeiten kann oder evtl. auch von fachkundiger Seite überprüfen lassen könnte. Für diese Zwecke werden in der GUI entsprechende Menu-Punkte eingebunden, die das Speichern und das erneute Einlesen vorher gespeicherter Daten ermöglicht.
Menupunkte zum Speichern und erneuten Einlesen der erfassten Daten
Menupunkte zum Speichern und erneuten Einlesen der erfassten Daten

Abschließend, sozusagen als Sahnehäubchen, wäre noch das Ausdruck der errechneten Versorgungsauskunft bzw. das Speichern in einer PDF-Datei wünschenswert. Idealerweise sollte die in der GUI angezeigte formatierte Versorgungsauskunft 1:1 als PDF-Datei abgespeichert werden können, um dann im Anschluss das PDF-Dokument auszudrucken.

Ich hoffe die eingebundenen Screenshots bringen die Idee rüber, die ich in diesem Projekt umsetzen möchte. Falls noch Verbesserungsvorschläge vorhanden sind, können diese gerne hier im Forum vorgetragen und diskutiert werden. Die nächsten Schritte werden jetzt wie folgt angegangen.

Der GUI-Prototyp wird jetzt Stück für Stück weiter ausgebaut und verfeinert. Ziel ist es, die im Prototyp investierte Arbeit soweit wie möglich zu nutzen und darauf aufbauend die endgültige Lösung zu entwickeln. Parallel dazu müssen wir uns dann auch langsam an die Entwicklung des sog. Anwendungskern heranwagen. Wenn wir nicht in unwartbaren "Spagetticode" landen wollen, dann ist dies die vielleicht anspruchsvollste Aufgabe. Durch die Bildung von fachlichen und technischen Softwarekomponenten und mit den Werkzeugen, die uns die objektorientierten Programmierung in der Programmiersprache Java liefert, werden wir versuchen eine saubere Trennung von fachlichen und technischen Aspekten in unserer geplanten Anwendung zu erreichen. Der sog. Anwendungskern sollte so weit es geht frei von technischen Restriktionen sein und möglichst durch sog. UnitTests automatisiert getestet werden können. Diese UnitTests werden dann eine große Hilfe sein, wenn wir im weiteren Projektfortschritt unsere Anwendung ausbauen und durch Refactoring-Massnahmen evtl. unseren bereits fertiggestellten Programmcode ändern oder umstrukturieren müssen. Durch die Testfälle habe wir dann jederzeit die Möglichkeit, die Lauffähigkeit und Funktionalität unserer Software sicherzustellen.

Das ist dann aber wieder ein neues Thema und wird dann in einem separaten Beitrag besprochen.
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Audruck der Versorgungsauskunft

Beitrag von Bernd Malessa »

In der fachlichen Anforderungsanalyse für das Projekt "Versorgungsauskunft-Rechner" wurde seinerzeit der UseCase aufgenommen, dass die Möglichkeit bestehen soll, die vom System errechnete Versorgungsauskunft ausdrucken zu können. Da die Versorgungsauskunft bereits im GUI-Prototypen (siehe letzter Beitrag) angezeigt werden kann, wäre es natürlich naheliegend, den Aufbau und die Formatierung aus der GUI für den Ausdruck zu übernehmen. An diese Aufgabe habe ich mich in den letzten Tagen herangewagt und es hat einigen Aufwand gekostet, dieses Problem zu lösen.

Wie bin ich bei der Implementierung des UseCase vorgegangen?
Der GUI-Prototyp wurde mit Hilfe des SWT-Framework erstellt und in diesem Framework existiert eine GUI-Komponente "StyledText". Diese Komponente ermöglicht es, einen formatierten Text zu erstellen und in der GUI zur Anzeige zu bringen. Die entsprechenden Screenshots habe ich ja im letzten Beitrag eingebunden. Neben der Formatierung mit unterschiedlichen Schriftgrößen, Schriftarten, Farben usw. besteht auch die Möglichkeit Grafiken in den Text einzubinden. Diese Feature habe ich genutzt, um im Header das Logo des "Prot-In-Support e.V." anzuzeigen. Ein kleines bisschen Eigenwerbung sozusagen, falls das Tool sich irgendwann mal doch als nützlich erweisen sollte. Die Komponente "StyledText" ermöglicht es bereits "out-of-the-box", den Text an einen Drucker weiterzuleiten und entsprechend auszudrucken. Also genau das, was wir für unsere Zwecke benötigen.

Die Idee war also, die vom System errechnete und formatiert in der GUI angezeigte Versorgungsauskunft auszudrucken. Noch besser als der direkte Ausdruck über einen Drucker wäre allerdings, diesen Druck in ein PDF-Dokument umzuleiten. Dieses PDF-Dokumente könnte dann bei Bedarf ausgedruckt werden oder aber als Anhang in einer Mail verschickt werden. Jedenfalls wäre ein Druck in eine PDF-Datei wesentlich flexibler für die verschiedensten Anwendungsszenarien. Im Prinzip ist das auch gar nicht so schwierig. Für die verschiedenen Betriebssysteme existieren Druckertreiber, die genau diese Funktionalität bereitstellen. Ich verwende als Betriebssystem "Window 10" und dafür existiert der Druckertreiber "Microsoft Print to PDF". Bin mir nicht mehr ganz sicher, ob dieser Druckertreiber bereits Bestandteil der Grundinstallation von "Windows 10" ist oder ob man das nachinstallieren muss. Jedenfalls ist dieser Druckertreiber kostenfrei. Für andere Betriebssystem wird es ähnliche Lösungen geben.
Druckertreiber Pint2PDF
Druckertreiber Pint2PDF
Das hörte sich erstmal sehr verlockend an. Einerseits liefert das GUI-Framework schon die Möglichkeit den in der GUI angezeigten Text auszudrucken. Zusätzlich existiert ein Druckertreiber, der es ermöglicht, den Ausdruck in ein PDF-Dokument umzuleiten. Leider war es dann doch nicht ganz so einfach. Aber jetzt erstmal der Reihe nach.
Der erste Versuch zeigte schnell welche Probleme gelöst werden mussten, um das gewünschte Ergebnis zu erreichen. Das Ausdruck ein PDF-Dokument war, so wie ich es erwartet hatte, grundsätzlich möglich. Allerdings ging die Formatierung im PDF-Ausdruck komplett verloren. Die Ursache dafür war, das für das Rendering in der GUI bzw. auf dem Bildschirm andere Rechnungseinheiten verwendet werden als beim Drucken. Das Zeichnen der Anzeigen auf dem Bildschirm basiert auf der Bildschirmauflösung in Pixeln, während beim Drucker die sog. DPI-Auflösung (dots per inch) zur Anwendung kommt. Die Schriftgrößen, Schriftarten und Schriftfarben wurden vom SWT-Framework zwar direkt richtig umgerechnet und sahen im PDF-Dokument schon brauchbar aus, aber die für die Formatierung verwendeten Tabstops in der GUI passten für den Druck überhaupt nicht mehr. Im Gegensatz zur Anzeige der Versorgungsauskunft in der GUI müssen wir uns beim Drucken auch überlegen, an welchen Stellen wir einen Seitenumbruch haben möchten, damit das Ganze nachher noch einigermaßen ordentlich aussieht. Außerdem wurde die Header-Grafik mit dem Prot-In-Support Logo nicht in den PDF Ausdruck übernommen. Hier sind einige Screenshots die zeigen, wie das erste Ergebnis des Druck aussah.

PDF ohne Header-Grafik
PDF ohne Headergrafik
PDF ohne Headergrafik
PDF mit Seitenumbruch an der falschen Stelle
PDF ohne richtigen Seitenumbruch
PDF ohne richtigen Seitenumbruch
PDF mit falscher Formatierung aufgrund der Länge der verwendeten Tabstops
PDF mit falscher Formatierung der Tabstops
PDF mit falscher Formatierung der Tabstops
Das Problem mit der unterschiedlichen Auflösung im Display und im Drucker und den unterschiedlichen Masseinheiten für die Tabstops lies sich relativ leicht lösen.
Das entsprechende Stück Software im GUI-Prototypen wurde von mir so umgeschrieben, dass die Versorgungsauskunft vor dem Ausdruck nochmal neu formatiert wird, damit die Formatierung auch für den PDF-Ausdruck passt. Bis da wieder alles ordentlich aussah, war einiges and "Trial and Error" Versuchen nötig, aber letzlich war es reine Fleißarbeit. Richtig aufwändig wurde es dann aber bei der Übernahme der Header-Grafik in den PDF-Ausdruck und den Seitenumbrüchen im PDF-Dokument an den passenden Stellen. Nach sehr vielen Versuchen und viel Analyse wurde es irgendwann klar, das diese Features in der verwendeten GUI-Komponente (StyledText) des SWT-Frameworks überhaupt nicht unterstützt werden. Das bedeutete, dass Druck so wie geplant nicht funktionieren konnte. Also entweder auf die Grafik und erzwungenen Seitenumbrüche im Ausdruck verzichten oder alles selber neu implementieren oder evtl. ein anderes Framework verwenden. Alles selber neu zu implementieren schied als Alternative sofort aus. Das Berechnen für das Rendering ist wirklich sehr komplex. Man muss quasi jeden einzelnen Druckpunkt irgendwie berechnen und dann auch noch die entsprechenden Rahmenbedingungen wie Schriftgrößen, Zeilenvorschub, Seitenumbruch berücksichtigen. Ich kann sowas nicht bzw. ich traue mir in der zur Verfügung stehenden Zeit nicht zu, das Drucken bis in das letzte Detail selber zu implementieren. Eine andere Alternative wäre die Verwendung eines anderen Frameworks für die Konvertierung in ein PDF-Dokument. Das OpenSource-Framework "The Apache FOP Project"(https://xmlgraphics.apache.org/fop/) existiert genau für diese Zwecke. Allerdings würde dies auch erst einmal eine intensive Einarbeitung in dieses neue Framework erfordern. Die letzte Alternative wäre die existierende SWT-Komponente "StyledText" so zu erweitern, das die Header-Grafik in den Ausdruck übernommen wird und das Seitenumbrüche an den gewünschten Textstellen erzwungen werden können. Das SWT-Framework ist ja ebenfalls OpenSource und grundsätzlich kann man daran natürlich auch Erweiterungen vornehmen. Allerdings ist das dann doch auch aufwändiger, weil man dann nicht mehr nur das Public-API der Komponente kennen muss, sondern auch die dahinter liegende Implementierung verstehen muss.

Letztlich habe ich mich auf mein Bauchgefühl verlassen und mich gegen den Schwenk auf das "Apache FOP - Framework" entschieden. Stattdessen habe ich mir die Sourcen des SWT-Framework besorgt und durch relativ aufwändiges Debuggen herausgefunden, welche Stellen ich erweitern muss, um die Grafik aus der Anzeige im Display in den Ausdruck zu übernehmen und Seitenumbrüche den den gewünschten Textstellen zu erzwingen. Für so ein relativ kleines Feature war das natürlich ein enorm hoher Aufwand. Insgesamt habe ich dann diesen beiden Features einige Tage Aufwand investiert, aber dabei habe ich auch sehr viel Neues gelernt und darauf kommt es letztlich ja auch an. Hin und wieder kommt man immer mal wieder an so einen Showstopper und dann muss man entscheiden, wie man weiter vorgeht. Wenn man Terminstress hat, könnte man natürlich auch zur Entscheidung gelangen, dass man das Feature, welches zum Showstopper führt erstmal außen vor lässt. Für dieses Projekt habe ich aber bereits in der Projektbeschreibung erwähnt, dass in diesem Projekt der Weg das Ziel sein soll und deshalb nehmen wir uns auch die Zeit, solche Probleme zu lösen und nicht einfach zu ignorieren. Außerdem ist es für die eigene Motivation auch eine schöne Bestätigung, wenn man schlussendlich doch noch zum gewünschten Ergebnis kommt.

Jedenfalls bin ich jetzt mit dem Druck in ein PDF-Dokument doch einigermaßen zufrieden. Ich habe ich noch ein paar Screenshots angefertigt, die zeigen, wie die Versorgungsauskunft jetzt nach dem Ausdruck in einem PDF-Dokument aussieht. Das dazugehörige PDF-Dokument habe ich ebenfalls als Anlage beigefügt. Wie man im PDF-Dokument erkennen kann, sind an einigen Stellen noch fehlerhafte Formatierungen vorhanden, aber das ist jetzt nur noch Kleinkram und wird in den nächsten Tagen noch bereinigt.


PDF jetzt mit Header-Grafik
PDF mit Header-Grafik
PDF mit Header-Grafik
Seitenumbruch jetzt an der passende Stelle
PDF mit Seitenumbruch
PDF mit Seitenumbruch
Formatierung jetzt mit passenden Tabstops
PDF mit passenden Tabstops
PDF mit passenden Tabstops

PDF-Dokument
mustermann.pdf
(178.21 KiB) 57-mal heruntergeladen
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Persistenzlösung für die Daten einer Versorgungsauskunft

Beitrag von Bernd Malessa »

In den vergangenen zwei Wochen habe ich mich damit beschäftigt, wie eine Persistenzlösung für den Versorgungsauskunft-Rechner aussehen könnte.
Der bisher erstellte GUI-Protyp und die bereits vorhandene Geschäftslogik sind für meinen Geschmack zumindest für den ersten Wurf schon ganz passabel, aber was definitiv noch fehlt, ist die Möglichkeit für den Anwender, dass er seine erfassten Daten zur Berechnung der Versorgungsauskunft speichern und bei Bedarf wieder erneut einzulesen kann. Es wäre nicht besonders benutzerfreundlich, wenn der Anwender jedesmal alle versorgungsrelevanten Daten erneut erfassen müsste, nur weil er nochmal eine Kleinigkeit in seinen Daten ändern möchte. Eine Persistenzlösung böte beispielsweise aber auch die Möglichkeit, die erfassten Daten zur Prüfung an eine fachkundige Person zu übermitteln, die nochmal die Plausibilität der erfassten Daten und die darauf basierende Versorgungsauskunft überprüfen könnte.

Für das persistente Speichern von Daten verwendet man üblicherweise eine Datenbank. Die Auswahl an Datenbank-Managementsystemen ist groß. Am weitesten verbreitet dürften sog. Relationale Datenbank Managementsysteme (RDBMS) sein. Mit den Opensource-Lösungen MySQL, MariaDB und Postgres finden sich hier einige kostenfreie Kandidaten, die sehr leistungsfähig und weit verbreitet sind. Es gibt aber auch einiges zu berücksichtigen, wenn wir darüber nachdenken, ob wir für unsere Software eine relationale Datenbank einsetzen möchten. Die zusätzliche Komplexität, die wir uns einhandeln ist nicht zu unterschätzen. Neben der Installation, Inbetriebnahme und Wartung einer neuen Softwarekomponente müssten wir uns auch noch in SQL (Structured Query Language) einarbeiten, um mit einem RDBMS arbeiten zu können. SQL ist eine Art Programmiersprache, die geschaffen wurde um mit Daten in einer relationalen Datenbank zu bearbeiten. Dazu gehören das Anlegen, Ändern und Löschen von Daten, aber auch insbesondere die Abfrage und Auswertung von Daten in einem RDBMS. Weiterhin müssen wir aus unserer in die Programmiersprache Java geschriebenen Software erstmal eine Verbindung zur Datenbank herstellen, um überhaupt SQL-Befehle an die Datenbank absetzen zu können. Im Java-Umfeld wird dazu die JDBC-Schnittstelle verwendet. Wenn wir es ganz ordentlich machen wollten, könnte wir auch noch darüber nachdenken, ob sich nicht ein Object-Relationales Mapping anstellen von direkten SQL-Kommandos anbieten würde. Auch der Entwurf des Datenbankschema zur Speicherung der Daten und die Normalisierung der relationalen Datenbanktabellen ist einigermaßen komplex und erfordert einige Zeit an Einarbeitung in diese Thematik. Bereits aus dieser kurzen Einleitung sollte klar werden, das Persistenz in einer relationalen Datenbank ein nicht ganz triviales Themengebiet darstellt. Bevor wir also dieses große Fass aufmachen, sollten wir erst einmal überlegen, ob wir uns wirklich darauf einlassen möchten oder ob wir nicht doch besser einen leichtgewichtigeren Ansatz wählen. Auch das Thema Datenschutz sollte hier berücksichtigt werden. Immerhin erfassen wir im Versorgungsauskunft-Rechner personenbezogenen Daten. Wenn wir die personenbezogenen Daten dann auch noch an einer zentrale Stelle (im RDBMS) speichern, dann haben wir hier noch eine weitere Baustelle, die es zu berücksichtigen gilt.

Aus den o.g. Gründen habe ich mich daher dazu entschieden, für die Persistenzlösung im Versorgungsauskunft-Rechner zunächst einmal auf eine Datenbank zu verzichten und stattdessen einen leichtgewichtigen Ansatz zu verfolgen. Es wäre für mich ausreichend, wenn der Anwender seine erfassten Daten in eine Textdatei auf seinen lokalen Rechner speichern könnte. Er kann dann selber entscheiden, ob er diese Daten mit anderen Personen (z.B. zum Zweck der Überprüfung) teilen möchte oder nicht. Wichtig ist, dass die gespeicherten Daten wieder erneut eingelesen werden können, um die Bearbeitung auf der Basis der bereits erfassten Daten wieder aufzunehmen. Damit dies funktionieren kann, müssten die Daten strukturiert, möglichst im Klartext, gespeichert werden. Als Speicherformat bieten sich hier XML oder JSON an. Für beide Varianten existieren OpenSource-Lösungen, die es ermöglichen die Datenstrukturen aus unserem objektorientierten Klassenmodell in eine Textdatei zu exportieren. Dabei werden die Klassen- und Attributbezeichner als Strukturelement verwendet und die jeweiligen Attribut-Werte abhängig vom Datentyp serialisiert. Ein Objekt vom Typ "Person", das den Antragsteller einer Versorgungsauskunft repräsentiert, könnte in einer XML-Notation dann beispielsweise wie folgt aussehen:

Code: Alles auswählen

<versorgungsauskunft>
	<person>
		<anrede>Frau</anrede>
		<vorname>Sabine</vorname>
		<name>Musterfrau</name>

		<besondereAltersgrenze>false</besondereAltersgrenze>
		<dateOfBirth>May 12, 1955 12:00:00 AM</dateOfBirth>
		<dateOfRetirement>Oct 1, 2020 12:00:00 AM</dateOfRetirement>
		<dateOfSubstantiation>Sep 1, 1976 12:00:00 AM</dateOfSubstantiation>

		<schwerbehindert>true</schwerbehindert>
		<schwerbehindertBefore20001117>false</schwerbehindertBefore20001117>

		<sonstigeZulage/>
		<stellenzulage/>

		<familienzuschlag>
			<anzahlKinder>0</anzahlKinder>
			<stufe>1</stufe>
		</familienzuschlag>

		<besoldung>
			<besoldungsGruppe>12</besoldungsGruppe>
			<besoldungsStufe>8</besoldungsStufe>
			<laufbahnOrdnung>A</laufbahnOrdnung>
		</besoldung>

	</person>
	....
	....
	<timePeriods>
		<element>
			<label null="Ausbildung im Beamtenverhältnis auf Widerruf (§6 BeamtVG)"/>
			<lfdNummer>1</lfdNummer>
			<timePeriod>
				<type>2</type>
				<startDate>Sep 1, 1977</startDate>
				<endDate>Aug 31, 1980</endDate>
				<factor>1.0</factor>
				<ruhegehaltsfaehigeTage>1460</ruhegehaltsfaehigeTage>
				<comments/>
			</timePeriod>
		</element>
		<element>
			<label>Beamtendienstzeiten nach dem 17. Lebensjahr (§6 BeamtVG)</label>
			<lfdNummer>2</lfdNummer>
			<timePeriod>
				<type>1</type>
				<startDate>Sep 1, 1980</startDate>
				<endDate>Jan 31, 1982</endDate>
				<factor>0.5</factor>
				<ruhegehaltsfaehigeTage>258</ruhegehaltsfaehigeTage>
				<comments/>
			</timePeriod>
		</element>
		...
	</timePeriods>
<versorgungsauskunft>	
Der Vorteil dieser XML-Struktur ist, das man diese auch außerhalb des Programms relativ leicht lesen kann. Mit etwas Übung könnte man diese Struktur sogar außerhalb der Software editieren um kleinere Änderung manuell vorzunehmen. Verbinden könnte man das Ganze dann noch mit einem XML-Schema. In diesem Schema könnte man genau beschreiben, welche Elemente in der Struktur mandatorsich oder optional sind, welche Elemente mehrfach innerhalb einer Liste vorkommen können etc.

Eine andere Variante ist das Speichern der Daten als JSON-Struktur. JSON ist heute in der Web-Entwicklung sehr weit verbreitet. Damit lassen sich komplexe Daten sehr einfach in eine Zeichenkette serialisieren und über das Netzwerk verschicken, um dann beim Empfanger anschließend wieder in die ursprüngliche Objektstruktur deserialisiert zu werden. Auch hier werden wie bei XML die komplexen Objektstrukturen so weit aufgelöst, bis schließlich nur noch die elementaren Datentypen wie String, Integer, Boolean übrig bleiben. Die Struktur bzw. das Netzwerk der vorhandenen Objekte bleibt jedoch erhalten, so beim anschließenden Deserialisieren wieder die ursprüngliche Objektstruktur aufgebaut wird. Wie die im GUI-Prototypen erfassten Daten für eine Versorgungsauskunft im JSON-Format aussehen, kann aus der als Anhang beigefügten Datei eingesehen werden. Ein serialisierter JSON-String ist zwar im Klartext der gespeicherten Datei etwas weniger gut lesbar als eine Serialiserung in XML-Format, aber dafür auch um einiges kompakter und in der Verarbeitung performanter.

Code: Alles auswählen

{
  "person": {
    "name": "Mustermann",
    "vorname": "Max",
    "anrede": null,
    "schwerbehindert": false,
    "schwerbehindertBefore20001117": false,
    "besondereAltersgrenze": false,
    "besondereAltersgrenzeJahre": 0,
    "dateOfBirth": "May 12, 1958 12:00:00 AM",
    "dateOfBirthString": "12.05.1958",
    "dateOfRetirement": "May 1, 2022 12:00:00 AM",
    "dateOfRetirementString": "01.05.2022",
    "dateOfRequestRetirement": null,
    "dateOfRequestRetirementString": null,
    "dateOfLegalRetirement": null,
    "dateOfLegalRetirementString": null,
    "dateOfSubstantiation": "Sep 1, 1978 12:00:00 AM",
    "dateOfSubstantiationString": "01.09.1978",
    "besoldung": {
      "laufbahnOrdnung": "A",
      "besoldungsGruppe": 12,
      "besoldungsStufe": 8
    },
    "familienzuschlag": {
      "stufe": 0,
      "anzahlKinder": 0
    },
    "stellenzulage": null,
    "amtszulage": null,
    "sonstigeZulage": null
  },
  "typ": 4,
  "anzwRecht": "Bund",
  "timePeriods": [
    {
      "timePeriod": {
        "type": 2,
        "startDate": "Sep 1, 1978 12:00:00 AM",
        "endDate": "Aug 31, 1980 12:00:00 AM",
        "factor": 1.0,
        "ruhegehaltsfaehigeTage": 731,
        "comments": []
      },
      "lfdNummer": 1,
      "label": "Ausbildungszeiten im Beamtenverhältnis auf Widerruf (§6 BeamtVG)"
    },
    {
      "timePeriod": {
        "type": 3,
        "startDate": "Sep 1, 1980 12:00:00 AM",
        "endDate": "Jan 31, 1982 12:00:00 AM",
        "factor": 1.0,
        "ruhegehaltsfaehigeTage": 517,
        "comments": []
      },
      "lfdNummer": 2,
      "label": "Wehrdienst-/Zivildienst und vergleichbare Zeiten (§8,9 BeamtVG)"
    },
    {
      "timePeriod": {
        "type": 1,
        "startDate": "Feb 1, 1982 12:00:00 AM",
        "endDate": "Dec 31, 2000 12:00:00 AM",
        "factor": 1.0,
        "ruhegehaltsfaehigeTage": 6905,
        "comments": []
      },
      "lfdNummer": 3,
      "label": "Beamtendienstzeiten nach dem 17. Lebensjahr (§6 BeamtVG)"
    },
    {
      "timePeriod": {
        "type": 1,
        "startDate": "Jan 1, 2001 12:00:00 AM",
        "endDate": "Dec 31, 2004 12:00:00 AM",
        "factor": 0.5,
        "ruhegehaltsfaehigeTage": 730,
        "comments": []
      },
      "lfdNummer": 4,
      "label": "Beamtendienstzeiten nach dem 17. Lebensjahr (§6 BeamtVG)"
    },
    {
      "timePeriod": {
        "type": 1,
        "startDate": "Jan 1, 2005 12:00:00 AM",
        "endDate": "Dec 31, 2015 12:00:00 AM",
        "factor": 1.0,
        "ruhegehaltsfaehigeTage": 4015,
        "comments": []
      },
      "lfdNummer": 5,
      "label": "Beamtendienstzeiten nach dem 17. Lebensjahr (§6 BeamtVG)"
    },
    {
      "timePeriod": {
        "type": 7,
        "startDate": "Jan 1, 2016 12:00:00 AM",
        "endDate": "Apr 30, 2022 12:00:00 AM",
        "factor": 0.9,
        "ruhegehaltsfaehigeTage": 2079,
        "comments": []
      },
      "lfdNummer": 6,
      "label": "Altersteilzeit im Blockmodel"
    }
  ],
  "ruhegehaltsSatz": 0.0,
  "summeRuhegehaltsfaehigeDienstbezuege": 0.0,
  "amtsabhaengigeMindestversorgung": 0.0,
  "amtsunabhaengigeMindestversorgung": 0.0,
  "abzugPflegeleistung": 0.0,
  "kindererziehungsZuschlag": {
    "aktuellerRentenwert": 34.19,
    "kindererziehungszeitenVor1992": [],
    "kindererziehungszeitenNach1991": [
      {
        "childName": "Lennard",
        "birthDate": "Apr 16, 1994 12:00:00 AM",
        "legalMonths": 0,
        "zulageMonths": 0,
        "vollerAnspruch": false,
        "anspruch": "Kein Anspruch nach BeamtVG (Anwartschaft in gesetzlicher RV vorhanden)",
        "type": 6,
        "startDate": "May 1, 1994 12:00:00 AM",
        "endDate": "May 1, 1997 12:00:00 AM",
        "factor": 1.0,
        "ruhegehaltsfaehigeTage": 0,
        "comments": []
      },
      {
        "childName": "Anna",
        "birthDate": "Jan 12, 1992 12:00:00 AM",
        "legalMonths": 0,
        "zulageMonths": 0,
        "vollerAnspruch": false,
        "anspruch": "Kein Anspruch nach BeamtVG (Anwartschaft in gesetzlicher RV vorhanden)",
        "type": 6,
        "startDate": "Feb 1, 1992 12:00:00 AM",
        "endDate": "Feb 1, 1995 12:00:00 AM",
        "factor": 1.0,
        "ruhegehaltsfaehigeTage": 0,
        "comments": []
      }
    ]
  },
  "vergleichsberechnungBeamtVG_PARA_85": true
}
Ich habe mich letzlich für das JSON-Format entschieden. Damit haben wir jetzt auch eine Persistenzlösung für den Versorgungsauskunft-Rechner. Wir sind jetzt in der Lage die Daten für eine Versorgungsauskunft im GUI-Prototypen zu erfassen und können diese Daten vom System validieren lassen und nach erfolgreicher Validierung als JSON-Zeichenkette in eine Datei speichern. Diese JSON-Datei könnten wir dann bei Bedarf z.B. per Mail an einen Dritten schicken, der diese Datei wieder einliest, die Deserialisierung durchführt und anschließend eine inhaltliche Prüfung der erfassten Daten (z.B, ob alle erfassten ruhegehaltsfähigen Zeiten in voller Höhe anerkannt werden können) vornehmen kann. Der Anwender selbst kann jetzt mit dieser neuen Möglichkeit ebenfalls das ein oder andere Szenarion relativ einfach durchspielen. Die verschiedenen Ruhestandsvarianten können jetzt relativ schnell durchgespielt werden ohne das immer alle Daten komplett neu erfasst werden müssen.

Zum Schluss füge ich noch einige Screenshots des GUI-Prototypen bei, aus denen ersichtlich wird, wie das Speichern und erneute Einlesen funktioniert.
Letzlich wählt man den entsprechenden Menupunkt aus und kann dann im FileDialog den gewünschten Dateinamen und Speicherort angeben. Das Einlesen eines bereits gespeicherten JSON-Files erfolgt analog. Nach Auswahl des Menupunkts "Versorgungsauskunft öffnen" kann im FileDialog die gewünschte JSON-Datei ausgewählt werden. Nach erfolgreicher Deserialisierung werden in der GUI die Felder mit den Werten aus der JSON-Datei gefüllt. Da eine Speicherung und Serialisierung der Daten nur nach einer erfolgreichen Validierung zugelassen wird, ist auch sichergestellt, dass die JSON-Struktur wieder eingelesen werden kann.
Menupunkt &quot;Versorgungsauskunft speichern&quot; auswählen
Menupunkt "Versorgungsauskunft speichern" auswählen
Dateinamen für die JSON-Datei festlegen und Speicherort auswählen
Dateinamen für die JSON-Datei festlegen und Speicherort auswählen
Damit haben wir nun eine nahezu vollständige Lösung eines Versorgungsauskunft-Rechner. In den nächsten Wochen werde ich noch die Implementierung der Geschäftslogik fertigstellen und an der Stabilität der Anwendung arbeiten. Ich denke, dies wird dann in ca. 2-3 Wochen erledigt sein. Danach wäre es dann tatsächlich an der Zeit das Ganze mal in "real-life" auszuprobieren. Wer Interesse hat, den Versorgungsauskunft-Rechner dann mal selber auszuprobieren und eine Versorgungsauskunft mit Hilfe des Tools durchzuführen, kann mich gerne kontaktieren. Wir werden dann einen Weg finden, wie ich die vorhandene Software weitergeben kann, damit diese auch auf einen fremden Rechner zur Ausführung gebracht werden kann.
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Fertigstellung des Prototypen für den Versorgungsauskunft-Rechner

Beitrag von Bernd Malessa »

Mittlerweile ist der erste Meilenstein des Projektes "Versorgungsauskunft-Rechner" erreicht. In den letzten 2 Monaten wurde einiges an Aufwand für Recherche, konzeptionelle Arbeit und Implementierung geleistet, so das nun ein Stück Software vorhanden ist, welches aus meiner Sicht darauf wartet, einfach mal ausprobiert zu werden. Nachdem in den letzten 2 Wochen noch kleinere Anpassungen vorgenommen wurden, habe ich nach einem Weg gesucht, wie ich diese Software der Community so bereitstellen kann, dass sie möglichst auch von Menschen, die keine große Erfahrung mit IT haben, einfach ausprobiert werden werden kann. Nicht jede(r) Interessierte kann oder möchte sich gleich eine komplette Software-Entwicklungsumgebung aufbauen, nur um mal schnell ein Programm auszuprobieren.

Das "Prot-In Support e.V. Bürgerportal" ist für diese Aufgabe leider nicht gut geeignet. Deshalb habe ich die bisher erstellten Software-Artefakte in einem öffentlich zugänglichen GIT-Repository auf github.com eingestellt. Auf github.com kann man Repositories für OpenSource-Software kostenfrei erstellen und nutzen. Zusätzlich kann man auch noch die gesamte Funktionalität eines Versionsverwaltungssystem (in diesem Fall "git") nutzen. Einige andere Möglichkeiten wie das Bug-Tracking, die Einstellung neuer Feature-Request und Funktionen für Aufgaben des Projekt-Managements sind dort ebenfalls verfügbar, werden momentan aber (noch) nicht benötigt. Sobald mehr Leute an diesem Projekt mitarbeiten, werden einige dieser Funktionen ggf. noch in Zukunft einmal benötigt.

In diesem GIT-Repository kann man sich den erstellten Sourcecode ansehen und bei Bedarf auch herunterladen. Man hat aber auch die Möglichkeit, sich den ausführbaren Prototypen herunterzuladen, um einfach mal die ganzen Features des "Versorgungsauskunft-Rechner" , über die ich in den letzten Wochen hier regelmäßig geschrieben habe, selber auszuprobieren.

Ich habe den "Versorgungsauskunft-Rechner" soweit mir möglich getestet und auch 2-3 Bekannte mal gebeten, sich das anzuschauen und auszuprobieren. Gleichwohl bin ich relativ sicher, dass doch noch der ein oder anderer Fehler vorhanden sein dürfte. Der Anspruch ist also nicht ein 100% fehlerfreies Stück Software. Es ist meiner Erfahrung nach leider immer davon auszugehen, dass nach der Freigabe für eine breitere Community noch Probleme hochkommen, die man mit einer kleinen Anzahl an Testern einfach nicht vor der Freigabe erkennt. Das soll aber keine Vorab-Entschuldigung sein. Das Gute an einer selbst entwickelten OpenSource-Software ist ja, dass man hier auch die Möglichkeit hat, erkannte Mängel in eigener Regie zu beheben.

Um das Ganze möglichst einfach zu halten, habe ich auch ein passendes "Java Runtime Environment" mit in das GIT-Repository eingecheckt. Das macht den kompletten Download dann leider etwas umfangreicher (ca. 90 MB). Die selbst entwickelte Software sowie ein paar weitere benötigte OpenSource-Bibliotheken umfassen nur ca. 6 MB. Der Vorteil dieser Vorgehensweise ist jedoch, dass mit diesem Download-Bundle die technische Hürde für das Ausprobieren des Prototyp deutlich niedriger wird. Andernfalls müsste sich jede(r) Interessierte separat eine passendes Java JRE oder Java SDK herunterladen.

Auf einer halbwegs aktuellen Windows-Umgebung (z.B. Win 10 oder Win 7), kann man den Prototyp mit minimalen Setup ausführen. Dafür wurde im Download ein Batch-Skript zugefügt, das über relative Pfade auf die für die Ausführung des Programms benötigten Ressourcen zugreift. Für andere Betriebssysteme wie Linux oder MacOS ist dann aber doch mehr Aufwand notwendig. In diesem Fall muss man sich ggf. ein Java JRE (> Version 1.8) für das jeweilige Betriebssystem selber aus dem Internet herunterladen und die Skriptdatei zum Starten des Programms muss dann auch entsprechend für das jeweilige Betriebssystem angepasst werden. Unix-Shellskripte und DOS-Commands sind dann eben doch etwas unterschiedlich in der Handhabung. Ich gehe aber davon aus, das die Mehrzahl der Interessierten mit Windows arbeitet und habe deshalb erstmal nur für dieses Betriebssystem die "out-of-the box" Lösung zusammengestellt.

Der Link zu dem o.g. GIT-Repository lautet wie folgt: https://github.com/bmalessa/ER-Software

Sofern sie den Prototypen mal ausprobieren möchten, müssten Sie die folgenden Schritte ausführen:
  • 1) Download des komplette Git-Repository von der o.g. URL (wird dann als "ER-Software-master.zip" auf den lokalen Rechner runtergeladen)
    Download des Prototyp von Github-Repo
    Download des Prototyp von Github-Repo
    github_download.png (17.81 KiB) 170 mal betrachtet
    2) Entpacken des ZIP-Files

    3) In den Ordner "Versorgungsauskunft-Rechner\Prototyp\Deploy" des ausgepackten ZIP-Files wechseln.

    4) Das Batch-Skript "runApp.bat" ausführen (funktioniert nur für Windows, ansonsten muss man das für Unix oder MacOS entsprechend anpassen)
Dann startet eine GUI, in der man eine Versorgungsauskunft anlegen kann. Ich habe auch 2 JSON-Files in den Download mit dabei gelegt, mit denen man sich bereits vorhandene Musterbeispiele für eine Versorgungsauskünfte ansehen kann. Diese JSON-Files liegen im Ordner "Versorgungsauskunft-Rechner\Prototyp\Json". Über den Menu-Punkt "Datei / Versorgungsauskunft öffnen" des Prototyps kann man diese JSON-Files einlesen.

Wenn Ihnen irgendwelche Probleme beim Starten des Programms oder Fehler in den Berechnungen der Versorgungsauskunft auffallen, wäre es schön, wenn Sie mir diese per PN zukommen lassen oder ihre Erkenntnisse einfach hier im Forum dokumentieren. Jede andere Form von Feedback wird natürlich auch gerne angenommen. Wie bereits oben geschrieben, bin ich mir darüber bewusst, dass noch nicht alles 100% perfekt ist und in den Berechnungen vermutlich noch das ein oder andere angepasst bzw. erweitert werden muss. Das Ziel ist es aber, diese Mängel sukzessive zu beseitigen und damit eine Lösung zu schaffen, die einen Mehrwert bietet. Da meines Wissens der "Engagierte Ruhestand" bei der Telekom für das Jahr 2021 gerade freigegeben wurde, kennt der ein oder andere vielleicht auch jemanden, der sich seine voraussichtlich zu erwartenden Versorgungsbezüge gerne mal schnell selber ausrechnen möchte. Das dazu notwendige Tool ist jetzt jedenfalls verfügbar.

Das soll's für heute erstmal gewesen sein. Bin gespannt auf die Rückmeldungen.
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Neue Version des Versorgungsauskunft-Rechner verfügbar

Beitrag von Bernd Malessa »

Nach der initialen Bereitstellung des Versorgungsauskunft-Rechner in dem öffentlich zugänglichen Github-Repository (https://github.com/bmalessa/ER-Software) sind nun auch die ersten Rückmeldungen aus der Community eingegangen. Ich entnehme dem Feedback, dass die Software prinzipiell einigermaßen gut ihren Zweck erfüllt. Einige kleinere Fehler haben sich erwartungsgemäß dennoch eingeschlichen.

Folgende Fehler oder auch Erweiterungswünsche wurde bisher gemeldet:
  • Bei der Berechnung von ruhegehaltsfähigen Zeiträume wurden kleine Unterschiede von wenigen Tagen gegenüber Berechnungen in den Versorgungsauskünfte der BAnstPT festgestellt. Die Ursache dafür war die Berechnung von Schaltjahren. Nach etwas Recherche und einigem Ausprobieren habe ich den Algorithmus jetzt so umgestellt, dass ich mit den mir vorliegenden Testdaten jetzt auf dieselben Zahlen wie die BAnstPT komme. In diesem Zusammenhang wurde auch noch deutlich, das in der alten Version der errechnete Ruhegehaltssatz noch nicht 100% richtig angewendet wurde. Der Ruhrgehaltssatz muss vor der weiteren Verwendung zur Berechnung des Ruhegehalt noch auf die 2 Nachkommastelle gerundet werden. Im Ergebnis waren das nur ein paar Cent in der Differenz, aber nach der Berichtigung stimmen jetzt auch diese Werte (Ruhegehalt und Abzug für Pflegeleistung) mit den Berechnungen der BAnstPT exakt überein.
  • Die Validierung der Eingabedaten war in der ersten Version noch nicht komplett wasserdicht, was dazu geführt hat, dass keine oder falsche Berechnungen durchgeführt wurden. Insbesondere die Validierung von Datumsangaben und nummerischen Werten war an einigen Stellen noch verbesserungsbedürftig.
  • Probleme wurden auch bei der Anzeige von Datumsfelder gemeldet, weil in den betreffenden Eingabefeldern nicht alle Zeichen sichtbar waren. Dieses Verhalten konnte ich auf meiner lokalen Umgebung nicht nachstellen. Ich habe die Felder mit Datumsangaben trotzdem etwas verbreitert, um die Anzeige aller eingegeben Zeichen auf jeden Fall sicherzustellen.
  • Beim Feature für den Ausdruck der Versorgungsauskunft in ein PDF-Dokument wurde bemängelt, dass keine Druckerauswahl möglich war, sondern immer direkt der systemseitig eigestellten Standarddrucker verwendet wurde. Ich habe das jetzt dahingehend geändert, das vor dem Druck in jedem Fall ein Druckerauswahldialog erscheint. Auch in der neuen Version ist es momentan allerdings weiterhin nur möglich über einen entsprechenden Druckertreiber in ein PDF-File zu drucken. Um alle möglichen Druckertreiber zu unterstützten, wären erhebliche Anpassungen an der Implementierung notwendig.
  • Es wurde auch der Wunsch geäußert, daß ältere Besoldungstabellen im System verfügbar gemacht werden. Damit hätte man eine bessere Möglichkeit mit diesem Tool Kontrollberechnungen gegen die von der BAnstPT erstellten Versorgungsbescheide oder Versorgungsauskünfte aus den Zeiträume vor dem 01.03.2020 (Beginn der aktuell gültigen Besoldungstabelle) durchzuführen. Insbesondere könnte man damit dann sukzessive die intern verwendeten Algorithmen an die von der BAnstPT verwendeten angleichen. Aus diesem Grund habe ich ältere Besoldungstabellen (Für "Beamtinnen und Beamte des Bundes" für den Zeitraum vom 01.03.2016 - 29.02.2020) in das System integriert.
Die letzten Tagen habe ich an der Analyse und Beseitigung der o.g. Fehler gearbeitet und als Ergebnis dieser Arbeiten ist nun eine neue Version des Versorgungsauskunft-Rechner entstanden. Diese neue Version habe ich auch bereits in das Github eingestellt. Jeder der daran interessiert ist kann sich die Software dort downloaden.

Ich würde das Resultat dieser Arbeiten immer noch in den Status "Prototyp" einordnen. Mittlerweile ist die Software meiner Meinung nach schon ziemlich stabil und fachlich für die wesentlichen UseCases, zumindest soweit ich das beurteilen kann, vollständig. Was noch verbesserungswürdig wäre sind eher technische Aspekte. Zur Zeit ist die komplette Steuerung der Anwendung fast komplett selbst implementiert. Der Startup-Prozess, das Eventhandling (z.B. Reagieren auf die Auswahl von Menu-Einträgen oder den Klick auf einen Button) oder das Management der anzuzeigenden GUI-Elemente (Fenster, Views, Dialoge) wurde bisher komplett mit selbst geschriebenen Code implementiert. Das ist natürlich erst einmal kein Nachteil, weil man mit dieser Vorgehensweise auch alle Fäden selber in der Hand hält. Für die weitere Entwicklung kommt man mit dieser Vorgehensweise aber allmählich an die Grenzen. Um die Komplexität einigermaßen unter Kontrolle zu halten, wäre es besser, wenn wir uns für die weitere Entwicklung und das Einbinden neuer Funktionen auf ein ausgereiftes Framework abstützen, welches uns viele der o.g. Aufgaben abnehmen kann oder uns zumindest dabei unterstützt.

Ich habe deshalb damit begonnen, die existierenden Softwareartefakte so umzubauen, das daraus eine RichClient-Anwendung auf der Basis des Eclipse-Framework entstehen kann. Wenn dies so funktioniert, wie ich mir das vorstelle, haben wir danach zwar keine zusätzliche fachliche Funktionalität im System, aber dafür läuft die Applikation dann innerhalb eines sehr ausgereiftes Frameworks mit vielen neuen Möglichkeiten. Der Einbau weitere Features wird dann wesentlich einfacher und modularer möglich sein. Das Eclipse-RCP-Framework bietet nahezu unendlichen Möglichkeiten. Das Beste von allem wäre aber die Möglichkeit, aus dieser dann vorhandenen RCP-Applikation eine Webanwendung zu entwickeln. Im Eclipse Universum existiert dafür das RAP-Framework. Die Migration einer RCP-Applikation in eine RAP-Webanwendung wurde schon mehrfach dokumentiert. Zu diesem Thema existieren auch einige Youtube-Videos und auch verschiedene Bachelor- und Mastarbeiten wurden dazu im Internet veröffentlicht. Während meiner aktiven Zeit bei der T-Systems habe ich so eine Migration auch schon mal durchgeführt.

Das langfristige Zielszenario wäre also eine Webanwendung für den Versorgungsauskunft-Rechner. Damit würde die momentan größte Hürde für eine größere Akzeptanz und Verbreitung, nämlich das relativ aufwändige lokale Setup der Runtime-Umgebung komplett entfallen. Ein lokales Java-SDK wäre nicht mehr erforderlich und eine neue Version könnte an einer zentralen Stelle eingespielt werden ohne das sich jeder Einzelne selbst um das Update kümmern müsste. Für die Nutzung des Versorgungsauskunft-Rechner wäre nur ein Webbrowser, der sowieso auf jedem Rechner bereits vorhanden ist, erforderlich.

Bis es soweit ist steht aber noch viel Arbeit an. In der Zwischenzeit wird der vorhandene Prototyp in der Community hoffentlich ausgiebig genutzt und getestet, damit parallel zu den oben beschriebenen Arbeiten weiter an der fachlichen Vollständigkeit und Fehlerfreiheit des Versorgungsauskunft-Rechner gearbeitet werden kann. Wer Fehler in den Berechnungen feststellt oder Vorschläge zur Usability oder sonstige Erweiterungswünsche hat, kann diese gerne hier im Forum oder per PN mitteilen.
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Software-Design Refactoring

Beitrag von Bernd Malessa »

In diesem Beitrag möchte ich den Schwerpunkt auf das Software-Design legen.

Ohne Kenntnis darüber, welche Erfahrungen im Zusammenhang mit objektorientierter Programmierung oder Softwareentwicklung im Allgemeinen bei den Lesern in diesem Forum vorhanden sind, ist es schwierig über das Thema Software-Design zu schreiben. In einem einzelnen Beitrag kann man dieses Thema sowieso nicht annähernd ausreichend abhandeln. Insofern ist mir bewusst, dass der ein oder andere die folgenden Ausführungen zum Thema Software-Design vermutlich als völlig oberflächlich ansehen wird, während andere sich fragen, wofür das eigentlich gut sein soll. Gutes Software-Design kann man an der GUI einer Software eben nicht einfach erkennen und insofern ist es auch manchmal schwierig, andere Leute von der Notwendigkeit solcher Maßnahmen zu überzeugen. Ich habe mir aber vorgenommen, während des Projektfortschritts regelmäßig über den aktuellen Stand der Dinge in diesem Forum zu berichten und diesmal geht es eben genau um das Thema "Software-Design".

Im Software-Design geht es nicht darum, die fachlichen Anforderungen in eine Software zu implementieren, sondern eher darum die nichtfunktionalen Anforderungen an eine Software in ausreichendem Maße zu berücksichtigen. Aspekte wie Wartbarkeit, Erweiterbarkeit, Robustheit und Performance müssen in einem Softwareprojekt ebenfalls Berücksichtigung finden. Eine Software, in der zwar alle fachlichen Anforderungen fehlerfrei implementiert sind, die aber ständig abstürzt oder inperformant daherkommt, wird niemand gerne nutze.

Leider hat man in Softwareprojekten oft nicht ausreichend Zeit, um sich diesen nichtfunktionalen Anforderungen ausreichend und frühzeitig zu widmen. Die Stackholder eines Projekt sind in der Regel eher an der Umsetzung fachlicher Anforderungen interessiert und interessieren sich weniger für die nicht nichtfunktionalen Aspekte in einer Software. Deshalb widmet man sich diesem Thema in der Praxis leider oft erst dann in ausreichendem Maße, wenn das Kind schon in den Brunnen gefallen ist und die Projekt-Stakeholder unzufrieden mit der Performance der Software sind oder sich darüber beschweren, warum die Integration eines neuen Features sich so aufwändig gestaltet.

Das ganze Thema Software-Design ist viel zu komplex, um den Anspruch zu erheben, das in einem einzigen Artikel ausreichend zu erläutern. Ich möchte daher auch lediglich meine eigenen Überlegungen und Entscheidungen bezüglich des Software-Design rüberbringen, die ich im "Versorgungsauskunft-Rechner" bereits angewendet habe und die ich noch umsetzen möchte.

Wenn ich ein neues Softwareprojekt anfange, dann versuche ich solche Software-Design Überlegungen möglichst gleich zu Beginn mit zu berücksichtigen. Manchmal ist es aber einfacher und auch sinnvoll erstmal ein ablaufähiges Programm zu erstellen und dann im nachhinein noch das ein oder andere Refactoring durchzuführen, um das interne Software-Design zu verbessern. Regelmäßiges Refactoring in Bezug auf eine Verbesserung des Software-Design ist immer eine gute Idee.
In den Bereichen einer Software, die eine hohe Wahrscheinlichkeit haben, häufiger Änderungen, Anpassungen oder Erweiterungen zu unterliegen, sollte man frühzeitig darauf achten, das man keinen "Spagetticode" produziert, sondern eine klare Ordnung einhält und sich dabei an etablierten Best-Practices oder dem ein oder anderen Design-Pattern orientiert. Für jede Programmiersprache existieren solche Best-Practices und für objektorientierte Programmiersprachen existieren sehr viele etablierte Design-Pattern. Design-Pattern beschreiben dabei Lösungsansätze für immer wiederkehrende Problemstellungen. Dazu gibt es eine Menge Fachbücher oder sonstige Tutorials, in denen die jeweiligen Anwendungsbereiche und die Vor- und Nachteile des jeweiligen Design-Pattern ausgiebig beschrieben werden. Die für mich wichtigsten Erkenntnisse daraus kann ich wie folgt zusammenfassen:

Die Auswirkungen von notwendigen Anpassungen oder Änderungen sollten innerhalb des Softwaresystem möglichst lokal begrenzt sein. Deshalb sollte man innerhalb einer Klasse, eines Packages und auch innerhalb von Teilprojekten nicht zu viele unterschiedliche Zuständigkeiten implementieren. Jede Klasse sollte einem eindeutigen Zweck dienen. Attribute oder Funktionen, die nur in der eigenen Klasse oder im eigenen Package benötigt werden, sollten auch nur innerhalb der eigenen Klasse bzw. innerhalb des eigenen Package sichtbar sein.

In objektorientierten Design-Pattern wird oft mit abstrakten Klassen oder mit Schnittstellen (Interfaces) anstatt mit konkreten Implementierungen gearbeitet.
Ein Interface unterscheidet sich von einer konkreten Klasse darin, dass in einem Interface keine Implementierung vorhanden ist. Lediglich das API, d.h. die Signatur der nach außen sichtbaren Methoden ist in Interfaces von Bedeutung. Das bietet viele Möglichkeiten, weil es ermöglicht, für ein und dasselbe Problem unterschiedliche Implementierungen bereitzustellen. Der Client oder Konsument, der die Funktionen eines Interfaces nutzen möchte, benötigt nur die Referenz auf das Interface. Welche konkrete Klasse dieses Interface implementiert ist für den Client nicht relevant. Er muss nur wissen, welche Eingabeparameter er der Schnittstelle übergeben muss und welchen Rückgabewert er als Ergebnis seines Aufrufs erwarten kann. Damit ermöglicht man eine Entkopplung des Client von der konkreten Implementierung eines Interface.

Ein Beispiel: Im Versorgungsauskunft-Rechner werden verschiedene Ruhestandarten unterstützt. Reguläre Altersruhestand, Antragsruhestand, Dienstunfähigkeit, Engagierte Ruhestand und Altersteilzeit. Letztlich will man für alle Arten aber dieselbe Informationen ermitteln, z.B. die Validierung der Eingangsvoraussetzungen, die Berechnung des Versorgungssatz oder eines Versorgungsabschlag etc. Aus diesem Grund wäre es natürlich sinnvoll, die o.g. Ruhestandsarten einheitlich bearbeiten zu können. Dafür könnte man beispielsweise das Interface "Pension" verwenden. In diesem Interface beschreibt man dann, welche Funktionen für die Erstellung und Bearbeitung einer Versorgungsauskunft erforderlich sind. Ein konkretes Beispiel wäre dann z.B. eine Methoden zur Validierung, ob die Voraussetzungen für den Ruhestandeintritt in die jeweils ausgewählte Ruhestandsart mit den übergebenen Eingabedaten überhaupt erfüllt sind. Die Implementierung der Validierung ist abhängig von der gewählten Ruhestandsart unterschiedlich. Auch bei der Berechnung von Versorgungsabschläge ist es wichtig, welche Ruhestandart ausgewählt wurde. In der einen Variante können die Abzüge bis zu 14,4% (Antragsruhestand) betragen, im anderen Fall nur bis max. 10,8% (Dienstunfähigkeit) oder es fallen überhaupt keine Abschläge (Engagierter Ruhestand) an. Wenn wir also alle Funktionen, die übergreifend für alle Ruhestandsarten benötigt werden in einem Interface zusammenfassen und dann in verschiedenen Klassen die konkrete Implementierung für die jeweiligen Ruhestandsart vornehmen, können wir den Client von der konkreten Implementierung entkoppeln. Änderungen in der Implementierung haben dann keinerlei Auswirkungen mehr auf den Client, solange das Interface stabil bleibt. Bisher sieht das Interface für die Erstellung einer Versorgungsauskunft wie folgt :

Code: Alles auswählen

public interface Pension {

	Person getPerson();
	
	String getPensionTyp();
	
	void setBesoldungstabelle(IBesoldungstabelle besoldungstablle);
	
	Set<ITimePeriod> getTimePeriods(); 
	
	void setTimePeriods(Set<ITimePeriod> timePeriods);
	
	IKindererziehungszeitenZuschlag getKindererziehungsZuschlag(); 
	
	void setKindererziehungsZuschlag(IKindererziehungszeitenZuschlag kindererziehungsZuschlag);
	
	float calculateRuhegehaltsfaehigenDienstbezug();
	
	float calculateMindestversorgung();

	float calculateAmtsabhaengigeMindestversorgung();
	
	float calculateAmtsunabhaengigeMindestversorgung();
	
	float calculateRuhegehaltssatz_Para_14_1_Neue_Fassung();

	float calculateRuhegehaltssatz_Para_85_Vergleichsberechnung();

	TimePeriodDetails calculateRuhegehaltsfaehigeDienstzeiten_Para_14();

	void calculatePflegeleistungsabzug();

	float calculateErdientesRuhegehalt();

	float calculateAbschlag_Para_14_BeamtVG();
	
	float calculateMaxAbschlag_Para_14_BeamtVG();
	
	float getAbzugPflegeleistung();

	float getFaktorAbzugPflegeleistungNachBeamtVG_50_f();
	
	float getAmtsabhaengigeMindestversorgung();

	float getAmtsunabhaengigeMindestversorgung();
	
	ValidationResult validate();

	void addTimePeriod(ITimePeriod timePeriod);

	void addDeductionPart(IDeductionPart deductionPart);

	void addAdditionPart(IAdditionPart additionPart);

	String getAnzwRecht();

	boolean isVergleichsberechnungBeamtVG_PARA_85();

	void setVergleichsberechnungBeamtVG_PARA_85(boolean vergleichsberechnungBeamtVG_PARA_85);

}
Im Prototypen des Versorgungsauskunft-Rechner haben wir die fachlichen Anforderungen zumindest für den Moment erstmal soweit, wie wir das in der vorangegangenen Anforderungsanalyse geplant hatten, implementiert. Die Umsetzung der fachlichen Anforderungen in den programmierten Java-Sourcecode haben wir im sog. Anwendungskern vorgenommen. Der Anwendungskern ist soweit wie möglich frei von technischen Restriktionen, die sich durch die Verwendung technischen Hilfsmittel (z.B. technische Frameworks für die GUI) ergeben. Insofern haben wir bereits schon im Prototypen darauf geachtet, das wir nicht wahllos neue Projekte, Packages und Klassen anlegen und nicht darauf achten, wie die Abhängigkeiten innerhalb der erstellten Softwareartefakte untereinander aussehen.

Ein weiterer Fokus für gutes Software-Design sollte meiner Meinung nach darauf gerichtet werden, das sog. "Dependency-Management" der beteiligten Software-Artefakte so gut wie möglich zu bewerkstelligen. Die Abhängigkeiten der erstellten Software-Artefakte sollte nach vorher festgelegten Regeln erfolgen. Vieles von dem was "mal eben" reinimplementiert wird, fällt einem regelmäßig zu einem späteren Zeitpunkt wieder vor die Füße und je komplexer das System wird desto eher und häufiger wird dies passieren. Die Sichtbarkeit von Klassen, Methoden und Attributen oder Abhängigkeiten von Projekten und Packages ist muss festgelegt werden. Zirkuläre Referenzen zwischen Projekten (d.h. Projekt A benötigt zu erfolgreichen kompilieren Projekt B und Projekt B benötigt Projekt A) müssen strikt vermieden werden. Bei der Sichtbarkeit von Klassen, Attributen, Methoden sollte man erstmal so restriktiv wie möglich vorgehen. Alles was nur innerhalb der eigenen Klasse, Package oder Projekt sichtbar ist, vermeidet eine ungewollte Abhängigkeit in einem anderen Projekt. Das hört sich vielleicht sehr theoretisch an, aber das ist tatsächlich eines der größten Probleme in komplexer werdenden Softwareprojekten.


Ein zu viel an Software-Design kann aber auch zum Problem werden, z.B. dann, wenn man das gerade gelernte Design-Pattern unbedingt anwenden möchte und dann unnötiges "Überdesign" vornimmt. Interfaces, also die Deklaration einer Schnittstelle, sind nach der reine Lehre eine super Idee. Wenn man allerdings jede triviale Implementierung mit einem Interface nach außen hin kapselt, wird es sehr schnell unübersichtlich. Ein zu viel an unnötigen Software-Design Maßnahmen kann deshalb ebenfalls problematisch werden.

Für die Einleitung zu dem Thema "Software-Design sollte das erstmal reichen.

Wie bereits in früheren Beiträgen erwähnt, möchte ich mich bei der weiteren Entwicklung des Versorgungsauskunft-Rechner auf das "Eclipse Rich-Client Framework (RCP)" abstützen. Dieses Framework basiert auf sog. OSGi-Bundles. OSGi-Bundles kann man als Software-Komponenten ansehen. Jedes OSGi-Bundle muss seine Abhängigkeit zu anderen OSGi-Bundles und die nach außen exportierte Sichtbarkeit der im OSGi-Bundle enthaltenen Softwareartefakte in einem sog. Bundle-Manifest explizit bekanntgeben. Eine OSGi-Runtime stellt dann sicher, das alle Abhängigkeiten aufgelöst werden können. Diese Vorgehensweise ist weitaus mächtiger als der "normale" Classloader-Mechanismus der "Java Virtual Machine". In einer OSGi-Runtime können beispielsweise verschiedene Versionen desselben Bundles verwendet werden, weil das anfordernde OSGi-Bundle der OSGi-Runtime die gewünschte Version eines OSGi-Bundle explizit mitteilen kann.

Wie so ein Bundle-Manifest aussieht zeigt die folgende Grafik:
OSGi-Bundle Manifest-File
OSGi-Bundle Manifest-File
Außerdem ist es in einem OSGi basierten System auch möglich, das einzelne OSGi-Bundles während des laufenden Betrieb nachgeladen oder ausgetauscht werden können. Aus Software-Design technischer Sicht hebt so eine OSGi-Platform die Qualität der Software ungemein. Eine irgendwie zusammengebastelte Software wird man in einer OSGi-Runtime vermutlich niemals zum Laufen bringen. Ganz einfach deshalb, weil man gezwungen wird, bei den selbst erstellten OSGi-Bundles das "Dependency-Management" zu anderen OSGi-Bundles explizit festzulegen. Mal eben die ein oder andere Klasse von "private" auf "public" setzen oder eine neue Fremdbibliothek in den Classpath aufnehmen funktioniert in einer OSGi basierten Umgebung schlichtweg nicht.

Was bedeutet das nun für die Weiterentwicklung des Versorgungsauskunft-Rechner? Ich habe jetzt für das weitere Vorgehen erstmal die folgenden Komponenten identifiziert, welche ich bereits als OSGi-Bundles anlegt habe. Die im Prototypen bereits vorhandenen Softwareartefakten wurden dabei so weit wie möglich 1:1 übernommen.
In der folgenden Grafik habe ich mal versucht das in einem UML-Diagramm darzustellen. Mein Tool unterstützt leider keine UML-Komponenten-Diagramme, aber ich denke für
diese Zwecke hier tut es auch ein UML-Klassendiagramm.
  • de.protin.support.pr.api beinhaltet alle Klassen und Interfaces, die keinerlei Abhängigkeiten zu anderen Plugins haben
  • de.protin.support.pr.core beinhaltet die Klassen, die den fachlichen Anwendungskern implementieren
  • de.protin.support.pr.gui beinhaltet alle Klassen, die für die GUI benötigt werden
  • de.protin.support.pr.main beinhaltet die Klassen und Resourcen, welche für die Anbindung und Integration in das e4 Framework benötigt werden
  • de.protin.support.pr.resources beinhaltet Resourcen wie Bilder, Icons, CSS-Files, die von den anderen Plugins benötigt werden
  • de.protin.support.pr.service.impl beinhaltet die Implementierungen der im API-Plugin vorhandenen Service-Interfaces
  • de.protin.support.pr.swt.customized entspricht den Prototyp-Projekt "CustomizedSWT"
UML Model der im Design-Refactoring  entstandenen OSGi-Bundles
UML Model der im Design-Refactoring entstandenen OSGi-Bundles
Die Abhängigkeiten alle verwendeten OSGi-Plugins untereinander kann man sich auch in der Eclipse-IDE in einer speziellen Ansicht anzeigen lassen.
Dependencies der OSGi-Bundles
Dependencies der OSGi-Bundles
Alle o.g. OSGi-Bundles haben Abhängigkeiten zum "Eclipse Rich-Client-Framework". Das "Eclipse Rich-Client-Framework" selber besteht aus ca. 80-90 OSGi-Plugins, der sog. Target-Platform. Das macht die Mächtigkeit dieses Frameworks aus. Im Prototypen musste wir uns noch um alles selber kümmern. Das Starten der Anwendung, das Event-Handling, den Aufbau der GUI mit Menueinträgen. Jede einzelne feingranulare Steuerung mussten wir selber implementieren. Im Eclipse-Framework klinken wir uns mit unseren selbst erstellten OSGi-Bundles lediglich in bereits vorhandenen sog. Extension-Points ein. Diese im Framework vorhandene Funktionalität ist mit Sicherheit in einer Qualität, die wir mit unseren Möglichkeiten nicht erreichen würden. Das Eclipse-Framework wird seit mittlerweile mehr als 10 Jahren auch von vielen großen Firmen weltweit eingesetzt, ist sehr stabil und ausgereift. Vielleicht nicht so "hip", wie die neuesten Web-Frameworks, aber für unsere Zwecke mehr als ausreichend.

Ein weiterer Vorteil der OSGi-Runtime ist, dass man auch während der Programmausführung den Status der einzelnen OSGi-Bundles anschauen und falls nötig ändern kann.
Damit ist es möglich - sofern die Anwendung entsprechend präpariert ist - während der Programmausführung neue OSGi-Bundles hinzuzufügen oder OSGi-Bundles zu stoppen und neu zu starten. Wie die Auflistung der vorhandenen OSGi-Bundles inklusive des jeweilige Status zur Laufzeit aussieht, kann der folgenden Grafik entnommen werden.
OSGI-Console - Liste der verfügbaren OSGi-Bundles
OSGI-Console - Liste der verfügbaren OSGi-Bundles
Die OSGi-Console zur Steuerung der OSGi-Runtime verfügt über eine ganze Reihe an Möglichkeiten sich über den Zustand der Anwendung zur Laufzeit zu informieren oder Aktionen vorzunehmen, um entweder Probleme zu beseitigen oder neue Features zu starten. Zum Abschluss noch ein Screenshot mit einem kurzen Ausschnitt den der Befehl "help" in der OSGi-Console ausgibt.
OSGi-Console - Help Command
OSGi-Console - Help Command

In den nächsten Wochen wird es nun darum gehen, den "Versorgungsauskunft-Rechner" mit den neu vorhandenen Möglichkeiten optisch aufzuwerten. Neue fachliche Anforderungen haben sich bisher nicht ergeben und Fehlermeldungen über falsche Berechnungen o.ä. wurden aus der Community bisher auch noch nicht gemeldet. Insofern können wir uns voll und ganz darauf konzentrieren, die Software auch optisch etwas aufzuwerten, indem wir einigen neue GUI-Elemente einbauen, um auch solche Parameter anzuzeigen, die wir bisher lediglich als konstante Werte direkt im Sourcecode hinterlegt hatten. Außerdem plane ich noch verschiedene Perspektiven anzulegen, um die GUI thematisch etwas zu ordnen. Damit die GUI nicht zu überladen wirkt, sollen die im System hinterlegten Besoldungstabellen und die übrigen berechnungsrelevanten Parameter sowie die Eingabedaten für die zu erstellende Versorgungsauskunft in separaten Perspektiven angezeigt werden. Ich bin ganz zuversichtlich, dass in einigen Wochen dann deutlich wird, welche Vorteile der Umstieg auf das Eclipse RCP-Framework tatsächlich bewirkt hat. Mit dem Umbau des Prototypen in eine RichClient-Anwendung auf Basis des Eclipse-Framework haben wir jetzt umgangssprachlich einen Kleinwagen auf dem Fahrgestell einer Luxuskarosse. Mal sehen was wir im weiteren Projektfortschritt daraus machen können.
Bernd Malessa
Beiträge: 14
Registriert: 06.01.2020

Re: Neue Version des Versorgungsprognose-Rechner verfügbar

Beitrag von Bernd Malessa »

Die neue Version des Versorgungsprognose-Rechner wurde jetzt fertiggestellt und steht bereits im Github-Repository zum Download bereit.
Die URL zum Github-Repo lautet: "https://github.com/bmalessa/ER-Software". Der direkte Download kann über folgende URL erfolgen: https://github.com/bmalessa/ER-Software ... master.zip. Wer den Versorgungsprognose-Rechner mal gerne ausprobieren möchte, sollte folgende Arbeitsschritte ausführen:

1) Download des komplette Git-Repository von der o.g. URL (wird dann als "ER-Software-master.zip" auf den lokalen Rechner runtergeladen)
2) Entpacken des ZIP-Files
3) In den Ordner "Versorgungsauskunft-Rechner\RichClient\Deploy\Ruhegehalt-Prognose" des ausgepackten ZIP-Files wechseln.
4) Die Datei "rgPrognose.exe" aufrufen (funktioniert nur für Windows) Falls nicht mit Windows, sondern mit einem anderen Betriebssystem gearbeitet wir (z.B. Linux oder MacOS) muss ein entsprechendes Start-Skript erstellt werden. Als Vorlage dafür kann das Batch-Skript "runApp.bat" im unter Punkt 3 genannten Ordner verwendet werden.

In den vergangenen Wochen habe ich über den Fortschritt und die technischen Herausforderungen der neuen Version in diesem Forum einige Beiträge eingestellt. Der wesentliche Unterschied zur bisherigen "Prototyp-Version" liegt darin, dass die neue "RichClient-Version" auf dem Eclipse-RCP-Framework basiert und modular auf der Basis von OSGi-Bundles implementiert wurde. Das Eclipse-Framework bietet viele neue Möglichkeiten. So wurden u.a. verschiedene Perspektiven in die Anwendung aufgenommen, die den Fokus auf bestimmte Teilaspekte legen. Die Perspektive "Versorgungsprognose" entspricht im Funktionsumfang in etwa der Funktionalität, die bereits in der Prototyp-Version vorhanden war. Allerdings wurde die GUI in einigen Bereiche nochmal "aufgeräumt". Zusätzlich ist jetzt auch noch ein Browser-Widget in die Anwendung integriert worden, mit dem ein schneller Zugriff auf versorgungsrelevante Informationen im Internet möglich ist. Einige Links (z.B. zum Gesetzestext des BeamtVG) sind bereits als "Favoriten" gespeichert und können - sofern ein Internetverbindung vorhanden ist - direkt in der Anwendung aufgerufen und angesehen werden (siehe Screenshots weiter unten).

Zusätzlich wurden zwei weitere Perspektive angelegt, um alle im System bekannten Parameter, die zur Berechnung der Versorgungsprognose benötigt werden, anzuzeigen.
Das sind zum einen insgesamt 5 Besoldungstabellen für Bundesbeamtinnen und -beamte für verschiedene Gültigkeitszeiträume. Damit sind nun auch rückwirkende Berechnungen bis zum Zeitraum März 2016 möglich. Dadurch wird es ermöglicht, durch entsprechende Vergleiche mit bereits vorhandene Versorgungsauskünfte der BAnstPT die Vollständigkeit und Fehlerfreiheit der internen Berechnungsalgorithmen zu validieren.

Außerdem wurde noch die Perspektive "Einstellungen" erstellt, in der weitere Parameter, die für die Berechnung der Versorgungsprognose relevant sind, angezeigt werden. Diese Informationen waren bisher an der GUI nicht sichtbar, sondern wurden lediglich als konstante Werte in den jeweilige Berechnungen genutzt. Zum Verständnis und ggf. erforderlichen Fehleranalyse kann es aber sehr hilfreich sein zu wissen, auf welchen Berechnungsparametern eine Versorgungsprognose basiert.

Optisch ist die GUI durch einige Überarbeitung und den Einsatz von grafischen Elemente (Icons und selbst erstellte Bilder) für die Buttons, Menupeinträge und einem Info-Dialog nochmal etwas "aufgehübscht" worden. Insgesamt macht das Ganze jetzt rein optisch schon einen "professionelleren" Eindruck als die Prototyp-Version.

Hier mal ein paar Screenshots zu den oben erwähnten Perspektiven.

Die Perspektive "Versorgungsprognose" und die darin enthaltenen Views "Grunddaten", "Aktuelle Besoldungstabelle", "Browser"
Perspektive &quot;Versorgungsprognose&quot;
Perspektive "Versorgungsprognose"
Die Perspektive "Besoldungstabellen" zeigt die im System bekannten Besoldungstabellen
Perspektive &quot;Besoldungstabellen Bund&quot;
Perspektive "Besoldungstabellen Bund"
Die Perspektive "Einstellungen" zeigt die Informationen zu bestimmten versorgungsrelevanten Parametern sowie die Berechnungswerte für Pflegeversicherungsbeiträge und Kindererziehungszeiten
Perspektive &quot;Einstellungen&quot;
Perspektive "Einstellungen"

Und hier noch einige weitere Screenshots zu neu hinzugekommenen und/oder neu gestalteten GUI-Elementen:

Das Layout der Versorgungsprognose-Berechnung wurde neu gestaltet. Die feingranulare und fehleranfällige Formatierung im Richtext-Widget wurde durch Verwendung eines SWT-GridLayout ersetzt. In der Formatierung führt dies nun zu "vorhersehbareren" Verhalten. Die Richtext-Formatierung für den Ausdruck in ein PDF-Dokument wurde beibehalten, da eine Änderung des Layout-Mechanismus für den PDF-Druck nur mit erheblichen Aufwand möglich ist.
View &quot;Versorgungsprognose&quot;
View "Versorgungsprognose"
Das Browser-Widget integriert einen Webbrowser in die Anwendung. Damit können Information aus dem Internet direkt in der Anwendung angezeigt werden. Voraussetzung ist natürlich eine bestehenden Internet-Verbindung. Einige Favoriten-URLs sind bereits eingerichtet, so dass z.B. direkt auf den Geestztestext des BeamtVG zugegriffen werden kann.
View &quot;Browser&quot;
View "Browser"
Außerdem wurde noch ein Info-Dialog erstellt, der über die Menuauswahl "Hilfe/Info" aufgerufen werden kann.
About-Dialog
About-Dialog
Durch die Aufnahme der "Material-Design-Icon-Library " wurden die grafischen GUI-Elemente wie Buttons, Menueinträge und die Toolbar visuell unterstützt. Neben der optischen Aufwertung evtl. auch noch für Aspekte bzgl. der Barrierefreiheit ganz nützlich.
Menu und Toolbar der Anwendung
Menu und Toolbar der Anwendung
Menu und Toolbar.PNG (7.33 KiB) 34 mal betrachtet
Haupt-Menu der Anwendung
Haupt-Menu der Anwendung
Menu.PNG.jpg (20.19 KiB) 34 mal betrachtet

Nachdem jetzt ein weiterer Meilenstein geschafft wurde, stehen in den nächsten Wochen noch folgende Aufgaben an. Ich möchte die Anwendung noch um ein Hilfesystem erweitern. Das Eclipse-Framework bietet für diese Aufgaben bereits ein entsprechendes Set an OSGi-Plugins an, die man dafür sinnvoll verwenden bzw. erweitern kann. In dieses Hilfesystem soll noch ein Benutzerhandbuch für die Bedienung der Anwendung aufgenommen werden. Außerdem könnte noch ein Glossar für erklärungsbedürftigen Begriffe aus dem Versorgungsrecht aufgenommen werden. Sobald dieses Hilfesystem fertiggestellt ist und in die Anwendung integriert wurde, werde ich zu diesem Thema nochmal einen Beitrag in dieses Forum einstellen. Ich denke mal, dies wird spätestens Mitte Dezember der Fall sein.

Im nächsten Jahr (vermutlich ab Ende Januar 2021) wird dann die nächste große Änderung/Erweiterung geplant und angegangen. Der aus meiner Sicht größte Nachteil der bisherigen Versionen "Prototyp" und "RichClient" liegt darin, dass jeder Interessierte sich mit zu vielen technischen Details herumschlagen muss. Für jemanden mit entsprechendem IT-KnowHow ist es kein großes Thema sich mit einer Java-Runtime zu beschäftigen, aber für Menschen ohne oder mit nur geringen IT-Kenntnisse kann das schon eine große Hürde darstellen und davon abhalten, sich mit dieser Software überhaupt erst zu beschäftigen. Deshalb plane ich die Portierung der Anwendung in eine Web-Applikation. Wenn dies funktioniert, benötigt man zur Bedienung der Anwendung lediglich noch einen der gängigen Internet-Browser. Der Download des (u.a. aufgrund der integrierten Java-Runtime) relativ großen Zip-Files vom Github-Repository wäre dann nicht mehr notwendig. Das ist ein ziemlich aufwändiges Vorhaben, aber grundsätzlich bin ich optimistisch, dass dies funktionieren kann. Das Eclipse-Framework bietet auch für diese Aufgabe eine ganze Menge an Unterstützung an. Wie bereits erwähnt wird dieses Thema aber erst im nächste Jahr angegangen. Bis dahin bleibt also noch jede Menge Zeit, die jetzt vorhanden Lösung ausgiebig zu testen und bekannt zu machen - zum Beispiel durch Mund zu Mund Propaganda oder durch Beiträge in entsprechenden Foren, z.B. auch im "You and Me Portal" der Telekom. Als Ruheständler habe ich zum YAM-Portal leider keinen Zugang mehr, aber vielleicht finde sich ja jemand, der das übernehmen könnte und in einer der YAM-Gruppen, die sich um Versorgung und Ruhestand kümmern (z.B. "Engagierter Ruhestand" oder "Altersteilzeit") mal einen Hinweis auf die jetzt verfügbare Lösung publiziert. Ich denke, mittlerweile ist die Software in einer Qualität, dass man sich zumindest hinter anderen frei verfügbaren Rechnern im Internet nicht verstecken braucht.

Wer in der Zwischenzeit noch Fragen zur Anwendung hat oder Unterstützung bei der Installation, Inbetriebnahme etc. benötigt oder wer fehlerhafte Berechnungen feststellt, kann mich gerne per PN benachrichtigen oder sein Anliegen durch einen Beitrag hier im Forum kundtun. Sofern gewünscht oder aufgrund wachsenden Interesses erforderlich, werde ich im Bürgerportal ggf. ein neues Forum anlegen, in dem dann konkrete Fragen zur Installation, neue Feature-Request oder gefundene "Bugs" eingestellt werden können.
Antworten