• Vom Bauplan zur fertigen Software

    Die Unified Modeling Language (UML) ist der Standard zur Konstruktion von Software am virtuellen Reißbrett.
    Wir haben die Erstellung individueller Software aus diesen Bauplänen weitgehend automatisiert. Die folgenden Seiten geben dazu einen Überblick.

  • Video Thumbnail
  • UML Literatur

  • Geschichte der UML

    Die UML existiert schon eine geraume Zeit, das erste abgebildete Buch erschien bereits 1998. Warum hat sich also die auto­matisierte Software­erstellung nicht schon lange durchgesetzt?

    • Das war lange nicht beabsichtigt

      Das Hauptziel war ursprünglich, eine gemeinsame verständliche Sprache zwischen den Fachleuten und den Programmierern zu schaffen. Also eher ein Kommunikationsmittel zwischen Menschen als zwischen Menschen und Maschine. Das war bereits ein gewaltiger Fortschritt und schien lange Zeit genug.

    • Vollständigkeit

      Eine technische Zeichnung z. B. für ein mechanisches Bauteil ist in der Regel vollständig. Eine Werkstatt kann ohne weitere Worte das gewünschte Werkstück exakt nach der Zeichnung herstellen. Eine "UML-Zeichnung" ist das gewöhnlich leider nicht. Viele Eigenschaften einer Software lassen sich auch heute noch nicht in einer standardisierten, leicht maschinell verwertbaren Form beschreiben.

  • Anwendungsplattform

    Zur Problematik der Vollständigkeit haben wir einen sehr pragmatischen Ansatz gewählt. Aus der UML verwenden wir zuerst die sogenannten Klassen­diagramme zur Beschreibung der Anwendungs­daten. Das ist der Kernbereich mit dem höchsten "Wirkungs­grad" einer automatischen Ver­arbeitung. In einem Aufbau­schritt lassen sich weitere Diagramm­typen zur Beschreibung von Abläufen verwenden.

    • Lauffähige Basisanwendung

      Die Festlegung des Gesamtaufbaus und der technischen Funktion der Software (Software­architektur) ist mit Blick auf das Ziel­einsatz­gebiet bereits erfolgt und als sogenannte Anwendungs­plattform verwirklicht.

      Der Aufbau einer neuen Software beginnt hier also stets mit einer schon funktions­fähigen Programm­hülle. Auch dieser Grund­aufbau basiert auf der UML. Die wesentliche Entwicklungs­tätigkeit in einem neuen Projekt besteht nun darin, die so gegebene Hülle mit der neuen fachlichen Nutzlast zu versehen.

    • Integrierter Bauplan

      Der UML-Bauplan ist nicht nur Ausgangs­punkt für die automatische Erzeugung des Programm­gerüsts, sondern wird vollständig in die Software integriert. Dort ist er dann als eingebettetes Fachwissen Informations­grundlage für die Arbeit der "intelligenten" technischen Grund­funktionen.

  • Basisanwendung
  • Instrument

  • Modellierung ...

    Hauptaktivität der Entwicklung ist die Erstellung neuer UML-Baupläne.

    • Virtuelles Reißbrett

      Als Modellierungsplattform verwenden wir derzeit Atlassian Confluence in der Cloud. So können wir standortunabhängig eng mit Kunden am gemeinsamen Projekt arbeiten. Die Bearbeitung der UML-Diagramme erfolgt mit dem dort integrierten Gliffy.

    • Klassen und Vererbung

      Ein mächtiges Ausdrucksmittel der objektorientierten Modellierung ist die Beschreibung neuer Strukturen als Variation bereits vorhandener Strukturen. So wird nicht jedes sprichwörtliche Rad neu erfunden. Die hier dargestellte Klasse (Musik-)instrument ist die Erweiterung eines als Grundbaustein vorhandenen Anlageguts (Klasse Asset). Die Verbindungslinie mit geschlossener Pfeilspitze zeigt diese sogenannte Vererbung.

  • ... Modellierung

    Hier die wichtigsten weiteren Ausdrucksmittel in Klassendiagrammen.

    • Attribute

      Klassen werden als Rechteck mit Abteilungen dargestellt. In der hier mittleren Abteilung befinden sich die sogenannten Attribute. Das sind in der Außensicht Datenfelder unabhängig davon, ob sie tatsächlich intern gespeichert oder aus anderen Quellen berechnet werden. Über vielfältige Parameter lassen sich solche Besonderheiten steuern.

    • Operationen

      Für unsere Plattform werden hier in einer weiteren Abteilung parameterlose Kommandos z. B. für Schaltflächen und Menüs definiert. Weitere auch parameterbehaftete Operationen für komplexe interne Programmlogik werden ggf. an sogenannten Erweiterungspunkten eingefügt.

    • Assoziationen

      Assoziationen sind Verbindungen zwischen Datenobjekten, z. B. die Adressen einer Person. Diese Zuordnungen können explizit gespeichert sein, oder wie hier als Ergebnis einer Suche aus den angegebenen Kriterien "berechnet" werden. Berechnete Assoziationen werden wie auch bei Attributen mit einem Schrägstrich vor dem Namen gekennzeichnet.

  • Instrumentenliste
  • Codegenerierung

  • Codegenerierung

    Jetzt wird es ernst. Aber halt! Muss das sein?

    • Eine strategische Entscheidung

      Grundsätzlich ist es möglich, die Anwendungsdaten direkt zwischen Benutzeroberfläche und Datenbank "hin und her zu schieben" und auch einfache Operationen mit sogenannten Script-Sprachen auszuführen.

      Eine Programmiersprache und -plattform für Unternehmensanwendungen wird dann benötigt, wenn die Programmobjekte direkt oder indirekt zur Integration mit anderen Softwaresystemen, -komponenten oder -diensten benötigt werden bzw. die internen Funktionen der Anwendung eine höhere Komplexität erreichen. Dieser Umstand tritt erfahrungsgemäß für jede nicht nur kurzlebige Software früher als gedacht ein.

      Unser Angebot richtet sich an Anwender, die eine strategische Entscheidung in diesem Sinne notwendigerweise oder vorausschauend treffen.

    • Programmierumgebung

      Die Abbildung links gewährt einen Blick in unsere Java-Programmierumgebung auf Basis von Eclipse und dem Spring-Framework. Dort haben wir unsere Komponenten integriert, welche die UML-Baupläne aus der Cloud aktualisieren, das Programmgerüst erstellen und weiterpflegen, und andere nützliche Dienste erledigen. Für einfache Änderungen ergibt sich eine sogenannte Zykluszeit von wenigen Minuten.

  • Datenbank

    Abschließend noch ein Blick auf die technische Datenbankanbindung.

    • Kapselung

      Die Kapselung spezifischer technischer Aufgaben ist ein zentrales Grundprinzip robuster objektorientierter Softwarearchitekturen. Das bedeutet hier, dass die Erzeugung und Anbindung der Datenbank kein direkter Bestandteil der Codeerzeugung aus der UML ist. Vielmehr ist das die Aufgabe einer sogenannten Storage-Komponente, welche mit ihrer Umgebung per sogenanntem Schnittstellenvertrag verbunden ist. Zu diesem Vertrag gehört der Lesezugriff auf den eingebetteten UML-Bauplan. Wie eine solche Komponente die Aufträge zum Lesen und aktualisieren der ihr anvertrauten Anwendungsobjekte erledigt, obliegt ihrer Eigenverantwortung. Dazu gehört auch das Verfahren, wie die logische Abbildung (Mapping) der Programmobjekte auf z. B. Strukturen einer relationalen Datenbank (RDB) erfolgt.

    • Aktuelle Oracle-Anbindung

      Für viele Anwendungsfälle ist die Anbindung zunächst einer Hauptdatenbank ausreichend. Für diese erste Stufe haben wir die Oracle-Datenbank ausgewählt. Die Festlegung der Tabellenstruktur erfolgt hier unveränderlich nach einem für Durchschnittsbedingungen bewährten Schema. Alternative Lösungen könnten hier einen variabel konfigurierbaren Ansatz vorsehen.

  • Datenbank
  • Ausbildungsportal

  • Voilà

    So oder ähnlich oder auch ganz anders könnte Ihre Anwendung aussehen.

    • Arbeitsplatzmodell

      Auch Struktur und Zusammenspiel der Elemente von typischen Oberflächen-Layouts sind wiederum per UML beschrieben. Hier sind es Workspace, Apps und Views. Auch die schon erwähnten Templates sind per UML erweiterbar, so dass sich Eigenschaften für eine individuelle Anzeigesteuerung ergänzen lassen.

      Durch Kombination all dieser Techniken kann jeder individuelle Wunsch an Gestaltung und Verhalten der Benutzeroberfläche erfüllt werden.

    • Ausbildungsportal

      Das hier beispielhaft gezeigte Ausbildungsportal ist eine produktive Anwendung, die wir gerade für den genannten gemeinnützigen Verein entwickeln. Wir betreiben das System sicher nach DSGVO in der Amazon Cloud (AWS).

      Mit unserer Technik sind wir in der ausgezeichneten Lage, auch eine nichttriviale Individualsoftware (magische Losgröße Eins) z. B. im Abonnement ab ca. 350 €/Monat zur Verfügung zu stellen (Unternehmenslizenz, Laufzeit 5 Jahre).

Noch Fragen?

Natürlich gerne.
Oder per Email mit einer kurzen Vorhabensskizze für eine erste unverbindliche Kalkulation.

Zurück

Einsatzgebiete

Unsere Plattform ist prädestiniert für langlebige, intra- und internetfähige Datenbankanwendungen in einem professionellen bzw. geschäftlichen Umfeld.

Als Anwendergruppen sehen wir Selbständige, Freiberufler und kleinere bis mittlere Unternehmen bzw. Organisationen, welche eine professionelle, individuelle und dennoch erschwingliche zukunftsfähige Softwarelösung benötigen.

Wir entwickeln unsere Plattform mit dem Hauptziel, im eigenen Unternehmen für alle individuellen Unternehmensprozesse eine homogene optimale Lösung zu bekommen. Eingeschlossen sind dabei Integrationen mit ausgewählten leistungsfähigen und zukunftssicheren Systemen wie z. B. DATEV und die transparente Einbindung von Cloud-Diensten. Als Softwarefirma haben wir den Vorteil, das selbst leisten zu können. Diesen Vorteil wollen wir gerne teilen.

Bereits im praktischen Einsatz sind folgende Funktionen: Dokumentenmagement und -archivierung, Leistungsabrechnung und Rechnungslegung, Dokumentenerstellung, Inventarisierung, ausgewählte Controllingaufgaben.

Schließen
Zurück

Laufzeitkomponenten

Laufzeitkomponenten sind Bestandteile (Komponenten) der sogenannten Laufzeitumgebung. Sie ist das Fundament der Anwendungsplattform und übernimmt die technischen Aufgaben (Dienste) zur Unterstützung der eigentlichen fachlichen Funktionen der Software. Die beiden wichtigsten Komponenten sind unten kurz dargestellt.

Wir haben unsere Laufzeitkomponenten mit der erforderlichen "Intelligenz" ausgestattet, den eingebetteten UML-Bauplan zu verstehen, und zur Erfüllung ihrer Funktion zu verwenden. Damit wird der Programmierer im bestmöglichen Umfang von aufwändigen und fehleranfälligen Routinearbeiten entlastet.

Datenbank

Ihre Daten dürfen natürlich nicht verloren gehen und sollen auch anderen Benutzern der Software zugänglich sein. Zur sicheren und langfristigen Speicherung und parallelen Bearbeitung durch mehrere Benutzer werden profesionelle sogenannte Datenbanksysteme eingesetzt. Bei klassischem Vorgehen besteht eine enge Verknüpfung von Anwendungsinhalten und Datenbanktechnik die vom Programmierer aufwändig hergestellt und unterhalten werden muss. Auf unserer Plattform ist die Anbindung einer spezifischen Datenbank eine austauschbare Komponente, die ihre Arbeit auf Grundlage des eingebetteten UML-Bauplans vollautomatisch erledigt. Dabei können auch unterschiedliche Datenbanken und besondere Speichertechniken kombiniert werden. Der übrige Teil der Software, insbesondere die fachlichen Funktionen bleiben davon unberührt. Tatsächlich ist auch der generierte Programmcode vollkommen unabhängig von der jeweiligen Speichertechnik.

Benutzeroberfläche

Die heimliche Hauptattraktion unserer Plattform ist das Prinzip der Benutzeroberfläche. Auch diese wird unter Bezugnahme auf den UML-Bauplan ohne Programmierung gestaltet. Die serienbriefähnlichen Vorlagen unter Verwendung vorgefertigter und ggf. neugeschaffener Oberflächenelemente werden in der Datenbank gespeichert und über ein erweiterbares intelligentes Auswahlverfahren (Matching) zur Anzeige gebracht. Das Übertragungsprotokoll zwischen Server und Endgeräten ist geräte- und anwendungsneutral. Die Übertragung eines minimalen Datenvolumens zur Aktualisierung der Oberfläche wird durch eine vollautomatische inkrementelle Änderungsermittlung erreicht.

Schließen