-
Die
Erfindung betrifft ein Softwareentwicklungssystem sowie ein Softwareentwicklungsverfahren
zum Entwickeln von Softwarekomponenten, wobei das Entwickeln mehrere
Arbeitsschritte umfasst, die mit unterschiedlichen Entwicklungswerkzeugen durchführbar sind.
-
Die
Entwicklung von Softwarekomponenten ist so komplex geworden, dass
eine durchgängige Entwicklung
mit einem Entwicklungswerkzeug (Entwicklungs-Tool) häufig nicht
mehr möglich
ist. Vielmehr gliedert sich die Entwicklung von Softwarekomponenten
in unterschiedliche Arbeitsschritte, die ihrerseits unterteilt sein
können
und mit unterschiedlichen Entwicklungswerkzeugen durchgeführt werden. Unter
einer Softwarekomponente wird im Folgenden ein abgeschlossener Teil
eines Softwareprogramms bestehend aus einer Folge von Verarbeitungsschritten
und Datenstrukturen verstanden, mit dem eine Anwendungsaufgabe gelöst werden
kann. Eine Softwarekomponente kann selbst eigenständige Elemente
umfassen. Ein Beispiel für
eine Softwarekomponente ist beispielsweise eine Mensch-Maschine-Schnittstelle,
insbesondere eine graphische Mensch-Maschine-Schnittstelle. Die einzelnen
Elemente einer graphischen Mensch-Maschine-Schnittstelle werden als Widgets bezeichnet.
Widgets weisen zum einen eine graphische Darstellung auf. Darüber hinaus
ist mit einem Widget eine Funktionalität verknüpft. Ein Widget kann beispielsweise
unterschiedliche Zustände
aufweisen, denen gegebenenfalls unterschiedliche graphische Darstellungen
des Widgets zugeordnet sind. Ein Beispiel für ein Widget ist zum Beispiel
ein Rollbalken. Ein zweites Beispiel für ein Widget, das in Abhängigkeit
von seinem Zustand seine graphische Darstellung ändert, ist eine Liste, in der
unterschiedliche Listeneinträge
ausgewählt
werden können,
wobei die jeweils ausgewählten
Listeneinträge
graphisch hervorgehoben werden. Mit jeder Auswahl eines der Listenelemente ändert sich
der Zustand des Widgets und somit die graphische Darstellung.
-
Die
Entwicklung der Softwarekomponente Mensch-Maschine-Schnittstelle
als graphische Benutzerschnittstelle mit Widget umfasst beispielsweise die
Arbeitsschritte: Spezifizieren der Schnittstelle, das Designen der
graphischen Darstellungen der Widgets, das Animieren der Widgets,
das Simulieren der Schnittstelle und das Implementieren der Schnittstelle.
Diese unterschiedlichen Arbeitsschritte werden in der Regel mit
unterschiedlichen Entwicklungswerkzeugen durchgeführt. Jedes
Entwicklungswerkzeug speichert seine Daten, die jeweils als Werkzeugdaten
bezeichnet werden, in einem unterschiedlichen Datenformat ab. Daher
ist es häufig
nicht möglich,
beliebige Tools zur Entwicklung der Softwarekomponente zu verwenden
und gleichzeitig auf die Arbeitsergebnisse eines anderen Arbeitsschrittes
zurückgreifen
zu können,
das bedeutet, auf die in Form von Werkzeugdaten vorliegenden Ergebnisse
eines Arbeitsschrittes zurückzugreifen.
Vielmehr müssen einzelne
Arbeitsschritte zumindest teilweise erneut durchgeführt werden.
Dieses verursacht bei der Entwicklung von Softwarekomponenten unnötige zusätzliche
Kosten und verlangsamt eine Softwarekomponentenentwicklung. Ferner
ist eine Konsistenz der beiden Arbeitsschritte nur schwer zu überprüfen.
-
Insbesondere
bei der Entwicklung von graphischen Benutzerschnittstellen, die
Widgets verwenden, können
die einzelnen Widgets in unterschiedlichen Benutzerschnittstellen
zumindest teilweise wieder verwendet werden. Hierbei ist es jedoch
häufig
wünschenswert,
leichte Veränderungen von
Projekt zu Projekt bzw. Softwarekomponente zu Softwarekomponente
vorzunehmen. Bei dem bekannten Verfahren bzw. den bekannten Systemen zur
Softwareentwicklung ist es nicht möglich, verschiedene Spezifikationen
zu vergleichen, um bei einem Auffinden einer gleichen oder sehr ähnlichen Spezifikation
in einem älteren
Softwareentwicklungsprojekt beispielsweise auf die zugehörigen Implementierungs-
und/oder Animationsergebnisse des älteren Projekts zurückzugreifen.
Nachteilig ist bei den bekannten Softwareentwicklungssystemen, dass nicht
festgestellt werden kann, wie sich beispielsweise einzelne Spezifikationsänderungen
für ein
Widget im Gesamtentwicklungsprozess auswirken. Das heißt, es ist
nur schwer nachvollziehbar, ob eine Spezifikationsänderung
große
Veränderungen
bei der Implementierung erforderlich macht oder eine bereits bestehende
Implementierung an die veränderte
Spezifikation einfach angepasst werden kann. Ferner ist es nicht
möglich,
Teilspezifikationen bzw. Teilimplementierungen bzw. Teile einer
Animation von Widgets miteinander zu vergleichen. Deswegen ist es häufig erforderlich,
Dinge doppelt zu entwickeln, die bereits für andere Widgets in identischer
oder sehr ähnlicher
Weise entwickelt worden sind.
-
Im
Stand der Technik ist es bekannt, die Daten unterschiedlicher Fachanwendungen,
die zum Teil isolierte Anwendungen sein können, in ein Daten-Warehouse
einzubringen, wo die Daten aufbereitet werden, um unterschiedliche
Sichten auf die Daten zu ermöglichen.
Hierdurch sollen insbesondere besser fundierte Managemententscheidungen
vorbereitet werden. In der Regel werden die Daten bereits beim Einbringen
in das Daten-Warehouse be- und verarbeitet. Beim Ver- und Bearbeiten
werden so genannte Aggregationen geschaffen. Dies bedeutet, dass
aus den eingebrachten Daten neue Daten errechnet und/oder abgeleitet
werden. Die Aggregationen ermöglichen
es, neue Sichten auf die Daten, beispielsweise in Form von Analyseergebnissen, schnell
aus der Datenbank abrufen zu können.
Nur selten werden die eingebrachten Daten vollständig abgespeichert. Die Datenhaltung
erfolgt in den bekannten Daten-Warehouses jeweils in einer Datenbank.
Bei den im Stand der Technik bekannten Daten-Warehouses ist es nicht
vorgesehen, im Daten-Warehouse
abgelegte Daten wieder in die Fachanwendung zu exportieren, von
der sie ursprünglich stammen.
Höchstens
ist vorgesehen, dass aufbereitete Daten, d. h. Aggregationen, den
Fachanwendungen zur Verfügung
gestellt werden. Ziel der bekannten Daten-Warehouses ist es, die
Datenhaltung der Fachanwendungen, die diese benötigen, um ihre Funktionalität zu erbringen,
von der Datenhaltung der Analysedaten, wie sie im Daten-Warehouse vorgehalten
werden zu trennen. So ist sichergestellt, dass den einzelnen Fachanwendungen
ihre jeweiligen Daten in der jeweils benötigten optimalen Form zur Verfügung stehen
und die Analysedaten ebenfalls schnell abgerufen werden können, da
die hierfür
erforderliche Analyse bereits bei der Einbringung der Daten in das
Daten-Warehouse, oder zumindest größtenteils vor einer Abfrage,
ausgeführt
wurde und in Form von Aggregaten in dem Daten-Warehouse vorgehalten
wird. Ein durch ein bekanntes Daten-Warehouse erreichter Mehrwert liegt
in der verbesserten Analyse der Daten und einer besseren Kontrolle,
nicht aber in einer direkten Auswirkung auf die operative Funktionalität bzw. Leistung
der Fachanwendungen. Diese werden nur indirekt dadurch beeinflusst,
dass aufgrund der Analyseergebnisse, die von dem Daten-Warehouse
zur Verfügung
gestellt werden, indirekt steuernd in from von Managemententscheidungen
in die Verwendung und/oder Art der Verwendung der Fachanwendungen
eingegriffen wird. Die oben erwähnten
Schwierigkeiten bei der Softwareentwicklung, bei der die Softwareentwicklungswerkzeuge
die Fachanwendungen sind, lassen sich mit Hilfe einer Verwendung
eines bekannten Daten-Warehouses
nicht beseitigen oder reduzieren.
-
Der
Erfindung liegt das technische Problem zugrunde, ein Softwareentwicklungssystem
und ein Softwareentwicklungsverfahren zu schaffen, mit denen eine
verbesserte, insbesondere schnellere, kostengünstigere und transparentere
Entwicklung von Softwarekomponenten ermöglicht wird.
-
Die
technische Aufgabe wird erfindungsgemäß durch ein Softwareentwicklungssystem
mit den Merkmalen des Patentanspruchs 1 sowie ein Softwareentwicklungsverfahren
mit den Merkmalen des Patentanspruchs 19 erfindungsgemäß gelöst. Weitere
vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den
Unteransprüchen.
-
Der
Erfindung liegt der Gedanke zugrunde, die unterschiedlichen Entwicklungswerkzeuge über ein
neuartiges Daten-Warehouse, welches im Folgenden als Entwicklungswarehouse
bezeichnet wird, miteinander zu verknüpfen. Insbesondere ist ein Softwareentwicklungssystem
zum Entwickeln von Softwarekomponenten vorgesehen, wobei das Entwickeln
mehrere Arbeitsschritte umfasst, die mit unterschiedlichen Entwicklungswerkzeugen
durchführbar
sind, umfassend ein Entwicklungswarehouse zum zentralen Verwalten
von Werkzeugdaten der unterschiedlichen Entwicklungswerkzeuge, wobei
die Werkzeugdaten in gemeinsame Werkzeugdaten und spezifische Werkzeugrestdaten
unterteilbar sind, die jeweils eine Teilmenge der gemeinsamen Daten
bzw. der spezifischen Restdaten sind, wobei die gemeinsamen Daten
die Werkzeugdaten umfassen, die von mindestens zwei Entwicklungswerkzeugen
als Werkzeugdaten verwendbar sind und wobei die gemeinsamen Daten
und die spezifischen Restdaten in einem Speicher ablegbar sind.
Bei einem Softwareentwicklungsverfahren gemäß der Erfindung, bei dem eine
durchgängige
Softwareentwicklung mit mehreren Arbeitsschritten ausgeführt wird,
wobei die mehreren Arbeitsschritte mit unterschiedlichen Entwicklungswerkzeugen
ausgeführt
werden, werden die Werkzeugdaten der einzelnen Arbeitsschritte in
einem gemeinsamen Entwicklungswarehouse gespeichert. Die Werkzeugdaten,
die die einzelnen unterschiedlichen Entwicklungswerkzeuge liefern,
werden jeweils in gemeinsame Werkzeugdaten und spezifische Werkzeugrestdaten
aufgeteilt und gegebenenfalls konvertiert. Die gemeinsamen Werkzeugdaten eines
Entwicklungswerkzeugs stellen eine Teilmenge der gemeinsamen Daten
dar. Die spezifischen Werkzeugrestdaten stellen eine Teilmenge der
spezifischen Restdaten dar. Die in gemeinsame Werkzeugdaten und
spezifische Werkzeugrestdaten aufgeteilten Werkzeugdaten werden
entsprechend gespeichert, wobei die gemeinsamen Daten mittels des
Entwicklungswarehouses den unterschiedlichen Entwicklungswerkzeugen
zugänglich
gemacht werden. Hierdurch wird erreicht, dass die Teilergebnisse,
d.h. die Ergebnisse eines Arbeitsschritts oder eines Teils hiervon,
einem anderen Arbeitsschritt zur Verfügung gestellt werden und in
diesem Arbeitsschritt genutzt werden können, obwohl dieser Arbeitsschritt
gegebenenfalls mit einem anderen Entwicklungswerkzeug ausgeführt wird.
Im Gegensatz zu den bekannten Daten-Warehouses ist bei dem Entwicklungswarehouse eine
Datenhaltung für
die Entwicklungswerkzeuge vorgesehen, bei der die Werkzeugdaten
eines Entwicklungswerkzeugs nach einem Einbringen in das Entwicklungswarehouse
erneut zu diesem Entwicklungswerkzeug exportierbar sind und wobei
ferner zumindest die Daten, die ein anderes Entwicklungswerkzeug
ebenfalls verwendet, auch dem anderen Werkzug zur Verfügung stellbar
sind.
-
Eine
besonders vorteilhafte Ausgestaltung des Softwareentwicklungssystems
sieht vor, dass das Entwicklungswarehouse eine Konverterschicht mit
Konvertern umfasst, wobei jeweils mittels eines der Konverter die
Werkzeugdaten eines der Entwicklungswerkzeuge in gemeinsame Daten
und spezifische Restdaten und umgekehrt konvertierbar sind. Die
Konverter ermöglichen
es, dass die Werkzeugdaten eines Entwicklungswerkzeugs, die von
einem anderen Entwicklungswerkzeug ebenfalls verwendet werden können und
somit gemeinsame Werkzeugdaten sind, in das entsprechende Datenformat
der Werkzeugdaten des anderen Entwicklungswerkzeugs konvertiert
werden können.
Die Verwendung von Konvertern verleiht dem Softwareentwicklungssystem
eine hohe Flexibilität.
Soll ein zusätzliches Entwicklungswerkzeug
in oder mit dem Softwareentwicklungssystem verwendet werden, so
reicht es im Wesentlichen aus, in das Entwicklungswarehouse in die
Konverterschicht einen neuen Konverter einzufügen, der die Werkzeugdaten
des zusätzlichen
Werkzeugs in gemeinsame Daten und spezifische Restdaten konvertiert.
-
Eine
besonders einfache Ausgestaltung der einzelnen Konverter erhält man,
wenn die gemeinsamen Daten in einem gemeinsamen Datenaustauschformat
in dem Entwicklungswarehouse gespeichert werden. In einem solchen
Fall ist es beispielsweise nicht notwendig, dass der zusätzliche
Konverter die gemeinsamen Werkzeugdaten des zusätzlichen Entwicklungswerkzeugs
in alle unterschiedlichen Datenformate der unterschiedlichen Entwicklungswerkzeuge
konvertiert. Es ist dann ausreichend, dass jeder Konverter jeweils
die gemeinsamen Daten in das gemeinsame Datenaustauschformat konvertiert
und die gemeinsamen Daten aus dem gemeinsamen Datenaustauschformat
jeweils in das Datenformat der Werkzeugdaten des entsprechenden
Entwicklungswerkzeugs konvertieren kann.
-
Um
die gemeinsamen Daten und die spezifischen Restdaten der unterschiedlichen
Entwicklungswerkzeuge verwalten zu können, sieht eine besonders
bevorzugte Ausführungsform
der Erfindung vor, dass das Entwicklungswarehouse eine Datenbank
umfasst, mittels der die gemeinsamen Daten und die spezifischen
Restdaten in dem Speicher verwaltbar sind. Die Verwaltung wird stark
vereinfacht bzw. begünstigt,
wenn die Struktur der Datenbank an die zu entwickelnden Softwarekomponenten und/oder
Elemente der Softwarekomponente, die als eigenständige Einheiten entwickelbar
sind, angepasst ist. Mit der Struktur der Datenbank kann ebenso
festgelegt werden, welche Daten der Softwarekomponenten und/oder
Elemente als gemeinsame Daten verwaltet werden sollen. Die Struktur
legt unter anderem das Datenformat für die Abspeicherung der gemeinsamen
Daten im Datenaustauschformat fest.
-
Eine
besonders vorteilhafte Weiterbildung der Erfindung sieht vor, dass
der Struktur der Datenbank eine Anwendungslogik zugeordnet ist.
Hierunter ist zu verstehen, dass einzelnen Daten, insbesondere den
gemeinsamen Daten, innerhalb der Softwarekomponenten bzw. deren
Elementen jeweils eine bestimmte Bedeutung oder Funktion zuordenbar
ist. Über
diese Bedeutung bzw. Funktion können unterschiedliche
Daten bzw. gemeinsame Daten miteinander in Beziehung stehen. Die
Bedeutungs- und Funktionsinhalte und ihre Beziehungen zueinander werden
hier als Anwendungslogik verstanden.
-
Als
besonders vorteilhaft erweist es sich, wenn anhand der im Entwicklungswarehouse
gespeicherten gemeinsamen Daten und spezifischen Restdaten, die
aus einem Arbeitsschritt bzw. einem Teil hiervon resultieren, Werkzeugdaten
für ein
anderes Entwicklungswerkzeug mittels eines der Konverter erzeugbar
sind, so dass diese erzeugten Werkzeugdaten so weit vollständig sind,
dass das Entwicklungswerkzeug für
einen neuen Arbeitsschritt genutzt werden kann. Hierbei kann es
erforderlich sein, dass Werkzeugdaten, die sowohl zu gemeinsamen
Werkzeugdaten als auch zu spezifischen Werkzeugrestdaten korrespondieren
können,
im Entwicklungswarehouse noch nicht gespeichert bzw. definiert sind,
da sie in den bereits ausgeführten
Arbeitsschritten von den hierbei eingesetzten Entwicklungswerkzeugen
nicht verwendet wurden. Dies gilt im besonderen Maße für die Werkzeugdaten,
die spezifische Werkzeugrestdaten sind, da diese nur von einem Entwicklungswerkzeug
verwendet werden und bis zu einem ersten Einsatz des entsprechenden
Entwicklungswerkzeugs somit nicht definiert sind. Daher sieht eine
besonders bevorzugte Ausführungsform des
Softwareentwicklungssystems vor, dass die Konverter so ausgestaltet
sind, dass beim Erzeugen der Werkzeugdaten für fehlende gemeinsame Daten und/oder
spezifische Restdaten Vorgabedaten erzeugbar und/oder verwendbar
sind. Bei der bevorzugten Ausführungsform
werden solche fehlenden Daten als Vorgabewerte erzeugt. Alternativ
können abgespeicherte
Vorgabewerte verwendet werden.
-
Es
hat sich gezeigt, dass bei der Softwareentwicklung von Softwarekomponenten
häufig
die Notwendigkeit besteht, unterschiedliche Varianten einer Softwarekomponente
oder unterschiedliche Varianten einzelner Elemente der Softwarekomponenten zu
erstellen. Als eine Variante werden solche Softwarekomponenten bzw.
Elemente bezeichnet, die eine hohe Ähnlichkeit, beispielsweise
eine strukturelle, eine funktionelle, eine inhaltliche usw. Ähnlichkeit, aufweisen,
sich jedoch in einem wahrnehmbaren Merkmal unterscheiden. Ferner
ist es häufig
notwendig, unterschiedliche Versionen, d. h. unterschiedliche Entwicklungsstufen
der Ausgestaltung einer Komponente oder eines Elements zu verwalten.
Dies ist insbesondere dann notwendig, wenn unterschiedliche Entwickler
gemeinsam an Softwarekomponenten und/oder ihren Elementen entwickeln.
Daher sieht eine besonders bevorzugte Ausführungsform des Softwareentwicklungssystems
vor, dass das Entwicklungswarehouse eine Verwaltungseinheit umfasst,
mittels der sowohl Varianten und Versionen der Softwarekomponenten
als auch Varianten und Versionen der Elemente sowie gegebenenfalls
Varianten und Versionen von Unterelementen der Elemente jeweils
unabhängig
voneinander verwaltbar sind. Hierbei kann vorteilhaft von einer
Datenbankstruktur für die
Abspeicherung der gemeinsamen Daten und spezifischen Restdaten Gebrauch
gemacht werden. Bei bekannten Softwareentwicklungssystemen ist bisher
nur eine Versions- und gegebenenfalls Variantenverwaltung auf Softwarekomponentenebene möglich. Eine
zusätzliche
und hiervon unabhängige und gleichzeitig
ausführbare
Varianten- und Versionsverwaltung der Elemente der Softwarekomponente
ist nicht automatisch möglich.
-
Eine
weitere vorteilhafte Ausgestaltung des Softwareentwicklungssystems
sieht vor, dass die Verwaltungseinheit eine Entwicklungsverfolgungseinheit
umfasst, die eine automatische Änderungsverfolgung
ermöglicht.
Hierdurch ist es möglich,
Fehler, die sich in einem späteren
Entwicklungsstadium der Softwarekomponente oder eines ihrer Elemente zeigen,
genau zurückverfolgen
lassen. Hierdurch wird eine Eingrenzung der von dem Fehler betroffenen
Varianten und/oder Versionen der Elemente möglich. Die Änderungsverfolgung kann zusätzlich Informationen über einen
Nutzer und/oder das Entwicklungswerkzeug mitprotokollieren, von
dem oder mit dem eine entsprechende Änderung vorgenommen wird. So
ist es nachträglich
möglich
festzustellen, wer eine Änderung
und wie eine Änderung
an einer der Softwarekomponenten bzw. eines Elements einer der Softwarekomponenten
vorgenommen wurde. Dies kann vorteilhaft sein, um beispielsweise
die Person ausfindig zu machen, die das entsprechende Element und
dessen Funktionsweise bearbeitet hat, um beispielsweise Ergänzungen
oder eine Variante von dieser Person entwickeln zu lassen, die mit
dem entsprechenden Element aufgrund der bereits ausgeführten Entwicklungsarbeit
gut vertraut ist. Dieses ist besonders bei Softwarekomponenten,
die von unterschiedlichen Kooperationspartnern entwickelt werden,
von großem
Vorteil.
-
Eine
besonders vorteilhafte Ausgestaltung des Softwareentwicklungssystems
sieht vor, dass eine Speicherung redundanzreduziert oder redundanzfrei
erfolgt. So ist es möglich,
dass jeweils nur Änderungen
der Softwarekomponenten bzw. der Elemente abgespeichert werden.
Wird eine Datenbank zur Speicherung im Entwicklungswarehouse verwendet,
so ist es ebenfalls möglich
zu überprüfen, ob
Elemente einer Softwarekomponente Elementen einer anderen Softwarekomponente ähneln oder
gar zu diesen identisch sind. Hierdurch kann eine erhebliche Verringerung
der abzuspeichernden Datenmenge erreicht werden. Ferner kann ein
erheblicher Entwicklungsaufwand gespart werden, wenn beispielsweise
bei der Spezifizierung eines Elements einer Softwarekomponente festgestellt
wird, dass eine andere Softwarekomponente ein Element umfasst, welches
dieselbe Spezifizierung aufweist. Die nachfolgenden Softwareentwicklungsschritte
für dieses
Element können
dann in der Regel eingespart oder stark reduziert werden, indem
auf die Entwicklungsergebnisse dieses bereits entwickelten Elements
zurückgegriffen
wird.
-
Bei
einer besonders vorteilhaften Ausführungsform des Softwareentwicklungssystems
umfasst das Entwicklungswarehouse eine Differenzeinheit, mittels
der Unterschiede zwischen Softwarekomponenten, Varianten oder Versionen
von Softwarekomponenten oder Unterschiede zwischen Elementen, Varianten
oder Versionen von Elementen oder deren Teilergebnissen und/oder
zwischen Unterelementen, Varianten oder Versionen der Unterelemente
ermittelbar sind, wobei Teilergebnisse die Entwicklungsergebnisse
eines der Entwicklungsarbeitsschritte oder eines Teils hiervon sind.
-
Insbesondere
wenn Softwarekomponenten oder ihre Elemente von mehreren Personen
mittels des Softwareentwicklungssystems entwickelt werden, ist es
von Vorteil, wenn den Werkzeugdaten Attribute, Methoden oder Metadaten
im Entwicklungsprozess zugeordnet werden können und diese gemeinsam mit
den Werkzeugdaten abgespeichert und verwaltet werden. Die Attribute,
Methoden und Metadaten können
beispielsweise Hinweise für
andere Mitentwickler oder Bemerkungen sein, wie man sie beispielsweise
auf gelben Zetteln als Haftnotizen im Büro verwenden würde. Eine
besonders vorteilhafte Weiterbildung des Softwareentwicklungssystems sieht
daher vor, dass den Werkzeugdaten und/oder den gemeinsamen Daten
und/oder den spezifischen Restdaten Attribute und/oder Methoden
und/oder Metadaten zuordenbar und mittels der Datenbank verwaltbar
sind.
-
Für eine arbeitsteilige
Softwareentwicklung mit unterschiedlichen Entwicklungswerkzeugen
ist es notwendig, die Datenintegrität, Vollständigkeit und Datenkonsistenz
zu überwachen.
Daher sieht eine vorteilhafte Weiterbildung der Erfindung vor, dass mittels
der Verwaltungseinheit eine Datenintegrität und/oder eine Datenvollständigkeit
und/oder eine Datenkonsistenz überwachbar
sind.
-
Besonders
vorteilhaft kann das erfindungsgemäße Softwareentwicklungssystem
eingesetzt werden, um graphische Benutzerschnittstellen, insbesondere
Mensch-Maschine-Schnittstellen
zu entwickeln. Die Elemente einer solchen Softwarekomponente sind
beispielsweise Widgets. Als Unterelemente können die graphischen Darstellungen
eines Widgets angesehen werden.
-
Eine
besonders vorteilhafte Ausführungsform
der Erfindung ist so ausgestaltet, dass die gemeinsamen Daten als
XML-Daten speicherbar sind.
-
Ein
besonders bevorzugtes Softwareentwicklungssystem umfasst die Entwicklungswerkzeuge,
die mit dem Entwicklungswarehouse werkzeugdatenaustauschtechnisch
verbunden sind.
-
Die
Merkmale der Unteransprüche
des Softwareentwicklungsverfahrens weisen dieselben Vorteile wie
die entsprechenden Merkmale des Softwareentwicklungssystems auf.
-
Die
Erfindung wird nachfolgend unter Bezugnahme auf eine Zeichnung anhand
eines bevorzugten Ausführungsbeispiels
näher erläutert. Hierbei
zeigen:
-
1 eine
schematische Darstellung eines Softwareentwicklungssystems;
-
2 eine
andere schematische Darstellung eines Softwareentwicklungssystems;
-
3 eine
weitere schematische Darstellung eines Softwareentwicklungssystems;
-
4 eine
schematische Darstellung einer Ausgestaltung eines Softwareentwicklungssystems zum
Entwickeln einer graphischen Benutzerschnittstelle; und
-
5 eine
Schematische Darstellung eines als HMI-Entwicklungswarehouse ausgestalteten
Entwicklungswarehouses eines Softwareentwicklungssystems.
-
In 1 ist
eine bevorzugte Ausführungsform
eines Softwareentwicklungssystems 1 schematisch dargestellt.
Unterschiedliche Arbeitsschritte zur Softwareentwicklung von Softwarekomponenten werden
mit unterschiedlichen Entwicklungswerkzeugen 2-6 durchgeführt. Die
Entwicklungswerkzeuge gehören
zu einer Entwicklungswerkzeugschicht 7. Mit den einzelnen
unterschiedlichen Entwicklungswerkzeugen 2-6 können jeweils
einzelne Arbeitsschritte der Softwareentwicklung durchgeführt werden.
Hierbei können
die einzelnen Entwicklungswerkzeuge 2-6 unterschiedliche
Entwicklungswerkzeuge sein, die ihre Werkzeugdaten in unterschiedlichen
Datenformaten vorhalten. Einzelne der Entwicklungswerkzeuge 2-6 können zur
Umsetzung identischer Arbeitsschritte in unterschiedlichen Arbeitsumgebungen
vorgesehen sein. Die Werkzeugdaten der einzelnen Entwicklungswerkzeuge 2-6 werden über Konverter 8-12,
die mit den Entwicklungswerkzeugen 2-6 korrespondieren,
konvertiert. Hierbei werden die Werkzeugdaten jeweils in gemeinsame
Werkzeugdaten und spezifische Werkzeugrestdaten geteilt bzw. konvertiert.
Zumindest die gemeinsamen Werkzeugdaten werden vorteilhafterweise
jeweils in ein gemeinsames Datenaustauschformat konvertiert. Ein
bevorzugtes Datenaustauschformat ist ein XML-Datenformat (Extensible
Markup Language Datenformat). Die Konverter 8-12 bilden eine
Konverterschicht 13. Unterhalb der Konverterschicht 13 befindet
sich eine Entwicklungswarehousefunktionalitätsschicht 14, die
wiederum auf einer Datenbank- und Speicherschicht 15 aufbaut.
Die Konverterschicht 13, die Entwicklungswarehousefunktionalitätsschicht 14 und
die Datenbank- und Speicherschicht 15 bilden gemeinsam
ein Entwicklungswarehouse 16. Bei einer anderen Ausführungsform
können
die Entwicklungswerkzeuge 2-6 der Werkzeugschicht 7 ebenfalls
zum Entwicklungswarehouse dazugehören. Die gemeinsamen Daten,
die die gemeinsamen Werkzeugdaten der einzelnen Entwicklungswerkzeuge 2-6 umfassen,
werden mittels einer Datenbank 17 in einem Speicher (nicht
dargestellt) abgelegt. Die Struktur der Datenbank 17 bzw. die
Datenstruktur, mit der die gemeinsamen Daten und die spezifischen
Restdaten der einzelnen Entwicklungswerkzeuge 2-6 in
dem Speicher abgelegt werden, ist vorteilhafterweise an die Softwarekomponenten
und die Elemente und/oder Unterelemente, aus denen die Softwarekomponenten
bestehen, angepasst. Bei einer geschickten Wahl der Datenstruktur
bzw. der Struktur der Datenbank 17, die zum Verwalten der
gemeinsamen Daten und der spezifischen Restdaten der Entwicklungswerkzeuge 2-6 verwendet
werden, gestattet es, eine effektive Verwaltung der abgelegten Werkzeugdaten
zu erhalten. Beispielsweise ist es möglich, die Daten redundanzreduziert
oder redundanzfrei abzulegen. Dies wird insbesondere dadurch erreicht,
dass die gemeinsamen Werkzeugdaten in dem Datenaustauschformat gespeichert
werden. Dies bedeutet, dass die Daten, die von unterschiedlichen
Entwicklungswerkzeugen 2-6 genutzt werden können, nur
einmal im Speicher abgelegt werden müssen, da sie über die
Konvertierung in den Konvertern 8-12 jeweils aus
dem Datenaustauschformat in das jeweilige Werkzeugdatenformat der
Entwicklungswerkzeuge 2-6 konvertiert werden oder
umgekehrt. Die Entwicklungswarehousefunktionalitätsschicht 14 bietet
die notwendige Funktionalität,
die benötigt
wird, um eine Softwareentwicklung durchgängig mit unterschiedlichen
Entwicklungswerkzeugen 2-6 ausführen zu
können.
Hierzu zählt u.a.
eine Verwaltungseinheit (nicht dargestellt), mit deren Hilfe eine
Varianten- und Versionsverwaltung der einzelnen Softwarekomponenten
möglich
ist. Die Verwaltungseinheit ist jedoch vorteilhafterweise so ausgestaltet,
dass sie zusätzlich
und unabhängig
von der Varianten- und Versionsverwaltung der Softwarekomponenten,
die entwickelt werden, ebenfalls Varianten und Versionen von Elementen
der Softwarekomponenten sowie von Unterelementen der Elemente selbstständig automatisch
verwalten kann. Hierdurch ist eine große Arbeitserleichterung realisierbar.
Beispielsweise können
Arbeitsergebnisse einer Softwareentwicklung, die für eine Softwarekomponente
geleistet wurden, in einem Entwicklungsprojekt für eine andere Softwarekomponente
verwendet werden. Dadurch, dass die Werkzeugdaten in gemeinsame
Werkzeugdaten bzw. gemeinsame Daten und spezifische Restdaten konvertiert
werden und zumindest die gemeinsamen Daten in einem gemeinsamen
Datenaustauschformat mittels einer Datenbank 17 verwaltet
werden, wird ein solcher Rückgriff auf
Teilentwicklungsergebnisse, die für andere Softwarekomponenten
geleistet wurden, erst ermöglicht. Hierbei
wird eine Versions- und Variantenverwaltung bis in die kleinsten
selbstständig
entwickelbaren Einheiten, die als Elemente Unterelemente, Unterunterelemente
usw. oder manchmal auch als atomare Bestandteile oder Atome bezeichnet
werden, vorgenommen. Zusätzlich
bietet die Entwicklungswarehousefunktionalitätsschicht 14 eine
Funktionalität
für eine
automatische Änderungsverfolgung.
Dies wird mittels einer Entwicklungsverfolgungseinheit realisiert
(nicht dargestellt). Diese Funktionalität ermöglicht es, jede Änderung,
die während
der Softwareentwicklung vorgenommen wird, zurückzuverfolgen. Hierbei ist
es ebenfalls möglich,
dass Daten über
das Entwicklungswerkzeug und gegebenenfalls den Entwickler mit abgelegt
und verwaltet werden.
-
Die
Entwicklungswarehousefunktionalitätsschicht 14 umfasst
ferner eine Differenzeinheit (nicht dargestellt), mittels der Unterschiede
zwischen einzelnen Softwarekomponenten bzw. Varianten oder Versionen
hiervon oder zwischen Elementen, Unterelementen oder Varianten oder
Versionen dieser ermittelt werden können. Hierdurch wird es insbesondere
einfach möglich
nachzuvollziehen, wie stark sich beispielsweise Änderungen in der Spezifikation bei
einer Simulation oder Implementierung auswirken. Dies ist insbesondere
für einen
Hersteller einer Softwarekomponente, der Teile der Softwareentwicklung
durch Fremdfirmen und Zulieferer realisieren lässt, von Vorteil, um entscheiden
zu können,
ob die abgerechneten Kosten für
eine Implementierung einer geänderten
Softwarekomponente angemessen sind. Wird beispielsweise eine Spezifikationsänderung
vorgenommen, so kann mittels der Differenzeinheit ermittelt werden,
wie stark sich der implementierte Softwarecode von dem zuvor bereits
entwickelten Softwarecode der ursprünglichen Variante unterscheidet.
Aus solchen Vergleichen kann zusätzlich abgeleitet
werden, wie einfach Veränderungen
an den Softwarekomponenten vorgenommen werden können. Sind beispielsweise bestimmte
Arten von Spezifikationsänderungen
jeweils nur mit geringen Veränderungen
bei der Implementierung verbunden, so kann eine Änderung dieser Art relativ
einfach vorgenommen werden. Sind jedoch andere Arten von Änderungen
der Spezifizierung mit einem großen Aufwand bei der Implementierung
verbunden, so wird sich dies in dem bei der Softwareimplementierung
erzeugten Code zeigen.
-
Eine
weitere Funktionalität,
die die Entwicklungswarehousefunktionalitätsschicht 14 liefert,
umfasst die Möglichkeit,
Attribute, Methoden und Metadaten, beispielsweise Kommentare in
Form von „gelben
Haftnotizen" mit
den Werkzeugdaten abzulegen. Diese werden den Werkzeugdaten mittels
der Datenbank 17 zugeordnet und mit diesen verwaltet.
-
In 2 ist
eine weitere Ausführungsform
eines Softwareentwicklungssystems 21 dargestellt. Technisch
gleich wirkende Merkmale sind mit identischen Bezugszeichen versehen.
Bei den unterschiedlichen Entwicklungswerkzeugen 2-6 kann
es sich um Entwicklungswerkzeuge im engeren Sinne, die beispielsweise
zum Spezifizieren, für
ein Layout und Design, für
ein Animieren, für
ein Simulieren oder Implementieren vorgesehen sind, handeln. Zusätzlich können die
Entwicklungswerkzeuge 2-6 aber auch Verwaltungswerkzeuge
umfassen, mit denen das Entwicklungswarehouse 22, das in
dieser Ausführungsform
die Datenbank- und Speicherschicht 15 sowie die Entwicklungswarehousefunktionalitätsschicht 14 umfasst,
verwaltet und bedient wird. Bei einer anderen Ausführungsform
kann diese Verwaltungsfunktionalität innerhalb der Entwicklungswarehousefunktionalitätsschicht 14 realisiert
sein. Ferner können
die Entwicklungswerkzeuge 2-6 ein Datenaustauschwerkzeug
umfassen, mit dem einzelne oder alle Daten einer Softwarekomponente
oder mehrerer Softwarekomponenten exportiert oder importiert werden
können.
Zusätzlich
kann ein Werkzeug vorgesehen sein, mit dem Zusammenhänge bestimmter
gemeinsamer Daten und/oder bestimmter Elemente der Softwarekomponenten
darstellbar und/oder verwaltbar sind.
-
In 3 ist
eine weitere Ausführungsform
eines Softwareentwicklungssystems 31 dargestellt. Technisch
gleichwirkende Merkmale sind erneut mit denselben Bezugszeichen
versehen. Es ist deutlich ersichtlich, dass das schematisch dargestellte
Softwareentwicklungssystem 31 eine sternförmige Konfiguration
aufweist. Die Entwicklungswerkzeuge 2-6, 32-35 stellen
die äußere Entwicklungswerkzeugschicht 7 dar,
die mit Bedienern (z. B. Softwareentwicklern) wechselwirkt. Die
entsprechend zugeordneten Konverter 8-12 und 36-38 verbinden
die Entwicklungswarehousefunktionalitätsschicht 14 mit den
Entwicklungswerkzeugen 2-6 und 32-35.
Im Zentrum des Softwareentwicklungssystems 31 befindet
sich die Datenbank- und Speicherschicht 15.
-
In 4 ist
eine Ausführungsform
eines Softwareentwicklungssystems 41 zur Entwicklung graphischer
Benutzeroberflächen,
insbesondere einer graphischen Mensch-Maschine-Schnittstelle (human machine interface – HMI) dargestellt.
Eine graphische Benutzerschnittstelle oder HMI-Schnittstelle besteht
aus einzelnen Elementen, die als Widget bezeichnet werden. Jedes
Widget kann innere Zustände
haben und weist jeweils mindestens eine graphische Darstellung auf.
Die graphische Darstellung kann sich jedoch auch in Abhängigkeit
von dem inneren Zustand des Widget ändern. Die unterschiedlichen
graphischen Darstellungen können
als Unterelemente der Widgets betrachtet werden. Die Softwareentwicklung
einer Mensch-Maschine-Schnittstelle (HMI-Schnittstelle) gliedert
sich grob in vier unterschiedliche Arbeitsschritte. Diese umfassen
die Spezifikation 42, das HMI-Design 43, die Simulation 44 und
die Implementierung 45. Die Spezifikation erfolgt über Visio-Statecharts 46 und
informale Spezifikationsanteile 47, die über einen
Statecharteditor 48 verarbeitet werden. Der Statecharteditor 48 ist
ein Entwicklungswerkzeug für
die Spezifikation der Mensch-Maschine-Schnittstelle und der von
dieser umfassten Widget.
-
Als
weiterer Arbeitsschritt umfasst die Entwicklung einer Mensch-Maschine-Schnittstelle
das HMI-Design 43. Mittels eines Layout- und Animationswerkzeugs 49 werden
Graphikentwürfe 50,
Merkmalslisten 51 und ein Verhalten der HMI-Elemente 52 verarbeitet
und entwickelt. Sowohl die Werkzeugdaten des Statecharteditors 48 als
auch die des Layout- und Animationswerkzeugs 49 werden
in einem HMI-Warehouse, das eine Ausgestaltung eines Entwicklungswarehouses 53 ist,
abgelegt und verwaltet. Hierbei werden die bei der Spezifikation
eingegebenen Werkzeugdaten, die in gemeinsame Daten konvertiert
worden sind, direkt an das Layout- und Animationswerkzeug weitergegeben.
Das HMI-Warehouse sorgt dafür,
dass sowohl eine Datenintegrität als
auch eine Datenkonsistenz gewahrt wird. Ein weiterer Arbeitsschritt
bei der Softwareentwicklung einer Mensch-Maschine-Schnittstelle
ist die Simulation 47. Mittels eines Simulations- und Bedienlogikentwicklungswerkzeugs 54 wird
die Bedienlogik der Mensch-Maschine-Schnittstelle simuliert und
getestet, die durch das Verhalten der einzelnen Mensch-Maschine-Elemente,
d.h. der Widgets, festgelegt ist.
-
Über ein
Export-/Importwerkzeug 55 werden die gemeinsamen Daten
und die spezifischen Restdaten zur Implementierung 45 exportiert
bzw. importiert. Hierbei wird eine digitale Spezifikation 56 der Mensch-Maschine-Schnittstelle
ausgetauscht. Zusätzlich
wird heutzutage noch die Spezifikation in Form eines Lastenhefts 57 in
die Implementierung 45 mit eingebracht, die mittels eines
Implementierungswerkzeugs oder mehrerer Implementierungswerkzeuge 58 ausgeführt wird.
Auch die bei der Implementierung der Mensch-Maschine-Schnittstelle
entstehenden Daten können über das
Export/Importwerkzeug 55 in das Entwicklungswarehouse 53 eingebracht
und dort verwaltet werden.
-
In 5 ist
schematisch eine weitere Ausführungsform
eine als HMI-Entwicklungswarehouse 61 ausgebildeten Entwicklungswarehouse
eines Softwareentwicklungssystems wiedergegeben. Das HMI-Entwicklungswarehouse 61 umfasst
eine Datenhaltungsschicht 62, die eine Speicherschicht
umfasst, eine als Middlewareschicht 63 ausgebildete Entwicklungswarehousefunktionalitätsschicht
und eine so genannte Plug-In-Schicht 64.
-
In
der Datenhaltungsschicht 62 werden in einem Kern 65 die
gemeinsamen Daten aufgeteilt in so genannte Dimensionen abgespeichert.
Die Abspeicherung und der Zugriff erfolgt mittels einer Datenbank.
Die Datenbankstruktur ist an die Dimensionen angepasst, die mittels
einer Unterteilung des Kerns 65 in Sektoren 70-74 graphisch
dargestellt sind. Jeweils einer der Sektoren ist einer der Dimensionen zugeordnet,
die in dem HMI-Entwicklungswarehouse,
angepasst an die mittels Entwicklungswerkzeugen zu entwickelnden
Widgets von HMI-Schnittstellen, eine Geometrie, eine Struktur, eine
Metabeschreibung, ein Verhalten und eine Semantik für die Widgets
umfassen. Die Datenstruktur ist somit vorteilhafterweise sternförmig ausgebildet. Über diese Datenstruktur
ist eine Bedeutung und Funktionalität der einzelnen in ihr abgelegten
Daten bekannt. Dies bedeutet, der Datenstruktur ist eine Anwendungslogik
zugeordnet. So ist es möglich
die gemeinsamen Daten, die in dem Kern 65 in den unterschiedlichen Dimensionen
abgelegt sind, auch in einem anderen Kontext als in dem, in dem
sie ursprünglich
erzeugt wurden, weiter zu verwenden. Hierdurch wird ebenfalls eine
redundanzreduzierte oder sogar redundanzfreie Speicherung ermöglicht.
-
Angedockt
an den Kern, werden die spezifischen Restdaten abgelegt. Dieses
geschieht so, dass eine Verknüpfung
mit gemeinsamen Daten so möglich
ist, dass einem mit dem HMI-Entwicklungswarehouse 61 zusammenwirkenden
Entwicklungswerkzeug (nicht dargestellt) ein vollständiger Satz Werkzeugdaten
zur Verfügung
gestellt werden kann.
-
Innerhalb
der Datenhaltungsschicht 62 werden automatisch Varianten
und Versionen der einzelnen Elemente, Widgets, der zu entwickelnden
Softwarekomponente, HMI-Schnittstelle, verwaltet. Ferner findet
ein Änderungsmanagement
der Art statt, dass Veränderungen
jederzeit nachverfolgt werden können.
Die unterschiedlichen Versionen der Elemente, Widgets, sind mit
Hilfe von Ringen 75 graphisch angedeutet.
-
Die
Middlewareschicht 63 stellt für das HMI-Entwicklungswarehouse
unterschiedliche Funktionalitäten
zur Verfügung.
Zum einen wird eine Funktionalität
zur Anbindung und Koordinierung von Konvertern, die bei der dargestellten
Ausführungsform
in Werkzeugschnittstellen 81, 82 der Plug-In-Schicht 64 umfasst
sind, bereitgestellt. Die Middlewareschicht 63 stellt ferner
Widgetstrukturen in Form von Objektstrukturen bereit. Die Middlewareschicht
setzt zusätzlich
festgelegte Regeln für
einen Export und Import von Werkzeugdaten durch. Schließlich stellt
die Middlewareschicht 63 die Funktionalität zum Suchen, Verwalten
und Bedienen sowie für
eine Wechselwirkung mit einer Benutzerschnittstelle 83 der Plug-In-Schicht 64 zur
Verfügung.
Alle diese Funktionalität
der Middlewareschicht 63 ist in einer Systemkomponente 77 umfasst.
-
Die
Plug-In Schicht umfasst zusätzlich
zu der Benutzerschnittstelle 83, die Werkzeugschnittstellen 81, 82 zur
Wechselwirkung mit Entwicklungswerkzeugen (nicht dargestellt). Jede
der Werkzeugschnittstellen 81, 82 umfasst jeweils
eine Extraktions-/Schreibkomponente 84 und
eine Transformationskomponente 85, die jeweils den Konverter
für das entsprechende
Entwicklungswerkzeug umfasst. Die Extraktions-/Schreibkomponenten 84 importieren und
exportieren jeweils die Werkzeugdaten des Entwicklungswerkzeugs
in der Form, in der das Entwicklungswerkzeug seine Daten gewöhnlich vorhält. Die Transformationskomponenten 85 konvertieren
die Werkzeugdaten in gemeinsame Daten und spezifische Restdaten
und umgekehrt. Hierbei wird vorzugsweise mit Objektstrukturen der
Middlewareschicht 63, die Bestandteil der Systemkomponente 77 sind,
gearbeitet. Dies bedeutet, es wird in die von der Middlewareschicht
bereitgestellten Objektstrukturen geschrieben bzw. aus diesen gelesen.
Am Ende eines Konvertierungsprozesses von aus einem Entwicklungswerkzeug
extrahierten Werkzeugdaten liegen diese aufgeteilt in gemeinsame
und spezifische Restdaten in einem Widgetobjekt 78 vor,
wobei zumindest die gemeinsamen Daten entsprechend der Dimensionen
der Datenstruktur im Kern 65 der Datenhaltungsschicht 62 untergliedert
sind. Bei einer Konvertierung in umgekehrter Richtung wird das Widgetobjekt
in ein Objekt (nicht gesondert dargestellt) überführt, in dem die Werkzeugdaten
in der Form vorliegen, in der das entsprechende Entwicklungswerkzeug
seine Werkzeugdaten gewöhnlich vorhält.
-
Für den Fachmann
ergibt es sich, dass Ausführungsformen
denkbar sind, bei denen die hier beschriebene Trennung der Funktionalitäten des
Entwicklungswarehouses nach den einzelnen Schichten anders oder
gar nicht auftritt. Die Konverterschicht, kann mit der Entwicklungswarehousefunktionalitätsschicht
nach 1 bis 3 oder der Middlewareschicht
nach 5 zusammenfallen. Ebenso ist denkbar, die Konverterschicht
in die Speicherschicht nach 1 bis 3 oder
die Datenhaltungsschicht nach 5 integriert
ist.
-
Einzelne
oder alle Bestandteile der beschriebenen Softwareentwicklungssysteme
können
ganz oder teilweise in Software oder Hardware ausgeführt sein.
Insbesondere können
die Konverter können
zumindest teilweise in Hardware ausgeführt sein.