niques already used in the earlier stages of software development. In this way, Provis aims at integrating object-oriented programming more closely with ana-.
Provis: Towards an Environment for Object-Oriented Visual Programming Andreas L. Opdahl & Jon Erik Solheim Department of Information Science University of Bergen N-5020 Bergen
Abstract The paper presents the Provis (\Programming visually") tool for object-oriented visual programming
and some of the ideas behind it. Provis is based on object diagrams from Rumbaugh's \Object Modeling Technique" (OMT) [18] and on data ow diagrams (DFDs) enhanced with control ows, logical input and output connectives, as well as object icons. Object diagrams specify class structures, while enhanced DFDs specify class interfaces and method implementations. The tool generates | and eventually will also parse | C++ source code, and it has been designed to provide some degree of freedom with respect to sourcecode language. Work on Provis has been motivated by several concurring trends in the software engineering eld, including the need to eliminate phase gaps in software development work, the availability of powerful, high-level target platform software, the gradual merging of design and implementation tasks, as well as the increasing interest for object-oriented programming (OOP) and visual programming (VP) in general. In particular, Provis distinguishes itself from the existing plethora of similar visual programming environments through its application of diagramming techniques already used in the earlier stages of software development. In this way, Provis aims at integrating object-oriented programming more closely with analysis and design work.
Keywords: visual programming, OOP, OOD, OMT, data ow diagrams, PrM.
1 Introduction Entering the second half of the 1990s, new methodologies, models, techniques and tools for software analysis, design and implementation continuously enter software engineering (SE) research and practice. As the nature of software systems and the problems of creating them become better understood, old truths
are called in questions as new ones gain acceptance. In particular, the nature of the process of software development itself has come under scrutiny.
1.1 Criticism of the waterfall model The conventional waterfall model was proposed by Boehm in 1976 [3] as an idealised view of software development consisting of a sequence of nonoverlapping and non-iterative phases separated by milestone products. For the last decade, this model has been criticised for its lack of correspondence with how software development projects are carried out in the real world. This has motivated a number of alternative models of the software development process, including the spiral model [4], rapid prototyping and evolutionary development. Criticism of waterfall development seems to have two main components:
Software development is not sequential by nature, but a highly repetitive process of continuous planning, risk identi cation, analysis, synthesis, and evaluation.
Software development is not by nature segmented and concerned with \one thing at a time", but often involves simultaneously carrying out several activities of di erent types and belonging to different phases.
In addition, it has been claimed that the milestones of waterfall development introduce phase gaps in the development process. These phase gaps increase development complexity as milestone products from one phase must often be transformed to become inputs to the next. Although gaps may to some extent be unavoidable, they should nevertheless be bridged whenever possible by using the same models, techniques and tools for several contiguous development phases.
1.2 Higher-level target platforms In parallel with this trend towards less sequentialised and segmented development processes, SE is bene ting from the availability of increasingly more powerful and high-level target platforms. In general, these target platforms include all the already existing libraries, shelfware packages, frameworks, components and designs (called elements in the sequel) that can be reused by the new software system. Two factors in particular seem to have increased the importance of target platforms in the development process: Experimental methods, techniques and tools (e.g. [10]) have become available which facilitate reuse of already existing software components, frameworks and applications [21]. Object-oriented (OO) technology has been introduced to package software and design elements in autonomous units with precisely de ned interfaces and informal descriptions of behaviour. Indeed, the two factors are closely related, as OO has quickly become the de facto packaging standard both for reusable software components, frameworks and applications. In parallel with the spread of object-orientation for programming and packaging, a plethora of objectoriented analysis (OOA) and design (OOD) methodologies have also emerged (e.g., [18]). Although OOA may have been oversold and has recently been criticised by a number of authors (e.g., [9, 5, 12]), the advantages of OOP seem to extend well into the design phase, making OOD a promising direction for future SE research and practice.
System requirements specification
Design
Designed system
Implementation
Implemented components
Integration
Implemented system (a)
System requirements specification
Reusable components
Refinement
Reuse
1.3 Merging design and implementation Between them, the trends towards object-oriented programming and packaging techniques and higherlevel target platforms are gradually reshaping software design and implementation work. As smaller and smaller parts of new software systems are being implemented in conventional high-level or 4th generation programming languages, the di erence between design and implementation work gradually disappears. Traditionally, design involves iterative re nement of a system speci cation into a hierarchical structure of independent, cooperating components. The re nement process ideally should be carried out top-down, with emphasis only on nding a detailed system speci cation which suciently supports the system requirements identi ed during analysis. Implementation then
Reusable designs
Designed system Implementation
Implemented components
Integration
Implemented system (b)
Figure 1: Conventional (a) and reuse-based (b) software engineering work.
involves creating the high-level or 4th generation language source code for each component, before integrating them into the nal system. This conventional mode of SE work is depicted in Figure 1a: From an initial speci cation of system requirements (dashed, open box) the design phase establishes a hierarchical system of components (connected, solid and open boxes). During the implementation step, each component is then coded (independent, lled boxes). Finally, the implemented components are integrated into the nal system (connected, lled boxes). The advent of more powerful target platform software complicates the picture. To utilise new possibilities o ered by reuse of available platform elements, top-down design can no longer be carried out only with respect to overall system requirements. Instead, design becomes a process of re nement with respect to system requirements and with respect to available platform elements as depicted in Figure 1b: This time, the design phase is based both on an initial speci cation of system requirements (dashed, open box, top row) and already existing, reusable implemented components ( lled boxes, top row) and component designs (open boxes, top row). The design phase thus becomes a combination of re nement of the requirements speci cation, and reuse of already implemented components and component designs. The result is a development process which sometimes has to deal with conventional implementation issues | such as component interfacing and high-level control structures | already during design. Also, as focus shifts from designing all parts of the proposed system in depth, towards reusing larger elements of available implementations and/or designs it becomes important to be able to verify early in the design process that these elements can in fact be integrated easily. The simplest veri cation possible is often by demonstration, another implementation activity. Hence, traditional design work is gradually becoming uni ed with implementation. Indeed, this trend ts nicely with | and is in part engined by | the increased popularity of OO techniques for software development: OOA, OOD and OOP. The OO methodologies advocate tighter phase integration through the use of the same or similar modelling languages, techniques and tools throughout all phases from analysis to implementation.1 The requirements on future integrated design-andimplementation tools will inevitably be changed as 1 However, a notable criticism of OOA, as pointed out in [9], is that many mainstream approaches to OOA (e.g. [18]) are probably not \real" problem domain-oriented analysis, but more akin to early, overall system design.
a result of this. This next generation of development tools must improve and integrate the support for traditional design concerns such as re nement of system structure, decomposition and inheritance hierarchy, information ow, component interface speci cation, and element identi cation and reuse, on one hand, and conventional implementation concerns such as component implementation, implementation hierarchy, data structure, and control ow on the other.
1.4 Visual programming during design The future software \implementer" can therefore be expected to carry out tasks closer to conventional design tasks than to traditional programming. While the latter is still largely dominated by producing conventional textual code in high-level and 4. generation languages, software design is typically based on visual languages, techniques and tools, e.g., DFDs, object diagrams and entity-relationship (ER) diagrams. Completing the picture, visual programming (VP) is therefore a natural candidate for introducing programming in general | and OOP in particular | into the visual world of design.
2 The Provis Tool At the University of Bergen, a tool for objectoriented visual programming (OOVP), Provis (Pro gramming vis ually), is being developed to re ect these concerns. In particular, Provis distinguishes itself from the existing plethora of similar visual programming environments (see, e.g., Burnett et al. [6], and Prograph [7] in particular) through its application of diagramming techniques already used in the earlier stages of software development. In this way, Provis aims at integrating object-oriented programming more closely with analysis and design work. In part, the tool is based on earlier ideas presented by Opdahl [15, 16]. The design and implementation of Provis is being carried out by Solheim and is scheduled for completion in May 1996.
2.1 Process modelling At the lowest and most detailed level, programming in Provis is based on process model (PrM) diagrams. The PrM language is a formalisation and extension of conventional DFDs (other important extensions include Ward [20] and Adler [1]) developed by Arne S lvberg's group at the University of Trondheim (e.g., Berdal et al. [2] and Opdahl [17]). PrM is one
true if()else
(a)
(b)
endif
(c)
false
Figure 2: PrM constructs: process (a), store (b), and
ow (c). (From [16].)
(a)
case_1
(a)
(b) switch()
Figure 3: PrM connectives: AND and XOR (a), and REP, COND, REPCOND, and CONDREP (b). (From [16].)
endswitch case_2
. . .
default
of the partial languages underlying the experimental PPP environment for information systems development [8] used in the ESPRIT project TEMPORA. Also, the language has been used by Opdahl for toolsupported performance assessment and improvement during software development (e.g., [13, 14]) within the IMSE ESPRIT-project. Since these projects have already demonstrated the usefulness of PrM for conventional design work, the initial version of Provis focusses on implementation issues, following an outline by Opdahl [15], which also positions PrM relative to other work on visual programming such as Kodosky et al. [11], Cox et al.'s Prograph [7] and Wasserman's Software through Pictures [19].
2.1.1 Control ow and connectives According to [15], a PrM diagram is essentially a graph of processes and stores connected by ows , as in conventional DFDs and depicted in Figure 2. The processes and stores in the diagram exchange items through ows. Items may represent either data or control signals. The latter are particularly important for the purposes of this paper. Flows are connected with processes through connectives. Each process has one input and one output connective, each of which is either 1. AND, meaning that all ows inside it are consumed from or produced to, or 2. XOR, meaning that one and only one ow inside it is consumed from or produced to
(b)
Figure 4: PrM templates for selection statements of the C language: (a) if() f g else f g and (b) switch() f g. (From [16].) per execution of the process, as shown in g. 3a. Moreover, PrM also provides repeating (REP), conditional (COND), or combined (REPCOND and CONDREP) connectives, as shown in g. 3b for an ANDconnective. Connectives may be composite , with the obvious semantics.
2.1.2 Templates, re nements and decompositions Together, the control ow and connective extensions of PrM supply the power to express control structures of conventional algorithmic languages. Figures 4 and 5 (from [16]) show templates corresponding to selection and iteration statements of C++, respectively. In each template, primitive processes are denoted with a white top, while the top of still undetermined processes is grey. [15] proposes a programming method based on continual replacement of undetermined processes with process templates. In addition, undetermined processes may sometimes be decomposed into lower-level PrM diagrams to keep diagrams small and easy to comprehend. The method iterates the following basic implementation step : 1. select some yet undetermined PrM process;
for()
3 The Provis Interface
while()
do while()
(a)
(b)
(c)
Figure 5: PrM templates for iteration statements of the C language: (a) for() f g, (b) while() f g, and (c) do f g while(). (From [16].) 2. determine if the process should be primitive or not, and mark it accordingly; 3. specify the process' semantics: (a) in terms of a provided menu if it is primitive; (b) by re ning it into a template or decomposing it if it is not. Re nement of undetermined processes into templates is done by selection from a (hierarchical system of) menu(s). In addition to conventional programming language statements and message passing between objects, templates can and should be provided for library functions, embedded database manipulation language operations, etc. As will be pointed out in Section 8, the template library is how available component implementations will be imported into Provis and made available for reuse.
2.2 Object modelling In addition to PrM diagrams, Provis is built on a subset of object diagrams as de ned by the OMT methodology (Rumbaugh et al. [18]). While PrM diagrams specify method implementations (and | as will be explained in Section 3.2 | also class interfaces), object diagrams in Provis specify the inheritance and aggregation structure of classes. In addition, OMT may in the future also serve as an embedding methodology for Provis: In the early stages, OMT proceeds along three parallel modelling paths of object modelling with object diagrams, dynamic modelling based on events and states, as well as functional modelling based of DFDs. While the resulting object diagrams are already used directly by Provis, using the functional DFDs as rst-cut method implementations is an interesting possibility for further work.
The Provis prototype o ers extensive support for graphical manipulation of class structure, class interface, and method implementation diagrams. Provis has been designed to give the user the appearance of a dedicated editor for each diagram type. In reality, the class interface and method implementation editors are implemented as a single module, and the two editors are similar in most respects. While the class structure editor is based on OMT's object diagrams, the class interface and method implementation editors are PrM based.
3.1 The class structure editor As explained in the previous section, Provis' class editor is an implementation of object diagrams from Rumbaugh's OMT methodology [18]. To limit the scope of the prototype, only the parts of the object diagramming language needed for speci cation of C++-class structures were included, i.e., classes, and inheritance and aggregation relations. Figure 6 shows the class structure of a part of the StarView framework used to implement the graphical user interface of Provis. The user speci es class inheritance and aggregation structures by pointing and clicking. The background menu (top right) has entries for class and method speci cation, as well as for relationships. The relationship entry in turn has a submenu for aggregation and generalisation relations. Powerful marking functions are also provided. The background menu further provides a code generation entry. The pop-up menu for each class node (middle) provide an entry for class interface speci cation (Methods). An additional Properties canvas lets the user name classes, and lists their methods, children and private data. Note that several functions are duplicated between the menus (and between the menus and the toolbar) for quick access. In addition, all Provis editors provide point-and-click support for conventional functions such as le handling, movement, copying and deletion of nodes, as well as zooming, printing and laying-out of diagrams.
3.2 The class interface editor From the Methods entry of the class node menus in the class structure editor, the user may at any time enter Provis' class interface editor. Figure 7 shows Provis' class interface editor. Each method is speci ed as a high-level PrM process with external control
Figure 6: Provis' class structure editor is based on Rumbaugh's object diagrams [18].
ows representing method initiation and termination. In addition, data ows depict the method's input and output parameters. Extending the initial method speci cation with composite input and output ports and data ows, the signature of the corresponding method is then de ned. The method editor also uses DFD store icons to depict data that are private to the class and ovals to depict member objects. The pop-up menus of PrM processes representing methods (bottom left) have entries for de ning new submodels and to view already existing ones. Both selections invoke Provis' method implementation editor (Section 3.3). The private data and local object icons also have pop-up menus for speci cation of links to and from processes, as well as of data types and object classes.
3.3 The method implementation editor The user enters the method implementation editor from one of the process menus in Provis' class interface editor, Initially, the single process representing the method in question appears in the implementation editor, along with its input and output connectives and control and data ows. Method implementation then proceeds by re nement and decomposition steps as explained in Section 2.1. Figure 8 shows the interface to Provis' method implementation editor: Icons are available for processes, stores and local objects. The background menu (top right) provides entries for creating methods, data ows, local processes and stores, as well as objects. Using the primitive process menu (bottom left), the user can furthermore re ne undetermined processes into templates. In particular, the Methods entry provides a submenu of all available classes, from which particular method invocations can be selected. Figure 9 shows a more complex method implementation diagram. As motivated in the introduction, Provis is mainly intended for programs with simple control structures which embed or reuse many high-level library components. Whenever there is a need for speci cation of more complex algorithms, incomprehensively complex diagrams will quickly result. The conclusion will point to the possibility of integrating Provis with a dedicated editor for textual speci cation of complex algorithms, using the visual interface for simpler algorithms and navigation. At the implementation level, Provis' class interface and method implementation editors share most of the code. At the user level, Provis attempts to give the impression of two distinct editors, serving two distinct purposes in the programming process. However, the
similar \look-and-feel" of the two editors should make them easier to learn. By making reusable software components available for process re nements just like programming language statements and library functions, the method editor gracefully integrates design and implementation issues with reuse. This is furthermore related to the question of parsing to be commented on in the next section. The implementation editor also incorporates a powerful prettyprinter which continually updates the layout of diagrams after each basic implementation step.
4 The Provis Implementation The initial Provis tool is implemented in C++ under Unix and X11. Due to the powerful StarView framework for graphical user-interfaces, the tool is currently limited to around 10 000 lines of source code. Internally, the Provis speci cation is stored in a tree structure akin to a conventional parse tree. The layout algorithm responsible for drawing PrM diagrams works from this tree, and re nements and decompositions of the basic implementation steps work by expanding its leaves. As a result, both code-generation and source-code parsing is made comparatively simple. The prototype supports full code generation, However, parsing has been left out. As a topic for further work, this is however mandatory, as the graceful reuse of externally designed and implemented software components within Provis is dependent on some automated means of making them easily available through the menus of the method implementation editor. Hence, class interface parsing is a possible intermediate and preliminary solution while awaiting full parsing capabilities. One simple way of providing the prototype with full or partial parsing capabilities is to provide a translator from C++-code to the internal storage format used for Provis speci cations. Target platform independence, discussed in [16], is partly related to parsing: In order to easily use Provis with a continuously expanding set of available libraries, some automated means is again needed to make library interfaces available within the tool. At a deeper level, one might even try to make Provis independent of a particular language (within the algorithmic language family). A rst step towards a target-independent template speci cation language for Provis has been taken in [16].
Figure 7: Provis' class interface editor is based on PrM diagrams [15, 16].
Figure 8: Provis' class method implementation is also based on PrM diagrams [15, 16].
Figure 9: A more complex method implementation.
5 Conclusion and Further Work This paper has presented the motivation behind, background of, and implementation of the Provis tool for object-oriented visual programming. In particular, Provis distinguishes itself from the existing plethora of similar visual programming environments through its application of diagramming techniques already used in the earlier stages of software development. In this way, the tool aims at integrating object-oriented programming more closely with analysis and design work. Work on Provis is in its initial stages, and there are numerous paths for further work. In particular, the tool must be applied to realistic case studies. While the programming method of Section 2.1 seems well suited for the implementation of new methods, modi cation of existing methods is not well supported. This problem is related to the tree-structure embedded both in Provis' programming method and in its internal data structure. For the moment, Provis is mainly based on a \throw away on failure" philosophy, noting that all methods in an OO program should be small. Limited modi cation of parts of an implementation is supported through a feature which \implodes" templates (recursively along with all its subtemplates) back into a single, undetermined PrM process. A further possibility is to provide the programmer with a fourth editor which would graphically depict the internal tree structure which Provis uses to represent method implementations. Using such an editor, more sophisticated code modi cations would be possible. Inclusion of data ows is another yet unresolved issue. Here, Provis rests on previous work on PrM [2, 8] in which data ow has played a major part. Also, source-code parsing is mandatory if Provis is to reach its practical goal of supporting reuse. As was pointed out in Section 3.3, Provis' method implementation diagrams are mainly intended for programs with simple control structures which embed or reuse many high-level library components. Nevertheless, there will sometimes be a need for specifying more complex algorithms. This will quickly lead to incomprehensively complex diagrams. An appealing possibility is to associate the tool with a client editor (e.g., an emacs client). In this scenario, the programmer will use Provis and the editor in parallel, with the source code being displayed | and dynamically updated | both visually and textually. While textual view can be used for detailed algorithm speci cation the visual view is available for simpler algorithms and navigation. Section 2.2 pointed to the further possibility of
using OMT as an embedding \analysis" and design methodology for Provis. While this paper has focused on implementation rather than design, this is an important path for further work, in particular with respect to the relation between OMT's DFDs and PrM diagrams.
References [1] Mike Adler. An algebra for data ow diagram process decomposition. IEEE Trans. on Software Eng., 14(2):169{183, February 1988. [2] S. Berdal, S. Carlsen, A. S lvberg, and R. Andersen. Information system behaviour expressed through process port analysis. Technical report, Division of Computer Science, The Norwegian Institute of Technology, 1986. [3] B. W. Boehm. Software engineering. IEEE Trans. on Computers, C-25:1226{1241, December 1976. [4] Barry W. Boehm. A spiral model of software development and enhancement. IEEE Trans. on Computers, pages 61{72, May 1988. [5] T. Bryant and A. Evans. OO oversold. Information and Software Technology, 36(1):35{42, January 1994. [6] Margaret Burnett, Adele Goldberg, and Ted Lewis, editors. Visual Object-Oriented Programming: Concepts and Environments. PrenticeHall/Manning Publications, Englewood Cli s, NJ, 1995. [7] P. T. Cox, F. R. Giles, and T. Pietrzykowski. Prograph. In Burnett et al. [6], chapter 3, pages 45{ 66. [8] Jon Atle Gulla, Odd Ivar Lindland, and Geir Willumsen. PPP | An integrated CASE environment. Proceedings of \CAiSE91, Trondheim, Norway", May 1991. [9] G. M. H ydalsvik and G. Sindre. On the purpose of object-oriented analysis. In A. Paepcke, editor, OOPSLA'93 Conference Proceedings, pages 240{ 255. ACM Press, 26 Sep{1 Oct 1993. (Also as ACM SIGPLAN Notices 28(10), Oct 1993). [10] E.-A. Karlsson, editor. Software Reuse: a holistic approach. John Wiley & Sons, 1995.
[11] Je rey Kodosky, Jack MacCrisken, and Gary Rymar. Visual programming using structured data
ow. In S.-K. Chang and T. Ichikawa, editors, 1991 IEEE Workshop on Visual Languages, Los Alamitos, California, 1991. IEEE Computer Society Press. [12] A. L. Opdahl and G. Sindre. A taxonomy for real-world modelling concepts. Information Systems, 19(3):229{241, April 1994. Available at . [13] Andreas L. Opdahl. A CASE tool for performance engineering during software design. Proceedings of \The Fifth Nordic Workshop on Programming Environment Research", Tampere/Finland, 8{10 January 1992. [14] Andreas L. Opdahl. Performance engineering during information system development. Technical report, Information Systems Group, Department of Electrical Engineering and Computer Science, Norwegian Institute of Technology, University of Trondheim, 1992. Ph.D. thesis. [15] Andreas L. Opdahl. Structured analysis, structured design, visual programming. In P. Glinert et al., editors, Proceedings of \1993 IEEE/CS Symposium on Visual Languages", Bergen/Norway, August 24{27 1993.
[16] Andreas L. Opdahl. A target-independent data ow diagram approach to visual programming. In B. Magnusson, G. Hedin, and S. Minor, editors, Proceedings of \NWPER'94 | Nordic Workshop on Programming Environment Research", Lund/Sweden, June 1{3, 1994, 1994. [17] Andreas Lothe Opdahl. RAPIER | A formal de nition of diagrammatic systems speci cations. Technical report, Diploma Thesis, DAISEE/STEVIE Work report No. 88, Technical report No. 18/88, Division of Computer Science, The Norwegian Institute of Technology, February 26 1988. [18] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-oriented modeling and design. Prentice Hall, Englewood Cli s, New Jersey, 1991. [19] Software through Pictures. Release 4.2, Sun Version, Reference Manual. [20] Paul T. Ward. The transformation schema: An extension to the data ow diagram to represent control and timing. IEEE Trans. on Software Eng., SE-12(2):198{210, February 1986. [21] R. Wirfs-Brock, Wilkerson B, and L. Wiener. Designing Object-Oriented Software. PrenticeHall, Englewood Cli s, New Jersey, 1990.
