Abstraction-based software development

Reviewer: Boumediene Belkhouche

This paper describes the experience of the authors in conducting a class project in software engineering. The goal of this project was to apply state-of-the-art software engineering principles through integration of technical as well as managerial concepts. The informal experiment, repeated over a five-year period, involved the development of a large and complex software project by teams of students. Each team was required to use the abstraction paradigm and to follow the conventional software life cycle. Initially, each team was involved in the analysis and refinement of the requirements. Afterwards, the system requirements were divided along independent categories and assigned to individual teams. The development process covered requirements definition, functional specification, architectural design, module design, and implementation. Abstraction and formal tools were used in each phase to express the design. The analysis of the results, though informal, is quite revealing. The major problems were integration, decomposition, tool availability, and testing. There was a failure to integrate separately implemented portions of the system. The authors attributed the failure to poor communication among design teams and noted that “. . . incomplete and conflicting product interfaces were found in the latter stages of the life cycle when parts of the system were distributed among teams for design and implementation.” A possible solution to this problem may be to provide a formal and independent definition of the interfaces at the specification stage only, and automatically transform these interfaces for the subsequent stages. Decomposition of the system was performed so as to achieve “. . . relatively homogeneous implementation size . . .” of the modules in order to be able to predict the amount of effort required to implement each unit and, thus, aid in planning. We suggest that this artificial segmentation itself may have contributed to the problem encountered in the interfaces between units. The decomposition should have been functional, for example, by abstract data type. The authors did observe, in fact, that this arbitrary decomposition resulted in integration problems not encountered by teams working on modules based on complete abstractions. Analysis of the models produced at different stages was hampered by the lack of automated tools. Special and PSL/PSA were initially selected, but were found inadequate for the task. A central database to coordinate the team efforts was built by the authors. In addition, a broad-spectrum language (MSG) was used to express the design. However, it seems that pseudocode was employed in module design. This fact suggests that the development moved from a formal to an informal description, thus implying a loss of valuable information and possible reintroduction of ambiguities which were eliminated at the specification stage. This informal experiment uncovers many issues concerning the use of abstraction in software development. As such, it provides a good and provocative basis for further research in this area.