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.

C. Donald Wilcox

dblp:42/5997 · DBLP profile ↗
← Back
4ranked-venue papers
1as first author
0since 2021 · last 1996
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 2Software engineering, systems software and programming languages · 2 · 1 first-author

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.

Theoretical computer science
2 papers
Logic in computer science · 62% Distributed computing theory · 38%
Software engineering, system software, and programming languages
2 papers
Concurrent programming · 100%
Computer architecture, parallel and distributed computing, and storage systems
1 paper
Embedded and real-time systems · 100%

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

TopicWeightPapersLastEvidence papers
Logic in computer science
temporal logic
0.011996
Reasoning About Places, Times, and Actions in the Presence of Mobility · IEEE Trans. Software Eng. 1996
Logic in computer science › program logic
UNITY logic
0.011996
Reasoning About Places, Times, and Actions in the Presence of Mobility · IEEE Trans. Software Eng. 1996
Concurrent programming › atomicity
atomic operations
0.011993
Dynamic Synchrony Among Atomic Actions · IEEE Trans. Parallel Distributed Syst. 1993
Concurrent programming
concurrency models
0.011993
Dynamic Synchrony Among Atomic Actions · IEEE Trans. Parallel Distributed Syst. 1993
Concurrent programming
synchronization
0.011993
Dynamic Synchrony Among Atomic Actions · IEEE Trans. Parallel Distributed Syst. 1993
Embedded and real-time systems
cyber-physical system platforms
0.011996
Reasoning About Places, Times, and Actions in the Presence of Mobility · IEEE Trans. Software Eng. 1996
Concurrent programming
concurrent system design
0.011994
Architecture-Directed Refinement · IEEE Trans. Software Eng. 1994
Distributed computing theory
leader election
0.011993
Dynamic Synchrony Among Atomic Actions · IEEE Trans. Parallel Distributed Syst. 1993

Methods — techniques the papers use, named apart from their topics

formal derivation · 0.0UNITY logic · 0.0formal semantics · 0.0program derivation · 0.0formal specification · 0.0
YearPublicationVenuePosition
1996 Reasoning About Places, Times, and Actions in the Presence of Mobility
abstract
The current trend toward portable computing systems (e.g., cellular phones, laptop computers) brings with it the need for a new paradigm to facilitate thinking about and designing distributed applications. We use the term mobile to refer to distributed systems that include moving, autonomous agents which loosely cooperate to accomplish a task. The fluid nature of the interconnections among components of a mobile system provides new challenges and opportunities for the research community. While we do not claim to have fully grasped all the issues involved in specifying and modeling such systems, we believe that the notions of place, time, and action will play a central role in any model that is developed. We show that these concepts can be expressed and reasoned about in the UNITY logic with a minimal amount of additional notation. The formal derivation of a control system for a radio-dispatched elevator is used to show how considerations involving place, time, and actions impact the design process, be it formal or semiformal.
C. Donald Wilcox, Gruia-Catalin Roman
IEEE Trans. Software Eng.1
1994 Architecture-Directed Refinement
abstract
As critical computer systems continue to grow in complexity, the task of showing that they execute correctly becomes more difficult. For this reason, research in software engineering has turned to formal methods, i.e., rigorous approaches to demonstrating the correctness of software systems. Unfortunately, the formal methods currently used in the design of concurrent systems do not provide any mechanisms for specifying and reasoning about the mapping of software to hardware. As a result, architectural constraints, even though they play an important role in the design process, are left out of the formal framework. We show how to state architectural constraints in a formal notation, how to prove that programs are allocated correctly to the underlying architecture, and how to factor architectural considerations into a program derivation process which uses a mixture of specification and program refinements. The approach is illustrated by the derivation of two related programs that solve the same problem but are designed to work on distinct architectures.>
Gruia-Catalin Roman, C. Donald Wilcox
IEEE Trans. Software Eng.2
1993 Dynamic Synchrony Among Atomic Actions
abstract
Synchrony continues to be an important concern in concurrent programming. Existing languages and models have introduced a great diversity of constructs for expressing and managing synchronization among sequential processes or atomic actions. The authors put forth a model in which synchrony is viewed as a relation among atomic actions, a relation which may evolve with time. The model is shown to be convenient for expressing formally the semantics of synchrony as it appears in many of the languages and models proposed to date. Among such models Swarm is singled out for its use of dynamic synchrony. The Swarm notation is briefly reviewed. A new concurrent algorithm for the leader election problem illustrates the use of dynamic synchrony in Swarm.>
Gruia-Catalin Roman, Jerome Y. Plun, C. Donald Wilcox
IEEE Trans. Parallel Distributed Syst.3
1992 On Deriving Distributed Programs from Formal Specifications of Functional Requirements and Architectural Constraints
abstract
A method for formal derivation of distributed programs is presented. The approach uses programwide assertions to formulate safety and progress properties of computations. Assertions are used to state functional requirements of the program as well as structural and behavioral constraints imposed by the choice of underlying architecture. The significance of this latter feature is that it offers a single, unified formal framework for integrating functional requirements and architectural constraints.>
Gruia-Catalin Roman, C. Donald Wilcox, Jerome Y. Plun
ICDCS2