ly, the remote procedure call problem, which an RPC protocol undertakes to solve, consists of emulating LPC using message passing. LPC has a number of "properties" -- a single procedure invocation results in exactly one execution of the procedure body, the result returned is reliably delivered to the invoker, and exceptions are raised if (and only if) an error occurs. Given a completely reliable communication environment, which never loses, duplicates, or reorders messages, and given client and server processes that never fail, RPC would be trivial to solve. The sender would merely package the invocation into one or more messages, and transmit these to the server. The server would unpack the data into local variables, perform the desired operation, and send back the result (or an indication of any exception that occurred) in a reply message. The challenge, then, is created by failures. Were it not for the possibility of process and machine crashes, an RPC protocol capable of overcomi...

As multimedia information systems begin to infiltrate organizations, there arises a need to capture and disseminate knowledge about how to develop them. Little is thus far known about the realities of multimedia systems development practice, or about how the development of multimedia systems compares to that of ‘traditional ’ information systems. Herein are discussed the findings of a survey of multimedia developers in Ireland. Practitioners generally agree that systematic approaches are desirable in order to beneficially add structure to development processes, but they are predominantly using their own in-house methods rather than those prescribed in the literature.

Abstract. Formal description techniques, verification methods, and their tool-based automated application meanwhile provide valuable support for the formal analysis of communication protocol designs. Nevertheless the practical analysis of modern protocols still requires relatively great efforts and therefore many protocol developments do not employ formal methods. In that context the transfer protocol framework aims to complementary support. It supplies a rich collection of specification modules and guides their efficient composition to service and protocol specifications. Moreover the functional relations between service properties and implementing protocol mechanisms have been investigated systematically. The framework provides a collection of corresponding theorems to be applied to protocol correctness proofs. In result protocol verification can be reduced to the selection, instantiation, and proper arrangement of framework theorems. The verification process can further be supported by special tool-assistance. The tool COAST identifies the compositional structure of a protocol specification mechanically and selects according framework theorems. It splits service property proofs into arrangements of subproofs where the subproofs can mainly be accomplished by application of the selected framework theorems. After outlining the general transfer protocol framework approach we concentrate on the introduction of the tool COAST. We describe its functions and clarify its application by means of the verification of the complex real-life high-speed data transfer protocol XTP.

this article as unfair, a recent study by The Standish Group ii confirms several key statistics we must begrudgingly acknowledge: These issues strike a major nerve within our industry because we all carry the scars of these efforts. Forty years after the invention of the subroutine, why are we still plagued by these failures? Most practitioners and researchers agree to these major causes: 1. Poor requirements management. We forge ahead with development lacking user input and without a clear understanding of the problem we are attempting to solve. 2. Poor change management. Changes to requirements and other development products are inevitable; yet we rarely track them or understand their impact. 3. Poor quality control. We have poor measures for system quality, little knowledge of processes that affect quality, and no feedback to modify the process after witnessing the effects of a particular development strategy. 4.<F12.

The “software crisis ” was first acknowledged in the mid 1960s. Some would claim that the software crisis is still with us. A recent issue of Scientific American ran a story on the currently infamous software disaster at the new Denver international airport [1]. Software engineering has been heralded as the needed discipline that can improve software development to meet the needs of modern software requirements. This paper will look at the key subject at the Queensland University of Technology (QUT) that introduces students to software engineering. This subject will be compared to current model curricula. The success of this subject will be evaluated and a corollary drawn to the usefulness of the model curricula. Then this paper will look at software engineering project work at QUT and consider what are appropriate compromises to make to run a successful group project in a single semester. 1

. Object-orientation seems to be the winning approach in the war of software development paradigms. Compilers for the C programming language have been largely updated to support the object-oriented C++, modern CASE tools and software development methods are designed for object-oriented approaches, and more and more software development organizations believe that objects help them to cut costs and improve software quality. A natural consequence of the popularity of object-oriented methods and tools is that today they are also used for developing large systems. This paper discusses how object technology affects the success factors of an organization developing large systems. This paper is based on experiences in institutionalizing objectoriented technology in the development organization of a large network management system called the Nokia OMC. 1 Introduction Typically, examples in software engineering books show how a software engineering methodology can be applied to a relatively sma...

Will the Next Generation Internet provide an appropriate infrastructure for critical applications, such as are emerging in such settings as health care, electric power grid control, air traffic control, banking, and military command and control? This paper suggests that current trends are unlikely to yield the required platform. Drawing lessons from successful critical networking projects of the past, we propose an alternative based on Virtual Overlay Networks (VONs). Support for VONs would not require radical departure from existing router capabilities, because a limited mechanism of the type we propose is already available. Given a simple Overlay Network (ON) capability, we show that tools for building more sophisticated VONs are already widely available.

etc. There are valid reasons for the diversity of models and standards imposed on our software development and maintenance processes, just as there is a legitimate concern that a high overhead is imposed by customers and markets that require multiple models and standards as a condition of doing business. This presentation describes the drivers behind different models and standards, why they are different, two strategies for integrating diverse models and standards from a model/standard developer’s perspective, and some of the strategies that model implementers can use. The business reality is that software organizations need to address a variety of models and standards, now and in the future, but there are mechanisms that can alleviate some of the overhead when thoughtfully used.

This paper describes MOOSE a full-lifecycle, modelbased approach to the engineering of computer systems. It describes how early lifecycle models that represent the logical behaviour and architecture of a system can be transformed into representations that allow implementation source for both hardware and software to be synthesised.

full paper published in: