<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
<channel>
<title>Softwaretechnik-Trends 27(4) - 2007</title>
<link>http://dl.gi.de/handle/20.500.12116/41390</link>
<description/>
<pubDate>Tue, 21 Jul 2026 14:25:00 GMT</pubDate>
<dc:date>2026-07-21T14:25:00Z</dc:date>
<item>
<title>Konfigurierung von eHome-Systemen</title>
<link>http://dl.gi.de/handle/20.500.12116/41405</link>
<description>Konfigurierung von eHome-Systemen
Norbisrath, Ulrich
Diese 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.
</description>
<pubDate>Mon, 01 Jan 2007 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://dl.gi.de/handle/20.500.12116/41405</guid>
<dc:date>2007-01-01T00:00:00Z</dc:date>
</item>
<item>
<title>aTool: Typographie als Quelle der Textstruktur</title>
<link>http://dl.gi.de/handle/20.500.12116/41404</link>
<description>aTool: Typographie als Quelle der Textstruktur
Meyer, Oliver
Um 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.
</description>
<pubDate>Mon, 01 Jan 2007 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://dl.gi.de/handle/20.500.12116/41404</guid>
<dc:date>2007-01-01T00:00:00Z</dc:date>
</item>
<item>
<title>Reverse Engineering of Complex Legacy Telecommunication Systems</title>
<link>http://dl.gi.de/handle/20.500.12116/41403</link>
<description>Reverse Engineering of Complex Legacy Telecommunication Systems
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.
</description>
<pubDate>Mon, 01 Jan 2007 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://dl.gi.de/handle/20.500.12116/41403</guid>
<dc:date>2007-01-01T00:00:00Z</dc:date>
</item>
<item>
<title>Semantische Unterstützung des konzeptuellen Gebäudeentwurfs</title>
<link>http://dl.gi.de/handle/20.500.12116/41402</link>
<description>Semantische Unterstützung des konzeptuellen Gebäudeentwurfs
Kraft, Bodo
Der 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.
</description>
<pubDate>Mon, 01 Jan 2007 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://dl.gi.de/handle/20.500.12116/41402</guid>
<dc:date>2007-01-01T00:00:00Z</dc:date>
</item>
</channel>
</rss>
