-
Die Erfindung betrifft ein computerimplementiertes Verfahren, einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge sowie eine Rechneranlage zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Softwaresysteme im Prozess der Entwicklung neuer Anwendungen für Rechneranlagen oder rechnergestützte Systeme, und ein Computerprogramm mit Programmcode, welches die Verfahrensschritte durchführt, wenn das Computerprogramm auf einem Computer oder einem Computernetzwerk ausgeführt wird.
-
Es werden Softwaresysteme betrachtet, die eine visuelle Programmierumgebung für die Programmierung von Softwarekonfigurationen beinhalten, Möglichkeiten des Exports von Teilkonfigurationen bieten, und ferner sowohl Werkzeuge um diese zu ablauffähigen Softwarekonfigurationen zusammenzubauen, als auch eine Ablaufumgebung für diese Softwarekonfigurationen beinhalten.
-
Bei der Entwicklung von Software stellt sich zunehmend das Problem, dass Anwendungen in kürzeren Entwicklungszeiten und zu geringeren Kosten bei gleichbleibend hoher Qualität zur Verfügung gestellt werden sollen.
-
Eine Möglichkeit diese Ziele zu erreichen liegt darin, bereits als qualitativ hochwertig bekannte Anwendungsbestandteile in anderen Projekten wieder zu verwenden. Die „bausteinorientierte Softwareentwicklung” ist nur dann einsetzbar, wenn bestimmte Rahmenbedingungen eingehalten werden. So muss gewährleistet sein, dass alle für die Implementierung relevanten Einstellungen, ohne Auswirkung auf die Schnittstellen der Bausteine, lokal verändert werden können.
-
Durch die Wiederverwendung der Bausteine muss der Entwicklungsprozess für eine neue Anwendung nicht immer wieder von vorne begangen werden, sondern kann auf bereits entwickelte, validierte und verifizierte Komponenten zurückgreifen, so dass Anwendungen mit weniger Aufwand entwickelt werden können. Wiederverwendbarkeit wird als eine Eigenschaft angesehen, die nicht nachträglich einer Komponente hinzugefügt werden kann.
-
Der Hintergrund dieser Problemstellung ist beispielsweise beschrieben in „Wissensmanagement und Software Engineering – Wiederverwendbarkeit" (www.community-of-knowledge.de/beitrag/wissensmanagement-und-software-engineering-wiederverwendbarkeit/) oder in „Software nach dem Baukastenprinzip" (Prof. Dieter Rombach, Fraunhofer Magazin 1.2003).
-
Aufgrund der Schwierigkeiten, Software-Bausteine für die Wiederverwendbarkeit heranzuziehen, muss man im Stand der Technik davon ausgehen, dass nur solche Anwendungen für die Wiederverwendung geeignet sind, die bereits bei der Konzeption für eine spätere Wiederverwendung ausgelegt wurden. Die Ansprüche an die Adaptierungsmöglichkeiten, Funktionalität, Schnittstellen etc. sowie die Verwaltung der wiederverwendbaren Komponenten in entsprechenden Software-Bibliotheken, können bei dieser Sichtweise nur dann erfüllt werden, wenn die Komponenten z. B. in einem objektorientierten Rahmen erstellt und entsprechend organisiert zur Verfügung gestellt werden. Eine weitere Variante wäre das Prototyping aus dem Rapid Application Development(RAD)-Ansatz, wo z. B. vorgefertigte Prototypen als Bibliothek in einem RAD Tool bereitgestellt werden.
-
Der grundlegende, übliche Ansatzpunkt bei der Entwicklung einer Software unter Verwendung von Schablonen liegt in der Erkenntnis, dass sich Lösungen zwar fachlich unterscheiden, jedoch unter gewissen technischen Gesichtspunkten ähneln. Durch Abstraktion können technische Lösungsmuster gefunden werden, die sich zur Entwicklung von Schablonen eignen. Je mehr sich das Verhalten abstrahieren lässt, desto allgemeiner einsetzbar und somit wertvoller sind solche Schablonen. Solche Lösungsmuster auf dem Gebiet der Enterprise Application Integration (EAI) wurden z. B. durch Gregor Hohpe, Bobby Woolf veröffentlicht in „Enterprise Integration Patterns. Designing, Building, and Deploying Messaging Solutions", Addison Wesley, 20. Oktober 2003, ISBN 978-0321200686.
-
Im Gegensatz zu solchen, nach dem Baukastenprinzip erstellten Komponenten, werden Konfigurationen für Standardsoftware im Stand der Technik nicht als geeignet für die Wiederverwendung bei der Anwendungsentwicklung angesehen.
-
Im Stand der Technik sind zahlreiche Methoden entwickelt worden, um die Erstellung von Software zu beschleunigen und zu vereinfachen.
-
So beschreibt beispielsweise die
DE 698 38 139 T2 ein Verfahren und ein System zur Schaffung von Datenbankanwendungssoftware, die minimales Programmieren benötigen. Dabei wird eine Methode zum automatischen Erzeugen von komplexen Softwareanwendungen ohne eingehende traditionelle und detaillierte Programmierung vorgestellt. Hierbei wird aus einer geeignet verfeinerten Softwarebeschreibung die Zielsoftware aus einer wiederverwendbaren universellen Softwareanwendung erzeugt.
-
Die
DE 690 31 078 T2 beschreibt eine rechnergestützte Softwareentwicklungseinrichtung, bei der unter anderem auch ein Augenmerk auf Wiederverwendbarkeit gerichtet ist. Der Aspekt der Wiederverwendbarkeit wird durch die Verwendung einer höheren Regelsprache realisiert, in der die Logik eines Programms in hochmodularer Form festgelegt werden kann und somit die Wiederverwendbarkeit fördert. Bei der automatisierten Erstellung des Quellcodes wird auf die wiederverwendbaren Elemente zurückgegriffen.
-
Gemeinsamer Nachteil des Stands der Technik ist, dass durch den Anwender selbst entwickelte Anwendungen (Softwarekonfigurationen) der Standardsoftware nicht als wiederverwendbare Komponenten für die Entwicklung neuer Anwendungen angemessen berücksichtigt werden können, da kein ausreichender Zugriff auf das Entitäten-Modell per API (Application Programming Interface) angeboten wird. Dadurch sind die Mittel zur Erstellung eigener Software-Bibliotheken mit Hilfe der visuellen Programmierumgebung dieser Standardsoftware dermaßen begrenzt, dass keine oder zumindest keine hinreichende Menge an Komponenten (Schablonen) für solche eigenen Bibliotheken erstellt werden kann, die eine komplexere Programmierung nach dem Baukastenprinzip ermöglicht. Lediglich einfachere Bausteinschnittstellen mit Parameterlisten wären mit dem im Stand der Technik üblichen Mittel, dem Suchen und Ersetzen, möglich. Komplexere Schnittstellen und Parametrisierungen jedoch, wie sie z. B. mit Hilfe von XML Schemas (XSD) erstellt werden können, sind damit nicht realisierbar. Die Generische Programmierung erfordert jedoch eine gewisse Abstraktion von Datentypen, beziehungsweise die Möglichkeit diese zu spezialisieren. XML Schemas würden diese Möglichkeit z. B. durch Neudefinition von Datentypen bieten.
-
Es ist daher Aufgabe der Erfindung, diesen Nachteil zu überwinden und ein Verfahren zur Verfügung zu stellen, mit dem auch bei Standardsoftware wiederverwendbare Bausteine in der Entwicklung neuer Anwendungen verwendet werden können, wobei die Unterstützung generischer Programmierung die wesentlichste Herausforderung ist. Hierbei soll es möglich sein, die einzelnen Bausteine in der visuellen Programmierumgebung weiter zu entwickeln.
-
Es ist auch Aufgabe der Erfindung, einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge bereitzustellen, die es ermöglicht, auch bei Standardsoftware wiederverwendbare Bausteine in der Entwicklung neuer Anwendungen zu verwenden.
-
Weiterhin soll eine Rechneranlage zur Verfügung gestellt werden, die so eingerichtet ist, dass damit auch bei Standardsoftware wiederverwendbare Bausteine in der Entwicklung neuer Anwendungen verwendet werden können.
-
Weiterhin soll ein Computerprogramm mit Programmcode zur Verfügung gestellt werden, welches die Verfahrensschritte durchführt, wenn das Computerprogramm auf einem Computer oder einem Computernetzwerk ausgeführt wird. Der Programmcode kann entweder auf einem Datenträger gespeichert sein, der das Verfahren als maschinenles- und ausführbares Programm enthält oder in einem Computernetzwerk wie z. B. das Internet für Client-Server-Systeme zur Verfügung gestellt werden, die mithilfe des Programms betrieben werden.
-
Diese Aufgaben werden durch das erfindungsgemäße Verfahren gemäß Anspruch 1, einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge gemäß Anspruch 7, ein Computerprogramm mit Programmcode gemäß Anspruch 13 und eine Rechneranlage, eingerichtet als Client-Server-System gemäß Anspruch 14 gelöst. Vorteilhafte Weiterbildungen und Ausgestaltungen sind Gegenstände der abhängigen Ansprüche.
-
Erfindungsgemäß wird auf ausführbare Softwarekonfigurationen für Softwaresysteme mit einer visuellen Programmierumgebung zurückgegriffen. Ein Softwaresystem stellt hierbei ein System von Software-Bausteinen dar, die miteinander in Verbindung stehen und untereinander kommunizieren können. Aus dem Zusammenwirken der Software-Bausteine eines Softwaresystems wird das Zusammenwirken von Teilen eines Computer-Systems, das aus Hardware und Software besteht, ermöglicht. Ein Softwaresystem besteht beispielsweise aus Haupt- und Unterprogrammen sowie Konfigurationsdateien und einer Ablaufsteuerung, welche die Software-Konfiguration ausführt. Eine Software-Konfiguration ist ein Datenmodell, bestehend aus Entitäten und deren Beziehungen, das beschreibt, wie eine Software an die vorhandene Hard- und Software angepasst ist, auf Ereignisse reagiert oder sich anderweitig verhalten soll. Um eine Software unter einer bestimmten System-Konfiguration einsetzen zu können, muss diese entsprechend eingerichtet werden.
-
Erfindungsgemäß wird eine Schablonenbibliothek erstellt, die wiederverwendbare Schablonen der Konfigurationen von Standardanwendungen eines Softwaresystems enthält. Die Schablonen dienen zum Erstellen von Software-Bausteinen, die zu neuen Softwarekonfigurationen zusammengefügt werden.
-
Zunächst müssen die Schablonen erstellt werden. Hierfür muss das Softwaresystem wenigstens eine Möglichkeit zum Exportieren von Teilkonfigurationen aufweisen. Zunächst wird eine Softwarekonfiguration erstellt und durch den Anwender eine Teilkonfiguration, d. h. ein Teilmodell der Konfiguration ausgewählt, das sich aus seiner Sicht zur Vervielfältigung als Schablone eignet und exportierbar ist. Dieser Konfigurationsteil wird dann als Teilkonfiguration in eine neue Schablone innerhalb der Schablonenbibliothek exportiert.
-
Beim Export einer Teilkonfiguration wird somit aus jedem wieder zu verwendenden Teil einer Anwendung mindestens ein Teilmodell einer Konfiguration dieser Anwendung erstellt, das für die Wiederverwendung in einer anderen Anwendung geeignet ist. Das exportierte Teilmodell darf Abhängigkeiten („Schnittstellen”) zu anderen Teilmodellen der Konfiguration aufweisen.
-
Diese Schablonen können dann für vielfältige Anwendungen wiederverwendet werden, wenn die in der Schablone enthaltenen Elemente und Verweise auf die entsprechende neue Umgebung angepasst werden können. Hierzu müssen die Namen und Attributwerte der Entitäten identifiziert, parametrisiert und instanziierbar gemacht werden.
-
Bei der Erstellung einer neuen Anwendung werden die Namen und Attributwerte der Entitäten von einem Zusammenbau-Automaten gefunden und geeignet an die neue Umgebung angepasst. Hierfür sucht der Zusammenbau-Automat mithilfe von Suchregeln die für ihn identifizierbar gemachten Namen und Attributwerte der Entitäten und ersetzt diese mithilfe von geeigneten Ersetzungsregeln. Die instanziierbare Teilkonfiguration wird somit durch den Zusammenbau-Automaten zu einer in der neuen Anwendung funktionsfähigen Teilkonfiguration instanziiert.
-
Im Folgenden wird beschrieben, wie die exportierte Teilkonfiguration erfindungsgemäß instanziierbar gemacht wird:
Um die zuvor genannten Beschränkungen im Stand der Technik zu überwinden, ist zunächst die visuelle Programmierumgebung des Softwaresystems so anzupassen, dass die Namen der Entitäten, inklusive deren Namensraum sowie die Eigenschaften, womit die Werte der Attribute gemeint sind, über die graphische Benutzeroberfläche (GUI) parametrisiert werden können.
-
Die Parametrisierung, in Form des Einfügens von Parametern und Funktionen, erfolgt in der visuellen Programmierumgebung über ein- und mehrzeilige Texteingabefelder. Für die Verwendung von Parametern und Funktionen ist eine formale Sprache zu definieren, über die die Parameter- und Funktionsnamen kodiert werden. Die vorhandenen Eingabefelder müssen dann so verändert werden, dass sie die Eingabe von Parametern und Funktionen im Text zulassen. Hierzu sind vorhandene Validierungsprüfungen für die Gültigkeit der Werte abzuschalten, wenn parametrisierte Eingaben anhand der dafür definierten formalen Sprache erkannt werden. Andere vorhandene Eingabetypen, z. B. Optionsfelder (engl.: Radio buttons) und Datentypen der Attributwerte, sind so anzupassen, dass sie ebenfalls parametrisierte Eingaben erlauben, z. B. entweder durch Umwandlung in Texteingabefelder oder durch Ergänzung einer Option, welche die Angabe eines Parameters ermöglicht. Die visuelle Darstellung der Parameter und Funktionen in den Texteingabefeldern kann durch Hervorhebung verbessert werden.
-
Entitäten, die parametrisiert wurden oder parametrisierte Entitäten enthalten, sind abstrakt, und Konfigurationen, in denen sie enthalten sind, können i. A. nicht fehlerfrei ausgeführt werden, bis die Parameterwerte zugewiesen und die Funktionswerte bestimmt sind. Das Softwaresystem sollte daher so angepasst werden, dass es die Ausführung von Konfigurationsteilen mit Entitäten, die abstrakt sind, unterbindet und diesen ”abstrakten” Zustand ebenfalls visuell hervorhebt.
-
Um die Flexibilität des Verfahrens zu erhöhen, ist es weiterhin möglich, bei der Parametrisierung der auf den Schablonen basierenden Teilkonfigurationen innerhalb der visuellen Programmierumgebung anstatt eines Instanz-Parameters mit Hilfe der formalen Sprache auch eine Funktion als Anweisung an den Zusammenbau-Automaten zur Durchführung einer Transklusion anzugeben. Vom Zusammenbau-Automaten wird an einer solchen Stelle also die Signatur der Funktion als Referenz auf eine Ressource bzw. eine Entität interpretiert, deren Inhalt bei der Instanziierung eingelesen wird. Der Zusammenbau-Automat erzeugt also in der neuen Teilkonfiguration an dieser Stelle den Inhalt der referenzierten Datei, so dass auch komplexere Anpassungen flexibel durchführbar sind. Damit der Zusammenbau-Automat einen solchen Verweis erkennt, wird die Signatur einer Funktion so eingerichtet, dass sie mindestens einen Funktionsparameter besitzt, der vom Zusammenbau-Automaten als Referenz auf eine Ressource bzw. Entität interpretiert wird.
-
Maximale Flexibilität wird erreicht, indem der Inhalt der Ressource bzw. Entität, auf die verwiesen wird, seinerseits durch Instanz-Parameter und Funktionen parametrisiert sein kann. Nach dem Einlesen des Inhalts der Entität bzw. der Ressource können in diesem Fall weitere Instanz-Parameter und Funktionen vorhanden sein, die zusätzlich durch den Zusammenbau-Automaten instanziiert werden. Erst nach Auflösung aller enthaltenen Instanz-Parameter und untergeordneten Funktionen wird der Wert der Funktion schließlich, analog einem Parameterwert, verwendet. Dies ist insbesondere da von Vorteil, wo der Inhalt auf einer Schemasprache basiert. Anstelle einfacher Parameter, die auf primitiven Datentypen wie String, Integer, etc. basieren, kann man damit nun komplexe Datentypen und Inhalte (z. B. XSD, XML) und ganze Schnittstellendefinitionen (z. B. WSDL) parametrisieren. Durch eine solche Abstraktion wird Generische Programmierung möglich.
-
Anstatt der Angabe einer Funktionen zur Durchführung einer Transklusion können Entitätswerte oder Entitäten, die genau einen Entitätswert als ”Inhalt” haben, auch verkürzt über die GUI als ”abstrakt” oder ”überschreibbar” markiert, d. h. gekennzeichnet werden. Der Funktionsparametername für die Transklusion, der die Datei mit dem Wert für den Inhalt referenziert und ansonsten anzugeben wäre, ist dann nicht frei wählbar, sondern wird explizit durch das Softwaresystem und den Zusammenbau-Automaten vorgegeben.
-
Einem abstrakten Entitätswert ist die Signatur für die Transklusionsfunktion zugewiesen und er muss überschrieben werden.
-
Für einen überschreibbaren Entitätswert muss ein gültiger Wert zugewiesen werden, für den implizit eine Ersetzungsregel erzeugt wird, falls dem Funktionsparameternamen eine Referenz zugewiesen wird. Insbesondere überschreibbare Entitätswerte eignen sich für die Generische Programmierung, wenn in der Schablone ein generalisierter Typ verwendet wird, der in der Schablone in Unterroutinen verwendet wird, um dann in abgeleiteten Bausteinen spezialisierte Typen einzusetzen.
-
Um zu sinnvollen Schablonen zu kommen empfiehlt es sich, den wiederzuverwenden Teil der Konfiguration für die Instanziierung vorzubereiten. Damit Schablonen dupliziert werden können, müssen sich bei zwei Duplikaten die Namen aller Entitäten im Teilmodell unterscheiden. Namensräume sind in der Regel hierarchisch in einer Ordnerbaumstruktur aufgebaut. Sie sollten sich in einem Ordner befinden, in dem keine Entitäten enthalten sind, die nicht zu dieser Schablone gehören.
- a) Alle zugehörigen Entitäten einer Schablone sind im Namensraum der Konfiguration unter einem für diese Schablone vorbehaltenen Pfad mit Hilfe der visuellen Programmierumgebung zu vereinen. Der Name des letzten Elements in diesem Pfad muss dann parametrisiert werden (Parameter: Bausteinname), um eine Vervielfältigung zu ermöglichen. Sollen mehrfache Installationen in Form von Projekten unterstützt werden, sollte das vorherige Pfad-Element ebenfalls parametrisiert werden (Parameter: Projektname).
- b) Referenzen (Attributwerte, die eine Pfadangabe darstellen) und Schnittstellen zwischen Schablonen außerhalb des Namensraums der Schablone und externen Komponenten (außerhalb des Systemkontextes) müssen parametrisiert werden, um eine ”lose Kopplung” zu erreichen. Das Verfahren ermöglicht eine Generische Programmierung, indem Schemasprachen wie XSD zur Definition von Datentypen verwendet werden können, die mittels parametrischer Polymorphie generisch behandelt werden können.
Die Kommunikation und der Datenaustausch über diese Schnittstellen basieren auf diesen Schemasprachen. So können Daten per XML ausgetauscht werden, oder sogar die Schnittstelle selbst über eine Beschreibungssprache auf Basis der Schemasprache definiert werden, wie z. B. WSDL.
Über die Parametrisierung kann somit erreicht werden, dass alle Sprachelemente wie XSD, XML und WSDL in den Bausteinen individuell eingestellt und aufeinander abgestimmt werden können.
- c) Ähnlich wie bei Superklassen in Objekt-orientierten Sprachen, muss die abstrakte Funktionalität einer Schablone mit den Parametrisierungen der Bausteine, die von ihr abgeleitet werden, zurechtkommen, was einer Semantik bedarf, die durch den Entwickler der Schablone zu planen ist. Das Problem, dass einer generischen Behandlung Grenzen gesetzt sind und man ggf. Bausteinspezifisch konkretisieren muss, kann ähnlich wie in der Objekt-Orientierung üblich durch Delegation an eine Baustein-spezifische Implementierung einer Unterroutine, z. B. XQuery oder Softwarebibliothek, gelöst werden. Der materielle Wert der Schablone ist abhängig von der Menge an Funktionalität, welche unabhängig von der Ableitung implementiert werden kann.
-
Nachdem jedes Teilmodell als Teil einer kopierfähigen Schablone exportiert und in der Schablonenbibliothek gespeichert wird, können die Schablonen nun von anderen, neu zu erstellenden Anwendungen wiederverwendet werden. Hierzu wird bei der Erstellung der neuen Anwendung ein Zusammenbau-Automat verwendet, der die zu verwendenden Schablonen erfindungsgemäß verwendet, aus der Anwendungsbibliothek herauskopiert, die konfigurierbaren Zeichenketten der Schablonen parametrisiert und durch Instanz-Variablen zu einem in der neuen Anwendung funktionsfähigen Baustein instanziiert. Die instanziierten Bausteine werden dann durch den Zusammenbau-Automaten automatisiert zusammengefügt und in der Regel mit weiterem Anwendungscode ergänzt. Dabei entsteht eine neue und ablauffähige Softwarekonfiguration und Anwendung.
-
Wird die Erfindung durch den Hersteller umgesetzt, so ist von ihm auch der Zusammenbau-Automat umzusetzen und dem Nutzer als Werkzeug bereitzustellen.
-
Eine vorteilhafte Ausgestaltung der Erfindung verwendet eine formale Sprache zur Kodierung der Namen und Attributwerte der Entitäten, bei der die Verwendung der Instanzparameter und Funktionen transparent bleibt. Dies ist insbesondere dann von Bedeutung, wenn die Wiederverwendung einer Teilkonfiguration nicht durch den Hersteller der einer Schablone zugrundeliegenden Standard-Anwendung erfolgt.
-
Um Probleme bei Syntaxprüfungen zu vermeiden, ist dabei eine ungewöhnliche Trennzeichenkettenfolge, ohne Verwendung von Sonderzeichen, aus dem Alphabet als Wort der formalen Sprache zu wählen. Diese kann durch Überlegung oder experimentell per Ausschlussverfahren ermittelt werden. Dadurch werden Zeichenketten gebildet, die zwar eindeutig vom Rest des Schabloneninhalts getrennt identifiziert werden können, aber gleichzeitig in der visuellen Programmierumgebung als gültige Zeichenketten interpretiert und somit problemlos verarbeitet werden. Wenn beispielsweise XXX als Trennzeichenkette festgelegt wird, kann der Parameter ”Schablonenname” als ”XXXSchablonennameXXX” geschrieben werden, ohne dass die Software (das Softwaresystem) von der Semantik dieser Modellierung etwas mitbekommen würde. Ein Funktionsaufruf ”Import(ReferenzA)” könnte analog z. B. als ”XXXImportYYYReferenzAXXX” geschrieben werden.
-
Funktionen werden in der Form modelliert, dass ihre Signatur als n-Tupel ausgestaltet ist. Mindestens eine eindeutige Trennzeichenkettenfolge grenzt den Funktionsaufruf von allen anderen Zeichenkettenfolgen ab. Dadurch kann der Zusammenbau-Automat sicher erkennen, dass an dieser Stelle eine Funktion aufgerufen wird. Innerhalb des Funktionsaufrufs werden der Funktionsname und die zur Funktion gehörenden Parameter benannt. Damit diese entsprechend erkannt und zugeordnet werden können, werden sie von mindestens einer weiteren, untergeordneten Trennzeichenkettenfolge jeweils eindeutig voneinander abgegrenzt.
-
Weiterhin können Funktionsparameter des Funktionsaufrufs Instanzparameter sein. Das heißt, dass auch die in der aufgerufenen Funktion verwendeten Parameter instanziierbar sein können und somit vom Zusammenbau-Automaten bei der Instanziierung gemäß entsprechender Regeln belegt werden.
-
Ein erfindungsgemäßes Verfahren zur Erzeugung und Verwendung einer Schablone kann gemäß Anspruch 3 erfolgen. Im Folgenden wird der Weg für den Nutzer, der nicht Hersteller ist, beschrieben. Wenn ein Hersteller des Softwaresystems diese vorteilhafte Ausführung der Erfindung umsetzt, kann er dies abwandeln und das Verfahren für Nutzer transparenter gestalten. Zu den einzelnen Ressourcen ist folgendes zu sagen:
- a) Datei mit Vorbelegungen der Werte der Instanzparameter:
Der Zusammenbau-Automat braucht für die Instanziierung eine vollständige Zuweisung aller in der Schablone verwendeten Instanzparameter zu einem Wert. Wenn eine Vorbelegung in der Schablone existiert, so kann dieser Schritt später für diese Instanzparameter entfallen. Vorbelegungen werden verwendet, wenn der Wert später nicht explizit für den Baustein angegeben wird (1). Am besten sollte eine vollständige Zuweisung für alle Instanzparameter mit Kommentar zur Dokumentation erfolgen; dies unterstützt auch das Softwaredesign-Paradigma ”Konvention vor Konfiguration”. Ein sinnvolles Datei-Format hierfür ist z. B. eine Java-Properties-Datei.
- b) komplementäre Teilkonfiguration:
Wenn die Schablone Abhängigkeiten zu Entitäten außerhalb deren Teilkonfiguration besitzt, kann diese ggf. nicht mehr alleine für sich in die visuelle Programmierumgebung geladen werden, wenn die visuelle Programmierumgebung Inkonsistenzen feststellt. In diesem Fall ist es für die Weiterentwicklung der Schablone erforderlich, eine minimale, komplementäre Teilkonfiguration zu erstellen, die zusammen mit der Teilkonfiguration der Schablone eine gültige Konfiguration ergibt.
- c) Ersetzungsregeln:
Diese Dateien enthalten Anweisungen, insbesondere zur Textmanipulati on. Der Zusammenbau-Automat liest diese Anweisungen aus und verwendet sie, um bestimmte Zeichenketten in der aus der Schablone exportierten und gegebenenfalls ausgepackten Teilkonfiguration zu suchen und diese zu ersetzen. Dadurch wird die Transklusions-Funktion auch dort einsetzbar, wo es aufgrund der Bauart der visuellen Programmierumgebung ansonsten nicht möglich wäre. Die Suche erfolgt in den innerhalb der Teilkonfiguration in den Ersetzungsregeln festgelegten Ressourcen gemäß den in den Ersetzungsregeln definierten Textmustern. Diese Textmuster werden dann durch ebenfalls in den Ersetzungsregeln definierte parametrisierte Texte ausgetauscht, was in der visuellen Programmierumgebung nicht möglich wäre.
- d) Anpassungsdateien:
Dateien in produktspezifischen oder selbstdefinierten Formaten, in welchen Ersetzungsregeln für Werte von ausgewählten Attributen von ausgewählten Entitäten der Teilkonfiguration beschrieben werden. Die Namen der Entitäten und die Werte der Attribute können durch Instanz- und Installationsparameter parametrisiert werden. Falls Anpassungsdateien aus der visuellen Programmierumgebung heraus erzeugt werden, wird diese Parametrisierung mit exportiert. Darüber hinaus kann die Parametrisierung auch direkt in den Anpassungsdateien der Schablone erfolgen. In den Installationsskripten werden die Anpassungsdateien schließlich verwendet, um die Konfiguration der Anwendung an die umgebungsspezifischen Parameter anzupassen; wie dies geschehen muss, hängt von den vorhandenen APIs des Softwaresystems ab. Auch hier werden die Dateien vom Zusammenbau-Automaten ausgelesen und die Anweisungen verwendet, um gezielt nach vorgegebenen Zeichenketten zu suchen und diese geeignet zu ersetzen.
- e) Installationsskripte:
Der Zusammenbau-Automat bindet diese Skripte als Unterroutinen in die Installations- und Deinstallationsprogramme der Konfiguration in einer Ablaufumgebung ein, indem er diese bei der Paketierung neben dem Installationsprogramm ablegt. Bei der Installation einer neuen Anwendung werden diese Installationsskripte vom Installationsprogramm iterativ, innerhalb einer Transaktion, ausgeführt.
- f) weitere Ressourcen:
Weitere, optionale Dateien, die einen logischen Bezug zu den Schablonen haben. Sie werden inklusive ihres Dateinamens parametrisiert, um durch den Zusammenbau-Automaten Kopien in einem Zielordner zu erzeugen. Damit können z. B. Dokumentationsbausteine für Handbücher für die Schablonen automatisiert erzeugt werden. Auch auf diesen Dateien werden vom Zusammenbau-Automaten entsprechende Ersetzungsregeln angewendet, um die Dateien auf die neue Konfiguration anzupassen.
-
Eine vorteilhafte Ausführung des Verfahrens ermöglicht es, auch solche Zeichenketten bzw. Ressourcen für eine Wiederverwendbarkeit der Software anzupassen, die in der zugrunde liegenden Konfiguration der Standardanwendung nicht parametrisierbar angelegt sind. Solche Zeichenketten oder Ressourcen werden parametrisierbar gemacht, indem in den Schablonen für die nichtparametrisierbaren Zeichenketten bzw. Ressourcen Manipulationen in Form von Anweisungen zur Durchführung von Such- und Ersetzungsregeln durch einen Text und/oder Binär-Datenstrom-Editor definiert werden. Diese Anweisungen sorgen dafür, dass beim Kopiervorgang durch den Zusammenbau-Automaten innerhalb der Teilkonfiguration der Schablone interne Dateien und/oder Teile darin gefunden und passend ersetzt werden. Hierfür werden diesen Dateien bzw. Teilen der Dateien neue Dateien bzw. Dateiinhalte zugewiesen. Die hierbei verwendeten Such- und Ersetzungsregeln enthalten reguläre Ausdrücke. Darin ist der Ort der bei der Instanziierung gegebenenfalls zu ersetzenden Datei genauso enthalten wie die Suchregel für eine gegebenenfalls zu ersetzende Text- oder Binärpassage bzw. für eine Komplettersetzung der ganzen Datei, falls dies erforderlich ist. Weiterhin enthalten die regulären Ausdrücke auch den Namens des Instanzparameters, welcher die Referenz auf die Datei enthält, die den gesuchten Inhalt ersetzt.
-
Die Dateien basieren auf einer formalen Sprache, z. B. einem Skript auf Basis des Befehlssatzes des Unix-Werkzeugs ”sed” (Stream EDitor). Diese Dateien können parametrisiert werden.
-
Um die Softwarekonfiguration effizient wiederverwenden zu können ist es vorteilhaft, wenn erfindungsgemäß auch die Installation und Deinstallation zugehöriger Komponenten bereits vorbereitet wird.
-
Hierfür werden Installationsskripte und Installationsparameter mit separatem Namensraum und eigener formaler Sprache verwendet. Da Schablonen mehrfach verwendet werden können, müssen Installationsparameter eindeutig gemacht werden, indem Werte von Instanzparametern einen Teil der Installationsparameternamen bestimmen.
-
Weiterhin werden zu den Schablonen passende Installations- und Deinstallationsskripte erstellt, in denen die für eine Konfiguration erforderlichen Referenzen zu externen Entitäten und/oder Ressourcen bei der Instanziierung automatisiert angelegt und/oder entfernt werden.
-
Schließlich ist es erforderlich, die Konfiguration zum Installationszeitpunkt an die Umgebung, in die installiert wird, anzupassen. Die Installationsskripte verwenden hierfür Anpassungsdateien, in denen die Parametrisierung der Instanzparameter durch den Zusammenbau-Automaten während der Baustein-Instanziierung aufgelöst wird. Bei der Installation werden die Installationsparameter dann entsprechend aufgelöst, indem sie durch die konkreten Werte ersetzt werden.
-
Besonders vorteilhaft ist es, wenn bei der Erstellung einer neuen Anwendung für den Zusammenbau-Automaten ein Projekt mit einer Projektkonfiguration angelegt wird. Die Konfiguration besteht aus einer Reihe von Bausteinen, die jeweils einer Anweisung zur Instanziierung einer vorhandenen Schablone entspricht. Diese Bausteine müssen alle erfasst und in einer Projektkonfigurationsbeschreibung aufgelistet werden. Die Eigenschaften der Bausteine werden jeweils in eigens angelegten Eigenschaftsdateien beschrieben, welche die Namen und Werte für die zugehörigen Instanzparameter enthalten, die bei der Instanziierung verwendet werden, um die vorbelegten Werte zu überschreiben. Diese Werte werden bei der Ausführung des Zusammenbau-Automaten verwendet, um die in der Schablone vorhandenen Platzhalter zu ersetzen.
-
Um die Bausteine geeignet zu organisieren wird zu jedem Baustein ein eigenes Verzeichnis angelegt, in das die Dateien bzw. Ressourcen abgelegt werden, die in den Ersetzungsregeln der Schablonen verlangt werden.
-
Von dem Zusammenbau-Automaten werden dann die Bausteine mit den zugehörigen Ressourcen aus den Schablonen erzeugt und im Zielverzeichnis des Projekts abgelegt. Dabei werden alle Instanzparameter und/oder Funktionen für die neue Teilkonfiguration geeignet gesetzt, so dass eine zusammengesetzte, installationsfähige Anwendung (Konfiguration) entsteht.
-
Ansprüche 7 bis 12 beschreiben einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge, wobei die Daten ein Programm zum Ablauf auf einer Datenverarbeitungsanlage darstellen, welches die in den Ansprüchen 1 bis 6 beschriebenen Verfahrensansprüche umsetzen, wenn das Programm auf einem Computer, Computernetzwerk oder über das Internet ausgeführt wird. Zur Vermeidung von Wiederholungen wird hinsichtlich dieser Anspruchsgegenstände im Wesentlichen auf die zuvor beschriebenen Ausführungen zu den Ansprüchen 1 bis 6 verwiesen.
-
Anspruch 13 beschreibt ein Computerprogramm mit Programmcode zur Durchführung aller Verfahrensschritte nach mindestens einem der Ansprüche 1 bis 6, wenn das Computerprogramm auf einem Computer, einem Computernetzwerk oder über das Internet ausgeführt wird. Unter einem Computerprogramm ist eine maschinenles- und ausführbare Befehlsfolge zu verstehen, welche durch Speicherung, z. B. auf einem Datenträger oder in einem flüchtigen oder nichtflüchtigen Speicherbaustein eines Computers, oder durch Signale, die über das Internet versendet werden, verkörpert ist. Dabei braucht das Computerprogramm nicht in einer unmittelbar ausführbaren Form vorzuliegen; es kann auch in einer für die Installation auf einem Benutzerrechner vorbereiteten Form vorliegen.
-
Anspruch 14 beschreibt eine Rechneranlage, die so eingerichtet ist, dass sie einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge verwendet, wobei die Daten ein Computerprogramm mit Programmcode gemäß Anspruch 13 darstellen und die Rechneranlage das Computerprogramm gemäß den in den Ansprüchen 1 bis 6 beschriebenen Merkmalen ausführt. Auch hier wird zur Vermeidung von Wiederholungen im Wesentlichen auf die zuvor beschriebenen Ausführungen zu den Ansprüchen 1 bis 6 verwiesen.
-
Die Erfindung wird im Folgenden anhand mehrerer Figuren und einem Ausführungsbeispiel näher erläutert. Die 1 bis 4 zeigen Ablaufdiagramme einer beispielhaften Ausgestaltung der Erfindung, während die 5 bis 18 erläuternde Screenshots aus einer zugehörigen visuellen Programmierumgebung zeigen.
-
Die 1 zeigt ein Ablaufdiagramm, welches ein beispielhaftes Projekt vom Erstellen einer geeigneten Umgebung zur Verwendung der entsprechenden Schablonen bis hin zum Installationspaket einer neuen, aus wiederverwendeten Konfigurationskomponenten zusammengesetzten Software darstellt und somit den beispielhaften Programmablauf des Zusammenbauautomaten in einem Projekt beschreibt.
-
2 zeigt ein Ablaufdiagramm für die in 1 genannte Baustein-Instanziierung, d. h. die Ersetzung der Parameter der Schablonen mit geeigneten Inhalten. Nach Durchführung der Instanziierung wird das Ablaufdiagramm in 1 ab dem Punkt „Baustein b im Arbeitsverzeichnis” fortgesetzt.
-
3 zeigt eine detailliertere Darstellung des ersten Arbeitsschritts des in 2 genannten Vorgangs der Erstellung einer Arbeitskopie. Nachdem die Arbeitskopie erstellt wurde, wird das Ablaufdiagramm in 2 ab dem Punkt „Arbeitskopie des Bausteins b” fortgesetzt.
-
4 zeigt eine Darstellung des in 1 genannten vorletzten Arbeitsschritts „Paketierung” als detaillierteres Ablaufdiagramm. Nachdem die Paketierung durchgeführt wurde, wird das Ablaufdiagramm in 1 ab dem vorletzten Punkt „Installationspaket der Anwendung” fortgesetzt.
-
Wie in 1 dargestellt, beginnt eine erfindungsgemäße Wiederverwendung einer ausführbaren Softwarekonfiguration mit einer grundlegenden Projektfestlegung. Nach der Parametrisierung des Programms mit den Datenablageorten für das Projekt und der Schablonenbibliothek wird die Projektkonfiguration inklusive der Projektparameter geladen. Danach wird für jeden der in der Projektkonfigurationsbeschreibung definierten Bausteine die Instanziierung aus der ihm zugewiesenen Schablone durchgeführt. Am Ende wird die Paketierung der fertigen Bausteine zu einem Installationspaket entsprechend 4 durchgeführt, was weiter unter erläutert wird.
-
Um die Instanziierung für einen Baustein jeweils durchzuführen, wird eine Liste der Instanzparameter für den Baustein aus der Eigenschaftsvorbelegungs-Datei der Schablone, der Eigenschaftsdatei der Bausteinkonfiguration und den Projekt- und Baustein-Eigenschaften der Projektkonfigurationsbeschreibung gebildet. Danach wird jeweils der Programmablauf entsprechend 2 durchgeführt, welches mit der Erstellung einer Arbeitskopie entsprechend 3 beginnt.
-
Der Ablauf zur Erstellung einer Arbeitskopie in 3 dient dazu eine Struktur anzulegen, die sowohl bei der Instanziierung des Bausteins als auch in der Paketierung genutzt wird. Die Struktur besteht aus der ausgepackten Teilkonfiguration, den Ersetzungsregeln, Anpassungsdateien und Installationsskripten sowie weiteren Ressourcen. Wie das Auspacken der Teilkonfiguration, genauso wie das spätere Einpacken, umzusetzen ist, hängt vom Exportformat ab, welches durch das Softwaresystem vorgegeben ist; oft werden jedoch Standardformate für Archive als Exportformat verwendet.
-
Nachdem die Arbeitskopie erstellt ist, wird der Ablauf in 2 damit fortgesetzt, dass in der Arbeitskopie eine Suche nach Parametern durchgeführt wird, um sie durch Ihren Wert zu ersetzen. Diese Parameter sind Instanzparameter und Funktionen, aber keine Installationsparameter. Die Suchgeschwindigkeit kann optimiert werden, indem Binär-Dateien mit bekanntem Typ, der z. B. am Suffix des Dateinamens erkannt wird, übersprungen werden, wenn bekannt ist, dass dort keine Ersetzungen vorgenommen werden. Konnte die Ersetzung nicht vollständig durchgeführt werden, so dass in der Arbeitskopie noch Instanzparameter vorkommen, welche nicht in der Liste der Instanzparameter vorhanden sind oder Funktionen mit unbekanntem Funktionsnamen oder unbekannter Signatur vorhanden sind oder deren Auswertung fehl schlägt, so ist eine Fehlermeldung für den Softwareentwickler auszugeben und das Programm zu beenden. Ist die Funktion eine Transklusion, so erfolgt die Auswertung rekursiv. Andere Funktionen können verwendet werden, müssen aber durch den Zusammenbau-Automaten angeboten und an dieser Stelle vollständig aufgelöst d. h. durch Ihren Wert ersetzt werden. Anschließend werden die Ersetzungsregeln auf der Teilkonfiguration in der Arbeitskopie ausgeführt, wobei die in den Regeln definierten Bestandteile der Teilkonfiguration mit den definierten Bestandteilen der Dateien (Ressourcen) aus der Bausteinkonfiguration ersetzt werden. Ist die Ersetzung vollständig, so ist der Baustein bereit für die Paketierung. Diese erfolgt nachdem dieser Ablauf für alle Bausteine abgeschlossen ist. Die Paketierung wird in 4 beschrieben, und beschreibt die Erzeugung eines Installationspakets für die erzeugten Bausteine. Dafür ist zunächst das Zielverzeichnis zu erstellen, welches am Ende in einem Archiv verpackt wird. Dabei werden auch Basisinstallationsskripte hineinkopiert, welche vom Zusammenbau-Automaten bereitzustellen sind. Diese Skripte müssen in der Lage sein, eine generelle Installation von Bausteinen im Softwaresystem durchzuführen, die wie folgt beschrieben abgelegt werden. Diese Ablage erfolgt indem die Teilkonfigurationen, Installationsskripte (Baustein-spezifisch) inklusive Anpassungsdateien und weitere Ressourcen (insofern vorhanden) im Zielverzeichnis so abgelegt werden, dass sie von den Basisinstallationsroutinen gefunden und die Bausteine bei der Installation im Softwaresystem installiert werden Im folgenden Beispiel ist eine erfindungsgemäße Umsetzung mit der Software Oracle Service Bus beschrieben. Die Software unterstützt die Entwicklung und den Betrieb von Integrationsstrecken im Business-to-Business (B2B) oder Enterprise Application Integration(EAI)-Umfeld.
-
Eine solche Integrationsstrecke (Datenübertragung) kann zum Beispiel Daten von einer Anwendung A entgegennehmen, danach ggf. filtern, umwandeln, modifizieren, etc. und an weitere Anwendungen B und C weiterleiten. Die Software unterstützt den Parallel-Betrieb solcher Integrationsstrecken (d. h. mehrere Anwendungen/Konfigurationen).
-
Der grundlegende, übliche Ansatzpunkt bei der Entwicklung einer Software unter Verwendung von Schablonen liegt in der Erkenntnis, dass sich solche Lösungen (hier Integrationsstrecken) zwar fachlich unterscheiden, jedoch unter gewissen technischen Gesichtspunkten ähneln. Durch Abstraktion können technische Lösungsmuster gefunden werden, die sich zur Entwicklung von Schablonen eignen. Je mehr sich das Verhalten abstrahieren lässt, desto allgemeiner einsetzbar und somit wertvoller sind solche Schablonen.
-
Hat man beispielsweise mehrere Integrationsstrecken, die Ihre Daten per WSDL-WebService entgegennehmen sollen, so kann man für das technische Problem des Integrationsstils „XML Nachrichten per WSDL WebService entgegennehmen” ein abstraktes technisches Lösungsmuster als Schablone verwenden:
-
1. Programmierung einer Schablone
-
In der visuellen Programmierumgebung wird zunächst eine Struktur angelegt. Die Instanzparameternamen werden in diesem Beispiel durch die Zeichenkette XXX eingeschlossen, um das Verfahren transparent für die visuelle Programmierumgebung zu gestalten. Die Eingaben erfolgen über Textfelder. Auf der obersten Ebene wird ein Verzeichnis „XXXprojectnameXXX” angelegt, in dem künftige Integrationsstrecken liegen werden. Der Wert wird später im Projekt festgelegt. Jede Anwendung wird dadurch nach der Installation ihren eigenen Ordner bekommen und von anderen Anwendungen getrennt.
-
Auf der zweiten Ebene wird ein Verzeichnis „XXXcomponentnameXXX” angelegt, s. 5, in welcher später die Bausteine (Teile) der jeweiligen Anwendung liegen werden und von anderen Bausteinen der Anwendung getrennt werden, selbst wenn sie auf der gleichen Schablone beruhen.
-
Es wird ein Zusammenbau-Automat erstellt, der so eingerichtet ist, dass er alle zur Erstellung einer neuen Software automatisierbaren Vorgänge zusammenfasst und durchführt.
-
Der Zusammenbau-Automat wird so eingerichtet, dass er zunächst die Werte der Instanzparameter ”projectname” und ”componentname” für jeden Baustein durch den Algorithmus vordefiniert festlegt.
-
Auf der dritten Ebene wird für jede Schablone ein Verzeichnis mit dem Schab-Ionennamen angelegt, um die Schablonen getrennt voneinander entwickeln zu können. Im Beispiel wird eine Eingangsschnittstellen-Schablone für WSDL-WebServices unter dem Namen „WSInboundAdapter” erstellt. Eine weitere Eingangsschnittstellen-Schablone für Dateiempfang und zwei Ausgangsschnittstellen-Schablonen für den Versand per WSDL oder Datei werden erstellt (s. 6). Am Ende wird es möglich sein, jeweils einen Baustein basierend auf einer Eingangsschnittstellen-Schablone wahlweise mit einem Baustein basierend auf einer der beiden Ausgangsschnittstellen-Schablonen zu koppeln.
-
Nun werden unter diesen Verzeichnissen die wesentlichen Entitäten angelegt. Bei WSInboundAdapter:
- – Eine WSDL-Datei mit einer Schnittstellenspezifikation und
- – Ein ProxyService, welcher die Konfiguration der Eingangsschnittstelle und die Programmierung der Servicefunktionalität beinhaltet, und die zuvor genannte WSDL-Datei verwendet (s. 7).
-
Die Eingabe der eben erwähnten WSDL-Festlegungen erfolgt über die visuelle Programmierumgebung, s. 8.
-
Da die Eingabe für jeden Baustein individuell festgelegt werden soll, ist nun an Stelle der WSDL-Datei eine Transklusionsfunktion, z. B: ”XXXimportYYYwsdlfilenameXXX”, zu parametrisieren.
-
Hierfür ist es erforderlich, dass die visuelle Programmierumgebung die Parametrisierung unterstützt. In unserem Beispiel sei dies jedoch nicht der Fall.
-
Hier wird die Transklusion nun ersatzweise mit Hilfe von Ersetzungsregeln umgesetzt und in der Teilkonfiguration nur ein Platzhalter verwendet, welche dann später bei der Erzeugung des Bausteins durch den Zusammenbau-Automaten durch Anwendung der Ersetzungsregeln und Transklusion ausgetauscht wird.
-
Die Transklusion könnte alternativ auch in einer Anpassungsdatei oder in einer Platzhalterdatei für ein Installationsskript definiert werden, welches ein API anspricht, ohne die Erfindung zu verlassen.
-
Nach der Anwendung der Ersetzungsregeln beinhaltet die Schablone die in 9 dargestellten Entitäten.
-
Die visuelle Programmierung des Proxy-Service zerfällt in 2 Abläufe (Pipelines) für den Nachrichtenfluss, in die Anforderung (request) und die Antwort (response), s. 10.
-
Die eingehende Seite für diese Abläufe wird durch die Wahl des technischen Protokolls, hier WSDL/SOAP/http, bei der Erzeugung des ProxyService festgelegt (in 10 „Service” genannt). Die ausgehende Seite soll mit dem nächsten Baustein kommunizieren. Hierfür wird der Nachrichtenfluss am Ende (s. „RouteNode1” in 10) des ProxyService mit ”Dynamischem Routing” so eingerichtet, dass der nächste Baustein mit Hilfe seines Bausteinnamens und des Schablonennamens lose angekoppelt wird (s. 11).
-
Der Name wird daher durch die Instanzparameter ”outboundcomponent” und ”outboundtemplate” parametrisiert (s. 12).
-
Zur Vereinfachung wird hier das interne Standardprotokoll (SOAP) verwendet. Innerhalb der beiden oben beschriebenen Nachrichtenfluss-Pipelines könnten z. B. noch generalisierbare Aktionen, wie Protokollierung, Normalisierung, Validierung etc. eingerichtet werden.
-
2. Anlegen der Schablonen in der Schablonenbibliothek
-
Nun wird ein Verzeichnis für die Schablonenbibliothek erstellt. Darunter wird ein Verzeichnis mit dem Schablonennamen „WSInboundAdapter” erstellt.
- a) In der visuellen Programmierumgebung werden nun ohne Abhängigkeiten die Ressourcen der Schablone in dieses Verzeichnis unter dem vorgegeben Dateinamen „sbconfig.jar” exportiert (s. 13), einem Standardformat für Archive als Exportformat.
- b) Anschließend wird für die exportierten Ressourcen unter dem vorgegeben Dateinamen „ALSBCustomizationFile.xml” im gleichen Verzeichnis eine Anpassungsdatei erzeugt (s. 14).
Die Anpassungsdatei wird nun noch parametrisiert, indem alle Werte, die darin vorkommen und umgebungsabhängig sind oder im Baustein individuell konfiguriert werden sollen, editiert werden. Bei der hier beispielhaft verwendeten Schablone ist dies nicht notwendig. Ein Beispiel hierfür folgt jedoch weiter unten.
- c) Die ”Ersetzungsregel”-Datei muss nun, wie zuvor erwähnt, eine Regel enthalten, den WSDL-Platzhalter zu ersetzen. Hierzu wird die Struktur der exportierten Teilkonfiguration berücksichtigt und ggf. analysiert. Sie liegt im Beispiel als jar-Datei vor, welches technisch einem ZIP-Archiv entspricht. Innerhalb dieses Archivs ist die WSDL-Datei abgelegt innerhalb von ”XXXprojectnameXXX\XXXcomponentnameXXX\WSInboundAdapter\InterfaceDefinition.WSDL”. Innerhalb dieser Datei ist der WSDL-Platzhalter eingebettet. Die Regel wird nun so aufgestellt, dass der Zusammenbau-Automat den Platzhalter (per Mustersuche, z. B. nach: ”<wsdl:definitions *</wsdl:definitions>”) findet und durch die Transklusionsfunktion ”XXXimportYYYwsdlfilenameXXX” ersetzt.
- d) Eigenschafts-Vorbelegungs-Datei
In der Schablone wurde die Variable wsdlfilename eingeführt. Diese wird in die Eigenschafts-Vorbelegungs-Datei (im Java Properties Format) aufgenommen und ihr ein Standard-Wert zugeordnet: wsdlfilename=definition.wsdl
Da der Instanzparameter innerhalb der Transklusion als Referenz auf einen Dateinamen verwendet wird, hat das zur Konsequenz, dass diese Datei in der Bausteinkonfiguration, die weiter unten beschrieben wird, bereitzustellen ist.
-
Die anderen Schablonen werden analog angelegt.
-
Die Schablone XMLFilelnboundAdapter löst das technische Problem des Integrationsstils „XML Nachrichten per Dateischnittstelle entgegennehmen”. Dazu wird der ProxyService etwas anders konfiguriert, und die WSDL entfällt (s. 15).
-
Der Endpunkt-URI (Uniform Resource Identifier) referenziert das Verzeichnis, aus dem die Nachrichtendateien eingelesen werden. Dieses wird in der Anpassungsdatei parametrisiert, indem der zugehörige Eintrag vom Entwickler gesucht und verändert wird.
-
Die Anpassungsdatei vor der Editierung ist in 16 dargestellt, nach der Editierung in 17.
-
Der Instanzparameter ”filepath” wird in diesem Beispiel in der Eigenschafts-Vorbelegungs-Datei auf eine Vorbelegung eingestellt. Da die Schablone aber mehrfach verwendet werden kann, muss es in der Eigenschafts-Datei des Bausteins verschiedene Wertzuweisungen geben, da ansonsten Plausibilitätsregeln der Software verletzt werden. Das wird hier bei der Entwicklung der Schablonen berücksichtigt, indem die Wertzuweisung durch ”componentname” parametrisieriert wird. Zugleich kann dieser Wert auch noch zum Installationsparameter erweitert werden. Folgender Eintrag in der Eigenschafts-Vorbelegungs-Datei wird in diesem Beispiel als Zuweisung verwendet:
filepath =@XXX componentnameXXX.filepath@
-
Die Schablonen ”WSOutboundAdapter” und ”XMLFileOutboundAdapter” versenden Nachrichten. Sie werden grundsätzlich analog eingerichtet, wobei das ausgehende Protokoll in einer hier nicht in den Figuren dargestellten Ressource ”BusinessService” konfiguriert wird. Der ProxyService wird, um Nachrichten von den Eingangsschnittstellen-Schablonen empfangen zu können, unter dem Namen ”Service” wie in 18 dargestellt konfiguriert.
-
3. Erstellen eines Projekts
-
Zur Steuerung des Zusammenbau-Automaten wird ein Projekt mit einer Projektkonfiguration erstellt.
-
Mit dem Projekt, das in diesem Beispiel ”Example1” genannt wird, soll beispielhaft eine Software erzeugt werden, die eine XML-Nachricht per WSDL entgegennimmt und im Verzeichnis ”/transfer/out/” ablegt. Hierzu wird ein Baustein A auf Basis des ”WSInboundAdapter” erstellt und mit einem Baustein B auf Basis des ”XMLFileOutboundAdapter” gekoppelt.
-
Es ist ein Projektverzeichnis ”Example1” anzulegen; danach folgen weitere Arbeitsschritte:
- a) Im Projektverzeichnis wird eine Projektkonfigurationsbeschreibung unter dem Namen project.xml angelegt. Es handelt sich hierbei um eine beispielhafte, fiktive Syntax, die vom Zusammenbau-Automaten verstanden wird:
- b) Im Projektverzeichnis wird eine Eigenschafts-Datei für jeden Baustein angelegt, z. B. für Baustein A als ”A.properties”:
- c) Im Projektverzeichnis werden Verzeichnisse mit zu importierenden Ressourcen angelegt; z. B. für Baustein A ein Verzeichnis ”A” in dem die WSDL-Datei definition.wsdl liegt.
-
4. Ausführen des Zusammenbau-Automaten
-
Der Zusammenbau-Automat wird ausgeführt und erzeugt erfindungsgemäß ein Installationspaket, in dem ein wist-Script liegt, welches so eingerichtet ist, dass es die erzeugten Baustein-Teilkonfigurationen und die Anpassungsdateien, welche ebenfalls im Installationspaket liegen, innerhalb einer Transaktion installiert.
-
Das wist-Script wird mit dem Weblogic Scripting Tool des Softwaresystems Oracle Service Bus gestartet.
-
Glossar
-
Datei – Ein Bestand meist inhaltlich zusammengehöriger Daten und Software-Ressourcen, der auf einem Datenträger oder Speichermedium gespeichert ist. In diesem Kontext spielt die gewählte Form der Persistenz eine untergeordnete Rolle und Begriffe wie Datei, Verzeichnis und Ressource werden zur Veranschaulichung gewählt; es muss sich nicht um eine Ablage in Verzeichnissen eines Dateisystem handeln, sondern könnte z. B. auch in Datenbanken persistiert werden.
-
Entität – Den Softwarekonfigurationen der Softwaresysteme liegt ein Datenmodell zugrunde, in denen eine konkrete Konfiguration an Entitäten des Softwaresystems und deren Beziehungen zueinander beschrieben werden.
-
Erstellungsprozess – Ein Erstellungsprozess bezeichnet in der IT einen Vorgang, durch den ein fertiges Anwendungsprogramm automatisch erzeugt wird. Der Zusammenbau-Automat setzt diesen Vorgang erfindungsgemäß im Kontext von Standardanwendungssoftware um.
-
Exportieren – Vorgang, bei dem eine Softwarekonfiguration ggf. transformiert und danach in einer Datei oder einem Repository abgespeichert wird, um diese zu einem anderen Zeitpunkt wieder zu importieren oder anderweitig, z. B. hier im Zusammenbau-Automaten, zu verwenden.
-
Formale Sprache – In diesem Kontext wird eine geeignete formale Sprache benötigt, in der Parameter und Funktionen definiert werden können, die eine Unterscheidung zu restlichen Zeichenketten regelt und ein eindeutiges Maschinenverhalten der visuellen Programmierumgebung und des Zusammenbau-Automaten herbeiführt. In der visuellen Programmierumgebung müssen Validierungen bei Angabe von Parametern und Funktionen abgeschaltet werden. Vom Zusammenbau-Automaten werden die Parameter und Funktionen ausgewertet.
-
Funktion – Funktionen in diesem Kontext sind parametrisierbare Anweisungen zur Ausführung vordefinierter Routinen des Zusammenbau-Automaten, die einen Wert zurück liefern, der wie ein Instanzparameter verwendet werden kann.
-
Funktionsparameter – Funktionsparameter sind Werte, Instanzparameternamen oder Entitätsnamen, die als Argument einer Funktion direkt verwendet werden.
-
Generische Programmierung – ist ein Verfahren zur Entwicklung wiederverwendbarer Software-Bibliotheken. Dabei werden Funktionen möglichst allgemein entworfen, um für unterschiedliche Datentypen und Datenstrukturen verwendet werden zu können.
-
Wesentlich bei der generischen Programmierung ist, dass die Algorithmen nicht für einen bestimmten Datentyp geschrieben werden, sondern nur bestimmte Anforderungen an die Typen stellen. Das Prinzip wird auch parametrische Polymorphie genannt.
-
Die Implementierung erfolgt normalerweise durch das Konzept generischer Typen bzw. Templates. In diesem Kontext wird dies jedoch durch Transklusion mit Schemasprachen erreicht.
-
Instanziierung – In Anlehnung an die objektorientierte Programmierung wird in diesem Kontext unter Instanziierung die Erzeugung einer konkreten Teilkonfiguration aus einer bestimmten Schablone verstanden. Diese Form der Instanziierung wird zunächst durch den Programmierer über die visuelle Programmierumgebung des Softwaresystems gedanklich und handwerklich vorbereitet und später durch den Zusammenbau-Automaten physikalisch durchgeführt. Die Konkretisierung erfolgt durch Übergabe einer Konfiguration der Instanzparameter und die verwendeten Schablonen, die dem Zusammenbau-Automaten übergeben werden.
-
Bei der Vorbereitung der Instanziierung durch den Entwickler ist zu beachten, dass Schablonennamen und alle Entitäten der Schablone so auf die Instanziierung vorbereitet werden, dass nach der Durchführung der Instanziierung und der Installation verschiedene Instanzen (Teilkonfigurationen) einer Schablone konfliktfrei koexistieren können. Ist dies der Fall, gilt die Schablone als instanziierbar.
-
Das Entitätenmodell und der Namensraum des Softwaresystems müssen diese Vorgänge grundsätzlich hergeben. Das Softwaresystem soll so gestaltet werden können, dass der Entwickler diese Vorbereitung durch die visuelle Programmierumgebung vornimmt, welche dies entweder direkt unterstützt, zumindest aber indirekt zulässt.
-
Instanzparameter – Instanzparameter werden hier Parameter einer Schablone bezeichnet, deren Wert bei Durchführung der Instanziierung durch den Zusammenbau-Automaten fest eingestellt werden, wodurch die daraus resultierenden Teilkonfigurationen frei von Instanzparametern werden sollen. Instanzparameter sollen auch im Namen der Schablone verwendet werden, um Teilkonfigurationen instanziierbar zu machen.
-
Installationsparameter – Installationsparameter sind Parameter, die sowohl in Schablonen als auch noch später, in den durch den Zusammenbau-Automaten erzeugten Teilkonfigurationen und zugehörigen Ressourcen, vorhanden sein können. Sie werden erst bei der Installation durch das Installationsprogramm fest eingestellt. Installationsparameternamen können durch Instanzparameter und Funktionen ihrerseits parametrisiert werden, so dass auch Installationsparameter durch die Instanziierung vervielfältigt werden.
-
Lose Kopplung – bezeichnet in diesem Kontext einen geringen Grad der Abhängigkeit der Bausteine voneinander, der durch Parametrisierung der Referenzen untereinander und die Abstraktion der Schnittstellendefinitionen durch Parametrisierung erreicht wird.
-
Namensraum – In diesem Kontext sind Namensräume für Entitäten der Teilkonfigurationen und Parameter relevant. Diese sind über Pfadnamen eindeutig identifizierbar und in eine Hierarchie eingeordnet.
-
Packen/Auspacken – Falls Teilkonfigurationen aus Dateiarchiven bestehen, kann die Durchführung einiger besonderer Funktionalitäten wie die Operation auf Einzeldateien des Archivs erfordern, was ein vorübergehendes Auspacken des Dateiarchives erfordert.
-
Parameter – Parameter werden im Rahmen der üblichen Begrifflichkeit verwendet. Sprachlich wird hier unterschieden zwischen Instanzparameter, Funktionsparameter und Installationsparameter.
-
Schablone – Schablonen in diesem Kontext sind vorgefertigte Komponenten, die als Entwurfsmuster für Wiederverwendung von Konfigurationen ausgelegt werden. Sie dienen als konkreter Bauplan für die Erzeugung bzw. Instanziierung ähnlicher Teilkonfigurationen mittels eines Zusammenbau-Automaten. Schablonen können miteinander in hierarchischen Beziehungen stehen und zu komplexen Strukturen zusammengesetzt werden. Das Konzept hat daher eine gewisse Ähnlichkeit zu Klassen, beinhaltet aber von sich aus keine Objektorientierung. Schablonen bestehen mindestens aus jeweils einer exportierten Teilkonfiguration und ggf. weiteren Dateien/Ressourcen.
-
Schablonenbibliothek – Schablonenbibliotheken entsprechen einer Komponentenpalette, wobei die Komponenten der Bibliothek Schablonen im o. g. Sinne sind. Durch eine hinreichende Menge an Schablonen in der Bibliothek wird Rapid Application Development ermöglicht. Weil eine logische Abhängigkeit der Teilkonfigurationen von Ihren Schablonen existiert, kann dies zur Umsetzung von Kontinuiierlicher Integration genutzt werden, indem Teilkonfigurationen automatisch neu erzeugt werden, wenn Ihre Schablonen überarbeitet wurden.
-
Schemasprache – Eine Sprache zur Klassifizierung von XML-Dokumenten, wie XSD, und darauf basierenden Standards, wie dem Schnittstellenstandard WSDL oder Abfragesprachen wie XPath und Xquery. In diesem Kontext wird diese Auszeichnungssprache als Beispiel für jede andere existierende oder künftige Auszeichnungssprache genannt.
-
Signatur – Schnittstelle einer Funktion, gekennzeichnet durch den Funktionsnamen, gefolgt von den Funktionsparametern.
-
Softwarekonfiguration – Eine Programmdatei, die durch das Softwaresystem, ähnlich wie ein Computerprogramm, ausgeführt werden kann. Außerdem muss es möglich sein, diese zu komplexeren Konfiguration zusammenzufügen (Aggregation), bzw. wieder in ihre Teilkonfigurationen zu zerlegen.
-
Softwaresystem – Hiermit ist eine Sammlung von Softwareprodukten gemeint, welche zur Ausführung einer Softwarekonfiguration geeignet sind, insbesondere funktionsübergreifende Standardsoftware und Anwendungsserver.
-
Standardanwendung und Standardsoftware – Als Standardsoftware bzw. Standardanwendungen werden Softwaresysteme verstanden, die einen klar definierten Anwendungsbereich abdecken und als vorgefertigte Produkte erworben werden können und nicht gezielt für den Einsatz bei einem Kunden bzw. Unternehmen entwickelt wurden.
-
Text-Datenstrom-Editor – Ein Werkzeug das zur Manipulation von Textdateien eingesetzt wird.
-
Textfelder und Textbereiche – Steuerelemente einer grafischen Benutzeroberfläche, die Benutzereingaben in Form von Zeichenketten in ein- und mehrzeiligen Textfeldern aufnehmen können.
-
Trennzeichenkettenfolge – Ein oder mehrere aufeinanderfolgende Zeichen, die als Separator in einer Syntax verwendet werden, welche vom Zusammenbau-Automaten und/oder Installationsprogramm unterstützt wird, um Parameter und Funktionen zu definieren.
-
Transklusion – Funktion ähnlich einer Include-Präprozessor-Anweisung in Programmiersprachen, wo Inhalte aus anderen Dateien eingefügt werden. Dieser Vorgang kann mehrstufig sein, d. h. die Dateien, die eingefügt werden, können selbst wiederum in dieser erweiterten Form parametrisiert sein und Transklusionsanweisungen enthalten.
-
Visuelle Programmierumgebung – Eine integrierte Entwicklungsumgebung mit einer visuellen Entwicklungsoberfläche, mit der die Softwarekonfiguration programmiert werden kann, wobei nicht ein gegebenenfalls vorhandener textueller Editor betrachtet wird, in dem das Erstellen von Software mit einer herkömmlichen textuellen Sprache erfolgt. Die visuelle Darstellung in Form der visuellen Sprache steht dabei nicht im Fokus, sondern das damit verbundene Vorhandensein einer Graphischen Benutzeroberfläche, deren Komplexität über die Programmierung mit einer textuellen Sprache deutlich hinaus geht.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 69838139 T2 [0011]
- DE 69031078 T2 [0012]
-
Zitierte Nicht-Patentliteratur
-
- „Wissensmanagement und Software Engineering – Wiederverwendbarkeit” (www.community-of-knowledge.de/beitrag/wissensmanagement-und-software-engineering-wiederverwendbarkeit/) [0006]
- „Software nach dem Baukastenprinzip” (Prof. Dieter Rombach, Fraunhofer Magazin 1.2003 [0006]
- „Enterprise Integration Patterns. Designing, Building, and Deploying Messaging Solutions”, Addison Wesley, 20. Oktober 2003, ISBN 978-0321200686 [0008]
