We have found many programming problems for which neither procedural nor object-oriented programming techniques are sufficient to clearly capture some of the important design decisions the program must implement. This forces the implementation of those design decisions to be scattered throughout the code, resulting in “tangled” code that is excessively difficult to develop and maintain. We present an analysis of why certain design decisions have been so difficult to clearly capture in actual code. We call the properties these decisions address aspects, and show that the reason they have been hard to capture is that they crosscut the system’s basic functionality. We present the basis for a new programming technique, called aspect-oriented programming, that makes it possible to clearly express programs involving such aspects, including appropriate isolation, composition and reuse of the aspect code. The discussion is rooted in systems we have built using aspect-oriented programming.

Although software documentation standards often go into great detail about the format of documents, describing such details as paragraph numbering and section headings, they fail to give precise descriptions of the information to be contained in the documents. This paper does the opposite; it defines the contents of documents without specifying their format or the notation to be used in them. We describe documents such as the "System Requirements Document", the "System Design Document", the "Software Requirements Document", the "Software Behaviour Specification ", the "Module Interface Specification", and the "Module Internal Design Document" as representations of one or more mathematical relations. By describing those relations, we specify what information should be contained in each document. 1 Introduction Engineers are expected to make disciplined use of science, mathematics and technology to build useful products. Those who construct computer systems are clearly Enginee...

Workflow management systems (WfMSs) have been used to support various types of business processes for more than a decade now. In workflows for e-commerce and Web-services applications, suppliers and customers define a binding agreement or contract between the two parties, specifying Quality of Service (QoS) items such as products or services to be delivered, deadlines, quality of products, and cost of services. The management of QoS metrics directly impacts the success of organizations participating in e-commerce. Therefore, when services or products are created or managed using workflows, the underlying workflow system must accept the specifications and be able to estimate, monitor, and control the QoS rendered to customers. In this paper, we present a predictive QoS model that makes it possible to compute the quality of service for workflows automatically based on atomic task QoS attributes. To this end, we present a model that specifies QoS and describe an algorithm and a simulation system in order to compute, analyze and monitor workflow QoS metrics. 1

Software architecture is an area of growing importance to practitioners and researchers in government, industry, and academia. Journals and international workshops are devoted to it. Working groups are formed to study it. Textbooks are emerging about it. The government is investing in the development of software architectures as core products in their own right. Industry is marketing architectural frameworks such as CORBA. Why all the interest and investment? What is software architecture, and why is it perceived as providing a solution to the inherent difficulty in designing and developing large, complex systems? This report will attempt to summarize the concept of software architecture for an intended audience of mid to senior level management. The reader is presumed to have some familiarity with common software engineering terms and concepts, but not to have a deep background in the field. This report is not intended to be overly-scholarly, nor is it intended to provide the techni...

Software testing involves execution of a program under test using some fault revealing input data and examination of the output to determine success or failure. A fundamental assumption of this testing is that there is some mechanism, an oracle, that will determine whether or not the results of a test execution are correct. In practice, this is often done by comparing the output, either automatically or manually, to some pre-calculated, presumably correct, output [39]. However, if the program is formally documented it is possible to use the specification to determine the success or failure of a test execution, as in [1], for example. This thesis discusses the development of a prototype tool that automatically generates a test oracle from formal program documentation. In [25], [27] and [28] Parnas et al. advocate the use of a relational model for documenting the intended behaviour of programs. In this method, tabular expressions are used to improve readability so that formal documentati...

Abstract not found

The first part of this paper provides rigorous definitions for several basic concepts underlying the design of dependable programs, such as specification, program semantics, exception, program correctness, robustness, failure, fault, and error. The second part investigates what it means to handle exceptions in modular programs structured as hierarchies of data abstractions. The problems to be solved at each abstraction level, such as exception detection and propagation, consistent state recovery and masking are examined in detail. Both programmed exception handling and default exception handling (such as embodied for example in recovery blocks or database transactions) are considered. An assessment of the adequacy of backward recovery in providing tolerance of software design faults is made. An earlier version of this paper was published in "Dependability of Resilient Computers", T. Anderson, Editor, BSP Professional Books, Blackwell Scientific Publications, UK, 1989, pp. 68-97 INTRO...

classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

We present a foundational theory of software system reliability based on components. The theory describes how component developers can design and test their components to produce measurements that are later used by system designers to calculate composite system reliability --- without implementation and test of the system being designed. The theory describes how to make component measurements that are independent of operational profiles, and how to incorporate the overall system-level operational profile into the system reliability calculations. In principle, the theory resolves the central problem of assessing a component, which is: a component developer cannot know how the component will be used and so cannot certify it for an arbitrary use; but if the component buyer must certify each component before using it, component-based development loses much of its appeal. This dilemma is resolved if the component developer does the certification and provides the results in such a way that the component buyer can factor in the usage information later, without repeating the certification. Our theory addresses the basic technical problems inherent in certifying components to be released for later use in an arbitrary system.

Abstract not found