Auflistung nach:
Auflistung Softwaretechnik-Trends 27(4) - 2007 nach Titel
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.
- ZeitschriftenartikelCHASID:A semantics-oriented authoring environment(Softwaretechnik-Trends Band 27, Heft 4, 2007) Gatzemeier, Felix H.In writing an informational document (such as a scientific article or a textbook), an author faces a number of complicated problems: not just creating the actual media (text, images, and so forth) with its intricacies of formulation, but also selecting the content to be presented and structuring it so that the document in its entirety is consistent and readable. The latter is complicated by re-iterations over the document, where the author reviews and edits it from different perspectives. CHASID, the project described in this book, addresses these tasks of the author: (a) Planning a document, (b) Upholding plans, and (c) Avoiding common structural problems. To do so, it blends itself into the existing conventional authoring environment and maintains a semantical model of the document, which is connected to its hierarchical structure of chapters, sections etc. The functionality is organized according to a cognitive model of the authoring process. The semantical model contains the topics of the document, together with their relations. It is thus also called the topic map here. The connection to the document’s hierarchical structure is kept in exports and imports, indicating which divisions explain a topic, and which ones expect it to be known. The additional functionality requires additional information which is not usually captured during authoring, namely the topic map and its connection. The author generally cannot be assumed to be willing to invest the effort of providing this information without seeing some direct benefit. So, the relationship between additional effort and kinds of possible functionality has also been considered. Beginning with the least additional effort, requiring no additional information to be supplied by the author, tree transformations have been defined to support modifying the document hierarchy. For example, a division may be dissolved, promoting all of its children one level. This functionality requires the author only to find and understand the respective commands. Addressing the overall planning problem, patterns have been introduced as a structured description of text types. A pattern has a name and consists of the problem to be solved (audience and content), a solution as a set of instructions, and a discussion pointing to alternatives and giving further advice. All these components are given in natural language. As a passive means of support (supplying documentation rather than functionality), they also do not require information from the author. On the next level, schemata are provided, proven building blocks of documents spanning both the conventional document and the topic map. A schema has a name and consists of a short and a longer description and a part of a document with weighted components. When the author chooses to use a schema, the document part is merged into the existing document. The new and the existing components participating in the schema instance are grouped in the document, and their weights in this context are recorded for later checks. These schema-based checks produce warnings if important or crucial schema components have been removed. To fix this, the author may connect another component from the document, or dissolve the schema instance. A third weight is used for optional components that may be removed without consequences. This structure is still simple enough for interested casual users to understand: it is basically a cut-out of a document with some parts marked as more and some as less important. This allows schemata to be defined by an author, even for small substructures that just occur repeatedly within a chapter. While instantiating schemata is the most convenient way to construct a topic map, operations for manual modeling are also available. On this level, the author invests the most effort and has to understand the types available in the topic map, but gets detailed control over the model. The author may insert topics and relations into the topic map, or remove them from it. With the topic map available, general checks can also detect faults in it, such as cyclic Part-Of relations. A CHASID prototype has been implemented, connecting to ToolBook and Emacs as conventional authoring applications. The topic map and its connection to the conventional document are maintained in a graph database. All semantical operations have been implemented using the graph-based specification language PROGRES. User-defined schemata are stored as XML files conforming to a proprietary DTD. The approach has been tested by translating advice from conventional writing guides into patterns and schemata. The results were generally satisfactory, but also revealed that more can actually be modeled than is commonly expressed in a guide. In a side-track of the development, topic maps with only a synonym relation were regarded as a means to characterize and evaluate documents. Such models may be constructed by an attentive reader who does not have to be proficient in the subject area of the document, or they may even be derived automatically from documents written in sufficiently equipped markup languages. Based on this, properties of topics relating to their order of exports and imports, being introduced only as a synonym, and others were defined. A formal concept lattice has then been constructed, regarding the topics and their properties as the objects and properties of a formal context. This lattice reveals characteristics of the document and can be used as a metric to spot trouble areas. For example, if many topics are imported before they are exported, an entire section may be misplaced. The experiences from this project indicate that schemata can provide the basis for a semantical model far richer than what may be obtained by manual modeling. This improves creation as well as maintenance of documents.
- ZeitschriftenartikelEinladung zur Konferenz: Software Engineering 2008, München, 18. bis 22. Februar 2008(Softwaretechnik-Trends Band 27, Heft 4, 2007) Bruegge, Bernd
- 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.
- ZeitschriftenartikelGraduiertenkolleg TrustSoft an der Carl von Ossietzky Universität Oldenburg(Softwaretechnik-Trends Band 27, Heft 4, 2007) Hasselbring, Wilhelm
- ZeitschriftenartikelImpact-Analyse für AspectJ - Eine kritische Analyse mit werkzeuggestütztem Ansatz(Softwaretechnik-Trends Band 27, Heft 4, 2007) Störzer, MaximilianAspekt-Orientierte Programmierung (AOP) wird seit Jahren als „die Lösung von SoftwareModularisierungsproblemen propagiert, die in der Literatur als die Tyrannei der dominanten Dekomposition” bekannt sind. Unterzieht man AO Sprachen jedoch einer kritischen Untersuchung, so zeigt sich, dass diese pauschale Aussage bezweifelt werden muss. Diese Arbeit trägt zwei Punkte in diesem Kontext bei: Zum Einen werden AO Sprachkonstrukte kritisch analysiert, um Programmierer auf problematische Anwendung dieser Konstrukte aufmerksam zu machen. In diesem Kontext wird demonstriert, dass AOP - ganz im Gegensatz zu seinen Zielen - leicht in schwerer verständlichem, schlecht wartbarem und fehleranfälligem Quellcode resultieren kann. Zum Anderen werden zur Unterstützung von Programmierern Software Werkzeuge basierend auf statischer und dynamischer Programmanalyse vorgeschlagen. Im Detail wird untersucht, wie Techniken der Change Impact Analyse verwendet werden können, um die Effekte von Aspekten und problematische Anwendung von AO Sprachkonstrukten automatisch zu ermitteln sowie um die Auswirkungen von Systemevolution handhabbar zu machen. Die Arbeit stellt ebenfalls eine Analysetechnik vor, um potentielle Interferenz von Aspekten automatisch zu ermitteln. Die Dissertation schließt mit einer Übersicht über verfügbare Open Source AspectJ Systeme, die zur Evaluierung der vorgestellten Techniken verwendet wurden, und einer auf softwaretechnischen Grundlagen und den in der Arbeit gewonnenen Erkenntnissen beruhenden Bewertung von AOP.
- 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.
- 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.