Auflistung nach:
Auflistung Softwaretechnik-Trends 27(4) - 2007 nach Erscheinungsdatum
1 - 10 von 15
Treffer pro Seite
Sortieroptionen
- ZeitschriftenartikelEin Ansatz zur Entwicklung von Modellierungswerkzeugen für die softwaretechnische Lehre(Softwaretechnik-Trends Band 27, Heft 4, 2007) Pleumann, JörgBeim Lehren und Lernen graphischer Modellierungssprachen wie der Unified Modeling Language (UML) ist eine Unterstützung durch entsprechende Werkzeuge sinnvoll und wünschenswert – nicht zuletzt, weil es die Lernenden frühzeitig an einen Umgang mit Werkzeugen gewöhnt, wie er im professionellen Umfeld Standard ist. Die meisten existierenden Modellierungswerkzeuge (z.B. IBM Rational Rose oder Borland Together) richten sich jedoch ausschließlich an die Zielgruppe der professionellen Software-Entwickler und lassen einen Einsatz in der Lehre völlig außer Acht. Das Ergebnis sind ausgesprochen schwergewichtige Produkte (im Sinne von Funktionalitätsumfang, benötigtem Hauptspeicher und CPU-Leistung), deren reichhaltige Möglichkeiten zwar den Bedürfnissen eines professionellen Umfelds entgegenkommen, aber weit über das hinausgehen, was in einem Praktikum oder einer Übungsgruppe benötigt wird oder angemessen ist. Zu viele Funktionen lenken die Studierenden vom eigentlichen Lehrstoff ab und führen dazu, dass mehr Zeit in die Erlernung der Verwendung des Werkzeugs als in die eigentlich zu vermittelnde Modellierungssprache investiert wird. Kommen mehrere Modellierungssprachen – und damit mehrere Werkzeuge – zum Einsatz, multipliziert sich dieser Aufwand, da die einzelnen Werkzeuge einander meist nicht ähneln. Bei einer großen Anzahl von Studierenden können auch Lizenzkosten schnell zu einem Problem werden. Um diesen Schwierigkeiten zu begegnen, wurde im Rahmen der vorliegenden Arbeit eine Familie von graphischen Modellierungswerkzeugen auf der Basis eines speziellen Meta-CASEFrameworks ausschließlich für die Lehre entwickelt. Diese Familie umfasst derzeit verschiedene Vertreter für strukturelle und dynamische Anteile der UML, Petrinetze sowie Prozessmodellierung und -begleitung auf der Basis des Unified Process. Bei der Planung und Realisierung dieser Werkzeuge wurde bewusst Wert darauf gelegt, nicht mit professionellen Produkten zu konkurrieren, sondern stattdessen leichtgewichtige Werkzeuge zu schaffen, die auf die Kernfunktionalität des Modellierens reduziert sind. Da alle Werkzeuge die gleiche technische Basis besitzen, war es möglich, eine einheitliche Benutzungsschnittstelle zu etablieren, die sich auf notwendige Elemente konzentriert und damit den Einarbeitungsaufwand minimiert. Gleichzeitig wurde didaktisch motivierte Funktionalität in die einzelnen Werkzeuge eingebracht, die in professionellen Produkten nicht zu finden ist. Diese zusätzliche Funktionalität beinhaltet zum Beispiel ein Hypertextsystem zur Integration von Lehrstoff sowie Simulations-, Analyse- und Visualisierungsmöglichkeiten, durch welche die Studierenden beim Lernen der jeweiligen Modellierungssprache unterstützt werden. Einige der Werkzeuge wurden im Rahmen der Lehre eingesetzt und evaluiert. Die Erfahrungen, die bei diesen Einsätzen gewonnen wurden, waren sehr positiv.
- ZeitschriftenartikelaTool: Typographie als Quelle der Textstruktur(Softwaretechnik-Trends Band 27, Heft 4, 2007) Meyer, OliverUm Texte schneller publizieren, nutzbringender archivieren und effektiver erschließen zu können, muss ihre innere Struktur Werkzeugen zugänglich gemacht werden. Dies geschieht heute i.d.R. nach der Texterstellung durch eine aufwändige Auszeichnung in SGML oder XML. Zur Zeit sind es noch die Verlage, die diese nachträgliche Konvertierung durchführen. Die heute verfügbaren XML-Werkzeuge sind entweder reine XML-Editoren, die für XML-Laien ungeeignet sind, oder Batch-Konverter, die letztlich ihrem Anspruch der vollautomatischen Konvertierung nicht gerecht werden können. Mit dem in dieser Arbeit entwickelten Werkzeug aTool, das als Aufsatz auf MS-Word implementiert wurde, kann der Autor die formale Struktur eines Textes bereits erzeugen, während er den Text erstellt. Dabei nutzt aTool u.a. die Typographie, um halbautomatisch die XMLStruktur abzuleiten und so den Autor zu entlasten. Die Arbeit stellt aTool, seine Konzepte und seine Anwendungen vor. Auch wenn aTool in erster Linie von Autoren verwendet wird, mindert es doch den Arbeitsaufwand der Verlage. Die Anforderungen an aTool wurden für diese Arbeit in Zusammenarbeit mit dem Springer-Verlag formuliert. Imprimären Anwendungsgebiet von aTool, den wissenschaftlichen Zeitschriftenpublikationen, erhält der Springer-Verlag als Einreichungen eine Vielzahl von MS-Word-Dokumenten. Um den dadurch notwendigen Konvertierungsaufwand zu verringern, möchte er von seinen Autoren unmittelbar XML gemäß seinen Vorgaben erhalten. Die Autoren sind i.d.R. jedoch XML-Laien, die an gewohnten Arbeitsweisen festhalten wollen. aTool muss die Autoren daher stark unterstützen und darf ihre gewohnte Arbeitsweise nur wenig ändern. Gleichzeitig soll es flexibel an unterschiedliche Vorgaben anpassbar sein und diese bereits beim Autor überprüfen. Findet es Fehler, sollen verständliche Fehlermeldungen den Autor bei der Korrektur anleiten. aTool erstellt die Struktur halbautomatisch gemäß den Strukturvorgaben aus dem Verlag, während derAutor den Text mit MS-Word erstellt. Dabei arbeitet aTool minimal-invasiv und eng mit MS-Word zusammen. Der Autor kann weiterhin instanzbasierte Formatierung verwenden, um Texte auszuzeichnen und zu strukturieren. Noch während der Erstellung parst aTool den Text und erstellt eine integrierte getypte XML-Struktur. Dazu abstrahiert aTool die konkrete Formatierung zu einem definierten Formattupel und fasst gleich formatierte Zeichen zu einem Token zusammen. Das Parsing erzeugt allein aus diesem Tokenstrom einen Strukturbaum, dem im Mapping Elementtypen zugewiesen werden. Das Mapping bildet die Synthese aus Formatierungsabbildung und Strukturvorgaben. Da der Fließtext immer im Sinne der Strukturvorgaben formal korrekt, aber inhaltlich falsch interpretiert werden kann, wird dabei der Formatierung ein größeres Gewicht gegeben als den Strukturvorgaben. Eine solche Abbildung ist per se mehrdeutig, da Autoren nicht eindeutig formatieren. aTool arbeitet daher nur halbautomatisch und verschiebt Entscheidungen, bis der Autor den Problemfall auflöst. Jede Veränderung der Struktur prüft aTool kontinuierlich und inkrementell gegen die vom Verlag vorgegebenen Regeln in Form einer erweiterten DTD. Unterschiedliche Verlage und verschiedene Zeitschriften bedeuten wechselnde Vorgaben für die Texte. aTool ist daher in hohem Maße parametrisierbar und kann neben dem Dokumentformat sowohl an die Vorbildung und Formatierungsvorlieben einer Benutzergruppe als auch an den einzelnen Autor angepasst werden. Der Autor kann über die Struktur im Text navigieren oder sie direkt manipulieren. Dabei helfen ihm konstruktive Operationen. Sie fügen automatisch sowohl ganze Teilbäume mit Elementen in ihrer üblichen Verwendung als auch umfassende Elemente ein. Verstößt ein Autor gegen die Vorgaben des Verlags, erzeugt aTool konstruktive Fehlermeldungen, die weit über das hinausgehen, was andere Werkzeuge im Fehlerfall an Unterstützung anbieten. Es berechnet den Abstand des aktuellen Dokuments zum erlaubten Dokument als Länge einer Editierfolge und fasst dann alle minimalen Editierfolgen zusammen. Die generierte Fehlermeldung gibt eine konkrete Anleitung, wie der Autor seine Dokumentstruktur korrigieren kann. Auch wenn aTool aus den Anforderungen des Publikationsszenarios entstanden ist, reichen die möglichen Einsatzgebiete darüber hinaus. Sein Anwendungsfeld liegt überall dort, wo Textdokumente in XML mit bekannter DTD erstellt werden sollen, die Autoren jedoch vorzugsweise formatierten Fließtext in MS-Word erstellen. Die Arbeit untersucht daher auch die Eignung für die Unterstützung einer Dokumentenfamilie. Dies geschieht am Beispiel des Benutzerhandbuchs für ein Softwaresystem, das die T-Systems GEI GmbH in unterschiedlichen Varianten vertreibt. Während bisher nur die Programmvarianten automatisch parametrisiert wurden, können mit dem hier entwickelten Konzept auch die Handbücher parametrisiert werden. Bei der Erstellung einer gemeinsamen Handbuchquelle hilft die XML-Struktur, gemeinsame und variantenspezifische Dokumentanteile zu erkennen. Diese werden methodisch zur Quelle zusammengesetzt. Anhand der Konfigurationsbeschreibung der Software generiert daraus eine Erweiterung von aTool konsistente spezifische Handbücher. Da auch in Zukunft Änderungen in der Software und den Handbüchern zu erwarten sind, geht die Arbeit ebenfalls differenziert auf die Wartung einer solchen Handbuchquelle ein. Auch hier hilft die zusätzliche XML-Struktur. Durch die Formatierung ausgezeichnet und direkt in den Text eingebettet werden kann jedoch nur die einfache, formale, syntaktische Struktur. Die komplexe, semantische Struktur, welche die Inhalte und ihre Abhängigkeiten beschreibt, muss als Graph neben dem Text modelliert werden. Dies ist in der Kodissertation [Gat04] zu dieser Arbeit geschehen. Als Top-down-Ansatz bietet sie ein ausgefeiltes Dokumentenmodell und mächtige Analysen im Graphwerkzeug CHASID. Als drittes Anwendungsfeld beschreibt diese Arbeit, wie aTool diese semantische Modellierung unterstützen kann. CHASID benötigt eine engere Integration mit dem konkreten Text und eine Anbindung an verbreitete Autorenwerkzeuge. Die Arbeit entwickelt daher ein Konzept zur Kopplung von aTool und CHASID, das die aus dem Fließtext abgeleitete syntaktische Struktur als Zwischenschritt zur semantischen Struktur nutzt. aTool dient als Front-End für CHASID und stellt Parametrisierungsfunktionalität bereit. CHASID kann dann unverändert für beliebige XML-Anwendungen verwendet werden. aTool bildet dazu Sichten auf die syntaktische Struktur und entscheidet anhand der Parametrisierung, wie es XML-Elemente in das semantische Modell von CHASID abbildet. Die Integration stellt für beide beteiligten Werkzeuge einen Gewinn dar: aTool gewinnt ein umfassendes semantisches Modell hinzu, das erweiterten Analysen dient. CHASID erhält ein feingranulareres Textmodell und kann so differenziertere Aussagen über die Struktur machen als bisher.
- ZeitschriftenartikelEin parametrisierbares Graph-Datenbanksystem für Entwicklungswerkzeuge(Softwaretechnik-Trends Band 27, Heft 4, 2007) Böhlen, BorisKlassische Datenbanksysteme sind für die Verwaltung komplexer Dokumente als Ergebnis von Entwicklungstätigkeiten nur bedingt geeignet. Dies gilt insbesondere, wenn die Dokumente untereinander auf einer sehr detaillierten Ebene miteinander vernetzt sind. Im IPSEN-Projekt und anderen Projekten des Lehrstuhls für Informatik 3 werden daher Graphen für die Modellierung der Dokumente verwendet. Die Speicherung der Dokumente erfolgt in der Graphdatenbank GRAS. Aktuelle Projekte definieren Anforderungen, die von GRAS nicht unterstützt werden. Die Konsequenz ist die Entwicklung des im Folgenden vorgestellten Datenbanksystems DRAGOS. Die Probleme von GRAS liegen im Bereich Erweiterbarkeit und Anpassbarkeit. Auf das einfache Graphmodell von GRAS können komplexe Graphmodelle — wie Hypergraphen — nur mit hohem Aufwand abgebildet werden. Graphersetzungssysteme mit anderen Graphmodellen können GRAS nicht einsetzen. Auch die Funktionalität kann nur schwer an neue Anforderungen angepasst werden, insbesondere wenn zentrale Komponenten betroffen sind. Die mangelnde Anpassbarkeit erschwert zum Beispiel die Realisierung verteilter Werkzeuge. GRAS wird daher nur von Werkzeugen verwendet, die mit dem Graphersetzungssystem PROGRES spezifiziert werden. Basierend auf den Schwächen von GRAS werden zunächst die Anforderungen an DRAGOS definiert. DRAGOS definiert ein allgemeines Graphmodell, auf das andere Graphmodelle mit geringem Aufwand abgebildet werden können. Durch seine serviceorientierte Architektur lässt sich DRAGOS an verschiedene Anwendungsszenarien anpassen. Der DRAGOS-Kernel stellt nur die Funktionalitäten als Dienste zur Verfügung, die von einem graphorientierten Datenbanksystem bereitgestellt werden müssen: Ereignisse, Persistenz, Regeln und Transaktionen. Jede zusätzliche Funktionalität — zum Beispiel die Versionierung von Graphen — wird von Erweiterungsmodulen zur Verfügung gestellt. Für die Einbindung der Erweiterungsmodule ist der Kernel verantwortlich. Die Anbindung der verschiedenen Werkzeuge und Graphersetzungssysteme — PROGRES, Fujaba, etc. — erfolgt durch spezialisierte Graphmodelle. Das Graphmodell von DRAGOS wurde mit der Maßgabe entwickelt, eine Vielzahl unterschiedlicher Graphmodelle zu unterstützen. Im Gegensatz zu seinen Vorgängern werden daher nicht nur Knoten und Kanten bereitgestellt, sondern auch graphübergreifende und n-äre Relationen sowie hierarchische Graphen. Diese Graphelemente können mit Attributen versehen werden. Zusätzlich muss jedes Graphelement typisiert sein. Die zugehörigen Graphelementklassen werden im DRAGOS-Graphschema definiert, das auch Mehrfachvererbung und abstrakte Klassen unterstützt. Für die persistente Speicherung der Graphen werden austauschbare Graphenspeicher verwendet, die einen Graphen unter anderem in Datenbanksystemen wie PostgreSQL speichern. Im Rahmen der vorliegenden Arbeit sind neben DRAGOS zwei verschiedene Erweiterungsmodule für DRAGOS realisiert worden. Die erste Erweiterung stellt inkrementell berechnete Attribute zur Verfügung. Von der zweiten Erweiterung wird die Versionierung von Graphen angeboten. Änderungen an einem Graphen lassen sich hiermit verfolgen. Zustände mehrerer unterschiedlicher Graphen können zu einer Konfiguration zusammengefasst werden. Die Erweiterungen können beliebig miteinander kombiniert werden. Oberhalb des DRAGOS-Graphmodells werden spezialisierte Graphmodelle realisiert. Dies wird durch SUMAGRAM unterstützt, das die Spezifikation von Graphmodellen und deren Abbildung auf das DRAGOS-Graphmodell durch UMLKlassendiagramme erlaubt. An den Beispielen GXL und DIAPLAN wird die Funktionalität von SUMAGRAM demonstriert. Die spezialisierten Graphmodelle für die Graphersetzungssysteme PROGRES und Fujaba wurden ebenfalls im Rahmen dieser Arbeit realisiert. Bei PROGRES wurden die Codegenerierung und das UPGRADERahmenwerk angepasst. DRAGOS ersetzt nun das bisher verwendete GRAS vollständig. Seine Verwendung ist transparent und hat keinen Einfluss auf die Spezifikation oder die Werkzeugentwicklung. Die durch GRAS bedingten Einschränkungen sind weggefallen. für Fujaba wurde ein spezielles Plugin entwickelt, das dessen Codegenerierung anpasst. Bis auf einige wenige Einschränkungen hat die Verwendung von DRAGOS keinen Einfluss auf die Spezifikation. Basierend auf den DRAGOS-Erweiterungen kann zukünftig die Funktionalität von Fujaba um komplexe Pfade, Nichtdeterminismus, etc. erweitert werden. Die vorgestellten Konzepte wurden implementiert und validiert. DRAGOS stellt einen vollständigen Ersatz für seine Vorgänger dar. Durch seine offene Architektur und Erweiterbarkeit ist DRAGOS für zukünftige Anwendungen gewappnet. Die Probleme seiner Vorgänger werden somit langfristig vermieden.
- ZeitschriftenartikelSemantische Unterstützung des konzeptuellen Gebäudeentwurfs(Softwaretechnik-Trends Band 27, Heft 4, 2007) Kraft, BodoDer frühe architektonische Gebäudeentwurf, der konzeptuelle Entwurf, wird durch SoftwareWerkzeuge derzeit nicht angemessen unterstützt. Während dieser Entwurfsphase ist das Verständnis der Organisation und Funktionsweise eines Gebäudes im Ganzen wichtiger als exakte Dimensionen und Materialdefinitionen. Im Mittelpunkt stehen die funktionalen Einheiten eines Gebäudes, z.B. Räume und Bereiche, und deren komplexes Beziehungsgeflecht. Diese abstrakte Sichtweise auf einen Gebäudeentwurf ermöglicht die semantische, d.h. inhaltlichec Betrachtung des Entwurfsproblems. Der Architekt muss alle für die konzeptuelle Entwurfsphase geltenden Vorschriften und Einschränkung kennen und beachten. Dies sind nicht nur Gesetze, Verordnungen und Normen, sondern ebenso Wünsche und Vorgaben der am Bau Beteiligten. Als Grundlage für alle folgenden Entwurfsphasen gefährden fehlerhafte konzeptuelle Entwürfe die Durchführung eines Bauprojekts und führen zu Mehrkosten. Mangels der Werkzeugunterstützung weichen Architekturen auf einfache Zeichenprogramme oder die klassische Papierskizze aus. Bei der manuellen Übertragung der Entwurfsskizzen in ein CAD-Werkzeug kann die implizit enthaltene, konzeptuelle Information nicht abgebildet werden und geht verloren. Zur Unterstützung des Architekten während der konzeptuellen Entwurfsphase identifiziert diese Arbeit zwei Schwerpunkte. Erstens erhalten Architekten bessere Werkzeugunterstützung für die Erstellung konzeptueller Entwurfspläne. Diese berucksichtigt den hohen Abstraktionsgrad der frühen Entwurfsphase und das kreative, evaluative Vorgehen der Architekten. Zweitens erhält ein Domänenexperte, ein erfahrener Architekt oder Bauingenieur, die Möglichkeit, konzeptuell relevantes Fachwissen zu formalisieren. Die Formalisierung erfolgt spezifisch für eine Gebäudeklasse. Die Zusammenfuhrung beider Schwerpunkte ermöglicht die Verwendung des formalisierten Fachwissens zur Prüfung der konzeptuellen Entwurfspläne. Als Hilfestellung für den Architekten markieren Fehlermeldungen und Hinweise inkonsistente Teile des Entwurfsplans. Die Schwerpunkte der Arbeit werden durch zwei Ansätze bearbeitet. Einerseits erfolgt die formale Modellierung und Spezifikation der zur Realisierung der Werkzeuge benötigten Konzepte. Hierzu wird das Graphersetzungssystem PROGRES verwendet. Andererseits wird eine praxisorientierte Vorgehensweise verfolgt. Durch die Beobachtung der Arbeitsweise von Architekten und der Analyse aktueller CAD-Werkzeuge wird fehlende Funktionalität identifiziert. Die erarbeiteten Konzepte sind in das CAD-Werkzeug ArchiCAD eingebettet. Die vorliegende Arbeit bietet die fundierte Motivation, validierte Konzepte und erprobte Realisierungsvorschläge zur Unterstützung der konzeptuellen Entwurfsphase durch SoftwareWerkzeuge. Die Bereitstellung problemadäquater Repräsentationen für die frühe Entwurfsphase sowie die Möglichkeit zur Formalisierung und Verwendung konzeptuellen Fachwissens führen zu einer manuellen, organisatorischen und kognitiven Entlastung des Architekten. Die gewonnene Kapazität kann der Architekt in die Verbesserung der Entwurfspläne investieren.
- ZeitschriftenartikelWorkshop “Applied Program Analysis” (APA 2007)(Softwaretechnik-Trends Band 27, Heft 4, 2007) Quante, Jochen; Mende, Thilo
- ZeitschriftenartikelIntegratoren zur Konsistenzsicherung von Dokumenten in Entwicklungsprozessen(Softwaretechnik-Trends Band 27, Heft 4, 2007) Becker, Simon M.In Entwicklungs- und Entwurfsprozessen entsteht eine Vielzahl von Dokumenten. Diese werden meist arbeitsteilig, unabhängig voneinander und mit heterogenen Werkzeugen bearbeitet. Da die Dokumente dasselbe zu entwerfende Produkt unter unterschiedlichen Gesichtspunkten beschreiben, bestehen zahlreiche feingranulare Abhängigkeiten zwischen ihnen. Um die Qualität des Produkts zu sichern, ist es unabdingbar, sie zueinander bezuglich dieser Abhängigkeiten konsistent zu halten. In realen Entwicklungsprozessen geschieht dies oft zeitaufwändig und fehleranfällig von Hand. Gängige Werkzeugunterstützung erlaubt lediglich die automatische Generierung abhängiger Dokumente, wobei die inkrementelle Natur von Entwicklungsprozessen und die Notwendigkeit des interaktiven Vorgehens unberücksichtigt bleiben. Diese Arbeit stellt einen darüber hinausgehenden Ansatz und die entsprechenden Werkzeuge zur Konsistenzsicherung vor, so genannte Integratoren. Basis des Ansatzes sind Graphen, Graphersetzungen und Tripelgraphgrammatiken. Als Anwendungsszenario werden verfahrenstechnische Entwicklungsprozesse im Anlagenbau betrachtet. Integratoren erlauben die bidirektionale Transformation zwischen Dokumenten sowie deren Konsistenzprüfung untereinander. Die feingranularen Beziehungen der Dokumente werden persistent in einem so genannten Integrationsdokument abgelegt. Integratoren arbeiten inkrementell, sodass bei der Transformation jeweils nur die Änderungen zwischen Dokumenten übertragen werden, ohne unbeabsichtigt von der Integration nicht betroffene Teile der Dokumente zu überschreiben. Die Integration wird durch Integrationsregeln gesteuert. Da die Zusammenhänge der Dokumente nicht eindeutig sind, wird Benutzerinteraktion bei der Integration unterstützt. Integratoren leiten neue Regeln zur Laufzeit aus Benutzerinteraktionen ab. Da es in den unterschiedlichsten Anwendungsdomänen jeweils eine Vielzahl möglicher Anwendungsstellen für Integratoren gibt, müssen diese mit geringem Aufwand realisiert und an bestehende Werkzeuge angepasst werden können. Integrationsregeln werden mittels eines größtenteils deklarativen, mehrschichtigen Modellierungsformalismus definiert. Er ist als Erweiterung des Metamodells der Unified Modeling Language (UML) realisiert. Innerhalb des Modells werden eine Typ- und eine Instanzebene unterschieden. Auf der Typebene werden zunächst in Dokumentenmodellen die Typen der in den zu integrierenden Dokumenten auftretenden Entitäten und deren mögliche Beziehungen als Klassendiagramme erfasst. Darauf aufbauend können als erste Klärung der möglichen feingranularen dokumentübergreifenden Beziehungen so genannte Linktypen zwischen den Entitätstypen verschiedener Dokumentenmodelle definiert werden. Konkreter werden die Beziehungen auf der Instanzebene des Modells formuliert. In Link-Templates werden mittels Instanzen der Entitäts- und Linktypen Graphmuster als UML-Objektdiagramme spezifiziert, die korrespondierende Situationen aus Quell- und Zieldokument sowie ihre Beziehungen beschreiben. Link-Templates sind deklarativ, sie beschreiben statische Situationen und nicht deren Erzeugung. Aus ihnen werden mittels des Tripelgraphgrammatik-Ansatzes drei Arten operationaler, ausführbarer Regeln abgeleitet: Vorwärtsregeln finden ein Muster im Quelldokument und erzeugen ein korrespondierendes im Zieldokument sowie die Beziehung im Integrationsdokument, Rückwärtsregeln arbeiten umgekehrt. Korrespondenzanalyseregeln erzeugen lediglich die Beziehung zwischen vorhandenen Mustern. Der mehrschichtige Modellierungsformalismus erlaubt die stufenweise Konkretisierung von Integrationswissen. Dadurch wird auch die Anbindung bereits existierender Datenmodelle erleichtert. Die Schichten werden untereinander auf Konsistenz geprüft. Die Ausführung von Integrationsregeln erfolgt durch Graphtransformationen. Im Gegensatz zum ursprünglichen Tripelgraphgrammatik-Ansatz wird jede Regel einem Integrationsalgorithmus folgend durch mehrere Graphtransformationen ausgeführt. Dies dient der Unterstützung mehrdeutiger Regelsätze. Es werden zunächst mögliche Regelanwendungen und deren Konflikte untereinander bestimmt, diese durch Benutzerinteraktion aufgelöst und erst dann Integrationsregeln angewendet. Um diese Art der Ausführung zu realisieren, werden Regelsätze in Graphtransformationssysteme überführt, die aus regelspezifischen und allgemeingültigen Anteilen bestehen. Mit dem resultierenden Graphtransformationssystem können Quell- und Zieldokumente dargestellt und Läufe des Integrators durchgeführt werden. Dabei werden verzahnt Vorwärts-, Rückwärts- und Korrespondenzanalyseregeln ausgeführt. Neben der Ausführung operationaler Integrationsregeln erlaubt der Algorithmus auch die prüfung und gegebenenfalls die Reparatur bereits bestehender Beziehungen im Integrationsdokument. Der Integrationsalgorithmus wird anhand der Darstellung als Graphtransformationssystem in der Arbeit detailliert beschrieben, wobei auch mögliche Optimierungen und Erweiterungen diskutiert werden. Die Konzepte dieser Arbeit sind in Form verschiedener Prototypen realisiert. Ein auf einem kommerziell verfügbaren UML-Werkzeug aufbauender Regeleditor dient der Definition und Konsistenzprüfung von Integrationsregeln. Außerdem wurden zwei unterschiedliche Ansätze zur Realisierung konkreter Integratoren geschaffen. Eine Evaluierungsrealisierung leitet unmittelbar aus den aus Regelsätzen gewonnenen Graphtransformationssystemen Prototypen ab. Diese sind nicht an reale Werkzeuge angebunden, da sie lediglich zum Testen von Integrationsregelsätzen und des Integrationsalgorithmus dienen. für den A-posteriori-Anschluss existierender Entwicklungswerkzeuge und somit den Einsatz in realen Entwicklungsprozessen wurde ein Integratorrahmenwerk geschaffen, das aus einer Architektur und vordefinierten Komponenten für Integratoren besteht. Zentraler Bestandteil ist ein Interpreter für Integrationsregeln, der Regelsätze analog zu den daraus ableitbaren Graphtransformationssystemen ausführt. Neben dem Integrator für das Anwendungsszenario werden in der Arbeit weitere Integratoren vorgestellt. Diese decken zumindest einen Teil der Bandbreite möglicher Integrationsprobleme ab. Besonders interessant sind dabei solche, die ein komplexes Geflecht von Dokumenten integrieren, wobei auch die Kopplung zwischen der technischen und der administrativen Ebene von Entwicklungsprozessen untersucht wird. Die Ergebnisse dieser Arbeit werden in Zukunft in Kooperation mit dem bisherigen Industriepartner im Rahmen eines Transferprojekts in die Praxis übertragen.
- ZeitschriftenartikelKonfigurierung von eHome-Systemen(Softwaretechnik-Trends Band 27, Heft 4, 2007) Norbisrath, UlrichDiese Arbeit stellt eine Möglichkeit vor, den Prozess der Einrichtung sogenannter SmartHome- oder eHome-Systeme aus softwaretechnischer Sicht zu unterstützen. Dies beinhaltet insbesondere, die Erstellung und Zusammenstellung von Software für solche Systeme zu vereinfachen. Das Hauptaugenmerk dieser Arbeit liegt darauf, eine Verschiebung des Entwicklungsprozesses zu einem beteiligten Diensteanbieter hin zu ermöglichen und gleichzeitig den Entwicklungsaufwand zu minimieren. Es gibt verschiedene Gebiete in einem potentiell automatisierten Heim, in denen mit eHomeDiensten eine Unterstützung im Alltag erreicht werden könnte, wie zum Beispiel Lebenskomfort, Sicherheit, Kommunikation oder Unterhaltung. Ein Sicherheitsdienst kann auch Dienste aus einem anderen Gebiet integrieren, insbesondere Dienste aus dem Kommunikationssektor zum Versand von Warnmeldungen oder Dienste aus dem Unterhaltungsbereich, um auf eine Gefahr aufmerksam zu machen. Gerade solche gebietsübergreifenden Dienste sind die, denen das meiste Potential zugeschrieben wird, da sie sich am meisten einer intuitiven Vorstellung von einem intelligenten Dienst nähern. Die Preise der Geräte, die in den gerade angesprochenen Diensten benutzt werden, sind größtenteils auf ein finanzierbares Maß gesunken, so dass es verwunderlich scheint, dass eHomeSysteme nicht schon längt in den meisten Wohnungen verfügbar sind. Einer der Hauptgründe, der eine Verbreitung von eHomes verhindert, ist der Preis solcher Systeme. Wie aber gerade beschrieben, ist es nicht der Preis der Hardware, der hier ins Gewicht fällt, sondern der Preis der Software, welche bisher noch für jedes neue eHome komplett neu entwickelt wird. Im Allgemeinen wird ein Hausbewohner aber keinen kompletten Software-Entwicklungsprozess finanzieren können. Für den Softwaretechniker ist es nun besonders interessant, wie sich dieser Entwicklungsprozess für Dienste in neuen eHome-Systemen so vereinfachen oder anders strukturieren lässt, dass seine Kosten einem großen zu erwartenden Markt angemessen werden. Somit ist der Kern dieser Arbeit die Umwandlung und Neustrukturierung des eHome-Entwicklungsprozesses in einen teilweise automatisierten Konfigurierungsprozess (eHomeSCD-Prozess) und dessen werkzeugseitiger Unterstützung. Mit Hilfe des in dieser Arbeit vorgestellten neu strukturierten Prozesses und einer diesen Prozess unterstützenden Werkzeugsuite, der eHome-Configurator-Werkzeugsuite, wird die eigentliche Entwicklungsarbeit für den Endbenutzer auf die Spezifizierung seiner Umgebung, einiger zu benutzender Dienste und einiger beschreibender Parameter reduziert, ohne Code angeben zu mussen. Die Arbeit zeigt, dass durch den Einsatz sogenannter Funktionalitäten-basierter Komposition und automatischer Konfigurierungstechniken eine signifikante Erleichterung des Entwicklungsaufwandes erzielt werden kann. Die Anwendung der eHome-ConfiguratorWerkzeugsuite an zwei eigenen Demonstratoren und bei einem externen Kooperationspartner bestätigt, dass speziell für die Werkzeugsuite entwickelte Dienste in völlig unterschiedlichen Umgebungen ohne Anpassungen neu eingesetzt werden können und sich sowohl der Entwicklungsaufwand vor dem eHome-SCD-Prozess, also die Dienstentwicklung, als auch der Aufwand innerhalb des Prozesses durch den Einsatz automatisierbarer Konfigurierung und interaktiver Werkzeugunterstützung erheblich reduziert.
- ZeitschriftenartikelReverse Engineering of Complex Legacy Telecommunication Systems(Softwaretechnik-Trends Band 27, Heft 4, 2007) Marburger, AndréReverse and reengineering of large and complex software systems is a difficult task. As a result, many methods and tools for reverse and reengineering have been developed so far. However, the work in this field has concentrated on sequential, and untimed systems, mainly for business applications. The majority of the approaches deals with decomposing monolithic systems, decoupling user interface/presentation from application logic and data handling/database management, or with identifying reusable components. In particular, numerous approaches have addressed the migration of legacy business applications to an object-based or object-oriented architecture. To a large extent, the corresponding methods are data-centered since they focus on structuring the data maintained by an application. Another stream of research has dealt with migration to code of programming languages such as C++ and Java which already provide language support for object-oriented programming. Reverse and Reengineering of process-oriented applications has been addressed less extensively. For example, a telecommunication system is composed of a set of distributed communicating processes which are instantiated dynamically for handling calls requested by the users of the system. Such a system is designed in terms of services provided by entities which communicate according to protocols. Understanding a telecommunication system requires the recovery of these concepts from the current source code and other sources of information. Furthermore, analyzing and visualizing the dynamic behavior is a key to system understanding. This dissertation describes the concepts and the implementation of integrated tools for reverse and reengineering of telecommunication systems which were developed in close cooperation with ERICSSON in the ECARES project (Ericsson Communication ARchitecture for Embedded Systems). The concepts are based on studies and evaluation of a real telecommunication system - Ericsson’s Mobile-service Switching Center (MSC) for GSM networks called AXE10. These studies led to specific requirements. These requirements and an abstract system structure are described within a conceptual framework, which specifies the problem domain and identifies and interrelates the necessary concepts, thus building the terminological and conceptual foundation of this dissertation. To guarantee the suitability and applicability of the methods and tools developed in this thesis, tool support was developed step by step in response to the requirements and questions stated by telecommunication experts. This approach implied an iterative and incremental analysis and development process. Each pass of this process concentrates on a subset of the overall functionality and delivers appropriate analysis functionality and result documents, thus providing another portion of the final reverse and reengineering environment. The essential contributions (concepts, methods, and tools) to reverse engineering of telecommunication systems are as follows: - Structural, control flow, and data flow information is seamlessly integrated into a modular graph scheme. In addition, the scheme organizes static (e.g., from code analysis) as well as dynamic information (e.g., from trace analysis). This enables complex analysis operations incorporating all kinds of information. - The structural analysis part combines aggregation, condensation, and lifting of information from different sources with deduction of additional information and multi-level abstraction and visualization. - Static and dynamic behavioral analyses are utilized to realize link chain analysis, state machine extraction, and trace analysis. For trace analysis, a comprehensive simulator is introduced. - The architecture recovery facility introduced allows to inspect software systems on architecture level described in ROOM notation. - Explicit usage of domain knowledge in the development of concepts, methods, and tools guarantees suitability and user acceptance. - The analysis of multi-language software systems is possible due to the realization of a seamlessly integrated yet open, modular, extensible, and flexible reengineering system. Not all of these concepts are new. There are a number of mature techniques that have already proved to work quite well, especially for the static structural analysis of software. So, there was no need to re-invent them but rather to adapt and incorporate them. However, the combination of these techniques within an open, modular, and flexible reengineering system leads to synergetic effects. These result in considerable improvements with respect to power, applicability, and integration within the reengineering system implementation showing the desired functionality and behavior described by the conceptual framework.
- ZeitschriftenartikelIntegrated Low-Cost eHome Systems: Prozesse und Infrastrukturen(Softwaretechnik-Trends Band 27, Heft 4, 2007) Kirchhof, MichaelIn dieser Arbeit werden eHome-Systeme mit Bezug auf die elektronische Geschäftsabwicklung betrachtet, die bisher in teuren Einzelanfertigungen realisiert werden müssen. Diese Situation kann geändert werden. Das Ziel ist die Ermöglichung einer effizienten und effektiven Realisierungsstrategie für integrierte Low-Cost eHome-Systeme. Der oft hinterfragte Nutzen von eHome-Systemen wird durch die Vorstellung innovativer Anwendungsszenarien belegt. Dabei wird insbesondere der konkrete und auch für den Nutzer erfahrbare Vorteil der Anwendung beleuchtet. Mit einer Einordnung in Generationen werden die gewachsenen Prozesse und Strukturen aktueller eHome-Systeme verdeutlicht. Darin eingeschlossen ist der Zwiespalt zwischen zu starker Technisierung und einhergehender Entmündigung auf der einen Seite und der teilweise mühsamen Erledigung alltäglicher Routinetätigkeiten auf der anderen Seite. Die Vision eines zukunftweisenden eHome-Systems wird als dritte Generation eingeführt. Der zugrunde liegende Gesamtprozess wird untersucht und in eine optimierte Form, basierend auf dem Konzept der Produkt-Familien und der Einbettung der Konfigurierungstechnik überführt. Für die Realisierung wartbarer und nützlicher eHome-Systeme wird das grundlegende Architekturmodell PowerArchitecture vorgestellt. Unter Berücksichtigung dieses Modells werden Basis-Infrastrukturen entwickelt, die als Instrumentarium die Entwicklung von eHome-Diensten optimal unterstützen. Wiederkehrende und zentrale Aufgaben innerhalb von eHome-Systemen sind damit abgedeckt und die Entwicklung der eigentlichen eHome-Dienste wird erleichtert. Die Implementierung kann somit auf die eigentliche Funktionalität beschränkt werden. Einen Hinderungsgrund für die weitere Verbesserung des Entwicklungsprozesses stellt der Bruch zwischen dem imperativen Programmiersprachen-Paradigma und dem Charakter von eHome-Diensten dar. Als geeignetere Abbildung des Verhaltens eines eHome-Dienstes wird das deklarative regelbasierte Paradigma eingeführt. Damit kann ein Entwickler die Funktionalität eines Dienstes deklarativ spezifizieren, während die atomaren Zusammenhänge flexibel und automatisch kombiniert werden. Der verbleibende Implementierungsaufwand wird dabei durch die Einbettung der KomponentenWiederverwendung weiter gesenkt. Mit den erzielten Verbesserungen im Bereich der eHome-Systeme wird eine Vielzahl von eHome-Diensten in diesem ubiquitären System entwickelt werden. Die gleichzeitige Verwendung dieser Dienste wird zu Konflikten im Bezug auf Ressourcen führen und damit die gewünschte Unterschwelligkeit des Systems zerstören. Zur Sicherung des störungsfreien Betriebs wird eine Lösung zur Konflikterkennung und Konfliktresolution vorgestellt. Schließlich wird die Vertriebs-Phase als letzte Phase des eHome-Prozesses als Geschäftsprozess formalisiert. Zur Effizienzsteigerung wird ein Kompetenz-orientiertes Vorgehen entworfen, das mit einem Arbeitsbereichsmodell gekoppelt wird. Damit wird ein hoher Flexibilitätsgrad erreicht. Der Einsatz eines Workflow-ManagementSystems für den Geschäftsprozess zur Unterstützung des Anbieters wird skizziert, womit bei einer Vielzahl zu betreuender eHomes die Prozess-Ausführung und -überwachung ermöglicht wird.
- ZeitschriftenartikelFeature-basierte Modellierung und Analyse von Variabilität in Produktlinienanforderungen(Softwaretechnik-Trends Band 27, Heft 4, 2007) von der Maßen, ThomasDie Entwicklung einer Software-Produktlinie stellt hohe Ansprüche an alle Aktivitäten des Entwicklungsprozesses, der sich durch die Lebenszyklen von Plattform und Produktentwicklungen auszeichnet. Als besondere Herausforderung gilt die Berücksichtigung von Variabilität in Anforderungen. Das zentrale Ziel dieser Arbeit ist es, zu untersuchen, wie Variabilität in Anforderungen im Rahmen der Plattformentwicklung bei Produktlinien modelliert werden kann und welche Qualitätskriterien für die entstehenden Modelle relevant sind, damit diese Modelle für die weiteren Phasen der Plattform- und Produktentwicklung verwendet werden können. Um die Fragen: „Welche Variabilitätskonzepte werden benötigt, um die notwendige Flexibilität in der Plattformspezifikation ausdrücken zu können und welche Notationen eignen sich für die Modellierung der Variabilität in Anforderungen?“ und „Wie kann die Adäquatheit, Widerspruchsfreiheit und Flexibilität der Plattformspezifikation bewerten werden und was sind die Voraussetzungen dafür, dass eine vollständige und widerspruchsfreie Produktspezifikation aus der Plattformspezifikation abgeleitet werden kann?“ beantworten zu können, werden im Rahmen dieser Arbeit zunächst ein Metamodell für die Variabilität in Anforderungen und Notationen daraufhin untersucht, in wie weit sie sich eignen die notwendigen Variabilitätskonzepte abbilden zu können. Als Ergebnis dieser Untersuchung lässt sich festhalten, dass sich insbesondere die FeatureModellierung, die erstmals in der DomainEngineering-Methode FODA in das Zentrum der Modellierungsaktivitäten für Software-Systeme rückte, eignet, Variabilität zu modellieren. Da der FeatureBegriff aber vage ist und es viele unterschiedliche kontextabhängige Definitionen gibt, wird der Begriff Feature für das Requirements Engineering für Produktlinien definiert und die bereits in den unterschiedlichen Methoden und Anwendungsgebieten eingeführten Modellierungselemente in einem Metamodell konsolidiert. Auf Basis dieser Grundlage können FeatureModelle als Basis für die Plattformspezifikation (Plattform-Feature-Modell) und die Produktspezifikation (Produkt-Feature-Modell) dienen. Obwohl sich die Feature-Modellierung in Industrie und Wissenschaft großer Beliebtheit in Bezug auf die Modellierung von Variabilität erfreut, wurde bisher nicht berücksichtigt, welche Qualitätskriterien herangezogen werden müssen, um Feature-Modellen bewerten zu können. Im Rahmen dieser Arbeit wird ein Qualitätsmodell für Feature-Modelle entwickelt, welches sich an dem Qualitätsmodell der IEEE für Anforderungsspezifikation orientiert. Insbesondere werden die Korrektheit und die Widerspruchsfreiheit von Plattform-Feature-Modellen untersucht. Anhand eines Katalogs von Defiziten, welche in die Kategorien Redundanzen, Anomalien und Inkonsistenzen eingeteilt werden, können Defizite in Feature-Modellen identifiziert werden. Da die beschriebenen Defizite immer auf ungeeignete oder widersprüchliche Anforderungen hinweisen, hilft die Beseitigung von Defiziten, die Korrektheit des Plattform-Feature-Modells zu verbessern. In Bezug auf die Korrektheit eines Plattform-Feature-Modells muss weiterhin untersucht werden, ob die modellierte Variabilität, die gewünschte Flexibilität der Produktlinie widergibt. Während eine zu geringe Flexibilität die Ableitung neuer Produkte erschwert und diese somit nur mit großem Aufwand möglich ist, führt eine zu große Flexibilität dazu, dass viel Aufwand in die Entwicklung, Qualitätssicherung und Wartung der gesamten Produktlinie investiert werden muss. Als Maß für die Flexibilität der Produktlinie kann die Anzahl von möglichen Produkt-Feature-Modellen dienen, die auf Basis des Plattform-Feature-Modells abgeleitet werden können. Dazu wird der Variationsgrad eingeführt und Berechnungsvorschriften unter Berücksichtigung aller Modellierungselemente der Feature-Modellierung für den Variationsgrad definiert. Insbesondere stellt die Bestimmung des Variationsgrads bei mehreren modellierten Abhängigkeiten eine große Herausforderung dar. Da die exakte Bestimmung des Variationsgrads unter Berücksichtigung mehrerer Abhängigkeiten die Bestimmung aller Produkt-Feature-Modelle voraussetzt, wird eine Approximation durch eine obere und eine untere Grenze eingeführt. Das vorgestellte Verfahren ermöglicht somit eine schnelle Berechnung des Variationsgrads, anhand dessen der Einfluss auf die Flexibilität der Produktlinie die durch Modifikation des Plattform-Feature-Modells entstehen, bestimmt werden kann. Der Variationsgrad hilft bei der Planung der Produktlinie im Rahmen einer proaktiven Entwicklung und enthüllt erstmals die Flexibilität bei der Migration mehrerer Einzelprodukte zu einer Produktlinie. Weiterhin wird die Entwicklung des Werkzeug-Prototypen RequiLine beschrieben, da bis dato kein kommerzielles Requirements Management Werkzeug die explizite und adäquate Modellierung von Variabilität in Anforderungen unterstützt. RequiLine dient dazu, die in dieser Arbeit eingeführten Konzepte und eine mögliche Werkzeugunterstützung zu demonstrieren.