Results 1 -
3 of
3
A formal object-oriented analysis for software reliability: Design for verification
- In Proc. FASE
, 2001
"... Abstract. This paper presents the OOA design step in a methodology which integrates automata-based model checking into a commercially supported OO software development process. We define and illustrate a set of design rules for OOA models with executable semantics, which lead to automata models with ..."
Abstract
-
Cited by 16 (8 self)
- Add to MetaCart
Abstract. This paper presents the OOA design step in a methodology which integrates automata-based model checking into a commercially supported OO software development process. We define and illustrate a set of design rules for OOA models with executable semantics, which lead to automata models with tractable state spaces. The design rules yield OOA models with functionally structured designs similar to those of hardware systems. These structures support modelchecking through techniques known to be feasible for hardware. The formal OOA methodology, including the design rules, was applied to the design of NASA robot control software. Serious logical design errors that had eluded prior testing, were discovered in the course of model-checking. 1
A critical review of "End-to-end arguments in system design"
, 2000
"... The end-to-end arguments raised by Saltzer, Reed and Clark in the early 1980s are amongst the most influential of all communication protocol design guides. However, they have recently been challenged by the advent of firewalls, caches, active networks, NAT, multicasting and network QOS. This paper r ..."
Abstract
-
Cited by 8 (0 self)
- Add to MetaCart
The end-to-end arguments raised by Saltzer, Reed and Clark in the early 1980s are amongst the most influential of all communication protocol design guides. However, they have recently been challenged by the advent of firewalls, caches, active networks, NAT, multicasting and network QOS. This paper reviews the end-to-end arguments, highlighting their subtleties, and provides additional arguments for and against end-to-end implementations. It shows the importance of trust as a criterion for deciding whether to implement a function locally or end-toend, and how end-to-end implementations can help robustness, scalability, ease of deployment, and the provision of appropriate service. It focuses on the performance implications of end-toend or localized functionality, and argues against end-to-end congestion control of the form used by TCP. I.
Integrity Checks Used for Security Can Also Be Used for Error Control.
"... Communication systems check integrity to protect information against alteration introduced by natural means such as noise and by malicious security attacks. This paper proposes that some integrity checks used for security should also be used for error control, since there are similarities between th ..."
Abstract
-
Cited by 1 (1 self)
- Add to MetaCart
Communication systems check integrity to protect information against alteration introduced by natural means such as noise and by malicious security attacks. This paper proposes that some integrity checks used for security should also be used for error control, since there are similarities between the functions used for both purposes, and repeated checking can have a high cost. The paper extensively examines where integrity functions should be implemented in a network, and the dependencies between functions implemented in a node, since these limit the extent to which such amalgamation of function is possible. The arguments presented in this paper mean that end-system-to-end-system (e.g. Transport layer) error checks will need to be cryptographically strengthened if they are to remain justifiable in the future.

