. In particular, what we want is
an editor that conveys, promotes, and enforces a high-level, consistent
conceptual view of software and software construction. We'll call
such an editor a conceptual editor.
Paolo Bucci
Department of Computer and Information Science
The Ohio State University
2015 Neil Avenue
Columbus, OH 43210
Tel: (614) 292-1152
Email:
bucci@cis.ohio-state.edu
Programming languages and tools have a direct impact on how programmers view and build software. If the languages and tools do not provide support for safe and sound reuse techniques, or, even worse, they allow and even encourage the construction of ad-hoc solutions and the practice of unsafe reuse habits, it is unlikely that programmers will be willing or even able to follow an appropriate, disciplined approach to software engineering and software reuse.
In this position paper we propose a new kind of program editor, a conceptual editor, that conveys, promotes, and enforces a high-level consistent conceptual model of software and software construction. If designed around an appropriate conceptual model, such a tool could support both the teaching of sound software engineering and reuse principles and the development of software according to the same principles.
Keywords: Programming environments, component-based software reuse, software education, reuse education
Workshop Goals: Learning, networking
Working Groups: (1) Rigorous Behavioral Specification as an Aid to Reuse; (2) Component Certification Tools, Frameworks and Processes
The Reusable Software Research Group (RSRG) at The Ohio State University has been focusing for over a decade on the technical problems involved in the design and construction of reliable, maintainable, efficient software systems. To address the difficult issues that arise in this area, the RSRG has been working at formulating a high-level, comprehensive view of software. The result is a very general model of software systems [1], and a set of relationships among components [2], that, integrated with principles and guidelines of the RESOLVE discipline [3], provide a fairly complete and coherent conceptual model of how software systems should be viewed and built.
To promote this conceptual view of software systems, it is necessary to provide programmers with appropriate tools to support the activities involved in the design, construction, and composition of software components. In our WISR7 position paper [4], we explored some of the ways in which a program editor could support safe software reuse. Here we briefly describe a new class of program editors, called conceptual editors, which expand the role of the editor by allowing programmers to reason at a higher conceptual level and by better supporting the programming task.
The way programmers view software and how they develop it is directly affected by the tools and languages they use. If the tools and languages do not provide support for the appropriate reuse techniques, or, even worse, they allow and even encourage the construction of ad-hoc solutions and the practice of unsafe reuse habits, it is unlikely that programmers will be willing or even able to follow an appropriate, disciplined approach to software engineering and software reuse. This may in part be the cause for why component-based, systematic reuse is not practiced much.
Here we concentrate on the program editor, i.e., the tool used to build
and manipulate program
descriptions. In particular, what we want is
an editor that conveys, promotes, and enforces a high-level, consistent
conceptual view of software and software construction. We'll call
such an editor a conceptual editor.
The conceptual editor should convey its view of software in the sense that a programmer using it would get the right mental model of what this view is; it should promote this view in the sense that a programmer using the editor should feel comfortable and even encouraged to think and act according to this view; it should enforce this view to protect the programmer from potential errors and to ensure the consistency of this view at all times.
What do we mean by ``high-level conceptual view of software and software construction''? Programs are not strings of characters or any other concrete representation; they are conceptual entities built from other conceptual entities to achieve an intended behavior. Each entity has a meaning, a role, and a purpose that go beyond the concrete syntactic representation the language assigns to the entity. The conceptual model must capture the nature and meaning of each entity and the relationships among them. And the conceptual editor must make sure that the user (programmer) thinks at all times in terms of this model.
The conceptual editor can be viewed as a tool to edit a description of the conceptual model of a program. The editing of a program becomes the process of transforming a program description into a new (different) description by applying one or more of the operations allowed by the editor. The programmer's ultimate goal is to transform some starting description into one that represents a valid program with the intended behavior, by repeatedly applying the editor's operations. Since each of the intermediate descriptions in this process is a description of the conceptual model of a particular program (behavior), it has to be ``meaningful'', i.e., it must make sense.
For a program description to be ``meaningful'' at all times at the conceptual
level, we first need to have conceptual entities that are meaningful,
and we must also make sure that the editor's operations only allow the
creation of meaningful combinations of these entities. A somewhat
primitive and restrictive view of a meaningful program is to consider
programs that can be successfully compiled.
Here, we suggest that a more powerful and effective notion is
possible if additional information is included in the conceptual model
(and thus in the program description). This information can be in the form
of formal specifications of the mathematical model of the objects involved
and of the behavior of the operations.
For many existing editors, it can be very hard, if not impossible, to assign a meaning to the intermediate descriptions; just think of the kind of intermediate descriptions it is possible to create by using a text editor. The programmer is responsible for ``cleaning-up'' the final product, and this may involve a lot more than just thinking about producing a program with the required behavior. On the other hand, imagine an editor that allows (or actually forces) programmers to move from meaningful description to meaningful description until they reach the desired result. In this way, programmers can just concentrate on editing a program until it has the appropriate meaning (i.e., the intended behavior) without having to worry about other issues or details, since at all times they are editing valid, meaningful programs. This is how we want a conceptual editor to behave.
What kind of operations should such a conceptual editor provide to build and manipulate the conceptual model? The operations must be chosen not based on the displayed representation, but based on the conceptual model itself. In other words, they need to make sense in the realm of the conceptual model, and they must satisfy the condition that they transform a meaningful program into a meaningful program, i.e., the space of meaningful programs is closed under the available operations. This requirement has some interesting implications over the interaction between the programmer and the editor. In fact, conceptually the operations need to be atomic (to be able to maintain the validity of the edited description) but they may require a sequence of smaller steps that is imposed by the editor on the programmer and that has to be completed before the operation is complete (and before the programmer can go on to the next operation). Just think of an operation trying to delete a variable or some other kind of entity that is currently being used by other entities in the program. In such a case, the editor must force the user to handle all the ``conflicts'' that would arise by the deletion of the entity, and this before the operation completes.
After the model and the operations have been chosen, it is still necessary to come up with a concrete representation for program descriptions (i.e., how programs are going to be displayed by the editor) and determine how the editor will interact with the user especially in the case of fairly complicated operations (e.g., conceptual cut and paste), which may require the programmer to perform many actions and make several decisions to determine the outcome of the operation. Here we only intend to raise the issue of the importance of a good design of the user interface for the success of the editor. It is essential that the representation chosen for each entity capture the properties of the entity's model. Furthermore, different representations will be needed for different entities, so that just using text or a tree as the representation for the whole program is not likely to be an effective choice.
The conceptual model of programs and program construction and the editor's user interface are critical issues in the successful design of a conceptual editor. If the appropriate model is chosen and if the editor's system image is designed accordingly, such a tool has the potential to not only help support programmers in their task, but also to actively promote an effective mental model of what programs are and how they are built. In addition, it can be useful not only to help novice programmers form a high-level view of software, but it can also aid experienced programmers in the transition to a new, more appropriate way of looking at software.
Text editors [7] essentially provide no useful support for the programmer's task (aside from syntax coloring, automatic indentation, and such similar primitive devices).
Language-based editors (e.g., [8], [9], [10], [6]) come in many different flavors and can be characterized along several dimensions such as what programming paradigm they promote (e.g., object oriented, structured, data flow, functional, etc.); how much language support they provide (e.g., context-free syntax checking, or complete static checking); what kinds of editing modes they allow (e.g., structure editing only, or hybrid text and structure editing) and to what degree the modes are integrated; whether they prevent errors or they detect errors and whether this is automatic or at the user's request; whether they provide an integrated execution environment (i.e., whether they can execute partially completed programs); whether they are created by an editor generator from the language's formal description or instead are built ``manually'' by a programmer; etc.
In most cases, the only concrete representation they provide is text and unrestricted text editing is still allowed in addition to structure editing. So we can say that they either provide no high-level conceptual model beyond a textual view of programs, or that they try to raise the model to a hierarchical structure (tree), but they fail to consistently support such a view. In any case, they clearly fall short of the definition of a conceptual editor.
An interesting and somewhat unique editing environment is the Prograph visual environment [11]. It differs from other systems in that text is not the primary representation used to display programs. The system provides a high-level, object-oriented conceptual model of programs. It uses different editors for different classes of conceptual entities. For instance, there is a class hierarchy editor where the edited representation is a graphical display of the class tree, and a method editor where data flow diagrams are the chosen representation. There are also editors to modify a class attributes, to add and remove methods, etc. The major shortcoming is that Prograph allows the programmer to edit description that are not meaningful, relying on its run-time environment to reveal the errors and inconsistencies in the program.
Paolo Bucci is a doctoral student in the Department of Computer and Information Science at The Ohio State University. He received his undergraduate degree in computer science from Università degli Studi, Milan, Italy in 1986, and his M.S. in computer science from Ohio State in 1989. His current research interests include software design and reuse, programming environments, programming languages, and education.
The author gratefully acknowledges financial support from the National Science Foundation (grant number CCR-9311702).