John D. McGregor

Understanding object-oriented: a unifying paradigm

The need to develop and maintain large complex software systems in a competitive and dynamic environment has driven interest in new approaches to software design and development. The problems with the classical waterfall model have been cataloged in almost every software engineering text [19,23]. In response, alternative models such as the spiral [2], and fountain [9] have been proposed. Problems with traditional development using the classical life cycle include no iteration, no emphasis on reuse, and no unifying model to integrate the phases. The difference in point of view between following data flows in structured analysis and building hierarchies of tasks in structured design has always been a major problem [4]. Each system is built from scratch and maintenance costs account for a notoriously large share of total system costs. The object-oriented paradigm addresses each of these issues. A look at the object-oriented software life cycle, as described by Meyer [5], Coad and Yourdon [4], and Henderson-Sellers and Edwards [9], identifies the three traditional activities of analysis, design, and implementation. However, each of the referenced descriptions eliminates the distinct boundaries between the phases. The primary reason for this blurring of boundaries is that the items of interest in each phase are the same: objects. Objects and the relationships between objects are identified in both the analysis and design phases. Objects and relationships identified and documented in the analysis phase serve not only as input to the design phase, but as an initial layer in the design. This continuity provides for a much more seamless interface between the phases. Analysts, designers and programmers are working with a common set of items upon which to build. A second reason for the blurring of these boundaries is that the object-oriented development process is iterative. Henderson-Sellers and Edwards further refine this idea by replacing the waterfall model of software development with a fountain model. Development reaches a high level only to fall back to a previous level to begin the climb once again. As an example of the blurring of the traditional boundaries of the life cycle phases, Coad and Yourdon recommend that classification relationships between objects be captured and documented during the object-oriented analysis (OOA) phase. This classification will be directly reflected in the class inheritance structure developed in the design and in the code. This classification is in no way required in order to document the system requirements. In other words, Coad and Yourdon are recommending a traditional design activity in the analysis phase. The blurring of the traditional design and implementation phases has been fueled by the development of encapsulation and abstraction mechanisms in object-oriented and object-based languages. For example, Meyer claims [14] that Eiffel is both a design and an implementation language. He goes on to say that software design is sometimes mistakenly viewed as an activity totally secluded from actual implementation. From his point of view, much is to be gained from an approach that integrates both activities within the same conceptual framework. The object-oriented design paradigm is the next logical step in a progression that has led from a purely procedural approach to an object-based approach and now to the object-oriented approach. The progression has resulted from a gradual shift in point of view in the development process. The procedural design paradigm utilizes functional decomposition to specify the tasks to be completed in order to solve a problem. The object-based approach, typified by the techniques of Yourdon, Jackson and Booth, gives more attention to data specifications than the procedural approach but still utilizes functional decomposition to develop the architecture of a system. The object-oriented approach goes beyond the object-based technique in the emphasis given to data by utilizing the relationships between objects as a fundamental part of the system architecture. The goal in designing individual software components is to represent a concept in what will eventually be an executable form. The Abstract Data Type (ADT) is the object-based paradigms technique for capturing this conceptual information. The class is the object-oriented paradigms conceptual modeling tool. The design pieces resulting from the object-oriented design technique represent a tighter coupling of data and functionality than traditional ADTs. These artifacts of the design process used in conjunction with a modeling-based decomposition approach yield a paradigm, a technique, which is very natural and flexible. It is natural in the sense that the design pieces are closely identified with the real-world concepts which they model. It is flexible in the sense of quickly adapting to changes in the problem specifications. Object-oriented remains a term which is interpreted differently by different people. Before presenting an overview of a set of techniques for the design process, we will give our perspective so the reader may judge the techniques in terms of those definitions. Briefly, we adapt Wegners [27] definition for object-oriented languages to object-oriented design. The pieces of the design are objects which are grouped into classes for specification purposes. In addition to traditional dependencies between data elements, an inheritance relation between classes is used to express specializations and generalizations of the concepts represented by the classes. As natural and flexible as the object-oriented technique is, it is still possible to produce a bad design when using it. We will consider a number of general design criteria and will discuss how the object-oriented approach assists the designer in meeting these criteria. We will refer to a number of design guidelines developed specifically for the object-oriented design paradigm and will discuss how these properties reinforce the concepts of good design. The paradigm sprang from language, has matured into design, and has recently moved into analysis. The blurring of boundaries between these phases has led us to include topics in this article that are outside the realm of design, but which we consider important to understanding the design process. Since the paradigm sprang from language, we define the concepts basic to object-oriented programming in the following section.

Testing a Software Product Line

The software product line approach to the development of software intensive systems has been used by organizations to improve quality, increase productivity and reduce cycle time. These gains require different approaches to a number of the practices in the development organization including testing. The planned variability that facilitates some of the benefits of the product line approach poses a challenge for test-related activities. This chapter provides a comprehensive view of testing at various points in the software development process and describes specific techniques for carrying out the various test-related tasks. These techniques are illustrated using a pedagogical product line developed by the Software Engineering Institute (SEI).

A systematic mapping study of software product lines testing

ContextIn software development, Testing is an important mechanism both to identify defects and assure that completed products work as specified. This is a common practice in single-system development, and continues to hold in Software Product Lines (SPL). Even though extensive research has been done in the SPL Testing field, it is necessary to assess the current state of research and practice, in order to provide practitioners with evidence that enable fostering its further development. ObjectiveThis paper focuses on Testing in SPL and has the following goals: investigate state-of-the-art testing practices, synthesize available evidence, and identify gaps between required techniques and existing approaches, available in the literature. MethodA systematic mapping study was conducted with a set of nine research questions, in which 120 studies, dated from 1993 to 2009, were evaluated. ResultsAlthough several aspects regarding testing have been covered by single-system development approaches, many cannot be directly applied in the SPL context due to specific issues. In addition, particular aspects regarding SPL are not covered by the existing SPL approaches, and when the aspects are covered, the literature just gives brief overviews. This scenario indicates that additional investigation, empirical and practical, should be performed. ConclusionThe results can help to understand the needs in SPL Testing, by identifying points that still require additional investigation, since important aspects regarding particular points of software product lines have not been addressed yet.

Getting there from here: a roadmap for software product line adoption

Mapping the technical and business activities and steps required for successful organizational adoption.

Initiating software product lines

E li Whitney revolutionized the manufacturing of rifles using interchangeable parts. Henry Ford did the same for automobiles, integrating the idea of interchangeable parts and an assembly line. A growing number of software development organizations are adopting approaches that emphasize proactive reuse, interchangeable components, and multiproduct planning cycles to construct high-quality products faster and cheaper. Standard methods, referred to as software product line or software family practices, have developed around these approaches. This special issue focuses on the technical, managerial, and organizational activities related to introducing these practices. guest editors’ introduction

Incremental Testing Of Object-Oriented Class Structures/spl dagger/

Although there is much interest in creating libraries of well-designed, thoroughly-tested classes that can be confi- dently reused for many applications, few class testing techniques have been developed. In this paper, we present a class testing technique that exploits the hierarchical nature of the inheritance relation to test related groups of classes by reusing the testing information for a parent class to guide the testing of a subclass. We initially test base classes having no parents by designing a test suite that tests each memberfunction individually and also tests the interactions among member functions. To design a test suite for a subclass, our algorithm incrementally updates the history of its parent to reflect both the modified, inherited attributes and the subclasss newly defined attributes. Only those new attributes or affected, inherited attributes are tested and the parent class test suites are reused, if possible, for the testing. Inherited attributes are retested in their new context in a subclass by testing their interactions with the subclasss newly defined attributes. We have incorporated a data flow tester into Free Software Foundation, Incs C++ compiler and are using it for our experimentation.

On strategies for testing software product lines: A systematic literature review

Context: Testing plays an important role in the quality assurance process for software product line engineering. There are many opportunities for economies of scope and scale in the testing activities, but techniques that can take advantage of these opportunities are still needed. Objective: The objective of this study is to identify testing strategies that have the potential to achieve these economies, and to provide a synthesis of available research on SPL testing strategies, to be applied towards reaching higher defect detection rates and reduced quality assurance effort. Method: We performed a literature review of two hundred seventy-six studies published from the year 1998 up to the 1st semester of 2013. We used several filters to focus the review on the most relevant studies and we give detailed analyses of the core set of studies. Results: The analysis of the reported strategies comprised two fundamental aspects for software product line testing: the selection of products for testing, and the actual test of products. Our findings indicate that the literature offers a large number of techniques to cope with such aspects. However, there is a lack of reports on realistic industrial experiences, which limits the inferences that can be drawn. Conclusion: This study showed a number of leveraged strategies that can support both the selection of products, and the actual testing of products. Future research should also benefit from the problems and advantages identified in this study.

An extensible program representation for object-oriented software

An extensible representation for object-oriented programs is presented. It is based on the concept of a program dependency graph and elaborated to include both control flow and data flow information. The representation takes advantage of the basic incremental philosophy of the object-oriented approach to develop a more compact representation that is useful with practical programs. The basic approach reported here provides a static view of an object-oriented program. The approach can be expanded to provide dynamic information for tools such as interactive debuggers and other runtime tools. The outline of this extension is also presented.

Guest Editors' Introduction: Successful Software Product Line Practices

A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way in place. Organizations adopting product development strategies that include a software product line have achieved impressive results, reducing product cycle time and increasing productivity by an order of magnitude. The software product line strategy is a blend of business and technical actions that lets an organization satisfy a wide range of customers, gain leverage with suppliers, meet the threats of substitute products, and deter other companies seeking to enter the market. The strategy is robust over a wide range of technologies, domains, and organizations of different structures, cultures, and goals. Service-oriented architectures, agile development methods, and open source business models have all played roles in successful product line organizations.

A note on inheritance and state machines

The inheritance relationships in an object-oriented program have been shown to be a natural structure for facilitating reuse in a number of areas such as test cases. This note reports on a technique for incrementally building the state machine for a class from the state machines of its base classes. Using a style of state diagram similar to object charts provides a graphical means of displaying the resulting state machine. This incremental technique allows more complex machines to be built with less effort.