Rapid Prototyping and Incremental Evolution Using SLAM ´ Angel Herranz Juan Jos´e Moreno-Navarro Universidad Polit´ecnica de Madrid Campus de Montegancedo s/n, Boadilla del Monte 28660, Spain
[email protected],
[email protected]
Abstract The paper shows the outlines of the SLAM system, that allows for an effective use of Formal Methods (FM) in Rapid Application Development (RAD) and other prototyping processes. The SLAM system, includes an expressive object oriented specification language and a development environment that, among other features, is able to generate efficient and readable code in a high level object oriented language (Java, C++, ...). SLAM is able to generate prototypes that can be used to validate the requirements with the user. The additional advantage is that the prototype is not throw-away because most part of the generated code can be directly used and the other part can be optimised with the additional help of assertions automatically included. Keywords Rapid application development, prototyping, incremental development, formal methods.
1. Motivation Information technology has been seeking the universal process for decades without success, probably because there is no ‘universal process’ to develop software. Anyway experiments have showed that prototyping processes are effective in gaining understanding of system requirements, simplifying the software design and providing an early validation of the system. Rapid Application Development (RAD) and other prototyping processes rely on several basic techniques that cover from reusing components to executing code from specifications. However, as bottom-up (synthesis) processes, additional risks are introduced [20]: 1. Prototyping, because it may be less controlled than conventional development methods, may lead to a reduction in programmer discipline. 2. In general, there is a lack of automated tools to help in the process.
3. Requirements that emerge during later prototyping may reduce the structural integrity of the partially designed system (e.g., increasing coupling between modules). 4. The cost of the prototype development could represent an unacceptably large fraction of overall system costs, specially if the reused components need to be bought, or sophisticated and expensive toolkits are used. 5. Usually the prototype is not enough efficient and can contain significant defects. So, re-implementation is recommended, and the developer has the impression of wasting time and effort. 6. Working prototypes may lead developers and customers to believe that the final product is almost ready for delivery. 7. Reliance on third-party components may either (i) sacrifice needed, or (ii) add unneeded functionality. Moreover, depending on the quality of the specification/documentation of reused components it could be difficult to determine if we are in (i) or (ii). 8. Prototyping may provide little room for the testing phase, specially concerning non-functionality requirements such reliability, robustness and safety. 9. Prototype may not scale. Due to those risks (specially 1, 2 and 3) and because written requirements are desired to formally define the system and to effectively communicate the its capabilities to customers some authors have advocated for the introduction of Formal Methods (FM) [16] in prototyping processes. Although apparently, the idiosyncratic of FM does not fit in bottom-up processes because, in Jean-Raymond Abrial’s words, ‘you have to think a lot before final coding’, we claim that FM can interleave with any established development process, so with RAD. On our view, RAD development must go on using the usual prototyping tools, specially those to develop GUIs, and FM can be introduced in the business logic stuff of the system. An specialised team in FM would produce formal specifications and a prototype with the business logic would
The SLAM System SLAM is a development environment based on formal methods; a modern and comfortable tool for specifying, refinement and programming. The formal notation SLAM - SL [13] embedded in the whole system is an object-oriented specification language valid for the design and programming stages in the software construction process. For this paper, one of the most relevant features of SLAM - SL is that it has been designed as a trade-off between the expressiveness of its underlying logic and the possibility of code synthesis. From an SLAM - SL specification the user can obtain code in a high level programming language (up to now Java and soon C+), a code that is readable and, of course, correct with respect to the specification. Because the code is readable, it can be modified, and improved by human programmers when needed. In addition, the synthesised code is annotated with assertions ([11, 12]) so any hand-code modification is tested at runtime. Our SLAM tool can be used in an evolutive prototyping process and can help to overcome the previously mentioned risks: 1, 2 and 3 can be minimized and, additionally, 4, 5, 6 and 7 are palliated:
be derived and integrated in the system. Risks 1, 2 and 3 would be partially overcome: 1. FM introduces a severe discipline of development and the final code can be checked w.r.t. original specifications. 2. There are many already operative FM tools 1 . 3. Inconsistencies in the intended behaviour of the system can be detected by the FM’s prover technology. The FM technology, including declarative language design and implementation technology, is mature enough to be used in prototyping. With respect to the prover technology, this must be improved but some lightweight provers (specially model checkers) have been demonstrated effective enough. From a notation point of view, we can find executable specification languages like Maude [6] that are expressive enough to specify abstract datatypes and programs that can be executed by using a rewriting interpreted mechanism (no evolutive code is generated). On other hand, Z [7], B [2] or VDM [17] specifications , very expressive too, cannot be executed in general although some tools can animate those specifications and some subsets, rather limited, of them can be used to automatically synthesised code. However, executable or animated specifications does not solve the problem of having a non-disposable prototype, therefore once the prototype is accepted the development needs to re-implement it in a productive language introducing an acceptable cost. To avoid this problem an adequate set of tools are needed. The objective of such tools is taking the maximum advantage of information in the formal specification. Assuming that we have got a powerful FM tool and an specialised team in FM, the development process for the critical components of the system could be the following:
4, 5 Typically, only a small part of the prototype needs to be re-implemented, saving time and cost. 6 In many cases, the resulting SLAM prototype is ready for delivery, at least as the first release. 7 SLAM components are fully specified, so in case of reusing the developer has a clear idea of the intended functionality. Let us postpone the discussion about how SLAM is helpful for risks 8 and 9 until the conclusion section. The Specification Language First of all, SLAM - SL is a formal specification language that can be classified as a state / model-oriented language technologically similar to VDM, B or Z. Some algebraic and logic formalisms have been introduced in the notation being the most relevant ones algebraic types (free types in Z terminology) and a semantics based on a typed first-order logic with partiality. The main difference with respect to notations mentioned above is that SLAM - SL is an object-oriented notation, more precisely, a class-based notation. The idea was to use the object-oriented metaphor in order to easily reach ordinary developers, and, at the same time, to study the implication of the objec-oriented approach in the design of an underlying logic. For more details, we refer to the SLAM site [19].
1. To specify the part of the most critical part of the system using a formal notation. 2. To use the theorem prover tool to check all the proof obligations generated. In this step inconsistencies and problems with the intended behaviour of the system can be captured. 3. To refine the specifications. 4. To check the new proof obligations generated during the refinement. 5. To automatically synthesise code by using the synthesiser tool.
From now on, we will focus on the most relevant characteristics for the purpose of the paper and the presentation will be agile relaxing the formal detail whenever possible. For the interested reader in FM, visit [16].
6. To manipulate the synthesised code in order to get efficiency, when needed. 1 Although
many more capabilities are still needed.
2
The rest of the paper is organised as follow: modelling capabilities will be see in section 2 and behaviour specification in section 3. In section 4 some interesting examples, from the point of rapid application development, are shown. Section 5 includes some comparison with related work already mentioned and conclusions.
class Polar_Point refines Point state polar (r : Float, a : Float) invariant r >= 0 and 0 n then 0 else p.votes / s
6
Another class PDivision is used to model the set of political parties. The method is relatively easy to specify by using the quantifiers in an adequate way. The constructor operation eliminates those parties that do not reach the fixed limit (needing the filter and the summatory quantifiers) and a second method assigns a new seat (by using the maximiser quantifier):
{ debug-def(PParty[MaxParties] pre_division = division; int pre_ln = ln;) int place = 0; float max = 0; for (int k = 0; k < ln; k++) if ((division[k].Votes() / (division[k].Seats() + 1)) > max) place = k; division [place].IncSeats(); post-check(AssignNewSeat( pre_division, pre_ln, division, ln)) }
class PDivision state (parties : [PParty], max_seats : Natural) invariant max_seats > 0 constructor mk_pdivision ([PParty]) call mk_division (parties) post result.parties = filter p in parties with p.votes > 3*result.max_votes/100 and result.max_votes = sum p in parties with p.votes
Program assertions are placed in the code, in such a way that possible manual wrong modifications can be detected when the program is executed in the debug mode. Additional prototypes can cover new requirements (statistics, chart diagrams, etc.).
modifier assign_seat call assign_new_seat post result = self \ parties \ i = parties(i).inc where table = map p in self.parties with map k in [1 .. max_seats] with p.coeff(k) (i, j) = maxim w in table with w
5. Related Work and Conclusion Abstract model based languages like Z, VDM or Larch are, in principle, more expressive than our language but they are not executable. Although there are object oriented extensions of Z and VDM, SLAM - SL has been design to directly support the object oriented paradigm. The expressiveness of SLAM and algebraic specification languages (mainly, the OBJ family) are difficult to compare. Algebraic specification languages can be executed but they do not provide readable imperative code. The abstraction level for specifying behaviour is higher in SLAM, however, a data model is needed to provide. If we restrict to the specification and the debugging facilities, every OBJ specification can be easily translated into a SLAM one. With respect to formal notations for information systems, SLAM, at the moment, does not cope with some important issues like persistence or concurrency. In fact, information systems specification languages are quite adequate for specifying the early stages of the information system development. The only one system that is able to produce C++, Java or Cobol code is Oblog [18]. The Oblog Rule Definition Language (RDL) is designed to be compiled to an imperative language but it has an imperative flavour and is rather limited (the only primitives are value assignment and an iterator). As a matter of fact, SLAM does not propose a methodology to develop information systems but can be used as a support for it. In this sense, SLAM components can model a significant subset of the elements in UML [4] and can replace OCL, the RDL language of Oblog, or other information systems specification language in a concrete methodology. As a future work, we want to formalise the relationship between UML/OCL concepts and SLAM - SL components. The SLAM goals are not completely achieved and parts
Notice that this specification is executable, and can be used to generate Prototype 1. A program to obtain the result of an election will construct an object of class PDivision with the correspondent number of votes for each party, and then call max seats times to the operation assign_new_seat. However, the naive specification about how to assign a seat is easy to optimise. It is obvious that there are many coefficients that will not be used. In fact, the coefficient p.votes / j is not used until we have already assigned j 1 seats to the party p. This means that a unidimensional table can be used and this optimal method can be specified as a new solution (the postcondition remains the same!) of assign_new_seat. modifier assign_seat ... sol result = self \ parties \ l = parties(l).inc where l = maxim y in self.parties with y.votes / (y.seats + 1)
This provide Prototype 2, that is efficient enough to be kept as the final code. From both specifications the SLAM environment is able to obtain automatically a C++ code. For simplicity we only describe the method assign_new_seat5 . void PDivision::AssignNewSeat (void) 5 Some simplifications like using arrays for SLAM sequences have been included to shorten the presentation.
7
of the system are under development. Current and future work includes (but is not limited to):
[3] P. Behm, P. Benoit, and J. Meynadier. Meteor: A Successful Application of B in a Large Project. In FM 99 — World Conf. on FM in the Development of Computing Systems, number 1708 in LNCS, pages 369–387. Springer Verlag, 1999. [4] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley Longman Inc., 1999. [5] T. Budd. An Introduction to Object-oriented Programming. Addison Wesley, 2nd edition, 1998. [6] M. Clavel, F. Dur´an, S. Eker, P. Lincoln, N. Mart´ı-Oliet, J. Meseguer, and J. Quesada. A Maude Tutorial. CSL, SRI International, March 2000. [7] A. Diller. Z: An Introduction to Formal Methods. John Wiley & Sons, 2nd edition, 1994. [8] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns - Elements of Reusable Object Oriented Software. Addison-Wesley, 1995. [9] J. V. Guttag and J. J. Horning. A tutorial on Larch and LCL, a Larch/C interface language. In S. Prehn and W. J. Toetenel, editors, VDM91: Formal Software Development Methods. Springer-Verlag Lecture Notes in Computer Science 551, October 1991. [10] I. J. Hayes and C. B. Jones. Specifications are not (necessarily) executable. TR 148, Key Center for Software Technology, Department of Computer Science, The Univ. of Queensland, St. Lucia 4072. Australia, January 1990. [11] A. Herranz and J. J. Moreno. Generation of and debugging with logical pre and post conditions. In M. Ducasse, editor, Automated and Algorithmic Debugging 2000. TU Munich, 2000. [12] A. Herranz and J. J. Moreno. On the role of functionallogic languages for the debugging of imperative programs. In Workshop on Functional and Logic Programming 2000. Univ. Polit´ecnica de Valencia, 2000. [13] A. Herranz and J. J. Moreno. On the design of an objectoriented formal notation. In Fourth Workshop on Rigorous Object Oriented Methods, ROOM 4. King’s College, London, March 2002. [14] A. Herranz and J. J. Moreno. Specifying in the large: Object-oriented specifications in the software development process. In Ehrig and Ertas, editors, The Sixth World Conf. on Integrated Design and Process Technology (IDPT’02), volume 1, Pasadena, California, June 23-28 2002. Society for Design and Process Science. ISSN 1090-9389. [15] A. Herranz and J. Moreno-Navarro. Formal extreme (and extremely formal) programming. Fourth International Conf. on eXtreme Programming and Agile Processes in Software Engineering (XP’03), May 2003. [16] The world wide web virtual library: Formal methods. http://www.afm.sbu.ac.uk. [17] C. B. Jones. Systematic Software Development Using VDM. Prentice Hall, 1986. [18] C. Sernadas, P. Goureia, and A. Sernadas. Oblog - object oriented logic: An informal introduction. TR, INESC, Lisbon, 1991. [19] The SLAM website. http://lml.ls.fi.upm.es/slam. [20] I. Sommerville. Software Engineering. Addison-Wesley, 3rd edition, 1989.
Support for data refinement and the identification and (semi)automatic proof of properties the specification must fulfil. Automatic generation of user interfaces of SLAM classes following the idea of having prototypes for free from specifications. Improvement of the compiler and generation of code in other languages like C++ or C#. Integration of the environment with existing tools for software edition and development (Microsoft Visual Studio, IBM Visual Age, Emacs, etc.) or FM tools (metrics, verification tools, model checking, etc.)
The SLAM system seems to be a very useful tool to develop high quality programs, i.e. error free with respect to the specification, clean, easy to read and manipulate to achieve modifications either in the specification or in the generated code, fully documented and including high level declarative debugging facilities to allow optimisations in a reliable way. SLAM can be used to generate prototypes and documentation that can be used to validate the requirements with the user. Most part of the generated code can be used at it is and the other part can be optimised with the additional help of the declarative debugging of the modified code. In summary, the SLAM system can help to solve some of the risks of using RAD and prototypes. SLAM proposes the use of precise and non ambiguous specifications that can be used either as documentation and for other automatic tools. The generated prototype is not throw-away, so development costs are not significantly increased. The quality and the efficiency of the generated code is excellent in a significant percentage of the cases and acceptable in most of the rest, including support for testing and debugging, what means that SLAM can be also used for test description including some non functional requirements. In this vein, we have reported some ideas combining prototypes, FM and agile methodologies in [15]. The adequacy of specification languages and FM for large projects has been shown in the use of B for the development of the control software of the 14th line of the Paris Underground [3]. The part developed with the B-method is entirely bug-free since the launching in October’98. SLAM can be used in a similar way because it is designed to cope with complex and large system and it can be used for ‘specifying in the large’ with success.
References [1] M. Abadi and L. Cardelli. A Theory of Objects. SpringerVerlag, 1996. [2] J. R. Abrial. The B-Book. Cambridge Univ. Press, 1996.
8
