The Larch/Smalltalk Interface Specification Language

Object-oriented programming languages, such as Smalltalk, help one to build reusable program modules. The reuse of program modules requires adequate documentation --- formal or informal. Larch/Smalltalk is a formal specification language for specifying such reusable Smalltalk modules. Larch/Smalltalk firmly separates specification from implementation. In Larch/Smalltalk, the unit of specification is an abstract data type, which is an abstraction of the behavior produced by one or more Smalltalk classes. A type can be a subtype of other types, which allows types to be organized based on specified behavior, and also allows for inheritance of their specifications. Larch/Smalltalk specifications are developed using specification tools integrated in the Smalltalk programming environment

Supporting software maintenance with non-functional information

The paper highlights the role of non functional information (about efficiency, reliability and other software attributes) of software components in software maintenance, focusing in the component programming framework. Non functional information is encapsulated in modules bound to both definitions and implementations of software components and it is written as expressions in a classical programming language. It is shown with an example how this notation supports software maintenance, with the help of an algorithm which is able to select the best implementation of a software component in its context of use, meaning byPeer ReviewedPostprint (published version

Including non-functional issues in Anna/Ada programs for automatic implementation selection

We present an enrichment of the Anna specification language for Ada aimed at dealing not only with functional specification of packages but also with non-functional information about them. By non-functional information we mean information about efficiency, reliability and, in general, any software attribute measuring somehow the quality of software (perhaps in a subjective manner). We divide this information into three kinds: definition of non-functional properties, statement of non-functional behaviour and statement of non-functional requirements; like Anna annotations, all of this information appears in Ada packages and package bodies and their syntax is close to Ada constructs. Non-functional information may be considered not only as valuable comments, but also as an input for an algorithm capable of selecting the “best” package body for every package definition in a program, the “best” meaning the one that fits the set of non-functional requirements of the package in the program.Peer ReviewedPostprint (author's final draft

Using non-functional requirements in component-based software construction

The main concern of this paper is to present the author's approach to support software development in the component programming framework taking functional and non-functional requirements into account. Functional requirements are written as algebraic specifications, while non-functional information is bound to specifications and implementations by means of ad hoc modules: the nonfunctional information is used to select automatically the most appropriate implementations of software components (the selection algorithm is not presented here). The existence of multiple type implementations is supported by a process model based on the prototyping paradigm. Prototyping is achieved by means of a mixed execution mechanism being able to operate in the context of incremental software development process allowing the execution of incomplete (partially implemented) systems. The ideas we present here are not bound to any particular programming language, giving rise to a method of wide applicability.Peer ReviewedPostprint (published version

A conceptual model for megaprogramming

Megaprogramming is component-based software engineering and life-cycle management. Magaprogramming and its relationship to other research initiatives (common prototyping system/common prototyping language, domain specific software architectures, and software understanding) are analyzed. The desirable attributes of megaprogramming software components are identified and a software development model and resulting prototype megaprogramming system (library interconnection language extended by annotated Ada) are described

The convenience for a notation to express non-functional characteristics of software components

Software systems are characterised both by their functionality (what the system does) and by their non-functionality (how does the system behave with respect to some observable attributes like performance, reusability, reliability, etc.). Both aspects are relevant to software development. However, non-functional issues have received little attention compared to functional ones. In this position paper we highlight the role of non-functionality, and we claim for a notation to deal with them. We enumerate some design principles for such a notation, and then we make a proposal, which allows to de ne non-functional attributes of software, non-functional behaviour of components with respect to these attributes, and also non-functional requirements over implementations.Peer ReviewedPostprint (author's final draft

Reengineering using a data abstraction based specification language

Thesis (M.S.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1992.This electronic version was submitted by the student author. The certified thesis is available in the Institute Archives and Special Collections.Includes bibliographical references (leaves 86-88).by Randall E. Duran.M.S

RICIS Software Engineering 90 Symposium: Aerospace Applications and Research Directions Proceedings Appendices

Papers presented at RICIS Software Engineering Symposium are compiled. The following subject areas are covered: flight critical software; management of real-time Ada; software reuse; megaprogramming software; Ada net; POSIX and Ada integration in the Space Station Freedom Program; and assessment of formal methods for trustworthy computer systems