The history of software development includes numerous tex- tual and graphical ways to represent software structures and the mechanisms for executing high-level instructions. The proliferation of programming languages is a visible outcome of that effort, with many popular languages having a strong association with their creator(s). In this paper, we present a historically focused overview of many different types of software representations, primarily programming languages, but also graphical notations that can generate code in a programming language or be directly executed with associated tools. The paper then describes some of the characteristics that differentiate them from one another, and concludes with a review of guidelines for designing programming languages and notations.

We use Grounded Theory to study the evolution of requirements practices of 16 software startups as they grow and introduce new products and services. These startups operate in a dynamic environment, with significant time and market pressure, and rarely have time for systematic requirements analysis. Our theory describes the evolution of practice along six dimensions that emerged as relevant to their requirements activities: requirements artefacts, knowledge management, requirements-related roles, planning, technical debt and product quality. Beyond the relationships among the dimensions, our theory also explains the turning points that drove the evolution along these dimensions. These changes are reactive, rather than planned, suggesting an overall pragmatic lightness, i.e., flexibility, in the startups' evolution towards engineering practices for requirements. Our theory organises knowledge about evolving requirements practice in maturing startups, and provides practical insights for startups' assessing their own evolution as they face challenges to their growth. Our research also suggests that a startup's evolution along the six dimensions is not fundamental to its success, but has significant effects on their product, their employees and the company.

Tech startups typically approach requirements gathering differently from the process that is used to develop requirements in existing businesses and for existing products. Many of these startups operate in “stealth mode”, taking care to minimize the number of people with whom they share their innovative ideas. It's common for these startups to create a succession of early releases, and apply user feedback from those releases to evolve the features and functions of their products. This talk describes various approaches used by tech startups to define product requirements, and contrasts those approaches with those used in more traditional requirements engineering activities.

This paper is a summary of the author’s keynote talk describing suitable approaches for software projects with small teams (including a single individual) and release cycles in days or weeks rather than in years. Traditional processes used for larger projects have significant shortcomings in smaller projects, particularly the need to devote a significant portion of the overall effort to the process itself.

No abstract available.

The authors explore object-oriented reuse from several perspectives, covering process, methods, technology, architecture, tools, patterns, frameworks and experience. The theme is: objects are neither necessary nor sufficient for effective reuse, but are extremely important if done right.>

This paper gives an introduction to important issues of software engineering and computer-aided software engineering (CASE), focusing on the necessary qualities for a CASE environment. These characteristics are then related to the needs of design automation, showing some of the analogies between CAD and CASE. Finally, the paper describes some properties of the Software through Pictures integrated CASE environment and shows how that environment provides those qualities.

User software engineering (USE) is a methodology, with supporting tools, for the specification, design, and implementation of interactive information systems. With the USE approach, the user interface is formally specified with augmented state transition diagrams, and the operations may be formally specified with preconditions and postconditions. The USE state transition diagrams may be directly executed with the application development tool RAPID/USE. RAPID/USE and its associated tool RAPSUM create and analyze logging information that is useful for system testing, and for evaluation and modification of the user interface. The authors briefly describe the USE transition diagrams and the formal specification approach, and show how these tools and techniques aid in the creation of reliable interactive information systems.

User software engineering (USE) is a methodology, supported by automated tools, for the systematic development of interactive information systems. The USE methodology gives particular attention to effective user involvement in the early stages of the software development process, concentrating on external design and the use of rapidly created and modified prototypes of the user interface. The USE methodology is supported by an integrated set of graphically based tools. The USE methodology and the tools that support it are described.

User Software Engineering is a methodology for the specification and implementation of interactive information systems. An early step in the methodology is the creation of a formal executable description of the user interaction with the system, based on augmented state transition diagrams. This paper shows the derivation of the USE transition diagrams based on perceived shortcomings of the "pure" state transition diagram approach. In this way, the features of the USE specification notation are gradually presented and illustrated. The paper shows both the graphical notation and the textual equivalent of the notation, and briefly describes the automated tools that support direct execution of the specification.

Abstract The programming language PLAIN has been designed to support conversational access to a data base, and incorporates relations as a built‐in data type. This paper describes the architecture of the data base handler for PLAIN, emphasizing the separation of the data base handler from other aspects of the language processor, and the modularization of the data base architecture to support modifications to the language and its implementation with minimal difficulty. The data base architecture is layered in order to provide the greatest possible degree of information hiding and separation of functionality. The paper shows the structure of the data base handler and the functions of the various modules of the system.

This paper discusses some high-level language programming constructs that can be used to manipulate the relations of a relational database system efficiently. Three different constructs are described: (1) tuple identifiers that directly reference tuples of a relation; (2) cursors that may iterate over the tuples of a relation; and (3) markings, a form of temporary relation consisting of a set of tuple identifiers. In each case, attention is given to syntactic, semantic, and implementation considerations. The use of these features is first presented within the context of the programming language PLAIN, and it is then shown how these features could be used more generally to provide database manipulation capabilities in a high-level programming language. Consideration is also given to issues of programming methodology, with an important goal being the achievement of a balance between the enforcement of good programming practices and the ability to write efficient programs.

Future information systems will involve the interconnection of databases through public networks, requiring the development of adequate security facilities within the local nodes in order to prevent unauthorized access and use of data. A key component of any security scheme is a set of lanuage primitives that define access rights; these language primitives must be combined with other language facilities that assure integrity of the data bases involved and that promote the development of reliable software systems. In such an environment, transaction-based systems, providing interactive access to stored data through a set of predefined operations, may be implemented with programming languages containing facilities for data base definition and manipulation. In such a case, it is necessary to provide some primitives for access control within the programming language. This paper presents a set of such primitives, embedded in a module definition facility, that permits defferent classes of users to share a data base in a controlled way. These facilities are presented as a possible set of extensions to the programming language PLAIN.

Abstract There is a great need for a systematic approach to the specification, design, and development of information systems. This article describes the motivating reasons for such an approach and surveys some of the techniques that have been developed to assist the software specification and design activity. A methodology is seen as a combination of tools and techniques employed within an organizational and managerial framework that can be consistently applied to successive information system development projects. The ways that information system development organizations can create and use such methodologies are emphasized.

The programming language PLAIN has been designed to support the construction of interactive information systems within the framework of a systematic programming methodology. One of the key goals of PLAIN has been to achieve an effective integration of programming language and database management concepts, rather than either the functional interface to database operations or the low-level database navigation operations present in other schemes. PLAIN incorporates a relational database definitional facility, along with low-level and high-level operations on relations. This paper describes those features informally, showing how the database operations are combined with programming language notions such as type checking, block structure, expression evaluation, and iteration. A brief description of the implementation status is included.