{'fraction_non_alphanumeric': 0.02702702702702703, 'fraction_numerical': 0.006119326874043855, 'mean_word_length': 5.288461538461538, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
The Role of Prototyping in Software Development

The term software engineering arose in the 1960s to emphasize that the production of software should not be an art, as it was then (and sometimes still is today), but an engineering discipline with a defined production process. As a consequence, approach models for the production of software were created, most noticeable the classic software life-cycle model (SLC) as described, e.g., in [Pomberger 93] and [Sommerville 85]. However, the classic SLC, although theoretically appealing, has some disadvantages, most of all that it cannot be used as is in practice. This led to several extensions and modifications of the model, whereas a very promising one is the use of prototyping, which leads to a prototypingoriented SLC. This paper first describes the problems with the classic approach model and how some of these problems can be solved by using a prototyping SLC. Then we describe TOPOS, a TOolset for Prototyping-Oriented Software development. Finally, we investigate how object-oriented programming, especially application frameworks, support a prototypingoriented approach. 1. The Classic Software Development Methodology The classic software life cycle as depicted in Figure 1 (further called simply life cycle) decomposes the software production process into distinct steps that are intended to make stepwise planning, decision and implementation possible. Analogous to other types of projects, software projects are thus subdivided into individual project phases . The prerequisites for the individual phases are well-defined inputs (usually in the form of documents). These inputs are processed in the respective phases with methods and tools availed by software engineering [Pomberger 93], and the results are passed on to the next phase. The phases are clearly defined, and a given phase is terminated only when its outcome is validated and verified. Requirements Analysis Requirements Definition