Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Társis Tolêdo

dblp:99/10534 · DBLP profile ↗
← Back
2ranked-venue papers
0as first author
0since 2021 · last 2013
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 2

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Program analysis · 91% Requirements engineering and software design · 9%

Topics — the 4 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Program analysis › data flow analysis
IFDS-based analysis
0.212013
SPLLIFT: statically analyzing software product lines in minutes instead of years · PLDI 2013
Program analysis › static analysis
interprocedural analysis
0.212013
SPLLIFT: statically analyzing software product lines in minutes instead of years · PLDI 2013
Program analysis
static analysis
0.212013
SPLLIFT: statically analyzing software product lines in minutes instead of years · PLDI 2013
Requirements engineering and software design
software product lines
0.012013
SPLLIFT: statically analyzing software product lines in minutes instead of years · PLDI 2013

Methods — techniques the papers use, named apart from their topics

IFDS · 0.2IDE framework · 0.2
YearPublicationVenuePosition
2013 SPLLIFT: statically analyzing software product lines in minutes instead of years
abstract
A software product line (SPL) encodes a potentially large variety of software products as variants of some common code base. Up until now, re-using traditional static analyses for SPLs was virtually intractable, as it required programmers to generate and analyze all products individually. In this work, however, we show how an important class of existing inter-procedural static analyses can be transparently lifted to SPLs. Without requiring programmers to change a single line of code, our approach SPLLIFT automatically converts any analysis formulated for traditional programs within the popular IFDS framework for inter-procedural, finite, distributive, subset problems to an SPL-aware analysis formulated in the IDE framework, a well-known extension to IFDS. Using a full implementation based on Heros, Soot, CIDE and JavaBDD, we show that with SPLLIFT one can reuse IFDS-based analyses without changing a single line of code. Through experiments using three static analyses applied to four Java-based product lines, we were able to show that our approach produces correct results and outperforms the traditional approach by several orders of magnitude.
Eric Bodden, Társis Tolêdo, Márcio Ribeiro 0001, Claus Brabrand, Paulo Borba, Mira Mezini
PLDI2
2011 On the impact of feature dependencies when maintaining preprocessor-based software product lines
abstract
During Software Product Line (SPL) maintenance tasks, Virtual Separation of Concerns (VSoC) allows the programmer to focus on one feature and hide the others. However, since features depend on each other through variables and control-flow, feature modularization is compromised since the maintenance of one feature may break another. In this context, emergent interfaces can capture dependencies between the feature we are maintaining and the others, making developers aware of dependencies. To better understand the impact of code level feature dependencies during SPL maintenance, we have investigated the following two questions: how often methods with preprocessor directives contain feature dependencies? How feature dependencies impact maintenance effort when using VSoC and emergent interfaces? Answering the former is important for assessing how often we may face feature dependency problems. Answering the latter is important to better understand to what extent emergent interfaces complement VSoC during maintenance tasks. To answer them, we analyze 43 SPLs of different domains, size, and languages. The data we collect from them complement previous work on preprocessor usage. They reveal that the feature dependencies we consider in this paper are reasonably common in practice; and that emergent interfaces can reduce maintenance effort during the SPL maintenance tasks we regard here.
Márcio Ribeiro 0001, Felipe Queiroz, Paulo Borba, Társis Tolêdo, Claus Brabrand, Sérgio Soares
GPCE4