Demo Data from VLDB 2026 / reviewers in the wild / expert
Gregory Zelesnik
dblp:64/330
· DBLP profile ↗
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
2 papers |
Requirements engineering and software design · 70% Software maintenance and evolution · 30% |
Topics — the 5 heaviest of 5, 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 | 1997 | Abstractions for Software Architecture and Tools to Support Them · IEEE Trans. Software Eng. 1995 Lessons on Converting Batch Systems to Support Interaction (Experience Report) · ICSE 1997 |
Software maintenance and evolution
software evolution |
0.0 | 1 | 1997 | Lessons on Converting Batch Systems to Support Interaction (Experience Report) · ICSE 1997 |
Requirements engineering and software design › software architecture › architecture description
architecture description language |
0.0 | 1 | 1995 | Abstractions for Software Architecture and Tools to Support Them · IEEE Trans. Software Eng. 1995 |
Requirements engineering and software design › software architecture
architecture description |
0.0 | 1 | 1997 | Lessons on Converting Batch Systems to Support Interaction (Experience Report) · ICSE 1997 |
Requirements engineering and software design › software architecture
architecture conformance checking |
0.0 | 1 | 1995 | Abstractions for Software Architecture and Tools to Support Them · IEEE Trans. Software Eng. 1995 |
Methods — techniques the papers use, named apart from their topics
experience report · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1997 | Lessons on Converting Batch Systems to Support Interaction (Experience Report)abstractSoftware often evolves from batch to interactive use.Because these two usage styles are so different, batch systems usually require substantial changes to support interactive use.Specific issues that arise during conversion include assumptions about duration of system execution, incremental and partial processing, scope of processing, unordered and repeated processing, and error handling.Addressing these issues affects the implementation in the areas of memory management, assumptions and invariants, computational organization, and error handling.We use as a working example our conversion of the batch processor .for the UniCon architecture description tool into an interactive architecture development tool.To capture the lessons for practitioners undertaking this type of conversion, we summarize with a checklist of design and implementation considerations. Robert DeLine, Gregory Zelesnik, Mary Shaw |
ICSE | 2 |
| 1995 | Abstractions for Software Architecture and Tools to Support ThemabstractArchitectures for software use rich abstractions and idioms to describe system components, the nature of interactions among the components, and the patterns that guide the composition of components into systems. These abstractions are higher level than the elements usually supported by programming languages and tools. They capture packaging and interaction issues as well as computational functionality. Well-established (if informal) patterns guide the architectural design of systems. We sketch a model for defining architectures and present an implementation of the basic level of that model. Our purpose is to support the abstractions used in practice by software designers. The implementation provides a testbed for experiments with a variety of system construction mechanisms. It distinguishes among different types of components and different ways these components can interact. It supports abstract interactions such as data flow and scheduling on the same footing as simple procedure call. It can express and check appropriate compatibility restrictions and configuration constraints. It accepts existing code as components, incurring no runtime overhead after initialization. It allows easy incorporation of specifications and associated analysis tools developed elsewhere. The implementation provides a base for extending the notation and validating the model.> Mary Shaw, Robert DeLine, Daniel V. Klein, Theodore L. Ross, David M. Young, Gregory Zelesnik |
IEEE Trans. Software Eng. | 6 |