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.

Anurag Mendhekar

dblp:28/1077 · DBLP profile ↗
← Back
2ranked-venue papers
0as first author
0since 2021 · last 1997
—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
Requirements engineering and software design · 100%

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

TopicWeightPapersLastEvidence papers
Requirements engineering and software design
software architecture
0.011997
Open Implementation Design Guidelines · ICSE 1997
Requirements engineering and software design › software architecture › architectural design
module interface design
0.011997
Open Implementation Design Guidelines · ICSE 1997
YearPublicationVenuePosition
1997 Aspect-Oriented Programming
Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina V. Lopes, Jean-Marc Loingtier, John Irwin
ECOOP3
1997 Open Implementation Design Guidelines
abstract
Designing reusable software modules can be extremely difficult.The design must be balanced between being general enough to address the needs of a wide range of clients and being focused enough to truly satisfy the requirements of each specific client One area where it can be particularly difficult to strike this balance is in the implementation strategy of the module.The problem is that generalpurpose implementation strategies, tuned for a wide range of clients, aren't necessarily optimal for each specific client-this is especially an issue for modules that are intended to be reusable and yet provide high-performance.An examination of existing software systems shows that an increasingly important technique for handling this problem is to design the module's interface in such a way that the client can assist or participate in the selection of the module's implementation strategy.We call this approach open implementation.When designing the interface to a module that allows its clients some control over its implementation strategy, it is important to retain, as much as possible, the advantages of traditional closed implementation modules.This paper explores issues in the design of interfaces to open implementation modules.We identify key design choices, and present guidelines for deciding which choices are likely to work best in particular situations.
Gregor Kiczales, John Lamping, Cristina V. Lopes, Chris Maeda, Anurag Mendhekar, Gail C. Murphy
ICSE5