<?xml version="1.0" encoding="UTF-8"?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
<title>Softwaretechnik-Trends 29(2) - 2009</title>
<link href="http://dl.gi.de/handle/20.500.12116/41256" rel="alternate"/>
<subtitle/>
<id>http://dl.gi.de/handle/20.500.12116/41256</id>
<updated>2026-07-21T14:22:46Z</updated>
<dc:date>2026-07-21T14:22:46Z</dc:date>
<entry>
<title>Messung und Nachdokumentation eines uralten COBOL-Systems zwecks der Migration zu Java</title>
<link href="http://dl.gi.de/handle/20.500.12116/41284" rel="alternate"/>
<author>
<name>Sneed, Harry M.</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/41284</id>
<updated>2023-04-25T10:43:09Z</updated>
<published>2009-01-01T00:00:00Z</published>
<summary type="text">Messung und Nachdokumentation eines uralten COBOL-Systems zwecks der Migration zu Java
Sneed, Harry M.
Der folgende Beitrag beschreibt die Analyse einer uralten COBOL Applikation als Voraussetzung für eine Migration zu Java. Zunächst wurde der Code gemessen um Basisdaten für die Aufwandsschätzung und Risikoanalyse zu gewinnen. Anschließend wurde der Code nochmals zwecks der Nachdokumentation bearbeitet. Aus den COBOL-Sourcen wurden sämtliche Verweise auf externe Objekte – Calls, IO-Operationen und DBZugriffe, sowie alle interne Verzweigungen, alle Regel und alle Datenreferenzen – abgeleitet und in ein Software-Repository überführt, aus dem es möglich war Modulaufrufe, Datenflüsse, Datenbankzugriffspfade und Datenquerverweise abzufragen und graphisch darzustellen. Darüber hinaus wurden einzelne Programme und Dateien prototypweise automatisch transformiert. Die COBOL Anweisungen wurden 1:1 in JavaMethoden, die  VSAM-Dateien 1:n in relationale Tabellen umgesetzt. Zum Schluss wurden die Migrationsaufwände geschätzt und eine Risikoanalyse durchgeführt.
</summary>
<dc:date>2009-01-01T00:00:00Z</dc:date>
</entry>
<entry>
<title>Automotive Software: Characteristics and Reengineering Challenges</title>
<link href="http://dl.gi.de/handle/20.500.12116/41283" rel="alternate"/>
<author>
<name>Schulte-Coerne, Vincent</name>
</author>
<author>
<name>Thums, Andreas</name>
</author>
<author>
<name>Quante, Jochen</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/41283</id>
<updated>2023-04-25T10:43:08Z</updated>
<published>2009-01-01T00:00:00Z</published>
<summary type="text">Automotive Software: Characteristics and Reengineering Challenges
Schulte-Coerne, Vincent; Thums, Andreas; Quante, Jochen
Automotive software is different from the kind of software that is usually addressed by current reengineering research. This paper gives an overview of the particular conditions and challenges that we face in the automotive domain.
</summary>
<dc:date>2009-01-01T00:00:00Z</dc:date>
</entry>
<entry>
<title>From Architecture to Source Code – How to Ensure Architecture Compliance in the Implemented System</title>
<link href="http://dl.gi.de/handle/20.500.12116/41282" rel="alternate"/>
<author>
<name>Knodel, Jens</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/41282</id>
<updated>2023-04-25T10:43:08Z</updated>
<published>2009-01-01T00:00:00Z</published>
<summary type="text">From Architecture to Source Code – How to Ensure Architecture Compliance in the Implemented System
Knodel, Jens
Software architecture is the key factor for efficient communication, planning, development, maintenance, and hence, the overall success of the development project. Architecting is an upfront investment made by development organizations to assure that the resulting system(s) will meet the required quality criteria in time and effort. Among others, the software architecture captures the envisioned structure of the system at development time (i.e., the decomposition of the system in manageable units like components). Verifying this planned decomposition late in the lifecycle of the software system reveals – too often – that the implemented system is not compliant to the specified structure. Consequently, efforts spent for architecting were made in vain because the decision and assumption made are no longer reliable and useful. To pro-actively prevent this structural decay, we propose constructive architecture compliance checking, which constantly monitors the modifications made by several (teams of) developers starting at day one of the implementation phase. Whenever structural violations are detected, the particular developer receives live feedback on the violations. Thus, a prompt removal of violations is possible, which ensures compliance of the implemented system with the architecture. Hence, the investments made into architecting are sustained over time.
</summary>
<dc:date>2009-01-01T00:00:00Z</dc:date>
</entry>
<entry>
<title>Reengineering (von &amp; mit) Architekturen</title>
<link href="http://dl.gi.de/handle/20.500.12116/41279" rel="alternate"/>
<author>
<name>Simon, Frank</name>
</author>
<author>
<name>Gawlik, Kai-Uwe</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/41279</id>
<updated>2023-04-25T10:43:07Z</updated>
<published>2009-01-01T00:00:00Z</published>
<summary type="text">Reengineering (von &amp; mit) Architekturen
Simon, Frank; Gawlik, Kai-Uwe
Architekturen stellen prinzipiell ein mächtiges Mittel zur Unterstützung von Reengineering-Aktivitäten dar. In der Praxis scheitert dies allerdings häufig, da Architekturen nicht präzise definiert und sich insbesondere im völlig qualitätssicherungsfreien Raum befinden. In diesem Papier werden diejenigen qualitätssichernden Maßnahmen beschrieben, die VOR dem Einsatz von Architekturen für ein Reengineering zwangsläufig notwendig sind, um Architekturen tatsächlich gewinnbringend für das Reengineering einsetzen zu können.
</summary>
<dc:date>2009-01-01T00:00:00Z</dc:date>
</entry>
</feed>
