By Topic

Software Engineering, IEEE Transactions on

Issue 8 • Date Aug 1994

Filter Results

Displaying Results 1 - 11 of 11
  • Addendum to “Proof rules for flush channels”

    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (96 KB)  

    The logic presented in a previous paper, see ibid., vol. 19, no.4, p.366-78 (1993) for processes that communicate using flush channels is inadequate for reasoning about processes that send multiple identical messages along a channel. A modification to the logic and proof system that remedies this deficiency is described herein View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A formal framework for ASTRAL intralevel proof obligations

    Page(s): 548 - 561
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1068 KB)  

    ASTRAL is a formal specification language for real-time systems. It is intended to support formal software development, and therefore has been formally defined. This paper focuses on how to formally prove the mathematical correctness of ASTRAL specifications. ASTRAL is provided with structuring mechanisms that allow one to build modularized specifications of complex systems with layering. In this paper, further details of the ASTRAL environment components and the critical requirements components, which were not fully developed in previous papers, are presented. Formal proofs in ASTRAL can be divided into two categories: interlevel proofs and intralevel proofs. The former deal with proving that the specification of level i+1 is consistent with the specification of level i, and the latter deal with proving that the specification of level i is consistent and satisfies the stated critical requirements. This paper concentrates on intralevel proofs View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Making changes to formal specifications: requirements and an example

    Page(s): 562 - 568
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (636 KB)  

    Formal methods have had little impact on software engineering practice, despite the fact that most software engineering practitioners readily acknowledge the potential benefits to be gained from the mathematical modeling involved. One reason is that existing modeling techniques tend not to address basic software engineering concerns. In particular, while considerable attention has been paid to the construction of formal models, less attractive maintenance issues have largely been ignored. The purpose of this paper is to clarify those issues and examine the underlying requirements for change support. The discussion is illustrated with a description of a change technique and tool developed for the formal notation LOTOS. This work was undertaken as part of the SCAFFOLD project, which was concerned with providing broad support for the construction and analysis of formal specifications of concurrent systems. Most of the discussion is applicable to other process-oriented notations such as CCS and CSP View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • CSDL: a language for cooperative systems design

    Page(s): 606 - 616
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (904 KB)  

    The aim of a cooperative system is to coordinate and support group activities. Cooperative Systems Design Language (CSDL) is an experimental language designed to support the development of cooperative systems from specification to implementation. In CSDL, a system is defined as a collection of reusable entities implementing floor control disciplines and shared workspaces. CSDL tries to address the difficulties of integrating different aspects of cooperative systems: cooperation control, communication, and system modularization. This paper presents CSDL as a specification language. Basic units are coordinators that can be combined hierarchically. A coordinator is composed of a specification, a body, and a context. The specification defines the cooperation policy; the body controls the underlying communication channels; and the context defines coordinators' interaction in modular systems View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Inconsistency handling in multiperspective specifications

    Page(s): 569 - 578
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1024 KB)  

    The development of most large and complex systems necessarily involves many people-each with their own perspectives on the system defined by their knowledge, responsibilities, and commitments. To address this we have advocated distributed development of specifications from multiple perspectives. However, this leads to problems of identifying and handling inconsistencies between such perspectives. Maintaining absolute consistency is not always possible. Often this is not even desirable since this can unnecessarily constrain the development process, and can lead to the loss of important information. Indeed since the real-world forces us to work with inconsistencies, we should formalize some of the usually informal or extra-logical ways of responding to them. This is not necessarily done by eradicating inconsistencies but rather by supplying logical rules specifying how we should act on them. To achieve this, we combine two lines of existing research: the ViewPoints framework for perspective development, interaction and organization, and a logic-based approach to inconsistency handling. This paper presents our technique for inconsistency handling in the ViewPoints framework by using simple examples View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Design and specification of iterators using the swapping paradigm

    Page(s): 631 - 643
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1188 KB)  

    How should iterators be abstracted and encapsulated in modern imperative languages? We consider the combined impact of several factors on this question: the need for a common interface model for user defined iterator abstractions, the importance of formal methods in specifying such a model, and problems involved in modular correctness proofs of iterator implementations and clients. A series of iterator designs illustrates the advantages of the swapping paradigm over the traditional copying paradigm. Specifically, swapping based designs admit more efficient implementations while offering relatively straightforward formal specifications and the potential for modular reasoning about program behavior. The final proposed design schema is a common interface model for an iterator for any generic collection View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Distributed information systems: an advanced methodology

    Page(s): 594 - 605
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (932 KB)  

    Information systems ranging over wide areas show properties that must be carefully analyzed and designed in order to meet the needs of the customers. Thus the development of such information systems is to be guided by software engineering methods that address problems like distribution of data and processes, communication aspects and fault tolerance. This paper shows the basic modeling concepts and the development process employed by the BOS Engineering Method to meet these requirements. The BOS Engineering Method applies the concept of business transactions to specify behavior in the early analysis phase. Appropriate abstraction levels are defined to reduce the complexity of specifying distribution issues. The development of complex distributed information systems needs a rigorous life cycle model. The BOS Engineering Method relaxes the waterfall life cycle model to allow controlled look ahead and feedback up and down the abstraction levels View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Measuring functional cohesion

    Page(s): 644 - 657
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1176 KB)  

    We examine the functional cohesion of procedures using a data slice abstraction. Our analysis identifies the data tokens that lie on more than one slice as the “glue” that binds separate components together. Cohesion is measured in terms of the relative number of glue tokens, tokens that lie on more than one data slice, and super-glue tokens, tokens that lie on all data slices in a procedure, and the adhesiveness of the tokens. The intuition and measurement scale factors are demonstrated through a set of abstract transformations View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • An empirical study of representation methods for reusable software components

    Page(s): 617 - 630
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (948 KB)  

    An empirical study of methods for representing reusable software components is described. Thirty-five subjects searched for reusable components in a database of UNIX tools using four different representation methods: attribute-value, enumerated, faceted, and keyword. The study used Proteus, a reuse library system that supports multiple representation methods. Searching effectiveness was measured with recall, precision, and overlap. Search time for the four methods was also compared. Subjects rated the methods in terms of preference and helpfulness in understanding components. Some principles for constructing reuse libraries. Based on the results of this study, are discussed View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Tractable dataflow analysis for distributed systems

    Page(s): 579 - 593
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1252 KB)  

    Automated behavior analysis is a valuable technique in the development and maintenance of distributed systems. In this paper, we present a tractable dataflow analysis technique for the detection of unreachable states and actions in distributed systems. The technique follows an approximate approach described by Reif and Smolka, but delivers a more accurate result in assessing unreachable states and actions. The higher accuracy is achieved by the use of two concepts: action dependency and history sets. Although the technique does not exhaustively detect all possible errors, it detects nontrivial errors with a worst-case complexity quadratic to the system size. It can be automated and applied to systems with arbitrary loops and nondeterministic structures. The technique thus provides practical and tractable behavior analysis for preliminary designs of distributed systems. This makes it an ideal candidate for an interactive checker in software development tools. The technique is illustrated with case studies of a pump control system and an erroneous distributed program. Results from a prototype implementation are presented View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Warm standby in hierarchically structured process-control programs

    Page(s): 658 - 663
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (560 KB)  

    We classify standby redundancy design space in process-control programs into the following three categories: cold standby, warm standby, and hot standby. Design parameters of warm standby are identified and the reliability of a system using warm standby is evaluated and compared with that of hot standby. Our analysis indicates that the warm standby scheme is particularly suitable for long-lived unmaintainable systems, especially those operating in harsh environments where burst hardware failures are possible. The feasibility of warm standby is demonstrated with a simulated chemical batch reactor system View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.

Aims & Scope

The IEEE Transactions on Software Engineering is interested in well-defined theoretical results and empirical studies that have potential impact on the construction, analysis, or management of software. The scope of this Transactions ranges from the mechanisms through the development of principles to the application of those principles to specific environments. Specific topic areas include: a) development and maintenance methods and models, e.g., techniques and principles for the specification, design, and implementation of software systems, including notations and process models; b) assessment methods, e.g., software tests and validation, reliability models, test and diagnosis procedures, software redundancy and design for error control, and the measurements and evaluation of various aspects of the process and product; c) software project management, e.g., productivity factors, cost models, schedule and organizational issues, standards; d) tools and environments, e.g., specific tools, integrated tool environments including the associated architectures, databases, and parallel and distributed processing issues; e) system issues, e.g., hardware-software trade-off; and f) state-of-the-art surveys that provide a synthesis and comprehensive review of the historical development of one particular area of interest.

Full Aims & Scope

Meet Our Editors

Editor-in-Chief
Matthew B. Dwyer
Dept. Computer Science and Engineering
256 Avery Hall
University of Nebraska-Lincoln
Lincoln, NE 68588-0115 USA
tseeicdwyer@computer.org