Partial implementations of abstract data types: a dissenting view on errors.
Proc. of the international symposium on Semantics of data types
The art of computer programming, volume 2 (3rd ed.): seminumerical algorithms
The art of computer programming, volume 2 (3rd ed.): seminumerical algorithms
The Science of Programming
Software Development: A Rigorous Approach
Software Development: A Rigorous Approach
A Discipline of Programming
ACM Transactions on Programming Languages and Systems (TOPLAS)
Software Reuse by Specialization of Generic Procedures through Views
IEEE Transactions on Software Engineering
Data abstraction and information hiding
ACM Transactions on Programming Languages and Systems (TOPLAS)
Formal Specification and Design of Mobile Systems
IPDPS '02 Proceedings of the 16th International Parallel and Distributed Processing Symposium
Interpreting the B-Method in the Refinement Calculus
FM '99 Proceedings of the Wold Congress on Formal Methods in the Development of Computing Systems-Volume I - Volume I
Programming methodology
Probabilistic invariants for probabilistic machines
ZB'03 Proceedings of the 3rd international conference on Formal specification and development in Z and B
Automating refinement checking in probabilistic system design
ICFEM'07 Proceedings of the formal engineering methods 9th international conference on Formal methods and software engineering
The challenge of probabilistic event B
ZB'05 Proceedings of the 4th international conference on Formal Specification and Development in Z and B
Relaxing restrictions on invariant composition in the B method by ownership control a la SPEC#
Rigorous Methods for Software Construction and Analysis
B'07 Proceedings of the 7th international conference on Formal Specification and Development in B
Proceedings of the 3rd annual conference on Systems, programming, and applications: software for humanity
Hi-index | 0.00 |
Generally speaking, a “module” is used as an “encapsulation mechanism” to tie together a set of declarations of variables and operations upon them. Although there is no standard way to instantiate or use a module, the general idea is that a module describes the implementation of all the values of a given type. We believe that this is too inflexible to provide enough control: one should be able to use different implementations (given by different modules) for variables (and values) of the same type. When incorporated properly into the notation, this finer grain of control allows one to program at a high level of abstraction and then to indicate how various pieces of the program should be implemented. It provides simple, effective access to earlier-written modules, so that they are useable in a more flexible manner than is possible in current notations. It generalizes to provide the ability to indicate structural transformations, in a disciplined fashion, in order to achieve efficiency with respect to time or space. However, the program will still be understood at the abstract level and the transformations or implementations will be looked at only to deal with efficiency concerns. Finally, some so-called “data types” (e.g. stack and subranges of the integers) can more properly be looked upon simply as restricted implementations of more general types (e.g. sequence and integer). Thus, the notion of subtype becomes less important.