Demo Data from EDBT 2026 / reviewers in the wild / expert
Bart Michiels
dblp:44/5842
· DBLP profile ↗
1ranked-venue papers
1as first author
0since 2021 · last 2000
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1 · 1 first-author
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 · 67% Software maintenance and evolution · 33% |
Topics — the 3 heaviest of 4, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Requirements engineering and software design › software architecture › component-based software engineering
component composition |
0.0 | 1 | 2000 | Component composition (poster) · ICSE 2000 |
Requirements engineering and software design › specification
message sequence charts |
0.0 | 1 | 2000 | Component composition (poster) · ICSE 2000 |
Software maintenance and evolution
software reuse |
0.0 | 1 | 2000 | Component composition (poster) · ICSE 2000 |
Methods — techniques the papers use, named apart from their topics
message sequence charts · 0.0behavioral matching · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2000 | Component composition (poster)abstractThis poster depicts a novel approach to document components in a uniform and abstract way. Every use of component is expressed with a specific kind of message sequence charts (MSC), using a limited set of standard primitives with predefined semantics. These primitives are mapped on the actual API of the component(s). This documentation is used to find compatible components and to detect conflicts when composing components. Because of the standard set of primitives, components from different sources can be matched and developers do not have to rely on the concrete API. The behavioural flavour of MSC's is suited to document, as a set of usage scenarios, how a component expects to interact with other components when configured in an application. This complements existing documentation techniques. Bart Michiels, Bart Wydaeghe |
ICSE | 1 |