EDBT 2026 Demo / reviewers in the wild / expert
Mark G. Staskauskas
dblp:31/4419
· DBLP profile ↗
7ranked-venue papers
2as first author
0since 2021 · last 1996
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 6 · 1 first-authorSystems, architecture and hardware · 1 · 1 first-authorComputer networks · 1
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
5 papers |
Program verification · 40% Requirements engineering and software design · 31% Concurrent programming · 27% | |
| Computer architecture, parallel and distributed computing, and storage systems
2 papers |
Distributed systems · 48% Embedded and real-time systems · 38% Parallel and multicore computing · 14% |
Topics — the 12 heaviest of 15, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Concurrent programming
concurrency bug detection |
0.0 | 2 | 1996 | Using Partial-Order Methods in the Formal Validation of Industrial Concurrent Programs · ISSTA 1996 Using Partial-Order Methods in the Formal Validation of Industrial Concurrent Programs · IEEE Trans. Software Eng. 1996 |
Program verification
formal validation |
0.0 | 1 | 1996 | Using Partial-Order Methods in the Formal Validation of Industrial Concurrent Programs · IEEE Trans. Software Eng. 1996 |
Program verification
model checking |
0.0 | 1 | 1996 | Using Partial-Order Methods in the Formal Validation of Industrial Concurrent Programs · ISSTA 1996 |
Concurrent programming
partial-order methods |
0.0 | 1 | 1996 | Using Partial-Order Methods in the Formal Validation of Industrial Concurrent Programs · IEEE Trans. Software Eng. 1996 |
Program verification › model checking
partial order reduction |
0.0 | 1 | 1996 | Using Partial-Order Methods in the Formal Validation of Industrial Concurrent Programs · ISSTA 1996 |
Requirements engineering and software design › specification
reactive system specification |
0.0 | 1 | 1996 | A Framework for Evaluating Specification Methods for Reactive Systems Experience Report · IEEE Trans. Software Eng. 1996 |
Requirements engineering and software design › specification
specification methods |
0.0 | 1 | 1996 | A Framework for Evaluating Specification Methods for Reactive Systems Experience Report · IEEE Trans. Software Eng. 1996 |
Requirements engineering and software design
formal specification |
0.0 | 1 | 1995 | A Framework for Evaluating Specification Methods for Reactive Systems: Experience Report · ICSE 1995 |
Program verification › program logic
UNITY |
0.0 | 1 | 1993 | Formal Derivation of Concurrent Programs: An Example from Industry · IEEE Trans. Software Eng. 1993 |
Embedded and real-time systems
reactive systems |
0.0 | 1 | 1995 | A Framework for Evaluating Specification Methods for Reactive Systems: Experience Report · ICSE 1995 |
Operating systems › i/o
i/o subsystem |
0.0 | 1 | 1993 | Formal Derivation of Concurrent Programs: An Example from Industry · IEEE Trans. Software Eng. 1993 |
Parallel and multicore computing
parallel programming models |
0.0 | 1 | 1988 | The Formal Specification and Design of a Distributed fElectronic Funds-Transfer System · IEEE Trans. Computers 1988 |
Methods — techniques the papers use, named apart from their topics
supertrace algorithm · 0.0static analysis · 0.0partial-order methods · 0.0partial order reduction · 0.0evaluation criteria · 0.0case study · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1996 | Validation-Based Test Sequence Generation for Networks of Extended Finite State Machines
Mark G. Staskauskas |
FORTE | 3 |
| 1996 | Using Partial-Order Methods in the Formal Validation of Industrial Concurrent ProgramsabstractWe have developed a formal validation tool that has been used on several projects that are developing software for AT&T's 5ESS™ telephone switching system. The tool uses Holzmann's supertrace algorithm to check for errors such as deadlock and livelock in networks of communicating processes. The validator invariably finds subtle errors that were missed during thorough simulation and testing; however, the brute-force search it performs can result in extremely long running times, which can be frustrating to users. Recently, a number of researchers have been investigating techniques known as partial-order methods that can significantly reduce the running time of formal validation by avoiding redundant exploration of execution scenarios. In this paper, we describe the design of a partial-order algorithm for our validation tool and discuss its effectiveness. We show that a careful compile-time static analysis of process communication behavior yields information that can be used during validation to dramatically improve its performance. We demonstrate the effectiveness of our partial-order algorithm by presenting the results of experiments with actual industrial examples drawn from a variety of 5ESS™ application domains, including call processing, signalling, and switch maintenance. Patrice Godefroid, Doron A. Peled, Mark G. Staskauskas |
ISSTA | 3 |
| 1996 | A Framework for Evaluating Specification Methods for Reactive Systems Experience ReportabstractNumerous formal specification methods for reactive systems have been proposed in the literature. Because the significant differences between the methods are hard to determine, choosing the best method for a particular application can be difficult. We have applied several different methods, including Modechart, VFSM, ESTEREL, Basic LOTOS, Z, SDL, and C, to an application problem encountered in the design of software for AT&T's 5ESS telephone switching system. We have developed a set of criteria for evaluating and comparing the different specification methods. We argue that the evaluation of a method must take into account not only academic concerns, but also the maturity of the method, its compatibility with the existing software development process and system execution environment, and its suitability for the chosen application domain. Mark A. Ardis, John A. Chaves, Lalita Jategaonkar Jagadeesan, Peter Mataga, Carlos Puchol, Mark G. Staskauskas, James Von Olnhausen |
IEEE Trans. Software Eng. | 6 |
| 1996 | Using Partial-Order Methods in the Formal Validation of Industrial Concurrent ProgramsabstractFormal validation is a powerful technique for automatically checking that a collection of communicating processes is free from concurrency-related errors. Although validation tools invariably find subtle errors that were missed during thorough simulation and testing, the brute-force search they perform can result in excessive memory usage and extremely long running times. Recently, a number of researchers have been investigating techniques known as partial-order methods that can significantly reduce the computational resources needed for formal validation by avoiding redundant exploration of execution scenarios. This paper investigates the behavior of partial-order methods in an industrial setting. We describe the design of a partial-order algorithm or a formal validation tool that has been used on several projects that are developing software for the Lucent Technologies 5ESS/sup (R/) telephone switching system. We demonstrate the effectiveness of the algorithm by presenting the results of experiments with actual industrial examples drawn from a variety of 5ESS application domains. Patrice Godefroid, Doron A. Peled, Mark G. Staskauskas |
IEEE Trans. Software Eng. | 3 |
| 1995 | A Framework for Evaluating Specification Methods for Reactive Systems: Experience ReportabstractNumerous formal specification methods for reactive systems have been proposed in the literature.Because the significant differences bet ween the methods are hard to determine, choosing the best method for a particular application can be difficult.We have applied several different methods, including Modechart, VFSM, ESTEREL, Basic LOTOS, Z, SDL and C, to an application problem encountered in the design of software for AT&T's 5ESS o telephone switching system.We have developed a set of criteria for evaluating and comparing the different specification methods.We argue that the evaluation of a method must take into account not only academic concerns, but also the maturity of the method, its compatibility with the existing software development process and system execution environment, and its suitability for the chosen application domain. Mark A. Ardis, John A. Chaves, Lalita Jategaonkar Jagadeesan, Peter Mataga, Carlos Puchol, Mark G. Staskauskas, James Von Olnhausen |
ICSE | 6 |
| 1993 | Formal Derivation of Concurrent Programs: An Example from IndustryabstractThe formal derivation of an implementation of the I/O (input/output) subsystem portion of an existing operating system is presented. The I/O subsystem is responsible for allocating I/O resources such as tapes, disks, I/O channels in response to requests from user processes. The derivation employs the UNITY methodology which captures the concurrent interaction of the I/O subsystem with its environment. The verified resource allocation algorithm that results from the derivation has been used as part of a high-level design by software engineers implementing the I/O subsystem. As the largest application to date of the UNITY methodology, the derivation illustrates a number of techniques for organizing large specifications and proofs.> Mark G. Staskauskas |
IEEE Trans. Software Eng. | 1 |
| 1988 | The Formal Specification and Design of a Distributed fElectronic Funds-Transfer SystemabstractThe design of an electronic funds-transfer (EFT) system, using the UNITY parallel programming methodology, is presented. The process begins with a high-level specification that captures the essence of transaction processing in the system. In a series of refinement steps, this specification is transformed into one that leads directly to a program suitable for execution on the distributed architecture of the EFT system. Each refinement step involves replacing a data structure by a distributed version that can be implemented efficiently on the target architecture. By defining a correspondence between the replaced data structure and its distributed counterpart, it can be demonstrated formally that each refinement step preserves the intent of the original specification.> Mark G. Staskauskas |
IEEE Trans. Computers | 1 |