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

John Socha

dblp:22/4649 · DBLP profile ↗
← Back
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

TopicWeightPapersLastEvidence papers
Requirements engineering and software design
software architecture
0.021999
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.011999
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
YearPublicationVenuePosition
1999 Analysis of a Conflict between Aggregation and Interface Negotiation in Microsoft's Component Object Model
abstract
Many 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 Standards
abstract
We 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
ICSE2