- Email: [email protected]
Visual methods in real-time programming
Copyright Q IFAC Real Time Programming, Lake Constance, Germany, 1994
VISUAL
METHODS
MICHAEL
G. HINCHEY
IN REAL-TIME
PROGRAMMING
University of Cambridge Computer Laboratory New Museums Site, Pembroke Street Cambridge CB2 3QG, England
Abstract.
It is widely accepted that visual programming techniques can offer increased productivity and reduced costs during the programming stage of real-time systems develop ment, and to a lesser extent at other phases in the system development life cycle. It is this author’s belief, however, that while visual programming languages have much to recommend them, their current usage is erroneous. Current trends will prevent visual programming languages from being successfully applied to complex real-time systems, and in the development of correct systems. We present a case for visual methoda of real-time system development, that recognize visual programming as a single component of a more complex development method; we conclude by briefly describing one such method. Keywords.
Visual methods,
visual programming,
1. INTRODUCTION
real-time systems, formal methods.
Brooks’ extreme view has been criticized (Harel, 1988) for failing to acknowledge developments in the area of CASE and visual formalisms (Harel, 1992). In addition, in recent years, much attention has focused on the use of visual programming as a means of improving productivity (in particular with real-time systems), highlighting contradictory requirements, and in short, taming Brooks’ ‘werewolf’.
In a widely-quoted and much-referenced article, Brooks (1987) warns of the dangers of complacency in software development. Software systems can suddenly turn from being well-behaved to behaving unThey are ‘werewolves’, and Brooks controllably. claims that there is no ‘Silver Bullet’ for dealing with such creatures.
2. VISUAL PROGRAMMING
Brooks’ view is, of course, very valid, albeit somewhat extreme. We still have not mastered system development, as evidenced by the fact that system maintenance costs on average now geatly exceed development costs.
Many believe that improvements in software specification and preliminary design need to be augmented with tools to aid in the detailed design, realization and future maintenance of complex computer systems (Schwartz et al, 1993). Such tools should ideally aid in prototyping and simulation as a means of validation and verification, in particular in concurrent and real-time applications where synchronization on particular resources and within given timing constraints is vital to the correct operation of a system.
Real-time systems are particularly problematic. All involve a certain degree of concurrency, with the result that we must deal with many events occuring simultaneously from various sources. We must recognize each of these and deal with them accordingly and within given timing constraints. More and more these constraints are becoming more rigid, as computer systems are applied to more and more areas deemed to be ‘safety-critical’.
In certain circles, visual progamming is classified as one of these tools, and indeed augurs great potential. Visual programming involves using visual respresentations as a means of creating and modifying programs. Visual progamming languages enhance the interface between developer and machine, and avoid the need to become familiar with minor syntactic changes to various ‘releases’ of programming languages. Such languages provide greater support for reactive aspects of system design than many existing
A number of programming languages have evolved to handle concurrent aspects of complex systems, and support features to enable us to develop systems with real-time aspects. While these enable us to develop the cIazzes of system we desire, they fail to simplify the task of actually developing such systems, and Brooks’ prediction of little progess towards finding the ‘Silver Bullet’ before 1997 seems perfectly valid.
157
design methods, and are superior to existing CASE tools in that they give a more complete ‘picture’ of the system functionality (Bastiaens & Van Campenhout, 1993).
and Jhtesmination
It is this author’s belief that while visual programming languages have much to recommend them, their current usage is erroneous. Programming accounts for a minor percentage of system development, and must be viewed in the context of a much larger process. The current trend of reducing design methods to visual programming languages (Bastiaens & Van Campenhout 1993) is, in the opinion of this author, not only wrong but has considerable ramifications for the future of software development, and the develop ment of correct real-time systems.
EvaluateResults
Visual programming must be employed as a component of the software development lifecycle. It should complement existing (and future) development methods; it must not attempt to replace them.
Fig 1. current trends in visual programming
We present here a case for visual methods and the need to integrate visual programming into a complete method of system development.
4. evaluate the results of the simulation, and modify the visual program to reflect the requirements more accurately; return to step 3;
3. CURRENT TRENDS
5. for the life-time of the system, execute the textual equivalent of the visual program; maintain the system as necessary, generally at the level of the textual implementation.
Current practice in the application of visual programming languages (as opposed to current theory) is clearly foresaking many of the principles now taken to be required as a basis for well-engineered systems. Many proponets of visual programming, and develop ers of new visual programming languages, are advocating what is effectively abandoning the specification and design phases, merging them with the implementation (programming) phase of the life cycle.
This model completely ignores the need for specification and design; rather it replaces these with an ad hoc implementation. It does not even offer reasonable support for an evolutionary model of development, as ‘improvements’ to the visual program are also made in an ad hoc manner, rarely using a library of transformations, as adequate libraries do not as yet exist.
The importance of appropriate specification and design in real-time system development cannot be understated. Yet in the application of visual pre gramming languages, proponents are subsuming these into a ‘prototyping’ phase, and effectively following a variation on the transformational or evolutionary approach, described earlier, but with a much less formal basis.
The model allows for very minimal iteration of phases of the life cycle, and no explicit support for changes to requirements (although this may be implicit in the model), as the earlier phases of development are completely isolated from the rest of the model; this was one of the major criticisms of the ‘Waterfall’ model, resulting in it being abandoned.
The model of development that people are beginning to adopt, seems to be something along the lines of that shown in figure 1:
4. VISUAL METHODS
using a visual programming language, implement a system that satisfies these requirements, effectively a prototype;
In the context of an engineering discipline, a method describes the way in which a process is to be conducted. In the context of system engineering, a method is defined to consist of: (1) an underlying model of development, (2) a language, or languages, (3) defined, ordered steps, and (4) guidance for applying these in a coherent manner. (This definition is modified from Kronliif (1993)).
run simulations of this prototype to uncover contradictory requirements, and to identify requirements that have not been adequately implemented, e.g., performance and other nonfunctional requirements (even though this is contradictory with the principles of prototyp ing);
nom this definition we can see that a visual programming language must be recognized as merely a camp+ nent of the system development method. It is this author’s belief that visual programming languages need to integrated into a more complex model of system development, that incorporates formal specification
Determine the requirements of the system;
158
4.1 Mir6
techniques, (optionally) prototyping and simulation, formal refinement to executable code, and support for proof of correctness. For this, we require not ODly a visual language that is easily understood by nonspecialists, but also a formal language that facilitates reasoning about system requirements and the system specification.
The Mild languages (Heydon et al, 1999) are a prime example of the sort of visual languages that develop ers should be employing at the early stages of development .
The Mird languages are specific-purpose - their role is in the specification of security constraints of operating systems. The instance language enables the specification of file system access capabilities, while the cot&mint language permits the specification of particular security policies. The notation used is not entirely dissimilar to that of Statecharts, and the se mantics of the languages are strongly based on higraphs.
This may require more than one language; but, in any case, the visual language should have a formal basis. Hare1 (1992) in his critique of Brooks’ assessment (1987) points to the use of CASE tools and visual formalisms as a means of taming the ‘werewolf’ of system development. Harel’s own formalism of Statecharts (Harel, 1987) is one particular example of the sort of visual formalism he has in mind.
The languages illustrate how a visual formalism can satisfy even the most strict requirements of rigor and formality, while admitting a suitable degree of expressiveness and lending itself to quite an intuitive interpretation even by non-specialists. Various support tools facilitate editing ‘pictures’, checking for ambiguity (which is facilitated by the formal semantics), checking that particular instances satisfy specified constraints, etc.
4.1 Statecharts The formalism revives the application of statetransition diagrams (STDs), the graphical equivalent of finite-state machines (FSMs) in the specification and design of complex reactive systems. The language has a formal semantics based on higraphs - a from of graph that permits each node to contain one or more subgraphs. And-decomposition supports the partitioning of a single state into a number of orthogonal sub-Statecharts; or-decomposition allows partitioning into a number of mutually-exclusive states.
The Mir6 languages are applied in a very specific domain - that of security. They do illustrate, however, an approach that is likely to lend itself to other areas, and which could be extended into a visual method. Such an approach incorporates more than one language (in the case of Mir6, all of the languages are visual), expressed at suitable levels of abstraction, and supported by various tools.
The language has formed the basis (directly or indirectly) of a number of visual programming languages and of a number of visual development environments, most notably STATEMATE and STATEMENT. In practice, it has proven to be very successful; its complete formal semantics permits reasoning about specifications, and provably correct manipulations of specifications.
4.1 Method Integration In the traditional (structured) approach to software development, problems are analysed using a collection of diagrammatic notations, such as Data-Flow Diagrams (DFDs), Entity-Relationship-Attribute Diagrams (ERADs) and State Transition Diagrams (STDs). In general, these notations are informal, or, at best, semi-formal. Only after the problem has been analysed sufficiently are the possible sequences of op erations considered, from which the most appropriate are chosen.
Unfortunately, much of the emphasis on the application of Statecharts has been to convert the formalism to a visual programming language and use it in an evolutionary-style approach similar to that described in the previous section. It is our belief that while Statecharts could indeed be used as the basis for a visual method, current trends in visual programming will prevent it from becoming so. As long as a single language (or more critically a single level of abstraction) is used throughout the system development, practitioners will be tempted into following the model of the system life cycle illustrated in figure 1 (or a model closely resembling this).
When using formal specification techniques, however, personnel must begin to think in terms of the deriviation of a model (either explicit or implicit - depending on the formal specification language being used, and the level of abstraction of the specification) of reality. In the specification of a functional system (one in which output is a function of the current state and the input) this involves relating inputs to outputs by means of predicates over the state of the system. In reactive systems, of which concurrent, real-time and distributed systems are representative, the specification is complicated by the need to consider side-effects, timing constraints, and fairness. In either case, the mismatch, or ‘gap’ between the
We need to base a visual method on visual formalisms, but augmented with other appropriate languages (which may be visual) that are couched at appropriate levels of abstraction to suit the various stages of system development, and to further facilitate formal manipulation.
159
thought processes that are required at the analysis stage and those needed to formally specify a system is significant. A method based on the integration of structured and formal methods seems to offer the best of both worlds:
l
it offers the structured method’s support for the software life cycle, while admitting the use of more formal techniques at the specification and design phases, supporting refinement to executable code, and proof of properties;
l
two views of the system are presented, allowing different developers to concentrate on those aspects that are of interest to them;
l
a means is provided for formally proving the correctness of an implementation with respect to its specification;
l
the structured design can be used as a basis for insights into the construction of a formal specification.
Fig 2. a visual method of development
5. THE SB METHOD In essence, an approach based on such an integration is entirely compatible with Harel’s concept of visual forma!isms. Effectively, the formal specification can be seen 8s assigning a formal semantics to (various components of) a structured notation. This has the result of ma!dng the structured notation more pmcise and less ambiguous. And, if such an approach can be applied to eech notational component of the structured method, the entire method becomes formal&d.
We believe that the SB method is exemplative of the form of visual method which must be developed if visual programming is to be scaled up for appropriate use with real-time systems of a rea!iitic size and complexity. SB meets all of the requirements of a real-time development method (Hinchey, 1993): it is based on a reactive mode! of computation and supports an event mode! that permits the expression of timing constraints and which can describe entities that have properties and relationships that vary over time.
Such an approach is also not entirely incongruous with the idea of making design notations executable. It diem, however, in that the notation is not direcfIg executable; it may be amlysed aud manipulated, and using executable specification languages, or various specification animation techniques (such as restating specifications in terms of declarative programming languages) supports prototypiug and simulation. The visual language itself only becomes exe cutable however as a result of applying a refinement calculus (ideally with too! support) to systematically transform the textual equivalent of the visual notation into executable code.
More importantly, from our point-of-view, it offers a visual language with a full forma! semantics that can be couched at Mlrious levels of abstraction as appropriate, and so fits in at various stages in the development life cycle.
5.1 Visual Language The visual language (SBYC) avoids the use of domain-specific constructs such as mailboxes and message queues. Rather, the only primitive in the language is that of a sequential process and unidirectional communication channels that allow messages to be passed between processes; processes are assumed to be receptive, with the result that a!! communication between processes is asynchronous. Synchronous communication may be expressed through appropriate handshaking. There are no buffers, or queues, and communication between processes is inst~t~~~ apart from pro~g~ion delays.
The result of the approach is a highly abstract visual language that is not constrained to any particular implementation, or range of implementations. The notation is augmented with one or more formal languages that facilitate proofs of properties, and eventually proofs of correctness. Abstraction levels are reduced as necessary during the design phase until the design ls expressed at a suitably low level. Only then should implementation-specific constructs such as mailboxes, buffers and queues be considered in refining the design to a particular imp!ementation.
The notation is very simple: processes 8re represented as simple rectangles, and channels are denoted by arrows appropriately labelled. There is no limit on the number of processes at either the specification or
This results in a system life cycle as shown in figure 2, which is more akin to accepted development practices than that described earlier. 160
5.3 Formal Semantics
design phrases. This is important as most real-time systems will be distributed, or at least involve some degree of multi-processing. More importantly, such an approach allows for the separation of concerts: real-time systems must react accordingly (and within given timing constraints) to conditions in their environments arising from various sauces simultaneously. It is easier to cope with this 8t earlier stages in the development if we con consider each condition individually; SB allows each process to be deiiued separately, and then combined with other processes to form a complete system. In thii way it supports 8 constructive or ‘bottom-up’ approach that allows more detail and specialiiation to be added to the model as further insights are gained into the operation of the system.
Sf3YL: has a full formal semantics in that each pro cess may be expressed in terms of a process algebra for which the semantics are well-defined The process algebra is an extension of Receptive Pro cess Theory (Josephs, 1992), a reworking of Hoare’s language of Communicating Sequential Processes (CSP) (Hoare, 1985) under the gumption that all processes 8re receptive. Thii allows process definitions to be combined algebraicly, with the assurance that the resultant process is equivalent in behaviour to the combined behaviours of each of the individual processes. The formal semantics of each individual process’s Structure D&ram are expressed in terms of the Z notation (Brien & Nicholls, 1993), augmented with a very simple tempo4 logic as used in TLA+ (Lamport, 1991; Lamport, 1994).
When it comes to the design phase, visual respresentations of a limited number of constructs such as buffers are available for use; a small number of such constructs are supported by the language, but in all cases these can be expressed directly in terms of a number of sequential processes combined using a small number of well-defined operators. In essence, such constructs are a shorthand notation for more complex combinations of processes; they do, however, also simplify the mapping to an implementation in 8 conventional language.
The transformations between SYNC and the formal languages are formally specified, which also facilitates the derivation of translation tools. An important point, however, is that the inverses of each transformation are 8lso specified. This means that the correctness-preserving algebraic laws of the process algebra may be used to manipulate the mathematical equivalent of StIVC (for example, to reduce the number of processes in the description) and that the changes may be reflected back in the visual notation. This means that SAX may be used as a visualization tool at all stages in the development, but the visualization will be couched at various levels of abstraction, as appropriate.
State-based aspects of each process 8re addressed in a top-down manner via a tree-like graphical notation called a Structure Diagram that illustrates the ordering of events in the life-time of the process. As such, the notation closely resembles and draws many of its concepts from Jackson System Development (JSD) (Jackson, 1983), a popular structured method that is used in both industry and academia. The underlying semantics of SBVL: are quite diierent, however, and more appropriate for use with realtime and reactive systems.
5.4 Implementation The SB method supports formal refinement to executable code. Extended Receptive Process Theory (ERPT) may be refined to skeleton A& code that exploits many of Ada’s advanced features, such 8s tasking, multiple entry-points, exception-handling, etc. Refinement of Z to executable code serves to ‘fill-in’ many of the omissions in the skeleton code. A combined ERPT and Z refinement calculus is planned.
5.2 Abstraction Levels The language supports a wide range of abstraction levels. Wisely choosing the events that a particular process may engage in determines the level of abstraction of the sp~fi~tion. The fact that no implementation-oriented constructs are supported at the specification phase ensures that there is no biag towards particular implementations.
ERPT when transliterated to occam is almost exe cutable on transputers, so transputer-based prototypes and simulations 8re possible, and may be de rived quite quickly and easily. Z may also be animated in various declarative languages (such as Prolog and Miranda), providing a basis for both prototyping and simulation.
At the design phase of system de~lopment, the level of abstraction is reduced in 8n iterative and systematic manner. A notion of nejinement generates proof obligations that designs at successively lower levels of abstraction are in some sense *better’ (i.e., more det~n~tic, more efficient, more concrete, etc.) and support the same functionality.
An automated toolkit for the SB method is currently under development by BEST CASE Ltd. Initially the toolkit will support refinement to Ada, but eventually other implementation languages will also be supported.
161
Harel, D. (1988) On Visual Formalisms. Comm. of the ACM, 31(5), 514-530, May 1988.
6. CONCLUSION Current trends in the application of visual programming to real-time systems are in direct contrast with many of the established techniques and principles for the development of ‘correct’ systems. These may not pose problems when applied to small ‘toy’ applications, but they will certainly prevent the scaling of visual programming techniques for use with larger systems.
Hare& D. (1992) Biting the Silver Bullet: Toward a Brighter Future for System Development. IEEE Computer, 25(l)&20, January 1992.
It is this author’s firm belief that if visual programming is to be successfully applied to the development of large-scale real-time systems, then it must be integrated into some form of visual method of develop ment.
Hinchey, M.G. (1993) The Design of Real-Time Applications. Proc. RTAW’93, New York City, May 1993, 178 - 182, IEEE Computer Society Press.
Heydon, A., Maimone, M, Tygar, J.D., Wing, J.M. and Zaremski, A.M. (1999) Mir6: Visual Specification of Security. IEEE tinactions on Software Engineering, 16(10), 1185-1197, October 1990.
Hinchey, M.G. (1994) Towards Visual Methods. submitted for publication.
Such a method is likely to employ one or more visual languages: a suitably abstract visual language with complete formal semantics at the specification stage and one or more (possibly visual) less abstract languages (or more concrete constructs from the same language) at later stages. These languages will facilitate formal manipulation and proof, and more likely formal refinement to executable code, rather than the direct transliteration of graphical constructs to equivalent code in a conventional programming language.
Hoare, C.A.R. (1985) Communicating Sequential Pnxesses. Prentice Hall International Series in Computer Science, Hemel Hempstead & Englewood Cliffs, 1985. Jackson, M.A. (1983) System Development. Prentice Hall International Series in Computer Science, Hemel Hempstead & Englewood Clii, 1983. Josephs, M.B. (1992) Receptive Process Theory. Acta Infonnatica 29, 17 - 32, February 1992.
We have highlighted visual formalisms and method integration as two possible starting-points for the development of visual methods. We believe that both of these approaches have much to recommend them, and that either approach is at least an improvement on current trends. We have also very briefly described a visual method which we believe to be exemplative of the sort of techniques that will be required in the future. This method combines structured and formal methods in establishing a visual formalism, and exploits the methodological aspects of these methods in future development and in deriving provably comcf real-time systems from a visual (abstract) program.
Kronliif, K. editor (1993) Method Infegmtion: Concepb and Care Studies. Wiley Series in Sot%ware Based Systems, 1993. Lamport, L. (1991) The Temporal Logic of Actions. Technical Report 79, Digital Systems Research Center, Palo Alto, 25 December 1991. Lamport, L. (1994) TLZ. Invited lecture, 8th Z User Meeting, 29 - 30 June 1994, Cambridge, UK. Schwartz, J.J., Skubich, J.J., Szwed, P. and Maranzana, M. (1993) Real-Time Mulitasking Design with a Graphical Tool. Proc. RTAW’93, New York City, May 1993, 8 - 11, IEEE Computer Society Press.
We do not claim that this method is ‘ideal’, but we do believe that is a step in the right direction . . . and that the future of visual programming for real-time systems lies in its exploitation as a component of a visual method of development.
4. REFERENCES Bastiaens, K. & Van Campenhout, J.M. (1992) A Visual Real-Time Programming Language. Prvc. WRTP’92, Bruges, June 1992, 75 - 79, Pergamon Press. Brien, S. & Nicholls, J.E., editors (1993) The 2 Base Standard. Oxford University Computing Laboratory/ZIP Project Report. Brooks, F.P. (1987) No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, 20(4),10-19, April 1987. Harel, D. (1987) Statecharts: a Visual Formalism for Complex Systems. Science of Computer Programming, 8(3),231-274, June 1987.
162
VISUAL
METHODS
MICHAEL
G. HINCHEY
IN REAL-TIME
PROGRAMMING
University of Cambridge Computer Laboratory New Museums Site, Pembroke Street Cambridge CB2 3QG, England
Abstract.
It is widely accepted that visual programming techniques can offer increased productivity and reduced costs during the programming stage of real-time systems develop ment, and to a lesser extent at other phases in the system development life cycle. It is this author’s belief, however, that while visual programming languages have much to recommend them, their current usage is erroneous. Current trends will prevent visual programming languages from being successfully applied to complex real-time systems, and in the development of correct systems. We present a case for visual methoda of real-time system development, that recognize visual programming as a single component of a more complex development method; we conclude by briefly describing one such method. Keywords.
Visual methods,
visual programming,
1. INTRODUCTION
real-time systems, formal methods.
Brooks’ extreme view has been criticized (Harel, 1988) for failing to acknowledge developments in the area of CASE and visual formalisms (Harel, 1992). In addition, in recent years, much attention has focused on the use of visual programming as a means of improving productivity (in particular with real-time systems), highlighting contradictory requirements, and in short, taming Brooks’ ‘werewolf’.
In a widely-quoted and much-referenced article, Brooks (1987) warns of the dangers of complacency in software development. Software systems can suddenly turn from being well-behaved to behaving unThey are ‘werewolves’, and Brooks controllably. claims that there is no ‘Silver Bullet’ for dealing with such creatures.
2. VISUAL PROGRAMMING
Brooks’ view is, of course, very valid, albeit somewhat extreme. We still have not mastered system development, as evidenced by the fact that system maintenance costs on average now geatly exceed development costs.
Many believe that improvements in software specification and preliminary design need to be augmented with tools to aid in the detailed design, realization and future maintenance of complex computer systems (Schwartz et al, 1993). Such tools should ideally aid in prototyping and simulation as a means of validation and verification, in particular in concurrent and real-time applications where synchronization on particular resources and within given timing constraints is vital to the correct operation of a system.
Real-time systems are particularly problematic. All involve a certain degree of concurrency, with the result that we must deal with many events occuring simultaneously from various sources. We must recognize each of these and deal with them accordingly and within given timing constraints. More and more these constraints are becoming more rigid, as computer systems are applied to more and more areas deemed to be ‘safety-critical’.
In certain circles, visual progamming is classified as one of these tools, and indeed augurs great potential. Visual programming involves using visual respresentations as a means of creating and modifying programs. Visual progamming languages enhance the interface between developer and machine, and avoid the need to become familiar with minor syntactic changes to various ‘releases’ of programming languages. Such languages provide greater support for reactive aspects of system design than many existing
A number of programming languages have evolved to handle concurrent aspects of complex systems, and support features to enable us to develop systems with real-time aspects. While these enable us to develop the cIazzes of system we desire, they fail to simplify the task of actually developing such systems, and Brooks’ prediction of little progess towards finding the ‘Silver Bullet’ before 1997 seems perfectly valid.
157
design methods, and are superior to existing CASE tools in that they give a more complete ‘picture’ of the system functionality (Bastiaens & Van Campenhout, 1993).
and Jhtesmination
It is this author’s belief that while visual programming languages have much to recommend them, their current usage is erroneous. Programming accounts for a minor percentage of system development, and must be viewed in the context of a much larger process. The current trend of reducing design methods to visual programming languages (Bastiaens & Van Campenhout 1993) is, in the opinion of this author, not only wrong but has considerable ramifications for the future of software development, and the develop ment of correct real-time systems.
EvaluateResults
Visual programming must be employed as a component of the software development lifecycle. It should complement existing (and future) development methods; it must not attempt to replace them.
Fig 1. current trends in visual programming
We present here a case for visual methods and the need to integrate visual programming into a complete method of system development.
4. evaluate the results of the simulation, and modify the visual program to reflect the requirements more accurately; return to step 3;
3. CURRENT TRENDS
5. for the life-time of the system, execute the textual equivalent of the visual program; maintain the system as necessary, generally at the level of the textual implementation.
Current practice in the application of visual programming languages (as opposed to current theory) is clearly foresaking many of the principles now taken to be required as a basis for well-engineered systems. Many proponets of visual programming, and develop ers of new visual programming languages, are advocating what is effectively abandoning the specification and design phases, merging them with the implementation (programming) phase of the life cycle.
This model completely ignores the need for specification and design; rather it replaces these with an ad hoc implementation. It does not even offer reasonable support for an evolutionary model of development, as ‘improvements’ to the visual program are also made in an ad hoc manner, rarely using a library of transformations, as adequate libraries do not as yet exist.
The importance of appropriate specification and design in real-time system development cannot be understated. Yet in the application of visual pre gramming languages, proponents are subsuming these into a ‘prototyping’ phase, and effectively following a variation on the transformational or evolutionary approach, described earlier, but with a much less formal basis.
The model allows for very minimal iteration of phases of the life cycle, and no explicit support for changes to requirements (although this may be implicit in the model), as the earlier phases of development are completely isolated from the rest of the model; this was one of the major criticisms of the ‘Waterfall’ model, resulting in it being abandoned.
The model of development that people are beginning to adopt, seems to be something along the lines of that shown in figure 1:
4. VISUAL METHODS
using a visual programming language, implement a system that satisfies these requirements, effectively a prototype;
In the context of an engineering discipline, a method describes the way in which a process is to be conducted. In the context of system engineering, a method is defined to consist of: (1) an underlying model of development, (2) a language, or languages, (3) defined, ordered steps, and (4) guidance for applying these in a coherent manner. (This definition is modified from Kronliif (1993)).
run simulations of this prototype to uncover contradictory requirements, and to identify requirements that have not been adequately implemented, e.g., performance and other nonfunctional requirements (even though this is contradictory with the principles of prototyp ing);
nom this definition we can see that a visual programming language must be recognized as merely a camp+ nent of the system development method. It is this author’s belief that visual programming languages need to integrated into a more complex model of system development, that incorporates formal specification
Determine the requirements of the system;
158
4.1 Mir6
techniques, (optionally) prototyping and simulation, formal refinement to executable code, and support for proof of correctness. For this, we require not ODly a visual language that is easily understood by nonspecialists, but also a formal language that facilitates reasoning about system requirements and the system specification.
The Mild languages (Heydon et al, 1999) are a prime example of the sort of visual languages that develop ers should be employing at the early stages of development .
The Mird languages are specific-purpose - their role is in the specification of security constraints of operating systems. The instance language enables the specification of file system access capabilities, while the cot&mint language permits the specification of particular security policies. The notation used is not entirely dissimilar to that of Statecharts, and the se mantics of the languages are strongly based on higraphs.
This may require more than one language; but, in any case, the visual language should have a formal basis. Hare1 (1992) in his critique of Brooks’ assessment (1987) points to the use of CASE tools and visual formalisms as a means of taming the ‘werewolf’ of system development. Harel’s own formalism of Statecharts (Harel, 1987) is one particular example of the sort of visual formalism he has in mind.
The languages illustrate how a visual formalism can satisfy even the most strict requirements of rigor and formality, while admitting a suitable degree of expressiveness and lending itself to quite an intuitive interpretation even by non-specialists. Various support tools facilitate editing ‘pictures’, checking for ambiguity (which is facilitated by the formal semantics), checking that particular instances satisfy specified constraints, etc.
4.1 Statecharts The formalism revives the application of statetransition diagrams (STDs), the graphical equivalent of finite-state machines (FSMs) in the specification and design of complex reactive systems. The language has a formal semantics based on higraphs - a from of graph that permits each node to contain one or more subgraphs. And-decomposition supports the partitioning of a single state into a number of orthogonal sub-Statecharts; or-decomposition allows partitioning into a number of mutually-exclusive states.
The Mir6 languages are applied in a very specific domain - that of security. They do illustrate, however, an approach that is likely to lend itself to other areas, and which could be extended into a visual method. Such an approach incorporates more than one language (in the case of Mir6, all of the languages are visual), expressed at suitable levels of abstraction, and supported by various tools.
The language has formed the basis (directly or indirectly) of a number of visual programming languages and of a number of visual development environments, most notably STATEMATE and STATEMENT. In practice, it has proven to be very successful; its complete formal semantics permits reasoning about specifications, and provably correct manipulations of specifications.
4.1 Method Integration In the traditional (structured) approach to software development, problems are analysed using a collection of diagrammatic notations, such as Data-Flow Diagrams (DFDs), Entity-Relationship-Attribute Diagrams (ERADs) and State Transition Diagrams (STDs). In general, these notations are informal, or, at best, semi-formal. Only after the problem has been analysed sufficiently are the possible sequences of op erations considered, from which the most appropriate are chosen.
Unfortunately, much of the emphasis on the application of Statecharts has been to convert the formalism to a visual programming language and use it in an evolutionary-style approach similar to that described in the previous section. It is our belief that while Statecharts could indeed be used as the basis for a visual method, current trends in visual programming will prevent it from becoming so. As long as a single language (or more critically a single level of abstraction) is used throughout the system development, practitioners will be tempted into following the model of the system life cycle illustrated in figure 1 (or a model closely resembling this).
When using formal specification techniques, however, personnel must begin to think in terms of the deriviation of a model (either explicit or implicit - depending on the formal specification language being used, and the level of abstraction of the specification) of reality. In the specification of a functional system (one in which output is a function of the current state and the input) this involves relating inputs to outputs by means of predicates over the state of the system. In reactive systems, of which concurrent, real-time and distributed systems are representative, the specification is complicated by the need to consider side-effects, timing constraints, and fairness. In either case, the mismatch, or ‘gap’ between the
We need to base a visual method on visual formalisms, but augmented with other appropriate languages (which may be visual) that are couched at appropriate levels of abstraction to suit the various stages of system development, and to further facilitate formal manipulation.
159
thought processes that are required at the analysis stage and those needed to formally specify a system is significant. A method based on the integration of structured and formal methods seems to offer the best of both worlds:
l
it offers the structured method’s support for the software life cycle, while admitting the use of more formal techniques at the specification and design phases, supporting refinement to executable code, and proof of properties;
l
two views of the system are presented, allowing different developers to concentrate on those aspects that are of interest to them;
l
a means is provided for formally proving the correctness of an implementation with respect to its specification;
l
the structured design can be used as a basis for insights into the construction of a formal specification.
Fig 2. a visual method of development
5. THE SB METHOD In essence, an approach based on such an integration is entirely compatible with Harel’s concept of visual forma!isms. Effectively, the formal specification can be seen 8s assigning a formal semantics to (various components of) a structured notation. This has the result of ma!dng the structured notation more pmcise and less ambiguous. And, if such an approach can be applied to eech notational component of the structured method, the entire method becomes formal&d.
We believe that the SB method is exemplative of the form of visual method which must be developed if visual programming is to be scaled up for appropriate use with real-time systems of a rea!iitic size and complexity. SB meets all of the requirements of a real-time development method (Hinchey, 1993): it is based on a reactive mode! of computation and supports an event mode! that permits the expression of timing constraints and which can describe entities that have properties and relationships that vary over time.
Such an approach is also not entirely incongruous with the idea of making design notations executable. It diem, however, in that the notation is not direcfIg executable; it may be amlysed aud manipulated, and using executable specification languages, or various specification animation techniques (such as restating specifications in terms of declarative programming languages) supports prototypiug and simulation. The visual language itself only becomes exe cutable however as a result of applying a refinement calculus (ideally with too! support) to systematically transform the textual equivalent of the visual notation into executable code.
More importantly, from our point-of-view, it offers a visual language with a full forma! semantics that can be couched at Mlrious levels of abstraction as appropriate, and so fits in at various stages in the development life cycle.
5.1 Visual Language The visual language (SBYC) avoids the use of domain-specific constructs such as mailboxes and message queues. Rather, the only primitive in the language is that of a sequential process and unidirectional communication channels that allow messages to be passed between processes; processes are assumed to be receptive, with the result that a!! communication between processes is asynchronous. Synchronous communication may be expressed through appropriate handshaking. There are no buffers, or queues, and communication between processes is inst~t~~~ apart from pro~g~ion delays.
The result of the approach is a highly abstract visual language that is not constrained to any particular implementation, or range of implementations. The notation is augmented with one or more formal languages that facilitate proofs of properties, and eventually proofs of correctness. Abstraction levels are reduced as necessary during the design phase until the design ls expressed at a suitably low level. Only then should implementation-specific constructs such as mailboxes, buffers and queues be considered in refining the design to a particular imp!ementation.
The notation is very simple: processes 8re represented as simple rectangles, and channels are denoted by arrows appropriately labelled. There is no limit on the number of processes at either the specification or
This results in a system life cycle as shown in figure 2, which is more akin to accepted development practices than that described earlier. 160
5.3 Formal Semantics
design phrases. This is important as most real-time systems will be distributed, or at least involve some degree of multi-processing. More importantly, such an approach allows for the separation of concerts: real-time systems must react accordingly (and within given timing constraints) to conditions in their environments arising from various sauces simultaneously. It is easier to cope with this 8t earlier stages in the development if we con consider each condition individually; SB allows each process to be deiiued separately, and then combined with other processes to form a complete system. In thii way it supports 8 constructive or ‘bottom-up’ approach that allows more detail and specialiiation to be added to the model as further insights are gained into the operation of the system.
Sf3YL: has a full formal semantics in that each pro cess may be expressed in terms of a process algebra for which the semantics are well-defined The process algebra is an extension of Receptive Pro cess Theory (Josephs, 1992), a reworking of Hoare’s language of Communicating Sequential Processes (CSP) (Hoare, 1985) under the gumption that all processes 8re receptive. Thii allows process definitions to be combined algebraicly, with the assurance that the resultant process is equivalent in behaviour to the combined behaviours of each of the individual processes. The formal semantics of each individual process’s Structure D&ram are expressed in terms of the Z notation (Brien & Nicholls, 1993), augmented with a very simple tempo4 logic as used in TLA+ (Lamport, 1991; Lamport, 1994).
When it comes to the design phase, visual respresentations of a limited number of constructs such as buffers are available for use; a small number of such constructs are supported by the language, but in all cases these can be expressed directly in terms of a number of sequential processes combined using a small number of well-defined operators. In essence, such constructs are a shorthand notation for more complex combinations of processes; they do, however, also simplify the mapping to an implementation in 8 conventional language.
The transformations between SYNC and the formal languages are formally specified, which also facilitates the derivation of translation tools. An important point, however, is that the inverses of each transformation are 8lso specified. This means that the correctness-preserving algebraic laws of the process algebra may be used to manipulate the mathematical equivalent of StIVC (for example, to reduce the number of processes in the description) and that the changes may be reflected back in the visual notation. This means that SAX may be used as a visualization tool at all stages in the development, but the visualization will be couched at various levels of abstraction, as appropriate.
State-based aspects of each process 8re addressed in a top-down manner via a tree-like graphical notation called a Structure Diagram that illustrates the ordering of events in the life-time of the process. As such, the notation closely resembles and draws many of its concepts from Jackson System Development (JSD) (Jackson, 1983), a popular structured method that is used in both industry and academia. The underlying semantics of SBVL: are quite diierent, however, and more appropriate for use with realtime and reactive systems.
5.4 Implementation The SB method supports formal refinement to executable code. Extended Receptive Process Theory (ERPT) may be refined to skeleton A& code that exploits many of Ada’s advanced features, such 8s tasking, multiple entry-points, exception-handling, etc. Refinement of Z to executable code serves to ‘fill-in’ many of the omissions in the skeleton code. A combined ERPT and Z refinement calculus is planned.
5.2 Abstraction Levels The language supports a wide range of abstraction levels. Wisely choosing the events that a particular process may engage in determines the level of abstraction of the sp~fi~tion. The fact that no implementation-oriented constructs are supported at the specification phase ensures that there is no biag towards particular implementations.
ERPT when transliterated to occam is almost exe cutable on transputers, so transputer-based prototypes and simulations 8re possible, and may be de rived quite quickly and easily. Z may also be animated in various declarative languages (such as Prolog and Miranda), providing a basis for both prototyping and simulation.
At the design phase of system de~lopment, the level of abstraction is reduced in 8n iterative and systematic manner. A notion of nejinement generates proof obligations that designs at successively lower levels of abstraction are in some sense *better’ (i.e., more det~n~tic, more efficient, more concrete, etc.) and support the same functionality.
An automated toolkit for the SB method is currently under development by BEST CASE Ltd. Initially the toolkit will support refinement to Ada, but eventually other implementation languages will also be supported.
161
Harel, D. (1988) On Visual Formalisms. Comm. of the ACM, 31(5), 514-530, May 1988.
6. CONCLUSION Current trends in the application of visual programming to real-time systems are in direct contrast with many of the established techniques and principles for the development of ‘correct’ systems. These may not pose problems when applied to small ‘toy’ applications, but they will certainly prevent the scaling of visual programming techniques for use with larger systems.
Hare& D. (1992) Biting the Silver Bullet: Toward a Brighter Future for System Development. IEEE Computer, 25(l)&20, January 1992.
It is this author’s firm belief that if visual programming is to be successfully applied to the development of large-scale real-time systems, then it must be integrated into some form of visual method of develop ment.
Hinchey, M.G. (1993) The Design of Real-Time Applications. Proc. RTAW’93, New York City, May 1993, 178 - 182, IEEE Computer Society Press.
Heydon, A., Maimone, M, Tygar, J.D., Wing, J.M. and Zaremski, A.M. (1999) Mir6: Visual Specification of Security. IEEE tinactions on Software Engineering, 16(10), 1185-1197, October 1990.
Hinchey, M.G. (1994) Towards Visual Methods. submitted for publication.
Such a method is likely to employ one or more visual languages: a suitably abstract visual language with complete formal semantics at the specification stage and one or more (possibly visual) less abstract languages (or more concrete constructs from the same language) at later stages. These languages will facilitate formal manipulation and proof, and more likely formal refinement to executable code, rather than the direct transliteration of graphical constructs to equivalent code in a conventional programming language.
Hoare, C.A.R. (1985) Communicating Sequential Pnxesses. Prentice Hall International Series in Computer Science, Hemel Hempstead & Englewood Cliffs, 1985. Jackson, M.A. (1983) System Development. Prentice Hall International Series in Computer Science, Hemel Hempstead & Englewood Clii, 1983. Josephs, M.B. (1992) Receptive Process Theory. Acta Infonnatica 29, 17 - 32, February 1992.
We have highlighted visual formalisms and method integration as two possible starting-points for the development of visual methods. We believe that both of these approaches have much to recommend them, and that either approach is at least an improvement on current trends. We have also very briefly described a visual method which we believe to be exemplative of the sort of techniques that will be required in the future. This method combines structured and formal methods in establishing a visual formalism, and exploits the methodological aspects of these methods in future development and in deriving provably comcf real-time systems from a visual (abstract) program.
Kronliif, K. editor (1993) Method Infegmtion: Concepb and Care Studies. Wiley Series in Sot%ware Based Systems, 1993. Lamport, L. (1991) The Temporal Logic of Actions. Technical Report 79, Digital Systems Research Center, Palo Alto, 25 December 1991. Lamport, L. (1994) TLZ. Invited lecture, 8th Z User Meeting, 29 - 30 June 1994, Cambridge, UK. Schwartz, J.J., Skubich, J.J., Szwed, P. and Maranzana, M. (1993) Real-Time Mulitasking Design with a Graphical Tool. Proc. RTAW’93, New York City, May 1993, 8 - 11, IEEE Computer Society Press.
We do not claim that this method is ‘ideal’, but we do believe that is a step in the right direction . . . and that the future of visual programming for real-time systems lies in its exploitation as a component of a visual method of development.
4. REFERENCES Bastiaens, K. & Van Campenhout, J.M. (1992) A Visual Real-Time Programming Language. Prvc. WRTP’92, Bruges, June 1992, 75 - 79, Pergamon Press. Brien, S. & Nicholls, J.E., editors (1993) The 2 Base Standard. Oxford University Computing Laboratory/ZIP Project Report. Brooks, F.P. (1987) No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, 20(4),10-19, April 1987. Harel, D. (1987) Statecharts: a Visual Formalism for Complex Systems. Science of Computer Programming, 8(3),231-274, June 1987.
162