In this paper we discuss the verification and validation of software architecture for system of systems. Software architecture plays a vital role in the systematic construction of large systems of systems; it defines the design space and provides a road map leading to the successful construction of system of systems that meet the functional and non-functional requirements. Moreover, a good architecture must allow the system of systems to evolve to meet new requirements due to change in mission. This paper introduces a mathematical model to tie the non-functional requirements of software systems to their architecture, and presents an approach to evaluate the quality of software architecture in light of meeting the requirements.

Article 5 ID: 1449608 DOI: 10.1145/1449603.1449608 It has long been recognized that there is a need for a comprehensive model for graduate software engineering education in the U.S. and worldwide. This article describes such an initiative and invites interested parties to participate.

The concept of use case has become popular in developing requirements for software systems. It is even recommended as an inherent part of the Unified Modeling Language (UML). An early predecessor of the use case for systems and procedures practice in the 1960's was the Playscript procedure. This article describes how Playscript can contribute to better use cases.

Many traditional engineering designs, other than software, depend on the physical properties of components. Those properties enable the engineer to specify precise tolerances between those components. Software components are abstractions with no inherent physical properties. The absence of physical properties makes it more difficult, but not impossible, to design to tolerances. This paper describes some design metrics for designing software components to tolerances. It uses some already established design metrics, and expands on the role of other software practices already available. This paper also restricts the discussion to software components, rather than to the algorithms contained within those components.

Software safety and software risk management are two of the most important facets of modern software engineering. To understand safety requires that we understand first what is not safe. This paper examines the concept of failure in software engineering and describes an approach to failure-driven software design (FDSD).

Software risk management is a critical aspect of software engineering. Software risks based on metrics derived from a large number of similar projects, along with effective statistical methods, can improve risk prediction, assessment, and management.

Many different concerns contribute to the complexity of software development. Some of these concerns are easy to spot. Others are right in front of us all along but not explicitly identified in a way that makes them intellectually accessible. We describe an idea that has always been in the background of awareness for programmers and software designers, but which seldom gets sufficient acknowledgement to be written about on its own. We call this linguistic [dis]continuity.

Speakers at conferences often mention the Principle of Least Surprise. This article explores the notion of surprise on a Surprise Tolerance Continuum. We also comment on how different disciplines benefit from managing surprise. Since this publication deals with software engineering, we focus on problems related to the creation, management, and maintenance of software.

We introduce the notion of an intelligent software decoy, and provide both an architecture and event-based lan- guage for automatic implementation of them. Our decoys detect and respond to patterns of suspicious behavior, and maintain a repository of rules for behavior patterns and de- coying actions. As an example, we construct a model of system behavior from an initial list of event types and their attributes in the interaction between computer worms and an operating system. The model represents patterns of suspicious or mali- cious events that the software decoy should detect, and specific actions to be taken in response. Our approach explicitly treats both standard and nonstandard invocations of components, with the latter representing an attempt to circumvent the public interface of the component. a

The Great Language Debate will explore the benefits of some of the currently in-use object-oriented programming languages. Languages will include Ada, Eiffel, Java, C++, and Smalltalk, and possibly others. This is a moderated panel. The moderator will be someone who is as unbiased as possible. Each language will be represented by an advocate who will share a short presentation about a favorite language. Members of the panel will pose questions to each other. Those in the audience will be free to ask questions of the panelists.This is a regular feature of the TOOLS USA conference. It is usually spirited - sometimes slightly irreverent as panelist and audience members identify their own prejudices about the languages represented.We hope that, as the participants frankly reveal their own views, and hear intelligent rebuttals, that everyone will learn something new about the languages we use for object-oriented software construction. Although no one can possible learn each language in depth from this panel discussion, participants might be encouraged to pursue more in-depth study of some language that might have eluded their interest in the past.

The creation of reusable software components is an important part of modern software practice. Generic templates are one technique for designing these components. A generic template is a module containing algorithms which can operate on some class of data types where the specific data type is not known until later in the development process. Many languages, including Ada, support this technique. In Ada, generic templates must be type-safe at compile time. We examine some features of Ada which allow us to define the type as an entire package module and to instantiate with that module. The main theme of this paper will be generic formal package parameters.