1,721,088 research outputs found
Visualisierung der Statik, Dynamik und Infrastruktur von Software mit Hilfe der Stadt‐Metapher
No full textOne of the biggest challenges for software engineers is to understand
software systems and their context quickly and efficiently. To
gain a comprehensive understanding of diverse applications, three
aspects must be analyzed: (a) the static properties of the software
to understand the established architecture, (b) the dynamic software
properties to grasp the loosely coupled dependencies (e.g., via REST)
of modern systems, and (c) the infrastructure and its costs to help understand
software operations. Visualizations can help to make complex
content easier to understand. Real‐life metaphors also help to
better comprehend abstract subjects such as software artefacts. Therefore,
the city metaphor was used in the context of this work to visualize
the three aspects mentioned. The city metaphor maps software
components to buildings and containers of components to districts.
Arcs between buildings represent dependencies between components.
Since the number of both static and dynamic dependencies of
a large software system is enormous, the dependencies that need to
be explicitly drawn in the software city must be reduced to preserve
clarity and foster understanding.
The main goal of this work is therefore to develop a suitable visualization
to best assist software engineers in understanding statics, dynamics,
and infrastructure. The developed visualization HOLOWARE
shows the three aspects in different views. The day view visualizes
static dependencies. To avoid cluttering the city visualization due to
many static dependency arcs, HOLOWARE uses a novel layered layout.
Unlike conventional layouts, dependencies are encoded in the layout
and only architecture‐violating dependencies need to be explicitly represented
as arcs. In a controlled experiment, professional software
engineers solved program comprehension tasks statistically significantly
faster (5.3%) and better (43%) than subjects who performed
the study with the conventional tree map layout. The layered layout
of HOLOWARE reduces static dependency arcs while improving the
understanding of the software architecture.
The night view visualizes the dynamics. When visualizing dynamic
dependencies, two reduction options were explored: clustering and
aggregating the dependencies. Clustering displays only one representative
trace per cluster, intended to reflect an application use case.
Two filtering options, on individual components and use cases, further reduce the arcs. A short study showed that the filters are considered
helpful and 81.8% of the subjects do not need the visualization of
all dependencies for typical software development tasks. The DYNACITY
view aggregates the dependencies. Calls between the same two
components are combined to a representative arc and the aggregate
load is calculated. The brightness of an arc indicates the load. DYNACITY
also visualizes the activity of the component buildings, the more
or longer requests they receive and/or spawn, the brighter they are. In
a controlled experiment, software engineers were able to solve typical
software understanding tasks faster (5.8%), better (11.7%), and with
less cognitive load (6.7%) using the DYNACITY visualization compared
to a traditional edge‐bundled visualization. The DYNACITYrc extension
opens up another use case: root cause analyses. It additionally colors
arcs and buildings according to HTTP status codes, so that errors
color an arc or component red. Another study was able to show that
software engineers find DYNACITYrc very helpful in root cause analysis.
The so‐called CLOUD COST CITY visualizes the infrastructure of
the software and its costs. For this purpose, the city metaphor known
so far is applied to infrastructure artefacts instead of software components.
The area of the buildings represents the usage of a resource
and the height its costs. Thus, bad cost‐benefit ratios can be identified
immediately. A case study showed that the city metaphor is suitable
for analyzing software infrastructure and its costs, and that cost analyses
can be performed more easily than with traditional cloud cost
dashboards.
HOLOWARE is an open‐source visualization that helps software engineers
understand statics, dynamics, and infrastructure. Several studies
investigated the solution approaches of the developed visualization
and were able to validate its usefulness for program understanding.Eine der größten Herausforderungen für Software‐Ingenieure ist
es, Software‐Systeme und deren Kontext schnell und effizient zu verstehen.
Um ein umfassendes Verständnis der vielfältigen Applikationen
zu erlangen, müssen drei Aspekte analysiert werden: (a) die statischen
Eigenschaften der Software, um die bestehende Architektur
zu begreifen, (b) die dynamischen Software‐Eigenschaften, um die
lose gekoppelten Abhängigkeiten (z. B. via REST) moderner Systeme
zu erfassen und (c) die Infrastruktur und deren Kosten, um das
Verständnis des Software‐Betriebs zu fördern. Visualisierungen können
dabei helfen, komplexe Sachverhalte besser verständlich zu machen.
Metaphern aus dem echten Leben helfen zudem, abstrakte Inhalte
wie Software‐Artefakte leichter greifen zu können. Deshalb wurde
im Rahmen dieser Arbeit die Stadtmetapher verwendet, um die
drei genannten Aspekte zu visualisieren. Die Stadtmetapher bildet
Software‐Komponenten auf Gebäude und Container von Komponenten
auf Stadtviertel ab. Bögen zwischen Gebäuden stellen Abhängigkeiten
zwischen Komponenten dar. Da die Anzahl sowohl statischer
als auch dynamischer Abhängigkeiten eines großen Software‐Systems
enorm ist, müssen die explizit zu zeichnenden Abhängigkeiten in der
Software‐Stadt verringert werden, um die Übersichtlichkeit zu wahren
und das Verständnis zu fördern.
Das Hauptziel dieser Arbeit ist es daher, eine geeignete Visualisierung
zu entwickeln, um Software‐Ingenieure beim Verstehen von
Statik, Dynamik und Infrastruktur bestmöglich zu unterstützen. Die
erarbeitete Visualisierung HOLOWARE zeigt die drei Aspekte in verschiedenen
Ansichten. Die Tagesansicht visualisiert statische Abhängigkeiten.
Damit die Stadt‐Visualisierung aufgrund der vielen statischen
Abhängigkeitsbögen nicht überladen wird, verwendet HOLOWARE
ein neuartiges Schichten‐Layout. Im Gegensatz zu herkömmlichen
Layouts werden die Abhängigkeiten in das Layout kodiert und
nur noch architekturverletzende Abhängigkeiten müssen explizit als
Bögen dargestellt werden. In einem kontrollierten Experiment lösten
professionelle Software‐Ingenieure Aufgaben zum Programmverständnis
statistisch signifikant schneller (5,3%) und besser (43%) als
Probanden, die die Studie mit dem herkömmlichen Kacheldiagramm‐
Layout durchführten. Es konnte gezeigt werden, dass das Schichten-Layout von HOLOWARE die statischen Abhängigkeitsbögen sinnvoll
reduziert und gleichzeitig das Verständnis der Statik fördert.
Die Nachtansicht visualisiert die Dynamik. Bei der Visualisierung
dynamischer Abhängigkeiten wurden zwei Reduktionsoptionen untersucht:
Clustern und Aggregieren der Abhängigkeiten. Beim Clustern
wird nur ein repräsentatives Trace pro Cluster angezeigt, der
einen Anwendungsfall der Applikation widerspiegeln soll. Zwei Filteroptionen,
auf einzelne Komponenten und Anwendungsfälle, reduzieren
die Bögen zusätzlich. Eine kurze Studie konnte zeigen, dass zum
einen die Filter hilfreich sind und zum anderen 81,8% der Probanden
die Visualisierung aller Abhängigkeiten für typische Software‐
Entwicklungsaufgaben nicht benötigen. Die DYNACITY‐Ansicht aggregiert
die Abhängigkeiten. Aufrufe zwischen denselben zwei Komponenten
werden zu einem repräsentativen Bogen zusammengefasst
und die aggregierte Last wird berechnet. Die Helligkeit eines Bogens
zeigt die Last an. DYNACITY visualisiert auch die Aktivität der Komponentengebäude,
je mehr oder längere Anfragen sie erhalten und/oder
erzeugen, desto heller sind sie. In einem kontrollierten Experiment
konnten Software‐Ingenieure mit der DYNACITY‐Visualisierung im
Vergleich zu einer herkömmlichen kantengebündelten Visualisierung
typische Aufgaben zum Software‐Verständnis schneller (5,8%), besser
(11,7%) und mit weniger kognitiver Belastung (6,7%) lösen. Die Erweiterung
DYNACITYrc erschließt einen weiteren Anwendungsfall: die
Ursachenanalyse. Sie färbt zusätzlich Bögen und Gebäude entsprechend
der HTTP‐Status‐Codes ein, sodass Fehler einen Bogen oder
eine Komponente rot färben. Eine weitere Studie konnte zeigen, dass
Software‐Ingenieure DYNACITYrc als sehr hilfreich bei Ursachenanalysen
empfinden.
Die sogenannte CLOUD COST CITY visualisiert die Infrastruktur
der Software und deren Kosten. Dazu wird die bisher bekannte
Stadtmetapher anstatt auf Software‐Komponenten auf Infrastruktur‐
Artefakte übertragen. Die Grundfläche der Gebäude bildet die Nutzung
einer Ressource und die Höhe deren Kosten ab. So können
schlechte Kosten‐Nutzen‐Verhältnisse sofort identifiziert werden.
Eine Fallstudie konnte zeigen, dass die Stadtmetapher zur Analyse
von Software‐Infrastruktur und deren Kosten geeignet ist und
eine Kostenanalyse einfacher als mit herkömmlichen Cloud‐Kosten‐
Dashboards möglich ist.
Mit HOLOWARE ist eine quelloffene Visualisierung entstanden, die
Software‐Ingenieure beim Verstehen von Statik, Dynamik und Infrastruktur unterstützt. Mehrere Studien untersuchten die Lösungsansätze
der erarbeiteten Visualisierung und konnten ihren Nutzen für
das Programmverständnis stützen
Going Beyond Counting First Authors in Author Co-citation Analysis
Get PDFThe present study examines one of the fundamental aspects of author co-citation analysis (ACA) - the way co-citation
counts are defined. Co-citation counting provides the data on which all subsequent statistical analyses and mappings
are based, and we compare ACA results based on two different types of co-citation counting - the traditional type that
only counts the first one among a cited work's authors on the one hand and a non-traditional type that takes into
account the first 5 authors of a cited work on the other hand. Results indicate that the picture produced through this non-traditional author co-citation counting contains more coherent author groups and is therefore considerably clearer. However, this picture represents fewer specialties in the research field being studied than that produced through the traditional first-author co-citation counting when the same number of top-ranked authors is selected and analyzed. Reasons for these effects are discussed
Experimentelle Methoden in der Informatik
Get PDFDieser Report enthaelt die Ausarbeitungen von Vortraegen aus einem
Seminar gleichen Namens, das am 3./4. Juli 1995 am Institut f"ur
Programmstrukturen und Datenorganisation unter Leitung von Walter
Tichy, Ernst Heinz, Paul Lukowicz und Lutz Prechelt stattfand.
Die Artikel geben einen Ueberblick ueber die moegliche Funktion
und den Stellenwert experimentellen Vorgehens in verschiedenen Teilen
der Informatik, sowie einerseits deren wissenschaftstheoretische
Grundlage und andererseits ihre bisherige praktische Umsetzung
Variations on the Author
Get PDF“Variations on the Author” discusses two of Eduardo Coutinho’s recent films (Um Dia na Vida, from 2010, and Últimas Conversas, posthumously released in 2015) and their contribution to the general question of documentary authorship. The director’s filmography is characterized by a consistent yet self-effacing form of authorial self-inscription: Coutinho often features as an interviewer that rather than express opinions propels discourses; an interviewer that is good at listening. This mode of self-inscription characterizes him as an author who is not expressive but who is nonetheless markedly present on the screen. In Um Dia na Vida, however, Coutinho is completely absent form the image, while Últimas Conversas, on the contrary, includes a confessional prologue that moves the director from the margins to the center of his films. This article examines the ways in which these works stand out in the filmography of a director who offers new insights into the notion of cinematic authorship
Appropriate Similarity Measures for Author Cocitation Analysis
Get PDFWe provide a number of new insights into the methodological discussion about author cocitation analysis. We first argue that the use of the Pearson correlation for measuring the similarity between authors’ cocitation profiles is not very satisfactory. We then discuss what kind of similarity measures may be used as an alternative to the Pearson correlation. We consider three similarity measures in particular. One is the well-known cosine. The other two similarity measures have not been used before in the bibliometric literature. Finally, we show by means of an example that our findings have a high practical relevance.information science;Pearson correlation;cosine;similarity measure;author cocitation analysis
Adaptive Parameter Pruning in Neural Networks
No full textNeural network pruning methods on the level of individual network parameters (e.g. connection weights) can improve generalization. An open problem in the pruning methods known today (OBD, OBS, autoprune, epsiprune) is the selection of the number of parameters to be removed in each pruning step (pruning strength). This paper presents a pruning method lprune that automatically adapts the pruning strength to the evolution of weights and loss of generalization during training. The method requires no algorithm parameter adjustment by the user. The results of extensive experimentation indicate that lprune is often superior to autoprune (which is superior to OBD) on diagnosis tasks unless severe pruning early in the training process is required. Results of statistical significance tests comparing autoprune to the new method lprune as well as to backpropagation with early stopping are given for 14 different problems
Plat_Forms
No full text
Introduction
Software developers during their work face several fundamental choices with a multitude of options. There are methodological choices, where one selects among possible development processes, and technological choices regarding for instance development tools or base technologies for the software product.
While a number of solid research results are available on some methodological topics (such as review or testing techniques), there is hardly any high-quality information on how specific technologies influence development success. There are narrow benchmarking studies comparing the execution performance of, for example, dababase management systems or application servers, there are feature lists comparing the functionality of base technology products, but there are essentially no holistic studies that compare directly how competing technologies shape a realistic product and how that may influence the project. Those few such studies that exist are very small-scale in terms of the system considered, a good example being jccpprt, and despite their small scale some also lack the methodological rigor required for high credibility, a popular example being Kelly's entertaining, yet visibly biased video.</jats:p
- …
