Demo Data from EDBT 2026 / reviewers in the wild / expert
John Socha
dblp:22/4649
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 1999
—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
2 papers |
Requirements engineering and software design · 100% |
Topics — the 2 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Requirements engineering and software design
software architecture |
0.0 | 2 | 1999 | Analysis of a Conflict between Aggregation and Interface Negotiation in Microsoft's Component Object Model · IEEE Trans. Software Eng. 1999 Using Formal Methods to Reason about Architectural Standards · ICSE 1997 |
Requirements engineering and software design › software architecture › component-based software engineering
component integration |
0.0 | 1 | 1999 | Analysis of a Conflict between Aggregation and Interface Negotiation in Microsoft's Component Object Model · IEEE Trans. Software Eng. 1999 |
Methods — techniques the papers use, named apart from their topics
formal analysis · 0.0review validation · 0.0formal theory · 0.0formal methods · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1999 | Analysis of a Conflict between Aggregation and Interface Negotiation in Microsoft's Component Object ModelabstractMany software projects today are based on the integration of independently designed software components that are acquired on the market, rather than developed within the projects themselves. A component standard, or integration architecture, is a set of design rules meant to ensure that such components can be integrated in defined ways without undue effort. The rules of a component standard define, among other things, component interoperability and composition mechanisms. Understanding the properties of such mechanisms and interactions between them is important for the successful development and integration of software components, as well as for the evolution of component standards. The paper presents a rigorous analysis of two such mechanisms: component aggregation and dynamic interface negotiation, which were first introduced in Microsoft's Component Object Model (COM). We show that interface negotiation does not function properly within COM aggregation boundaries. In particular, interface negotiation generally cannot be used to determine the identity and set of interfaces of aggregated components. This complicates integration within aggregates. We provide a mediator-based example, and show that the problem is in the sharing of interfaces inherent in COM aggregation. Kevin J. Sullivan, Mark Marchukov, John Socha |
IEEE Trans. Software Eng. | 3 |
| 1997 | Using Formal Methods to Reason about Architectural StandardsabstractWe present a study in which we used formal methods to reason precisely about aspects of a widely used software architectural standard, namely Microsoft's Component Object Model (COM).We developed a formal theory of COM to help us reason about a proposed compositional architectural style based on COM, intended for use in a novel commercial multimedia authoring system.The style combined COM objects, integration mediators, and the COM reuse mechanism of aggregation.Our use of formal methods averted an architectural disaster by revealing essential but subtle and counterintuitive properties of COM.We partially validated our theory by subjecting it to review by the designers of COM and by testing it against other available data.The theory has good evidential support. Kevin J. Sullivan, John Socha, Mark Marchukov |
ICSE | 2 |