Gerður Jónsdóttir

dblp:95/4963 · DBLP profile ↗
← Back
1ranked-venue papers
0as first author
0since 2021 · last 2001
—ORCID · none

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

Software engineering, systems software and programming languages · 1

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
Requirements engineering and software design · 87% Software maintenance and evolution · 13%

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

TopicWeightPapersLastEvidence papers
Requirements engineering and software design › software architecture
component-based software engineering
0.012001
A notation for problematic architecture interactions · ESEC / SIGSOFT FSE 2001
Requirements engineering and software design
software architecture
0.012001
A notation for problematic architecture interactions · ESEC / SIGSOFT FSE 2001
Software maintenance and evolution
software integration
0.012001
A notation for problematic architecture interactions · ESEC / SIGSOFT FSE 2001
YearPublicationVenuePosition
2001 A notation for problematic architecture interactions
abstract
The progression of component-based software engineering (CBSE) is essential to the rapid, cost-effective development of complex software systems. Given the choice of well-tested components, CBSE affords reusability and increases reliability. However, applications developed according to this practice can often suffer from difficult maintenance and control, problems that stem from improper or inadequate integrate solutions. Avoiding such unfortunate results requires knowledge of what causes the interoperability problems in the first place. The time for this assessment is during application design. In this paper, we define problematic architecture interactions using a simple notation with extendable properties. Furthermore, we delineate a multi-phase process for pre-integration analysis that relies on this notation. Through this effort, potential problematic architecture interactions can be illuminated and used to form the initial requirements of an integration architecture.
Leigh A. Davis, Rose F. Gamble, Jamie Payton, Gerður Jónsdóttir, Dennis J. Underwood
ESEC / SIGSOFT FSE4