Auflistung Softwaretechnik-Trends 35(2) - 2015 nach Titel
1 - 10 von 22
Treffer pro Seite
Sortieroptionen
- ZeitschriftenartikelAPI-related Developer Profiling (Extended Abstract)(Softwaretechnik-Trends Band 35, Heft 2, 2015) Aksu, Hakan; Lämmel, RalfWe analyze the version history of software projects to determine API-related profiles of software developers. To this end, we identify API references in source-code changes and aggregate such references through suitable metrics that provide different views on the API usage per developer so that certain conclusions regarding developer experience or comparisons between developers become feasible. We apply this approach in a case study for the open-source project JHotDraw.
- ZeitschriftenartikelArchitecture-based Analysis of Changes in Information System Evolution(Softwaretechnik-Trends Band 35, Heft 2, 2015) Heinrich, Robert; Rostami, Kiana; Stammel, Johannes; Knapp, Thomas; Reussner, RalfSoftware is subject to continuous change. Software quality is determined by large extent through architecture which reflects important decisions, e.g. on structure and technology. For sound decision making during evolution change impacts on various system artifacts must be understood. In this paper, we introduce a new evolution scenario (replacing the database) to an established demonstrator for information system evolution. We demonstrate the application of an architecture-based approach for change impact analysis to identify artifacts affected by the scenario.
- ZeitschriftenartikelA Co-evolution Approach for Source Code and Component-based Architecture Models(Softwaretechnik-Trends Band 35, Heft 2, 2015) Langhammer, Michael; Krogmann, KlausDuring the lifecycle of a software system, the software needs to evolve, e.g, through new features or necessary platform adaptions. If architecture and source code are not kept consistent during this software evolution, well-known problems, such as architecture drift and architecture erosion, can occur. To solve these problems, existing approaches usually focus on the consistency between class diagrams and code, or use approaches where the architecture model can completely be generated from the code. In this paper, we present a fully integrated coevolution approach for component-based architecture and source code based on Vitruvius. We also present initial, extendable mapping rules from componentbased architecture to source code.
- ZeitschriftenartikelData Reengineering, Evolution and Migration to Prepare a Legacy Application Platform Migration(Softwaretechnik-Trends Band 35, Heft 2, 2015) Teppe, WernerLanglebige Softwaresysteme erfahren während ihrer Lebenszeit vielfältige Änderungen und Anpassungen. So werden Fehler behoben und kleinere Anpassungen durchgeführt (Maintenance). Massive Erweiterungen auf Grund von Kundenanforderungen können an die Grenzen der anfänglichen gewählten Architektur gehen. Das gleiche kann bei Anwendungsrückbauten auftreten, Außerdem kann sich das Applikationsumfeld ändern: neue Technologien kommen auf bei Hardware, Software, Middleware usw. In jedem der letztgenannten Fälle gilt es zu entscheiden, ob man zu einer “Standardsoftware” wechseln soll, die Anwendung neu entwickeln oder migrieren soll. Wenn der Funktionsumfang der Anwendung nahezu unverändert bleiben kann, bietet die Migration Vorteile (Kosten, Risikominimierung u.a. [2, [3]).
- ZeitschriftenartikelEditorial: 17. Workshop Software-Reengineering und -Evolution der GI-Fachgruppe Software-Reengineering (SRE) Bad Honnef 4.-6. Mai 2015(Softwaretechnik-Trends Band 35, Heft 2, 2015) Riediger, Volker; Quante, Jochen; Borchers, Jens; Jelschen, Jan
- ZeitschriftenartikelEstablishing Common Architectures for Porting Mobile Applications to new Platforms(Softwaretechnik-Trends Band 35, Heft 2, 2015) Stehle, Tilmann; Riebisch, Matthias
- ZeitschriftenartikelA Methodology for Impact Analysis Based on Model Differencing(Softwaretechnik-Trends Band 35, Heft 2, 2015) Müller, Klaus; Rumpe, Bernhard
- ZeitschriftenartikelModularity – Often Desired, but Rarely Achieved(Softwaretechnik-Trends Band 35, Heft 2, 2015) Knodel, Jens; Naab, Matthias; Weitzel, Balthasar“Everything should be modular” is an exalted goal stated by almost every architect – but is it really possible to achieve this goal? In this experience paper, we share our lessons learned across a number of restructuring projects that went modular. We discuss typical business motivations, restructuring efforts starting with good intentions, and reconstruction reality striking back. In retrospective, we analyze typical pitfalls to be circumvented. Examples illustrate our findings and support a truism too often ignored by architects: everything has its price, and more often than not, the price for modularity is a lot higher than initially estimated.
- ZeitschriftenartikelMulti-Level Debugging for Extensible Languages(Softwaretechnik-Trends Band 35, Heft 2, 2015) Pavletic, Domenik; Raza, Syed AounMulti-level debugging of extensible languages requires lifting program state to the extension level while translating stepping commands to the base-level. Implementing such bi-directional mappings is feasible for languages with a low abstraction level (e. g., C). However, language workbenches support language stacking with a bottom-up approach from low- to high-level (e. g., domain-specific) languages. This way, generation of code written with these high-level languages is incremental. However, languages can have more than one generator, which is selected depending on the execution environment. On the other hand, provision of such flexibility makes multi-level debugging much harder. In this paper, we present an approach on how to enable debugging for such multi-staged generation environments. The approach is illustrated by mbeddr, which is an extensible C language.
- ZeitschriftenartikelNamensänderung in einem Reverse Engineering Projekt(Softwaretechnik-Trends Band 35, Heft 2, 2015) Sneed, Harry M.In diesem Beitrag wird das Problem der verstümmelten Daten- und Prozedurnamen im alten Code für Reengineering Projekte angesprochen. In den meisten Legacy-Systemen sind diese Namen mnemotechnische Abkürzungen die keiner mehr versteht. Dies verhindert, dass Diagramme und andere Dokumente, die aus dem Code gewonnen werden, verständlich sind. Sollte der Code transformiert werden, z.B. von COBOL in Java, bleibt auch der Java Code unleserlich und wird von zuständigen Entwicklern abgelehnt. Um erfolgreiche Reverse- oder ReEngineering Projekte durchzuführen muss etwas mit den Namen im Code geschehen. Hier wird eine Lösung beschrieben, die für ein Mainframe-Migrationsprojekt in einer Landeverwaltung angewandt wurde. Mit Hilfe dieser Lösung konnten verständliche Dokumente aus altem VisualAge Code gewonnen werden, die als Basis für eine Re-Implementierung dienen.
- «
- 1 (current)
- 2
- 3
- »