Specifications in Software Prototyping

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 prototyping, 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.

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 module 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. 3 Synchronization constraints have a dierent form. Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140 127 butes can be formalized using the event model as follows. · The vocabulary of a system is the set of all external stimuli recognized by the system. An external stimulus is a message that is received by the system and originates from a module outside the system. A stimulus that is recognized by the system is the cause of the associated system response events. The vocabu- Fig. 1. Types of changes. lary is usually in®nite, and can be ®nitely represented as the union of a set of message types. The set of message types recognized by a system can be made ®nite that each primitive change preserves two of the three at- via a suitable representation for generic message tributes. Meaning-preserving changes are in general con- types (e.g. generic subprograms declared in Ada servative extensions: the new speci®cation satis®es the packages). The vocabulary of a system represents original one, and it may have additional properties. the set of functional capabilities provided by the sys- Contracting and relaxing changes are in general mean- tem. ing removing, and can be used to construct meaning- · The granularity of a system is the set of all internal changing modi®cations when combined with the other stimuli recognized by the system. An internal stimu- types of changes. There are two ways to add information lus is a message that originates from a module inside to a design: adding message types via extending or re®n- the system and is received by a module inside the sys- ing changes which add elements to the vocabulary or tem. The granularity represents the amount of detail granularity, and by adding new constraints via con- in which the computation has been speci®ed. At one straining changes which reduce the set of legal behav- extreme is a black-box speci®cation, which does not iors. mention any internal stimuli at all. At the other extreme (if we avoid the embedded hardware) is ma- 2.3. Examples of modi®cation types chine code, which speci®es internal events corresponding to individual machine instructions. We illustrate these concepts via examples. · The behavior of a system is the set of all possible trac- · Extending changes add new types of messages to a es for the system in relation to a given vocabulary and system. For example, adding a new command to a granularity. The behavior of a system contains each graphical editor is an extending change because it cre- of the possible responses of the system to each stim- ates a new message type. ulus in the given vocabulary and granularity. The be- · Contracting changes are inverses of extending chan- havior is usually in®nite. ges: they remove possible types of interactions from Note that each of these three attributes is a set, and that a system. A message type may be dropped because subset relationships on these attributes are related to re- it is deemed useless by customers. ®nements. We believe that a useful representation of a · Constraining changes restrict the behavior of a system design history can be obtained by decomposing each by placing constraints on legal responses to a stimu- step in the evolution of a software prototype into prim- lus. For example, adding a postcondition to a mes- itive substeps that preserve two of the three attributes sage speci®cation consisting only of a type signature and makes a monotonic change (either Ì or ) in the is a constraining change, as is strengthening a post- third [8]. condition (replacing the postcondition P with The part of the behavior that must be preserved by P 0 where P 0 ) P& : P ) P 0: primitive substeps that change the vocabulary or ab- · Relaxing changes are inverses of constraining chan- straction level is determined by the intersection of the ges. They remove some restrictions on the behavior vocabularies of the initial and modi®ed systems, and that exist in the previous version. An important class the intersection of the granularities. This says that chan- of relaxing changes is applied because the more re- ges that add new message types or remove previously de- strictive requirement is not logically satis®able, can- ®ned messages types should not aect the behavior of not be implemented with existing technology, or the system with respect to the other previously de®ned cannot be realized within given constraints on budget message types. The proposed restrictions lead to the and computing resources. An example is relaxing a classi®cation of primitive changes shown in Fig. 1. The requirement to keep an airplane exactly on course symbol AS represents the attribute A of the original sys- to the requirement for corrective steering when the tem S, and AS0 represents the attribute A of the modi®ed airplane strays o its course, thus keeping it within system S. some tolerance of expected position. This type of Extending, abstracting, re®ning and constraining change is needed because perfect control of physical changes are meaning preserving, given our convention systems is not feasible. 128 Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140

· Re®ning changes constrain the internal details of the We can return to prototype evolution, followed by an- computation speci®ed by a program without chang- other instance of production code generation. The ing its vocabulary or its externally visible behavior. prototyping process is illustrated in Fig. 2. Such a change may decompose a module into a net- The prototype evolution phase consists of the activi- work of submodules or choose algorithms and data ties labeled ``analyze requirements'', ``construct proto- structures for implementing a module. type'', and ``execute prototype''. The process starts · Abstracting changes are inverses of re®ning changes. with requirements analysis to determine an initial ver- Abstracting changes abstract away some details of a sion of the requirements. Next, a prototype is construct- computation, without aecting the vocabulary or ed based on the requirements. For complex systems, this the externally visible behavior. They may occur in re- process usually requires decomposition of the system verse engineering process, such as the TMM ap- into simpler subsystems. proach to software maintenance [1]. In our approach, a prototype consists of a hierarchy of modules, where each module has behavioral speci®cation augmented with optional implementation informa- 3. Prototyping via speci®cations tion, such as a decomposition or a reusable program. The prototype execution activity demonstrates some typ- 3.1. The prototyping process ical cases of prototype behavior and generates a series of prototype adjustments based on the customer's quick Prototyping enhances communication with the user feedback. This feedback is used in the requirements anal- community by providing an executable model of the sys- ysis activity to produce an updated set of requirements tem early in the development process. Early feedback and trigger the next prototyping cycle. The analysis trac- from the user community leads to software systems that es cases of unwanted behavior to identify incorrect or in- are more likely to meet user needs, and reduces lifecycle complete requirements, and proposes one or more costs because changes made at the early stages of devel- plausible ways to modify the requirements. The next opment are much cheaper than changes made after the round of prototype execution tests the validity of the system has been delivered. Prototyping can also be use- proposed changes, provides guidance to choose between ful for streamlining software evolution. In this section alternative formulations, and explores previously unval- we discuss speci®cation-based prototyping. idated aspects of system behavior. This process contin- There are two phases in our model of the prototyping ues until the requirements have been thoroughly process, prototype evolution and production code genera- exercised and the customers are satis®ed with the demon- tion [15]. The purpose of prototype evolution is to stabi- strated behavior of the prototype. The result of the pro- lize the software requirements before eort is invested in totype evolution phase is a software architecture for the detailed implementation and optimization. The purpose proposed system, which consists of formal speci®cations of production code generation is to generate an ecient for the proposed system, and a system decomposition implementation when the requirements are stable. If that includes formal speci®cations for the subsystems there is a need to modify the requirements after delivery. and a description of their interconnections.

Fig. 2. Prototyping lifecycle process model. Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140 129

The production code generation phase consists of the Our procedure for realizing a prototype is illustrated activities labeled ``simplify/verify structure'' and ``imple- in Fig. 3, which provides an exploded view of the ``con- ment/optimize''. The deliverable version of the envi- struct prototype'' box in Fig. 2. sioned system is constructed based on the spec- For each subsystem in the prototype, the results of re- i®cations, decomposition, and other attributes deter- quirements analysis are used to propose a system inter- mined in the prototype evolution phase. The simpli®ca- face and the behavior of the interface is expressed in the tion of the prototype structure is an optional activity Spec language. The speci®cation is then converted to ex- aimed at reducing implementation and maintenance ecutable form. There are three ways to do this. costs. The veri®cation of the structure of the prototype · Convert the speci®cation into the executable subset of is an optional process whose purpose is to prevent inte- the Spec language if it is not already in an executable gration problems, especially in cases where dierent form. This step is necessary because the full Spec lan- groups or subcontractors produce dierent subsystems. guage includes unbounded quanti®ers and is strong This veri®cation seeks to prove that the proposed de- enough to specify functions that are not computable. composition of a system will meet the speci®cations However, if the requirements are feasible, then the for the entire system whenever the subsystems identi®ed conversion into executable form must also be feasi- in the decomposition meet their speci®cations. In the ble. In cases where the conversion is too dicult, near term it is rational to assume that the analysis and we can use one of the methods listed below to realize design process is potentially imperfect. It may therefore the speci®cation. be useful to verify the highest levels of the decomposi- · Produce code in a programming language such as tion before the decomposition is used as a starting point Ada. This can be done by retrieving and adapting re- for detailed implementation. usable components based on the speci®cations [12], The implement/optimize activity produces ecient or by creating new code, either manually or via pro- implementations of the subsystems. The design-level gram generation and transformation tools. pragmas associated with the Spec language [6] can in · Decompose the module into lower-level components. principle provide computer aids for this process. The This requires specifying the components (using Spec) software to realize this is currently in an early stage of and their interconnections (via an augmented data development. ¯ow diagram, as in PSDL [17]. The prototype design-

Fig. 3. Constructing a prototype. 130 Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140

er supplies intelligent insights in this step and propos- prototype. Prototyping usually focuses on critical sub- es useful lower-level abstractions. This process can systems or particular aspects of the system that cause simplify implementation via the previous mecha- uncertainty. For example, if human factors are domi- nisms, and can signi®cantly improve performance, es- nant, then formatting requirements may be preserved pecially if frequently executed substeps are realized while requirements on system semantics may be relaxed by ecient reusable program modules. for the prototype. The result of realizing a subsystem by this mechanism is Partially developing and then relaxing some of the re- a hierarchical decomposition into modules that are ei- quirements is often preferable to delaying the elabora- ther directly executable (Ada, C++, etc.) or can be sim- tion of the less critical requirements, because dierent ulated via symbolic execution (Spec, OBJ, etc.). aspects of a system are rarely completely independent, A key issue for realizing the bene®ts of prototyping in although they may be weakly coupled. Access to the practice is rapid and correct construction and modi®ca- complete requirements is sometimes necessary to make tion of prototypes via computer aided tools such as the sensible choices in a prototyping eort, even if some of Computer Aided Prototyping System [16]. those requirements are not intended to be realized by A prototype demonstration often results in user re- the prototype. quests for adjustments to the behavior of the prototype. The prototype evolution phase is dominated by a se- These adjustments can be classi®ed as Spec adjustments, ries of nonmonotonic changes to the behavior of the which modify the speci®ed behavior of a module in the prototype. These changes are realized via contracting prototype, and as structural adjustments, which rear- and extending changes or via relaxing and constraining range the modulus in the prototype and add or remove changes. Meaning-preserving changes are applied at this subcomponents. Prototype adjustments usually consist stage mainly for adjusting the structure of the prototype of Spec adjustments at the highest levels of the hierarchi- to make it easier to understand or modify, and to com- cal structure, and a mixture of Spec adjustments and pletely or partially implement non-constructive speci®- structural adjustments in the lower levels. One of the cations. Improving eciency is a major goal only if goals of computer aid for prototype evolution is to help feasibility of hard real-time constraints must be estab- propagate intended changes from the highest level of the lished or if prototype demonstrations take impractically structure to the lower levels, and to ensure that this long to run. propagation is complete. Some modi®cations achieve We illustrate some additional uses of meaning-chang- one goal at the expense of destroying the integrity of ing changes to realize non-constructive speci®cations. the design, so that other modi®cations must follow to One of the ways to carry out the ``produce Ada code'' ®x things up. Modi®cations should be packaged togeth- activity shown in Fig. 3 is to retrieve a reusable software er in transactions that guarantee the design to be free component from a software base, a typical matching ac- from some classes of faults, such as references to unde- tivity in the reuse-based prototyping approach. Relaxing ®ned variables. changes are useful in this context. If a component that The structure of the prototype must also be periodi- satis®es the speci®cation given by the designer cannot cally simpli®ed to maintain intellectual control and en- be found, the software base management system can able future modi®cations to be carried out with speed make a query broader by applying relaxing changes to and accuracy. This cleanup function involves restructur- the speci®cation. Some candidates are relaxing changes ing the prototype, and removing old features that are no that drop some of the postconditions. For example, if longer needed to support current requirements. It can be the output of an operator must be a sequence that con- considered part of the ``modify prototype'' activity tains all elements satisfying a given set of constraints, shown in Fig. 3. This process is generally done between and which must be in monotonically increasing order demonstration sessions, based on design reviews or com- with respect to a given ordering, the software base man- puter-aided dependency analysis rather than on custom- agement system can seek modules that satisfy only the er feedback. Section 3.2 discusses how speci®cation ®rst constraint, or only the second constraint. The orig- changes contribute to the construction and evolution inal speci®cation and two relaxed speci®cations are of prototypes. shown in Fig. 4. In this case, the retrieval will succeed for the second 3.2. The role of speci®cations and changes in prototyping relaxed speci®cation, yielding an instance of a generic module that sorts a sequence with respect to an ordering The initial formulation of a prototype may involve de®ned by a generic procedure parameter. The retrieved contracting and relaxing changes to the original re- module can then be used to suggest a realization of the quirements. These changes are used to simplify the original design via decomposition. This example is an in- problem and speed up the prototyping process by ig- stance of a ®lter decomposition, which succeeds because noring less important stimuli, or to relax some of the re- the postcondition of the ®rst relaxed speci®cation is in- quirements for stimuli that are modeled in the variant under the function de®ned by the second relaxed Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140 131

Fig. 4. Relaxing changes for approximate component retrieval. speci®cation. Strategies for meeting complex goals via Reformulating changes are also useful for speeding operations that interfere with some subgoals, such as up the speci®cation matching process. These changes re- those developed in the context of robot task planning, alize several dierent normal forms that support signa- can be useful for enhancing this approach. ture indexing, fast semantic elimination procedures, Matching relative to extending and contracting chan- and implication checking [21]. ges is also useful for retrieving reusable software compo- Constraining and relaxing changes are useful when nents. Accepting stored components with supertypes for the designer discovers that it is possible to implement speci®ed arguments, or with optional parameters that a stronger version of a component than was required were not speci®ed in the query are some simple examples by the original design. A simple example comes form of useful extending changes. Retrieving via partial the timing constraints associated with a time-critical op- match with the same postcondition is a useful contract- erator. Suppose that the original design sought an oper- ing change that results in a partial operation. This appli- ator with a maximum execution time of 100 ms, and a cation of changes diers from the use of relaxing software base retrieval located an implementation for changes outlined above, because the changes extend or the operator with a maximum execution time of only contract the matching criterion, rather than modifying 23 ms. The designer is likely to change the design to re- the query, as did the relaxing changes above. quire a response for the operator in 23 ms, thus perform- When integrated with matching, changes can be con- ing a constraining change by replacing a loose timing structed as part of the matching process, rather than be- constraint by a tighter one, as illustrated in Fig. 5. ing given a priori. The change that enables the match In this particular application, the constraining change can contribute to the synthesis of the design. For exam- can be followed by a relaxing change that reallocates ple, the contracting change used as a guard for the par- computation time to some components that are yet to tial operation in a modi®ed decomposition. In general, be implemented, making it easier to ®nd implementa- contracting changes can be applied both to the query tions for those components. For this example and for and to the stored component. The stored component other cases involving simple numerical constraints, the may not satisfy the query as a total operation, but it associated changes can be eciently implemented using may have a partial subfunction that satis®es a contrac- a constraint maintenance system. More dicult exam- tion of the query as a total operation, but it may have ples include cases where the retrieved component satis- a partial subfunction that satis®es a contraction of the ®es stronger behavioral properties than were requested query. An example is using a remainder function to par- by the designer. Such components may subsume func- tially satisfy a query seeking a modulo function: the two tions allocated to other parts of a decomposition, if are identical for non-negative arguments, but dier for the designer in fact desired these additional properties. negative arguments. The result of the query is a contrac- If this is not the case, and the requirements were initially tion of the remainder operation that is limited to non- incomplete, then such a retrieval may suggest corre- negative arguments via a synthesized guard predicate. sponding constraining changes on the speci®cations. 132 Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140

Fig. 5. Timing reallocation induced by software component.

This in turn suggests new requirements to be evaluated the service region into several service areas (cells) and by customers in a prototype demonstration session. cluster a certain number of cells as a group in which In the production code generation phase of the pro- communication channels are used without repetition. cess, the desired behavior of the system is relatively sta- All the other adjacent clusters (areas) can reuse the same ble, and the major concern is improving eciency, spectrum of channels within their own regions without capacity, or robustness. This part of the process is dom- causing signal interference. In this way, maximal e- inated by meaning-preserving changes for optimizing ciency of channel utilization is achieved. There are three the design and implementation (the ``implement'' activ- types of basic components within a mobile telephone ity of Fig. 2). Meaning-preserving transformations have system. been studied extensively [2±4,11,13,14,22]. However, · The Mobile Telephone Units (MTU ± a telephone re- changes to the functionality are sometimes also needed questing services). to optimize a design. · The Base Site (BS ± monitoring MTUs via radio com- Ecient algorithms are often applicable only in spe- munication). cial cases, so that their use may constrain the set of · The Mobile Switching Center (MSC ± the switching problems that can be solved. This makes the operation administration center for a service area). partially de®ned. We do not want to leave such an oper- The prototype development and evolution process starts ation partial (the result of contracting change), because with the decomposition of a mobile telephone system that would put the burden on the user to avoid inputs into three types of components. At this point we know outside the domain of the function. We prefer to remove little about the details of the mobile phones and base all constraints on the behavior of the operation outside sites except that each mobile phone has a unique identity the domain of the ecient implementation (via a relax- number and a telephone number and each base site also ing change) and then to reconstrain the speci®cation by has a unique identity number. This is re¯ected in the def- de®ning safe responses for the remaining cases, such as initions of the mobile and base_site types. See exception conditions or error messages. A common ex- Fig. 6. ample of an optimization that speeds up an algorithm The de®nition of mobile_switch_centre is a by introducing constraints is static memory allocation, syntactically correct skeleton of a speci®cation in Spec. which puts a ®xed bound on the size of a data structure. So are the de®nitions of mobile_identity, Such an optimization adds a class of potential over¯ow base_site_identity and dialable_numbers. errors to the speci®cation, or at least changes the cir- Details of these de®nitions need to be re®ned by further cumstances under which an over¯ow error will occur. evolution. Due to lack of space, this paper gives only the Since meaning-changing modi®cations can change the details of mobile phone units. observable behavior of the system, they require a valida- Like an ordinary hard-wired telephone, a mobile tion step, possibly via an additional prototyping cycle phone has a set of digit buttons for dialing telephone focused on demonstrating the proposed change. or mobile phone numbers. However, a mobile phone also has several additional function keys such as the on/o switch, send button, end button, erase button, an- 4. Example swer button, etc. The on/o switch is responsible for pow- ering the mobile phone unit. When the on/o switch is in In this section, we illustrate the evolution process the on position, the user can initiate a call. The digit but- of software speci®cations via a case study on simula- tons are designed for dialing phone numbers. Pressing tion software for a cellular mobile phone system [10]. any of these buttons will append the number pressed The formal speci®cation is written in the Spec language to the dialing register. When the erase button is pressed, [6]. the dialing register is cleared. When the send button is In a cellular mobile phone system, many mobile pressed, the number in dialing register is sent to the base phone units may request communication services via a site to initiate a call. The end button is pressed during a limited number of channels. A cellular system divides conversation to terminate the phone call and place the Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140 133

Fig. 6. Top level speci®cation of mobile phone system ± Version 0. phone in the idle on-hook state. When the on/o switch the implicit assumption that mobiles have internal states is in the on position, the mobile is tuned automatically to that are subject to change by inheriting the properties listen to the nearest base site's overhead message so that common to all types of mutable object from a standard when a call to the mobile phone is paged, it responds to library module whose de®nition can be found in [6]. We the call by sending a message to base site and rings the now perform relaxing/constraining changes that give full bell of the mobile to inform the user that a call has been speci®cations of the responses to the messages. The re- received. The user can then start a conversation by sult of these changes is shown in Fig. 8. pressing the answer button, which puts the mobile into When specifying the pre-/post-conditions, it is real- the active o-hook state. The function of each button ized that the mobile unit should keep track of informa- is speci®ed by a corresponding message, producing the tion about the tuned base site. Another message, tune, is extended type de®nition shown in Fig. 7. then added into the type de®nition of mobile phones. An Version l of mobile type de®nition is an extension of analysis of the state transitions identi®es a trap state, version 0. A number of new message types are added which makes the analyst recognize a missing interaction into the vocabulary, but the behavior of a mobile phone between the mobile switch center and the mobile unit. A is not yet formally speci®ed because some of the state new message connected is added to represent this inter- transitions and post-conditions of the messages are de- action. This results in the extending and constraining scribed only by informal comments. We have recorded changes to the speci®cation shown in Fig. 9. 134 Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140

Fig. 7. Speci®cation of mobile phone unit ± Version 1.

A type consistency analysis of send_button indicates sidered the functions of special keys such as * and #), we that sequence{digits} must be a subtype of the previously can provisionally interpret that type to be the same as unspeci®ed type dialable_number. Since we do not have sequence{digits}. The only other unspeci®ed type is mo- reason to generalize dialable_number (we have not con- bile_identity. Since all we know about this type so far is Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140 135

Fig. 8. Speci®cation of mobile phone unit ± Version 2.a. that it must have an `` '' operation, it can be interpre- structed in response to each event. Thus in the context ted as any type with a well-de®ned equality operation. of appropriate tool support, we have constructed an ex- Natural numbers will serve. ecutable prototype at this point, which can be tested and Given these interpretations, the above speci®cation demonstrated to clients. The prototype can also be becomes executable, because all of the postconditions instrumented to check the truth of the invariant after are free of quanti®ers and have the form of equations each state transition. In this case the invariant can be that unambiguously de®ne the quantities to be con- made executable by enumeration because the bound 136 Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140

Fig. 9. Speci®cation of mobile phone unit ± Version 3.a. variables range over a type with a ®nite population. Any is likely to remain true when additional aspects of the mutable type has a ®nite population because the instanc- application are included in the model. If it is true, then es are dynamically created, and there can be only a ®nite the state component m.hook is not independent: its val- number of such creation events prior to any given point ue can be derived from m.state. Consequently, the spec- in a computation. i®cation can be simpli®ed by dropping m.hook from the At this stage it is not useful to demonstrate the proto- MODEL and all preconditions and postconditions in type to clients because the process of receiving a call is this speci®cation. It can be de®ned as a derived concept still unde®ned, and calls cannot yet be completed. How- if it turns out to be needed for explanation or for spec- ever, engineers examining execution traces notice that ifying future enhancements to the system. the mobile is o hook only when it is in the dialing, The speci®cation and prototyping of a large and com- sending, and conversation states. Monitoring of proto- plex software system often divides the task into a num- type execution and analysis of the state machine con®rm ber of concurrent processes. Each process concentrates that this is indeed an invariant of the current speci®ca- on one particular aspects of the problem. For example, tion. This suggests checking with the clients whether this the above speci®cation is only concerned with the Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140 137

Fig. 10. Speci®cation of mobile phone unit ± Version 2.b. initiation process of mobile phone calls. While a team of ing a call, hence, the re®nement of the hando process software engineers works on specifying and prototyping is postponed for future development. this process of initiating a call and produces the speci®- Since the mobile phone unit is simple enough so that cation given in Fig. 9, another team may well be work- there is no need to decompose its structure into compo- ing on specifying the process of receiving a call. nents, there are no granularity changes during the spec- Based on version 1 of the speci®cation, another set of i®cation of the ®rst prototype in this example. However, messages is added to specify the receiving process. The when prototypes are used for deriving the software ar- state space extension is also dierent from the calling chitecture, granularity changes may happen. Readers process team. The fragments of formal speci®cations are referred to [7] for a theory and method of merging for receiving calls are given in Fig. 10. of changes in software structure. There are no timing When the bell is ringing, the user of the phone constraints visible at the black box granularity level of can start the conversation by pushing the answer but- this example. However, they do appear at lower levels ton. Therefore, we add and specify the answer_button of the protocols, which rely on timeout constraints to message as shown in Fig. 11. This is an extending determine aspects such as the success of failure of a re- change. quested connection. After the two teams ®nish their parallel developments, the result versions, i.e. version 3.a and version 3.b, must be merged into a consistent one. It is easy to 5. Conclusions see that the dierences between the two versions are not in con¯ict with each other. The merging of the Evolutionary prototyping is a promising approach to two versions results in the speci®cation given in the problem of formulating system requirements that ac- Fig. 12. The whole evolution process is shown in curately re¯ect the needs of the stakeholders. This ap- Fig. 13. proach becomes particularly attractive if we can As formally speci®ed in Fig. 12, the tuning process is provide formal models and decision support tools to performed when power is on but the state is not conver- aid the process. One of the reasons software evolution sation. During a conversation, a mobile phone may need is dicult is that realistic software designs are compli- re-tuning into another base site if the phone is moving cated by optimizations. These optimizations improve from the coverage area of one base site to another. This the eciency of the software by introducing additional process is called hando. At this stage of speci®cation constraints that complicate the implementation and in- and prototyping, a software engineer may want to con- troduce dependencies between parts of the system that centrate on the process of tuning, initiating and receiv- might otherwise be independent.

Fig. 11. Speci®cation of mobile phone unit ± Version 3.b. 138 Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140

Our approach to evolutionary prototyping uses high- · They can be used as search keys for retrieving reus- level subsystem speci®cations to simplify evolution sup- able software components to realize subsystems of port. We have used the prototyping language PSDL to the prototype. describe the software architecture and the speci®cation · They can be used to verify (prove the soundness of) a language Spec to describe the constraints, obligations, decomposition before it is used as the basis for divi- and relationships between the slots in the prototype sion of labor in a detailed implementation and opti- software architecture. Spec annotations provide a ®rst mization eort. This should reduce the incidence of step towards high level descriptions of optimizations system integration problems late in the development to produce the product versions of the proposed soft- process. ware. A continuing challenge is to ®nd the proper balance Speci®cation can serve several purposes in the context among expressiveness of speci®cations, simplicity, and of prototyping. tractability of processing by automated tools. Practical · They can be used to document the range of behaviors impact of formal speci®cations hinges on ®nding formal expected for the component slots in the evolving soft- representations that practical software engineers can un- ware architecture. derstand and are willing to use, and providing tool sup- · They can be used to record the rationale for imple- port with enough practical bene®t to overcome the extra mentation decisions, to guide later evolution and en- eort required to formalize requirements, speci®cations, hancement of the design. and designs. Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140 139

Fig. 12. The merging of Version 3.a and Version 3.b ± Version 4.

Fig. 13. The evolution process of the speci®cation of mobile phone units.

References Lecture Notes in Computer Science, vol. 183, Springer, Berlin, 1985. [1] G. Arango, I. Baxter, P. Freeman, C. Pidgeon, TMM: Software [3] F. Bauer et al., The Munich Project CIP. Vol. II: The Program Maintenance by Transformation, IEEE Software 3 (3) (1986) 27± Transformation System CIP-S, in: G. Goos and J Hartmanis, eds., 39. LectureNotesinComputerScience,vol.292,Springer,Berlin,1987. [2] F. Bauer et al., The Munich Project CIP. Vol. I: The Wide [4] F. Bauer, B. Moller, H. Partsch, P. Pepper, Formal program Spectrum Language CIP-L, in: G. Goos and J Hartmanis, eds., construction by transformations ± Computer-aided, intuition- 140 Luqi et al. / The Journal of Systems and Software 42 (1998) 125±140

guided programming, IEEE Trans. Software Eng. 15 (2) (1989) in: C. Rich, R. Waters (Eds.), Readings in Arti®cial Intelligence 165±180. and Software Engineering, Morgan Kaufmann, Los Altos, CA, [5] V. Berzins, Luqi, An introduction to the speci®cation language 1986, pp. 191±200. spec, IEEE Software 7 (2) (1990) 74±84. [6] V. Berzins, Luqi, Software Engineering with Abstractions: An Chang directs the International Center for Software Engineering Integrated Approach to Software Development using Ada, (ICSE) at the University of Illinois at Chicago. ICSE is targeted to the Addison-Wesley, Reading, MA, 1991. research and development of methodologies and tools to help enhance [7] V. Berzins, D. Dampier, Software merge: Combining changes to software productivity and quality. Currently Chang is serving as the decompositions, J. System Integration 6 (1/2) (1996) 135±150. Secretary of the IEEE Computer Society and an active member of its Executive Committee, after ®nishing his ®rst 3-year term on the Board [8] V. Berzins, Recombining changes to software speci®cations, in: of Governors (1995±1997) and being re-elected for the second 3-year Proc. SEKE 96, pp. 136±144. term on the BOG (1998±2000). He has been serving on the program [9] B. Boehm, A spiral model of software development and committee of International Computer Software and Applications enhancement, Computer 21 (5) (1988) 61±72. Conference (COMPSAC) since 1982. He served as the Program Chair for the 1993 International Conference on Computer and Information [10] C.K. Chang, X. Shu, G. Chan, M. Aoyama, An object-oriented (ICCI) held in Sudbury, Canada. He helped found the International real-time distributed simulation of cellular phone switching Conference on Requirements Engineering (ICRE) in 1992 and is now system, in: Proceedings of 1993 IEEE International Symposium chairing the ICRE steering committee. He was the General Chair for on Circuits and Systems, May 1993, pp. 2232±2235. ICRE 96. He also served as the Program Co-Chair for COMPSAC 96 held in Seoul, Korea. In 1997 he chaired the Program Committee for [11] S. Fickas, Automating the transformational development of the 1997 IEEE Workshop on Future Trends in Distributed Computing software, IEEE Trans. Software Eng. 11 (11) (1985) 1268±1277. Systems (FTDCS) held in Tunis, Tunisia. He has contributed exten- [12] J. Goguen, D. Nguyen, J. Meseguer, Luqi, D. Zhang, V. Berzins, sively as referees for numerous technical journals including IEEE Software component search, J. Systems Integration (special issue Transactions on Computers, IEEE Transactions on Software Engi- neering, IEEE Computer, and IEEE Software, as well as major Con- on CAPS) 6 (2) (1996) 93±134. ferences such as COMPSAC, ICCL, NCC, International Conference [13] C. Green, A summary of the PSI Program Synthesis System, in: on Parallel Processing (ICPP), and International Conference on Data Fifth International Joint Conference on Arti®cial Intelligence, Engineering. He is on the Editorial Board of IEEE Computer Society 1977, pp. 380±381. Press. He served two terms as the Editor-in-Chief of IEEE Software from 1991±1994. Chang earned a BS in mathematics from National [14] E. Kant, On the ecient synthesis of ecient programs, Arti®cial Central University in Taiwan, an MS in computer science from Intelligence 20 (3) (1983) 253±305; also appears in: C. Rich, R. Northern Illinois University, and a Ph. D. in computer science from Waters (Eds.), Readings in Arti®cial Intelligence and Software Northwestern University. Prior to joining UIC, he was with GTE Engineering,MorganKaufmann,LosAltos,CA,1986,pp.157±183. Automatic Electric at Northlake, Illinois (1978±1979) and AT&T Bell Laboratories at Naperville, Illinois (1982±1984). He is a member of [15] Luqi, Software evolution via rapid prototyping, IEEE Comput. ACM, Sigma Xi and Upsilon Pi Epsilon and a senior member of IEEE. 22 (5) (1989) 13±25. His current research interests in software engineering include software [16] Luqi, M. Ketabchi, A computer aided prototyping system, IEEE process and metrics, object-oriented technology, and distributed real- Software 5 (2) (1988) 66±72. time systems. He is also working on the critical issues in distributed multimedia computing with applications in Internet-based collabora- [17] Luqi, V. Berzins, R. Yeh, A prototyping language for real-time tion technologies. Luqi is a professor of computer science at the US software, IEEE Trans. Software Eng. 14 (10) (1988) 1409±1423. Naval Postgraduate School, Where she chairs the Software Engineer- [18] B. Kraemer, Luqi, V. Berzins, Compositional semantics of a real- ing program and leads a team producing highly automated software time prototyping language, IEEE Trans. Software Eng. 19 (5) tools, including CAPS (Computer-Aided Prototyping System). She worked for the Science Academy of China, the computer Center at the (1993) 453±477. University of Minnesota, and industry. Since receiving a Ph. D. in [19] U. Pletat, Algebraic speci®cation of abstract data types and CCS: computer science from the University of Minnesota, Luqi has super- An operational junction, in: Protocol Speci®cation, Testing, and vised more than eighty graduate student theses. She headed ®fty Veri®cation, Elsevier, Amsterdam, 1986. software R&D projects and hundreds of technical papers. She has received support from many organizations including a Presidential [20] C. Rich, R. Waters (Eds.), Readings in Arti®cial Intelligence and Young Investigator Award from the National Science Foundation and Software Engineering, Morgan Kaufmann, Los Altos, CA, 1986. the 1997 Technical Achievement Award from the IEEE Computer [21] R. Steigerwald, Luqi, J. McDowell, CASE tool for reusable Society for her research on the enabling technologies for computer- software component storage retrieval in rapid prototyping, aided prototyping of real-time systems. In addition to chairing or serving on the program committees of more than forty conferences, she Inform. Software Technol. 33 (9) (1991) 698±706. is or has been an associate editor for IEEE Expert, IEEE Software, the [22] D. Wile, Program developments: Formal explanations of imple- Journal of Systems Integration, and Design and Process World. She is mentations, Commun. ACM 26 (11) (1983) 902±911; also appears a senior member of IEEE.