View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Calhoun, Institutional Archive of the Naval Postgraduate School Calhoun: The NPS Institutional Archive Faculty and Researcher Publications Faculty and Researcher Publications 1998 Specifications in software prototyping Luqi The Journal of Systems and Software, Vol. 42 (1998), pp. 125-140 http://hdl.handle.net/10945/42329 The Journal of Systems and Software 42 (1998) 125±140 Speci®cations in software prototyping 1 Luqi a, Carl K. Chang b,*, Hong Zhu c a Computer Science Department, Naval Postgraduate School, Monterey, CA 93943, USA b Department of EECS (M/C 154), University of Illinois at Chicago, Chicago, IL 60607-7053, USA c Institute of Computer Software, Nanjing University, Nanjing 210093, China Received 20 December 1996; received in revised form 10 November 1997 Abstract We explore the use of software speci®cations for software prototyping. This paper describes a process model for software proto- typing, and shows how speci®cations can be used to support such a process via a cellular mobile phone switch example. Ó 1998 Elsevier Science Inc. All rights reserved. 1. Introduction ties of a prototype can be readily discovered in practice just because the prototype can be executed. An execu- Classical approaches to software development have tion capabilitymust be augmented with systamatic tech- been criticized for lack of early feedback about the ap- niques, theoretical results, and practical automated tools propriateness of a proposed system [9]. If testing occurs for representing and analyzing the properties of a proto- only after the bulk of the implementation eort, then type to fully realize the bene®ts of rapid prototyping. there is a substantial risk of discovering serious prob- The types of analysis needed include static symbolic ex- lems near the end of the development project, when it ecution techniques as well as generation and execution is too late to make major changes. Software prototyping of particular test cases. seeks to provide user feedback early in the development Accurately specifying the desired behavior of a soft- process, so that requirements and speci®cations can be ware system before the implementation is developed validated before available resources for the initial devel- can be quite dicult in practice. Constructing correct opment have been consumed by implementing an unde- speci®cations is hard because a set of informal ideas sirable version of the system. must be turned into a formal model via incomplete Early attempts at prototyping have been criticized for and imprecise communication between people. A valida- lack of documentation and sound engineering. The goal tion process is needed because correctness of the soft- of rapid prototyping is to improve the quality of the sys- ware depends on whether the speci®cation corresponds tems developed, as measured by their value to their user to the customers' real needs, in addition to whether communities. This implies that prototyping must be the implementation conforms to the speci®cation. Exe- coupled with methods for speci®cation and analysis, so cutable prototypes of the speci®cation are useful for ob- that the essential properties of proposed systems can taining user con®rmation that a proposed speci®cation be determined and alternative proposals can be evaluat- correctly represents the problem, and for guiding the re- ed and compared. Once the desired system behavior is formulation of the speci®cation in cases where it misrep- identi®ed, it must be captured in a form that is suitable resents the problem. as a basis for creating and testing the deliverable version This paper explores how software speci®cations can of the system. It is unrealistic to assume that the proper- support formulation of requirements via evolutionary software prototyping. The prototyping process repeats a guess/check/modify cycle until the users agree that * Corresponding author. Tel.: +1 312 996 4860; fax: +1 312 413; e- the demonstrated behavior is acceptable. Most of the mail: [email protected]. modi®cations seek to change the behavior of the system 1 This research was supported in part by the National Science Foundation under grant number CCR-058453 and by the Army to re¯ect new requirements, rather than to preserve the Research Oce under grant number ARO 111-95. behavior while improving eciency. 0164-1212/98/$19.00 Ó 1998 Elsevier Science Inc. All rights reserved. PII: S 0 1 6 4 - 1 2 1 2 ( 9 8 ) 1 0 0 0 4 - 3 126 Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140 The rest of the paper is organized as follows. Sec- variant of an Ada task entry corresponds to a message tion 2 suggests a classi®cation of changes to a software type, as does each variant of function or procedure de- speci®cation to support the prototyping process. Sec- clared in an Ada package speci®cation. Each call of such tion 3 discusses rapid prototyping and describes the role an entry or subprogram corresponds to an individual of speci®cations in the prototyping process. Section 4 message. Messages can also be realized by other mecha- presents a complete example for a cellular mobile phone nisms, such as remote procedure calls, I/O, updates to switch. Section 5 contains conclusions. shared data, exceptions, and hardware interrupts. An event occurs when a module receives a message at a particular instant of time. Every event has a target 2. Software speci®cations in prototyping module, an arriving message, and an occurrence time, and each event is uniquely identi®ed by these three attri- We are still short of software speci®cation methods butes. Events represent both stimuli and responses, and that are suciently powerful to describe all signi®cant serve as reference points for timing constraints. properties of a proposed software system and that can A computation history (or trace) is a set of events represent these properties in a way that is tractable both that is partially ordered by a causes relation. The causes to practicing software engineers and to decision support relation connects each stimulus event to each of the re- tools. For example, algebraic speci®cation methods such sponse events caused by the stimulus. as ACT-ONE, Larch, and OBJ3 and denotational meth- Requirements expressed in terms of the event model ods such as VDM and Z have only limited abilities to ex- are constraints on the causes relation for all possible press concurrency, synchronization, communication, traces. Most of these constraints 3 have the form ``every and real-time constraints. These are central issues in dis- event satisfying pre must cause a corresponding event tributed and real-time systems. Speci®cations would be- satisfying post'', where the precondition pre and the come hard to understand, therefore they deserve formal postcondition post are predicates on attributes of events support that can aid understanding both via concise and states. The state of module is externally modeled as conceptual models that abstract from low-level details, the sequence of all events that occurred at the module and via automated analysis and synthesis capabilities. prior to arrival of the most recent stimulus. The events Conversely, CCS and other formalisms that focus on occurring at each module are totally ordered by their oc- processes in distributed systems are weak in their ability currence times. to de®ne abstract data types. Recognition of this issue System structures are represented in the event model has led to number of attempts to integrate the approach- via the contains relation. The contains relation connects es, by combining algebraic speci®cation facilities with each module to each of its subcomponent modules. The CSP [19] or Petri nets [18]. Another approach is to ex- contains relation for a hierarchically described system tend the actor model of computation and to combine speci®es its internal structural relationships. In particu- it with a logic for expressing requirements on outputs lar, the contains relation distinguishes the modules in- and state changes [5]. side a system from those outside the system. The image under the contains relation is empty for any mod- 2.1. The event model ule that is primitive at the chosen level of abstraction (see granularity below). A system that is primitive at The event model is an extension of the actor model one level can be viewed at lower levels of abstraction that can represent real-time systems as well as concur- by introducing its subsystems and specifying the interac- rent and distributed systems [6]. The primitives of the tions between the system and its subsystems. A trace at simpli®ed event model 2 used in this paper are modules, the higher level of abstraction can be recovered from a messages, and events. lower level trace by removing all events occurring at A module is a black box that interacts with other the subsystems as well as the events at the decomposed modules only by sending and receiving messages via in- system that consist of messages arriving from its subsys- terfaces. Modules can represent software systems, such tems. as PSDL operators and types [6], Ada subprograms, tasks and packages; or people and hardware devices. 2.2. Classi®cation of speci®cation changes A message is a data packet that is sent from one mod- ule to another. Messages are classi®ed into message We characterize changes to a system in terms of three types based on the name of the message and signature orthogonal attributes of the system speci®cation: its vo- of the associated data. For example, each overloaded cabulary, its granularity, and its behavior. These attri- 2 The full event model has an additional primitive for modeling temporal events.